ENTRY3603

Identification Info

Kind:

Sample

Type:

ENTRY

Registrator:

fabian.plass

Registration Date:

2023-07-21 10:40:52.579376

Modifier:

fabian.plass

Modification Date:

2023-07-26 12:12:41.749293

Parents

ENTRY743

Children

ENTRY3604

Properties

Name:

Results

Document:

Results

 

4.1. Features of openBIS as ELN-LIMS system within CRC 1411
 

As openBIS is accessible for users via a web app, accessible even from outside the university network, access to the user’s own data and data provided by others is guaranteed always and everywhere. It is not only crucial to be able to create and implement (meta-)data, but further enables the function that every user can permit access to its projects to selected users. This covers different roles (observer, user, admin) with different rights like reading, writing or even deleting. The authorization process lies here completely in the hands of each user and can be adjusted independently – with respect to other users within the network or other projects by the same user. In general, openBIS has a predefined hierarchical structure, which is divided into several levels: The first and overall level is the Work or Data Space level, which, in addition to general rights and access, primarily contains all Projects, and the second level, which means the projects themselves. These, in turn, have for example Collections (third level), which in turn consist of different Object Types (fourth level), with/without Datasets (see also Figure 1), like Experimental Step, Entry or Instrument(Bauch et al, 2011). This is also valid for Collections. In fact, the first and second level are hardcoded, which means that due to the persistent identifier only one specific path with the nomenclature “/user(workspace)/projectx” exists.  Moreover, following our example, we can move Collection 1 with all its containing entries to Project 2, but not vice versa. Moreover, object types (like OBJ 3can be used by collections several times, as stated in Figure 1. This in fact reduces redundancy.

 

Figure 1. Logical structure layers of openBIS containing the Work- or Data space, Projects, Collections, Object Types (OBJs), and attached Datasets (red). This figure is adapted from Barillari, C., et al. (Barillari et al, 2016).

 

Limitations like a maximum of users working one openBIS ELN system are not existing. The only limitations are connected to the available and used server resources. It can also link data on samples, materials, instruments, and experiments, since a good ELN-LIMS system to increase the findablilty. Here, openBIS features the parent-childrenrelationship model (see also Figure 2 for further detail): This means that every created Object type is somehow logically interconnected between other Object types. As an example of our CRC, synthesis and characterization groups are trying to develop specific and well-defined particles considering different synthetic samples, materials, and processes. To ensure that the creation, modification, or deletion of any electronic records is traceable, computer-generated, and time-stamped audit trails are used to record the date and time of the user’s intervention. As an example, to create an Experimental Step X and Y (see also Figure 2), the researcher/user requires a different amount of Samples A and B, as well as one specific Instrument I. Moreover, for a specific Simulation Z, one uses Sample B and Software S. Here, Sample, Instrument, Software, as well as the Experimental Step and Software or later on Publication are all different created Object types that are accessible and existing for every user of our openBIS system. Furthermore, all Object Types within our system are classified into three different categories and differ if they are generalized entries (Entry and General Type), experimental procedures or analysis (like Experimental Step or Simulation) or properties and (real existing) objects (like Instrument or Software). In our basic examples, it is valid that Sample A and B, Instrument I, and Software S are all parents of the Experimental step X, Y, and Simulation Z, respectively, which are automatically the child(ren) of the prior Object types. If we now create an Object type Publication P, which is linked and fed via our Experimental step X, Y, and Simulation Z, then accordingly, P is the child of X, Y, and Z, and vice versa. This results in a clear and well-understandable line of ancestry, which fulfills the FAIR concept. In our example, even after publishing (Publication P), one can clearly find and reuse 
(meta-)data of the corresponding project. Moreover, one has not to create object types (and their underlying (meta-)data) multiple times, as one can reuse them, if needed, infinitely. This can save not only a lot of time, but also leads to the possibility to create and implement a more comprehensible laboratory and research system. 

 

Figure 2. The hierarchical structure of the parents-children relation in action. Every object type (for example Sample, Experimental Step, and Publication) is child and parent depending on its ancestry relation. In our example, Publication P is child of every other object type like Instrument I or Experimental Step X

 

OpenBIS can also be used not only in labs, but also for administrative and lab-specific workflow processes. To understand how, we have to take one step back and need to consider how openBIS works from each user’s point of view of. First of all, every user possesses its own Workspace, which can be compared to its own desktop or computer storage. Within this Workspace, it can create and adjust projects, metadata, etc., without necessarily being connected to other users. This is possible using the Manage Access option, a function, which allows you to simply grant access to those users within the system, who should be allowed to read and/or write and/or delete information in your project. All now permitted users will appear as folder icons below the own Workspace folder icon. However, one researcher or user is connected to a specific working group or institute containing several other researchers/users. Finding a way to bring the entire working group together without repeatedly pressing the Manage Access button and effectively defining user roles is a key consideration. Especially for general administrative or instruments within the institute, which are accessible for every researcher of the corresponding group, creating for example several Instrument object types is not only time-consuming, but also hold the danger of creating different metadata for the same, here exemplarily, instrument. This would result in problems with the FAIR principle.

Moreover, openBIS includes an additional working area called Inventory, which serves as a "common work environment" for user-groups to access information and data stored within this section. This area houses data and information that is universally relevant or of interest to all users or larger groups, and it contains spaces for the CRC, such as an openBIS on-boarding or a common folder. Furthermore, we have made further adjustments to the Inventory section by implementing sub-Inventories that are specific to the working groups/institutes within our CRC

These different spaces, including the Inventory and our institute-based Inventories, provide fields for collaborative projects and administrative workflows, offering a general and overall usage area, along with a sub-Inventory containing commonly used, institute-dependent instruments, materials, etc. With collaborative used Inventory, each user has access to collections of items like Instrumentation, where necessary object types (e.g., Instrument I1, I2, ...) are created once and can be utilized by any user within the workgroup (those with access permission to the specific folder of the Instrumentation section). The same concept applies to collections of samples or documents/protocols, which are employed in large collaborative projects.

By following the principle of the parent-child relation depicted in Figure 2, we ensure that instruments (e.g., Instrument I from our example) within an Instrumentation folder can now be used for tracking as part of the Inventory folder, while avoiding redundant information and directly providing the required documentation. In fact, like this, it is possible to combine a classical working group environment with interdisciplinarity and FAIR data management within an overall framework. 

 

4.2. openBIS as a multi-institutional framework within a material science-based environment – Adjustments and Experiences 

 

This multi-institutional framework can now be implemented and customized to your own needs. Via an additional overlay (Core UI), the implementation of different object types (from simple general types to specifically customized types) is possible. The implementation process will involve questions regarding the number and types to be implemented. It needs to be clarified in advance whether more specific and fine-tuned types are preferred or not. In our case, we shifted from specific object types (as the pre-defined openBIS system for a bio-medical environment provides with, e.g., bacteria, yeast etc.) to more generalized object types such as sample or simulation, which are usable in an interdisciplinary environment by multiple groups at once. We decided to use openBIS as foundation or “hollow” version, while winnowing object types that exist by default, but may be not required in our digital illustration of our CRC -based workflows, and to develop new ones using our own CRC-based ontology, accordingly. To achieve this, we decided to form a pilot group for all users within the CRC 1411 about six months before handing the openBIS system over to the entire group. Since our interdisciplinary working environment consists of different disciplines, from pure particle synthesis to their characterization, analysis, simulation, and theoretical optimization, we invited about fifteen people from the different working groups/disciplines and implemented, discussed, and modified our preliminary system up to this point, so that everyone was satisfied with the result. It turned out that implementing dozens of different and fine-tuned object types for each user, while appearing functional at first sight, also brings some disadvantages, because while each (overall) object type is visible in the drop-down menu, not every object type is used by every user. For example, theoretical scientists, who use mathematical models to simulate and predict physical properties of potential nanoparticles, rarely use synthesis-based object types like General Protocol or Experimental Step. This means that any user from a particular discipline will only stick to the types that are useful for their own research. Furthermore, since each type is always present in the system's drop-down menu, it quickly becomes cluttered and confusing, leading to poorer usability and, consequently, a less accepted package. So, this should be avoided. Therefore, we finally decided to use only eleven object types, two of which (Entry and Experimental Step) are already preset by the developers, while eight types contain specific (meta-)data and one which is defined as an overall or general object type (General Type). 

Meeting requirements, such as scientific or administrative needs, that may exist within the same discipline can be a challenge. Again, our implemented multi-institutional framework could help. Now, that each workgroup/environment has its own "space" within the overall openBIS system, it is possible to implement specific "workgroup-defined object types". For example, in our CRC 1411, synthesis and processes can vary between workgroups, so implementing finely tuned objects, which can only be used by users within that workgroup or users with access privileges, is preferable. Furthermore, there are no negative effects, such as usability on interdisciplinary work or traceability of (meta-)data, since, within the entire openBIS system (and users with access rights), the new (and now workgroup-specific) types can still be viewed. As a result, this leads to a balanced combination of a universal and well-usable openBIS data management system and a well-tailored work environment. 

 

Figure 3. The current joint venture project within CRC 1411 involves collaboration between synthesis (project process related to the red arrow) and theoretical simulation (project process related to the red arrow). The "real" scheme (hierarchy graph) in (a) provides a comprehensive representation of complete process workflows during this cooperative project. For better clarity and visibility, we have filtered and shortened (a), while (b) illustrates the proposed structure of our CRC in relation to the joint venture project between our synthetic (red arrow) and theory (violet arrow) research groups. Both the proposed (b) process structure and the implemented (a) structure exhibit similarities even though (a) is more complex overall.

 

Now each user can edit and share their own data, both scientific and non-scientific in nature/origin, with themselves or with other users within the openBIS system by creating and storing data and metadata that can be exported in turn. The reasons for this can be quite different: More and more journals are demanding that special attention needs to be paid to Open Science and research data management, e.g., by using a data repository to which publication-specific (meta)-data must be uploaded and made freely available to all. In some journals, for example, it is common to prepare a data availability statement when submitting the publication. This statement includes information about the data itself, where to find it, an identifier for the data (DOI or persistent identifier), and how to access the data. The function used for re-exporting stored and listed (meta)data is the Export Metadata & Data function. The openBIS server now plays the role of a kind of e-mail distributor. That is, openBIS exports the project folder selected by the user as a .zip file, which now contains all (meta)-data, as .txt, .doc, .html, and .json files, as well as the introduced structure by the researcher and the system. In fact, the system uses a terminology adapted for our workflows within the CRC. This means that the default syntax and terminology of our openBIS system, along with the modifications and additions made to display workflows for various research areas within our CRC, will be included in the .zip file. The management of the researcher’s data will therefore also be displayed in the folder.  Since each user has its own account in openBIS, the user can send the exported file to others directly to their e-mail inbox via a download link, with no data (size) limitations, by entering their e-mail address. This .zip file can now be attached to a publication as Supplementary or Supporting Information or uploaded to a data repository, and the DOI thus obtained can be noted in the actual publication. This closes the entire research data management data lifecycle, from project inception through data production and analysis to long-term archiving. Moreover, as stated above, the pre-structured organization of your project(s) on openBIS (and via the Object types) stays the same after export and may be re-imported by writing a parser to another ELN system, e.g. openBIS. That means that no additional structuring process is needed. Furthermore, after implementation of the gathered publication or research papers that have been published under the CRC 1411 roof, we track all of them via openBIS now as well. 

As mentioned at the beginning, the ELN-LIMS system openBIS@CRC is designed to adhere to FAIR principles. This is evident in various aspects of the system. Firstly, the data stored in the openBIS database can be easily found through persistent identifiers and a search function. Additionally, the data is easily accessible via the internet without the need for a virtual private network (VPN), allowing users to access the webapp from anywhere. The system is also interoperable, allowing external and internal scripting to interact with the data. Moreover, the data and metadata can be exported, making it reusable. Alongside the FAIR principles, the system also promotes good scientific practice and follows the data management lifecycle, covering aspects such as documentation, tracking of projects and data, and archiving. Collaboration is facilitated through role management and the availability of separate workspaces for individuals and working groups within openBIS.

 

Figure 4. The depicted view represents the graphical user interface of openBIS from the researcher's perspective. The top-left section clearly displays the hierarchical folder structure shown in Figure 1, while the right side allows the researcher to fill in relevant metadata and connect it with the corresponding raw or processed data, as shown in the bottom-left part.

 

Our current openBIS system has been up and running since end of December 2021, but we are still testing new features and making minor and major changes. Following the rollout of the "final" version of the openBIS system to our users within the CRC 1411, we have organized several introductory events within our iRTG (integrated Research Training Group). In addition, we host monthly support meetings where questions or comments can be brought forward, and support is offered. Furthermore, we did not want to develop an exclusive data management system, so young research students, e.g., in the context of their Bachelor’s or Master’s thesis, will have access as new users to get in touch with research data management. In addition, the existing benefits for students and their supervisors or research colleagues remain, so sluggish use of our openBIS system has not really been the case, even in the early days, immediately after the roll-out. Rather, the purchase of lab notebooks/tablets has increased the adoption of openBIS, as data creation, processing and sharing within the labs is now very fast and easy. The use of paper-based laboratory notebooks has been decreasing significantly over time.   

However, our CRC aims to expand the capabilities of the ELN-LIMS concept in the future. As described in section “3.1 Current situation, methodology, and strategy”, our vision of a virtual research environment includes integration of data repositories like Zenodo, enhanced visualization options including AR/VR technologies, and post-processing tools for stored raw data. This can be achieved through Python scripting using openBIS's internal API, enabling the implementation of scripts and other post-processing functionalities. The flexibility and range of possibilities offered by openBIS played a significant role in our decision to select this ELN-LIMS for our CRC.

One specific example of collaboration and post-processing within our CRC involves the implementation of a script for color calculations of nanoparticles. This script will assist our synthesis groups in developing nanoparticle synthesis routes even before they begin their experiments. By utilizing the openBIS server, the synthesis groups can directly access the theoretical calculations typically performed by our theory groups, eliminating any time delays. This iterative process of development, deployment, implementation, and utilization accelerates research within our CRC and highlights the value of the openBIS ELN system. Furthermore, we are planning to integrate a Jupyter Hub system with our openBIS@CRC system in the future, providing researchers with additional post-processing and scripting options within our environment.