Long-term Data Management
Updated
It is understandable that PIs want to have continued access to, or ownership of, work produced in their lab. Researchers and team members may come and go over time, and in science, it's often important to build upon past work, access legacy data, or reproduce the results of experiments performed by people who may no longer be part of your lab. RSpace is designed specifically for this purpose.
A list of LabGroup members is displayed in the LabGroup management page for your LabGroup. When someone leaves your organization, their account is usually disabled by your RSpace System Admin. Disabled users are automatically moved to a new section in the PI's view of the LabGroup page called "Disabled Users". Disabled users can no longer log in, but their data can be permanently accessed exactly as before, as long as they are not removed from the LabGroup.
In many cases, since it is easy to see the data of former lab members by default, when a LabGroup member leaves, no further action may be necessary. However, be sure to consider some of the options and best practices described below.
The example below shows a single Disabled Account. Over the years, it is likely that the number of disabled users will grow. Eventually there may be many fromer LabGroup members listed, perhaps more even than your list of "current" LabGroup members. Note that in this image you can also see that the PI has access to an "Export Work" button for each user that they can use to easily get a copy of all work by that user.
If necessary a user can be removed from the group list by clicking the Remove button. Depending on your LabGroup organizational structure, the user's former PI may no longer have access to that work once a user is removed from their LabGroup, however, the user's work continues to be stored on the system for as long as it exists, and remains accessible to the sysadmin and perhaps other colleagues if, for example, they have moved to a new LabGroup. The sysdmin can add the former user BACK to the old LabGroup if necessary (e.g., if a PI clicks "Remove" by mistake), or the System Admin can choose to add the disabled user to any other Group to grant access to the former user's data.
Alternatively, a copy of ALL the user's work, or perhaps just some parts of it (e.g., important work located in a specific shared folder or subfolder) can be exported and imported back to the account of some other user. See "Transfer using Export - Import section below".
Reorganizing data of former users
It's a good best practice for PIs to meet with departing users to review the following:
• Settings for shared data and permissions so that future access is optimized. If necessary, PIs can ask their RSpace sysdmin to assist with adjusting the sharing schema and/or access permissions for former users who are no longer available. The System Admin can do this using the System tab > Operate As feature.
• Reorganization of the work if necessary. One common scenario for "reorganization" via moving and selective sharing is to adjust the access of legacy work located in shared notebooks owned by a former user such that the same work will also appear in a newer notebook owned by someone else who has taken over that project. Another strategy might be to unshare ALL work by a departing user, and then use autoshare to reshare it to a single named folder named after the user who has left, so that all of that user's work is available with read-only access in a single location. You can fine more information about various data sharing and management scenarios here. If you forget to ask a user to reorganize work when they leave, you can ask the sysdmin to do it using the System tab > Operate feature.
• Export options for the departing user. The user can visit the My RSpace Export-Import page and use "Export all my work" to get a copy in an appropriate format (s) to take with them or to leave with the PI as appropriate.
Transfer using Export - Import
Users (or their PI, or the sysadmin) can also EXPORT a copy of user's data as XML and then reimport it to a different account, (or even a different server). This method may not be ideal though, because it generates a new copy of the data. Generally a good best practice in RSpace is to avoid creating multiple copies of work in the system whenever possible so that you don't later have to deal with ambiguous duplicate results when you use the RSpace search tool to relocate the work, although sometimes this may be unavoidable.
