A general uncertainty regarding which data to store, e.g., raw vs. processed files, and how to organize the stored data was reported, especially due to a lack of guidelines in this area. Thus, doctoral researchers often establish their own individual directory structure, documentation practices, software tools to use, file and sample naming conventions, and workflows. While this works for the individual in the short term, establishing a holistic data governance within a research group planning phase enables wider collaboration as it provides structure and guidance. Proper data organization, first and foremost, ensures that those currently working with the data can do so efficiently. Furthermore, it enables others to easily understand and therefore reuse or build upon the data, from future doctoral students in the same group to external researchers with whom the data may be shared.

Starting in the planning phase of research, it must be determined where to store data and how this should be structured. A common practice, observed during exchange with researchers, is for the individual to sort data in a folder bearing their name. However, creating common, structured folder templates for each project and storing data accordingly—instead of associating it with the person conducting the research—ensures the data can be correctly found in the years to come. Central, shared storage options, such as institutional servers or rented server space from the university’s central service providers, are recommended, while access to individual folders is controlled on an administrative level.

It must be clear to all group members at what stages research data should be saved. For example, as with the cases outlined in Section 3.3, certain IR devices produce raw data in proprietary formats, while exported data may be used to continue work on the researcher’s computer. Raw data may not be transferred as it cannot be opened without the device software. However, best practice is to always store raw data, even if in proprietary format, in read-only folders within the given directory structure.

These agreed upon practices and structures should be documented in a group-wide DMP as well as plain-text README files contained within the directory structure for easy reference. Further data policies and on- and off-boarding checklists ensure data are transferred smoothly from one researcher to the next.

This planning and documentation does not stop with data organization and storage, but should also include other aspects that will arise in data production and analysis, such as data exchange formats for storage as well as preservation and reuse, documentation tools and standards, as well as data archival and publication platforms to ensure preservation, access, and re-use, the specifics of which are discussed in the following.

In this phase, clear documentation of the processes and data-producing methods also proves useful to better understand where improvement may be required. For example, a group-level project can fully assess the status quo to determine where data workflows may be improved and where external help may be required,

These efforts not only aid in managing research and the corresponding as a group, but also provide a reference for (external data) stewards or data managers, e.g., those involved in INF projects, while providing contextual information for data publication.

As noted, doctoral researchers often individually establish documentation practices. In turn, it was often mentioned, that understanding a predecessors’ data and work proved difficult. This indicates that common, group-level documentation standards need to be established.

Using the above SRFM case as an example, the raw data obtained from the device does not necessarily contain all relevant measurement parameters. For IR, raw data files cannot be opened without the device software, while full etadata are not exported with all available data exports. Thus, as a bare minimum, establishing templates and even metadata schema in text-based formats such as YAML or JSON provides a simple, machine and human-readable format that may be filled out for each dataset. Such files can then be stored directly alongside the data to give a digital metadata record. This practice may be extended to digitally record and document research, thereby documenting agreed-upon minimum information for an experiment, measurement, or sample, and by following existing community standards, where available. These templates should be established in the planning phase of the research data lifecycle and updated, when necessary, throughout the data production and analysis phases (see Figure 6).

Up until here, this and the previous section cover very basic data storage and management that does not employ any specialized tools or infrastructure, besides a well-managed central storage, defined directory structure, and documentation using agreed-upon templates. This provides group members, especially junior scientists, with the basic framework to operate in an efficient and organized manner, while producing transparent results that are (re)usable by other current and future research group members. However, sophisticated tools and platforms exist, and are being continuously updated and improved, to further assist researchers in effective research data management.

In many natural sciences, the laboratory journal stands as the staple of research documentation. However, analog journals are not machine-readable and do not necessarily follow uniform documentation standards. Digital counterparts, ELNs, offer a powerful solution to documenting research in a digital and structured manner, while also managing and connecting the associated research data. These platforms exist with a wide variety of styles and target user groups, from the more synthetic chemistry focused Chemotion ELN [13], [14], [15] to the broadly customizable eLabFTW [16], [17]. One group within the CRC transitioned to Chemotion ELN after the survey had been conducted, while limited use of eLabFTW was reported, yet in a rather individualized manner. Proprietary solutions such as FURTHRmind and mbook were also employed. Many CRC members reported using analog journals or solutions such as MS Word and MS Excel files, as noted above.

For ELNs, it is important to continue to follow data organization and documentation best practices. While some ELNs, such as the Chemotion ELN, strive to adhere to minimum information standards for supported methods, highly customizable instances or unsupported methods require high-level organization from within the group or institute. As with the templates outlined above, groups or institutes should agree on the information to record for their experiments and create templates for the ELN. eLabFTW, for example, enables custom metadata and allows for the creation of experiment templates. Chemotion has recently also expanded to include LabIMotion [18] which enables custom modules for non-chemistry or not yet included methods. Therefore, an ELN must be centrally managed and documented within the group, analogous to the basic data organization and storage outlined above. This not only includes providing templates and usage guidelines, but also training group members on ELN use.

For the examples, the IR use case involves a research group that employs the Chemotion ELN. The ELN offers direct connections for many methods, including IR, which directly transfers data and attaches it to an experiment [19]. It also offers ChemSpectra to edit the analytical data [20]. These methods extract necessary metadata to complete the documentation, ensuring documentation, research data as well as the analysis are bundled in one place.

For the SRFM use case, eLabFTW is available, which allows for structured metadata templates to be established within experiment templates. Since not all relevant metadata are captured in a given measurement, researchers can employ such templates to document their research and manually enter any missing information. However, as opposed to IR, attaching SRFM data to experiments within the ELN is not viable due to size limitations. Therefore, creating meaningful links to the data within the documentation proves helpful.

For cases such as this, where increased storage is required while metadata management is at the forefront, the RWTH Aachen IT Center has developed Coscine (short for Collaborative Scientific Integration Environment) [21], [22]. This platform primarily aims to organize and manage working research data in ongoing projects. On a group level, Coscine offers various storage types, called resources, with a storage quota of up to 125 TB per project for participating universities or groups involved in NFDI-related projects. Custom metadata application profiles can be generated to fit group needs, which result in a fillable metadata form that includes metadata validation for input values. Data within a project or subproject is organized into resources, each of which has been assigned a specific application profile and a PID in the form of an ePIC [23], which leads to a contact page. Therefore, groups can customize their data documentation and storage structure to fit their needs and incorporate community-specific minimum information standards. Details pertaining to the collaborative aspects of this platform will be discussed in Section 3.3.4.

Both eLabFTW and Coscine offer a Representational State Transfer Application Programming Interface (REST API). Such interfaces allow for information to be exchanged between the platforms in an automated manner. Therefore, to maintain the local documentation using the ELN while maintaining a connection to the associated raw and processed data, a Python script on the device computer can transfer the measurement data to Coscine, while a link is added within the ELN entry. Metadata from the ELN is then also mirrored in Coscine.

Similar templates workflows may be setup for different methods to ensure the datasets include complete documentation for all methods employed within the group. Working from a basis of well-structured and well-documented data organization, including governance and research data documentation, established during the planning phase and implemented during the data production and analysis phases of the research data lifecycle (Figure 6), provides the foundation for RDM in collaborative projects. Maintenance of these practices and proper onboarding of group members ensures adherence and avoids uncertainty.

Vendor software typically directs data formats for output data, which may be proprietary. Interoperable data requires open and standardized data formats, which do not (yet) exist for every method [24]. For many methods, open export formats such as TEXT and comma-separated values (CSV) were reported, however, the associated metadata may be lost or incomplete upon export, as indicated for IR, for example. Furthermore, while these formats may be machine-readable to a certain extent, they are not necessarily machine-understandable as they lack a defined structure and semantic annotation.

As standard open data exchange formats exist for certain analysis methods within the CRC and since many of them were not mentioned in the survey responses, we gathered recommendations and summarized these in Table 1, sourcing information from FAIRsharing [9] and NFDI4Chem’s Knowledge Base [11], as well as the Chemotion Repository documentation [25].

This information has also been shared on the CRC 985 SharePoint along with the method information outlined above. Gathering this information specifically arose from communication over the common misconception that data should always be stored and published as CSV or TEXT files. Other options exist, may even be supported by vendor software, and simply lack awareness.

The existing standard data exchange formats listed in Table 1 provide guidelines on formats to choose from, while recommended standards and common formats are highlighted in bold font. The exact format choice for each method will depend on available software and export or conversion tools and also the format data types specific repositories will accept for publication (see, for example, Chemotion Repository requirements in [25], [38]).

Notably, many methods do lack specific standards, for which the above-mentioned practice of documenting data appropriately and sharing data along with the associated metadata in open, text-based formats is advised. As the various efforts such as the NFDI consortia continue their work, more standards will become available. Furthermore, minimum information standards will continue to direct how data should be formatted and documented, further guiding format standards. Table 1 as well as the published overview [8] serve to inform the standards and infrastructure community on which formats researchers are employing in their day-to-day work and where standards are lacking.

For the example case IR, as the connection can be made to Chemotion ELN, the data should be exported to JCAMP-DX as advised by not only the Chemotion Repository as denoted in Table 1, but also the Chemotion ELN to allow for automatic data transfer. This format was not reported, yet it is supported by the vendor software. For SRFM, OME-TIFF may prove beneficial by adapting an instance of Omero on an institutional or university level [39]. Without this option, TIFF files are appropriate. Connecting the documentation and data management, as described, ensures full metadata annotation, especially since Coscine enables semantic metadata.

As with data organization and documentation, data exchange formats must be agreed upon as part of the planning stage of the data lifecycle (Figure 6), communicated within the group, and updated as more standards become available.

Up until now, the discussion has focused on the group level. Having a well-documented approach to data organization, documentation, and the tools used helps in identifying how collaborative projects such as CRCs and the contained subprojects can best manage data.

The CRC 985 INF project addressed sample tracking throughout a collaborative project involving many different groups and institutes in previous funding periods [1], as described in Section 1. This system aimed to solve a specific problem with sample traceability within the project, while enabling project members to directly attach associated data to a (digital) sample. In this funding period, the system was further improved. As such, metadata fields for better sample tracking were added, enabling users to define who initially created the sample and who was currently working with it. The main view was altered according to user feedback to only show the most relevant information. This enabled researchers to better find relevant samples and data.

However, as shown in Figure 4, some research within the CRC may not involve physical samples, for example, computational chemistry methods such as molecular dynamics. Furthermore, SharePoint relies on database storage that cannot accommodate larger datasets. It is therefore not suitable for methods with large (raw) data output, e.g., SRFM and numerical methods (see Figure 5). For these cases, other systems can provide the necessary solutions. It should also be noted that the metadata describe the sample rather than any attached data, and therefore would still require external documentation to fully describe the dataset belonging to the sample if not included directly within in the files.

A central ELN instance, that is used by all the members of the CRC, could provide one solution, yet, this did not prove realistic in this CRC for multiple reason, from varying user and group needs to the lack of a centralized solution offered by the university. As individual groups and institutes have indeed implemented ELNs, exchange formats between these could assist in collaborations in such projects. This is a central goal of the ELN Consortium [40], which currently involves ten ELN providers, including Chemotion ELN and eLabFTW.

The RDM platform Coscine, described in Section 3.3.2, is intended for collaborative work- Roll management occurs on a project level, therefore, members can be given access to their respective subproject, with all data relevant to the project collected and documented in one place. As described, a REST API allows for automated data workflows, e.g., between local servers or ELNs and Coscine. As such, metadata, data, and identifiers may be mirrored between platforms, giving members a working-group agnostic option. As outlined for SRFM, its large storage capacity assists researchers where institutional servers or systems that rely on a database structure such as SharePoint and some ELNs reach their limits. As such, it has been employed within CRC 985 not only for SRFM, but for computational chemistry data as well as tensiometry.

An example of such an automated workflow would be transferring measurement data from a folder on an institutional server, such as a device computer or research group server, to a central RDM platform such as Coscine. A script would, in a given time interval, check for new data, parse the file for relevant metadata, and use the Coscine’s API to transfer the individual files and assign metadata in a structured manner. Thus, the data becomes available for project members on one centralized system in an automated manner, while similar workflows can pull relevant data from Coscine to their local storage and RDM solutions.

Implementing solutions that employ such interfacing options require scripts or programs, or even software development for more complex tasks. These should be maintained on a system such as RWTH Aachen University’s GitLab instance to facilitate access and collaboration. It should be clear what resources are available, aside from the API itself, such as networked computers and other available hardware, and who is responsible for deploying and maintaining these systems within the research group or institute. Staff with development skills may also be required, depending on the complexity of the solution. Due to updates in a given software’s API, updates to technical implementations may be required.

Aside from facilitating research within groups as well as large projects, the aim to make data reusable according to FAIR also includes making the (meta)data available to others while describing how to access the data (Figure 6: Access and Re-Use). Therefore, a data policy was established during the second funding period [1], which stipulated that all data underlying a published journal article should be published as well.

Various options exist for such publications, with the three common categories being: (1) institutional repositories, (2) general repositories, and (3) community-specific repositories. Where possible, community-specific repositories are preferred, as these are able to provide detailed metadata templates, enabling researchers to fully describe the published data. When using general or institutional repositories, adding as many (optional) metadata fields is best practice, while providing plain-text files for additional metadata and context. As institutional repositories may be used for reporting purposes, importing published datasets is also important, analogous to text publications.

Within these categories, we make the following recommendations for data sharing and archival in CRC 985 and similar projects, outlined in Table 2, which completes the final objective of this study (Figure 7). These were selected according to the methods reported within the conducted survey, the institutes involved in the CRC, while recommendations by NFDI4Chem [11] were preferred. Information on file sizes has been included to provide a reference as to which repository may accommodate larger data amounts for methods producing larger amounts of data.

Certain repositories are also tied to ELNs, therefore providing direct data and metadata workflows. Going a step further, data may also be converted to standard open formats, as is the case with Chemotion ELN and Chemotion Repository, as mentioned in Section 3.2.

The published data should then be explicitly referenced via their DOI within the article using a data availability statement, which journals are increasingly requiring [62]. They may also be cited within the article itself. Especially in cases which involve multiple published datasets, this provides additional context for the reader.

As shown in Figure 5, much of the data volume falls into smaller sizes, with imaging and numerical methods requiring larger storage if all data were to be published. For these, the use of institutional repositories such as RWTH Publications Research data are the best option. For some methods, such as Atomic Force Microscopy, not all extracted data must be published, yet the scripts employed to do so could be. Hence, the data may be reproduced in the same manner when needed, while the published data volume is held to a minimum in cases where repositories limit quota. Otherwise, much of the produced can be published on subject-specific or general chemistry repositories without too much concern for data volume. Furthermore, repositories may offer more quota upon request.

In terms of data access control, most of the repositories mentioned offer embargo periods to ensure the creators’ first rights to the data. In addition, zenodo allows restricted access in cases where data cannot be made public.

As shown in Figure 8, RADAR4Chem has proven itself as a readily-accepted data publication platform, which may be attributed to its ease of use, the ability for data stewards to add standard pre-filled metadata, as well as the recently-added notification system, allowing the INF project to quickly respond to requests for dataset review. Institutional repositories found favor as well, as RWTH Publications is used for 34.5% of data publications. Again, ease of use, but also a certain trust in one’s own services could be a strong factor here. For those using Chemotion ELN, the direct publishing workflow to the Chemotion Repository considerably assists authors in the publication process. In the example case for IR data, automated workflows from the Chemotion ELN to the Chemotion Repository exist and enable simple data publication. Both the Chemotion Repository and RADAR4Chem guarantee storage and accessibility for 10 years or more, conforming with German Research Foundation (DFG) requirements; the data herein is therefore successfully be deemed archived, while it can also be accessed and reused in accordance with the research data lifecycle in Figure 6. RWTH Publications does not specifically list a time span, but considers items published as archived as well. It should be noted that the Institut Laue-Langevin carried out measurements for the CRC 985, the data for which is published on the associated data repository, as indicated in Figure 8. This institutional data repository was only omitted from Table 2 as only institutional repositories for direct participants were included. ‚ Typically, projects will amass more data than that, which has been published. This therefore requires additional archive resources. For project members in CRC 985, the above-mentioned Coscine also serves as an archiving space and may also be used where data access must be controlled. It should be noted, however, that while the dataset PID may be used in a data availability statement, the access restrictions should be stated. Furthermore, as the data has not been published and received a DOI, it may not be cited.

The entire SharePoint, including the sample management system, will be archived under the CRC’s Coscine project, while members can gain access to the system to archive their data as needed.