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 here 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 in XML format, 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 admin(s) can directly view a user's Workspace by default. 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:

In the main LabGroup sharing folder, documents can be shared into new or 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 in the main LabGroup_SHARED folder is therefore enforced mainly 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 shared folders or shared notebooks within a single LabGroup 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 "First 4 trials assigned to grad students" 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 Pione_SHARED folder (below). All users in the LabGroup “Pione” can access "First 4 trials assigned to grad students" and “experiment1”, 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, ALL members of the LabGroup "Pione" can see ALL content within the "Pione_SHARED" folder including the owner of each document, its unique ID, and its location within the shared folder hierarchy, as 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.

In this case, sorting work into shared folders or notebooks may be a useful way to segregate or organize work into projects, but it does not physically prevent ALL members of LabGroup "Pione" from being able to see the all work in the "Pione_SHARED" folder, even if they are not involved with the project "NIH R01GM987653 - Gene activation in NASH patients".

'PI one' can also see the project notebook that 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 and if necessary Change Group > Pione LabGroup details 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

Sometimes work needs to be more completely segregated so that only certain users can access it. In this example, the PI will use a totally separate LabGroup rather than a folder in their main LabGroup to be the defining container for a project.

Note that in RSpace Enterprise Edition, 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.

If "self-service" LabGroup creation is NOT turned on for your server, then the PI must contact their RSpace System Admin and request a new LabGroup for use with the new project.

If you are using RSpace Community edition, see instead Creating a New LabGroup.

In RSpace Enterprise Edition version 1.77 or newer, if "self-service" LabGroup creation has been enabled by the System Admin, than PIs can create new LabGroups without any need to contact the System Admin using the My RSpace > Create Labgroup tab. This can be especially useful for allowing the PI to create new LabGroups that can be used for scenarios such as:

• Creation of new project, where data is segregated and organized within the shared folder of that LabGroup, and access to project data is defined by the LabGroup membership.

• Creation of subgroups withn a large LabGroup.

• Creation of transient LabGroups used for specific purposes such as teaching a class, gathering data from various LabGroups for export as a single data bundle, or other collaborative or organisational scenarios.

In the example below, Pione has created a LabGroup (from 1.77 or higher) called "confidential project" with only 2 users. Both members can, if they wish, share documents into "confidential project_SHARED".

Once the new group has been created, the PI can see the following in the My RSpace > My LabGroups area. If necessary they can use Change Group > confidential project to see the LabGroup details page:

Only the two member users can see data shared into this LabGroup’s "confidential project_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 that document into the “Eunjyu’s Data” folder with edit permission, and asks Eunjyu to paste her contributions into that document. This allows the PI to retain ownership of project data, even if Eunjyu leaves the LabGroup. All edits are properly attributed to the correct authors regardless of who currently owns the document. In Tree view, Pione’s workspace view now looks like this:

Note that if Pione 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 manage a list of items 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 Pione 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-centric LabGroup. It follows that it is often important to decide who should be the owner of shared documents because although CURRENT access to the document is decided by how it is shared, FUTURE access may be decided based on the owner.

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 indelibly recorded in the system audit trails and this information cannot be edited or altered.

Note that when a standard LabGroup created by either the System Admin or a PI is used to define a project, the PI will be able, by default, to see ALL work of ALL of the Group members who are not PIs. For this reason, users should exercise caution when accepting an invitation to join a new LabGroup that comes from an unfamiliar PI. In general, this scenario is mainly intended for the creation of project-centric LabGroups or subgroups where all members are already supervised by the PI leading the new LabGroup. For projects involving members of 2 or more LabGroups with different PIs, a Collaboration Group may be a better way to define a project while still maintaining the privacy of other work not related to the project.

If the project-centric LabGroup was created by a PI using the "self-service" feature, then the same PI can delete the LabGroup when the project is completed. This will delete the SHARED folder for that LabGroup, but all work will still be available in the workspaces of the users who created the work.

The PI can also export all the work associated with the project (i.e the content of the LabGroup shared folder) for storage outside of RSpace.

3. Using a Collaboration Group to define a project

In this example, three PIs (real names: Jan Yi, Nadine Bissue, Franz Ferdinand) from three different labs (LabGroup1, LabGroup2 LabGroup3) need to jointly supervise work created as part of a single collaborative project called "ProjectX". However, it's important to all the PIs that although they need to see the work that is part of "ProjectX" they DON'T want their counterparts to be able to see ALL the work of the members of the collaboration who are not already under their oversight.

Steps required:

1) One of the PIs sends a "Create a Collaboration Group" message to the other two PIs.

2) The other PIs accept the invitation. This triggers the creation of the Collaboration group automatically called "Yi-Bissue-Ferdinand-collabGroup" and the creation of a shared folder called "Yi-Bissue-Ferdinand-collabGroup_SHARED" located in Home / Shared / CollaborationGroups.

3) Each of the three PIs can now invite specific users who they already supervise to join that LabGroup. The invitation must be accepted by each user before they are added to Yi-Bissue-Ferdinand-collabGroup.

4) Members of Yi-Bissue-Ferdinand-collabGroup can now select specific items from their workspace related to "ProjectX" and share those into the Yi-Bissue-Ferdinand-collabGroup_SHARED folder with appropriate read or edit permission.

Result:

All members of Yi-Bissue-Ferdinand-collabGroup can access the work associated with "ProjectX", but they cannot see other work made by members of this group unless they would normally be able to see that work. As with other LabGroups, PIs and appointed LabAdmins can organize work within Yi-Bissue-Ferdinand-collabGroup_SHARED into a suitable hierarchy.

When the project ends, PIs have the option to leave the Collaboration Group, or the System Admin can delete it. This will delete the SHARED folder for that Group, but all work will still be available in the workspaces of the users who created the work.

The participating PIs also have the ability to export all the work associated with the project (i.e. the content of the Collaboration Group shared folder) for storage outside of RSpace or re-import to a new location in RSpace.


How did we do?


Powered by HelpDocs (opens in a new tab)

Powered by HelpDocs (opens in a new tab)