Examples of Sharing Scenarios and Project Organisation
Here are some examples of how individuals and groups can organise their data. You can read more about how to share at Sharing Content.
Basic individual organisation in an individual's own workspace
Individual RSpace documents are arranged in each user’s own Workspace and can be manually organised by that user into folders and/or Notebooks. Project separation and organisational structure is defined and enforced entirely by the owner. A typical strategy is for top-level folders to represent projects, and within that folder, a user might place one or more notebooks, plus other sub-folders or RSpace documents as needed. If a user moves to a new lab, or exports all their data as .xml then imports it to a new RSpace server, the individual user's organisational structure of work in their own Workspace is unaffected.
Only the owner, the owner's PI, a properly authorized LabAdmin with view permission (assigned by the PI) and the system admins can directy view a user's Workspace. PIs and LabAdmins can view the user's Workspace by going into Labgroup records, which contains the Workspaces of all the LabGroup members:
The example below shows a user who has two main project folders they created in their Workspace shown in "List View". The folder "robert41 PHD work" contains three Notebooks and an RSpace document.
Locating the shared folder for a LabGroup
The main LabGroup Sharing folder contains:
- manually shared work from each user in the group, or
- all work, automatically shared using the autoshare feature
In the main LabGroup sharing folder, documents can be shared into existing folders or Notebooks by any user in the group, with the owner’s choice of either “read only” or “edit” access, but documents can be only moved or deleted by the PI or designated LabAdmins.
Project separation and organisation is therefore enforced by the folder/Notebook structure defined and enforced by the PI or by designated LabAdmins. All users who are members of the main LabGroup can access all folders and Notebooks in the main shared folder. For a lab with an open culture, the PI might choose to turn on autosharing for all members, so that all work performed in the lab is automatically added to the shared folder, with a named top-level subfolder for each user in the group, and all work accessible to all lab members.
In the example below we see how the user "robert41" can access the main sharing folder for the LabGroup they belong to called "Pione", shown in "List View".
Users can also access the same shared folder from the "LabGroup Records" shortcut as seen in "List View":
Examples of sharing scenarios and project organisation
1. Using a shared folder to define a project
Now let's look at what happens when a user wants to make a specific experiment they performed accessible to others using manual sharing. In this case, the experiment is part of a collaborative project called "NIH R01GM987653 - Gene activation in NASH patients".
The image below shows what robert41 sees in their own Workspace using “Tree View". There are 2 main project folders: The first contains a single RSpace document “experiment1”, and the second contains robert41’s PhD research, with 3 Notebooks used to record progress. Only robert41 and his PI can see Robert41’s Workspace by default. The PI in this group has opted not to turn on autosharing, but has asked robert41 to make “experiment1” accessible to other lab members via manual sharing (orange arrow).
When robert41 shares “experiment1” with the LabGroup “Pione” and places it in a designated shared Notebook created by Pione, then the RSpace document “experiment1” can now be accessed in two locations – one managed by robert41 in their Workspace (top) and the other managed by the PI in the Shared folder (below). All users in the LabGroup “Pione” can now access “experiment1” part of a larger project, as well as the related experiments 2, 3 and 4 which were contributed to the same shared Notebook by other users. In the image below the user has selected "Tree View".
Users with appropriate access can also examine the shared Notebook “First 4 trials assigned to grad students" in "List View" to see the following:
Note that in this view, users can see the owner of each document, its unique ID, and its location in the shared folder hierarchy indicated by the breadcrumb trail at the top of the page. It is also immediately apparent from the names in the “owner” column that robert41 has contributed the RSpace Document "experiment1", but other users have contributed the other 3 documents visible in the same shared Notebook.
PI one can also see the project notebook they shared in their own Workspace (below), as well as in its shared context in the Pione_SHARED folder:
The view above shows List view of Pi one’s workspace. Note that:
• An indicator next to the Notebook shows that it is shared.
• The organisational structure in PI one’s Workspace does not have to be the same as that in the Pione_SHARED folder.
• PI one has clicked the blue info button next to Notebook icon to see additional information in the info popup. The popup shows that PI one is the owner and that the Notebook is shared. PI one has also added the grant number to the caption area of the notebook for increased searchability.
At any time, PI one can visit the My RSpace > My LabGroups > Change Group > Pione page (or indeed, any LabGroup they lead) to verify membership. This makes it clear who has access to the work in the shared folder Pione_SHARED. From this view the PI can also click on the work folders of individuals in their lab to examine their work more closely (below).
2. Using a LabGroup to define a project
In this example, the PI will use a LabGroup rather than a folder to be the defining container for a project. Imagine that the PI called "Pione" wants to set up a restricted access project. First, the PI contacts their RSpace System Admin and requests a new LabGroup for use with a confidential project (if using RSpace Enterprise; see Creating a New LabGroup for Community). The SysAdmin makes a new LabGroup called "confidential project" with Pione as the PI and Eunjyu Yu as the only other member.
Note that in RSpace, the System Admin can create any number of LabGroups, and although sometimes these may be permanent structures, it is also possible to create and disband LabGroups at any time to represent more transient assemblages and collaborations.
Data is segregated in the project-based LabGroup and accessible to only these 2 users. The PI creates “placeholder document” in order to retain ownership of project data, and asks a contributing user to paste in their contribution. All edits are properly attributed to authors regardless of who currently owns the document.
Once the new group has been created the PI can see the following in the My RSpace > My LabGroups area:
Note that there are just two members. Only these two users can see data shared into this LabGroup’s Shared folder. The PI could invite additional members if needed. The PI now makes a sub-folder within the “confidential project_SHARED” area called “Eunjyu’s Data”, creates an empty document called “EJ confidential data” in their Workspace, shares the document into the “Eunjyu’s Data” folder with edit permission, and asks Eunjyu to paste her data into that document. In Tree view, PI one’s workspace view now looks like this:
Note that if the PI wants fast access to the folder “Eunju Yu’s Data” they can select that folder in list view and add it (or any other shared folder) to their favorites. For PIs with access to many shared folders or notebooks, “Favorites” can be a good place to keep a managed list of the ones that are currently of most interest.
In this example, the PI created the empty placeholder document “EJ confidential data” as a way to prompt Eunjyu to submit required data, but because the PI is the original creator and therefore owner of the document, the PI can later opt to remove Eunjyu from the LabGroup “confidential project” which will mean that subsequent work added to that project will not be visible to Eunjyu. However, the revision history for “EJ confidential data” makes it clear when and how Eunjyu contributed, even if she is no longer part of that project-based LabGroup.
To view the revision history, select “EJ confidential data” and click “Revisions” to see the document history.
The revision history is shown. Click “View” to see the edits performed by Eunjyu. Note that the attribution of specific edits to specific authors is also recorded in the system audit trails and this information cannot be edited or altered after the fact.