DMP information requirements in PaN facilities

We first introduce the DMP requirements in PaN facilities by giving an overview of research workflows, involved roles, and infrastructures. In this section, the requirements of data handling in PaN facilities will be explained by listing the general requirements given by facility data policies and requirements resulting from PaN specific recommendations on FAIR data.

Inside the PaN facility, a typical workflow for facility experiments that will take place has been elaborated in Matthews et al. (2012), where the roles and workflows in different stages of the research lifecycle in PaN facilities were analyzed. Typically, the first contact of a researcher with a PaN facility is the facility’s user office. The researcher must submit a proposal to request a slot for measuring time on a specific instrument provided by the facility. This is assessed for scientific merit and feasibility, and after the approval and scheduling of time on the instrument, the experiment will be executed. Then, the data will be generated, stored, and analyzed, and the results ultimately published (cf. Figure 1).

The major actors involved in the research lifecycle are listed below (Matthews et al. 2012):

• The Experimental Team: a group of largely external (e.g., university-based) researchers who propose and undertake the experiment.
• The User Office: a unit within the facility dedicated to managing external users of the facility. User Office staff and systems will typically register users and process their applications for beam-time, in addition to arranging their visit to the instrument.
• The Instrument Scientist: a member of the facility’s staff with specialist scientific knowledge of the capabilities of a particular instrument or beamline and its use for sample analysis.
• Research Data Managers: within the facility support the collection and curation of data and are becoming more prominent as this task gains importance.

During the different stages of the research lifecycle, these actors interact with various information systems supported in the facility. Depending on the different instruments, these information systems and roles will have to be considered when implementing a system that supports the creation of DMPs (cf. Figure 2).

Data curation, validation, and reporting have been identified as main goals to achieve with active DMPs, known as aDMPs (Bolmsten et al. 2021; Görzig et al. 2022). Validation comprises validation against the existing standards for the different PaN measurement techniques, but also validation against data policies. Reporting should be used to plan infrastructure usage in PaN facilities, as well as meeting funders’ requirements (Görzig et al. 2022). It is specifically stated that for data curation, information should be reused as much as possible, which can be done by also reusing pre-existing information available before a project proposal is even submitted.

Most PaN facilities in Europe have adopted data policies for their research data during the last decade. These data policies detail embargo conditions, open access requirements, access rules while under embargo, and the applicable licence for the research data (Wilson et al. 2011). Some facilities have updated their policies, integrated the usage of FAIR data, and included the obligation of DMP creation in their data policy (Götz et al. 2020; McBirnie et al. 2021).

Further, recommendations for minimal metadata within FAIR Photon and Neutron Data management have been elaborated in Salvat et al. (2020) and Soler et al. (2022). These recommendations are guided by the FAIR Data Maturity Model, or FDMM (RDA FAIR Data Maturity Model Working Group 2020) to prioritize metadata as essential, important, and useful. These recommendations are meant to concretize the information required for re-usability in PaN, on top of specifications in the FDMM. We give the information considered as essential and important for experimental data in PaN as follows:

Essential:

• Visiting experimental team (user id)
• Experiment date
• Sample information
• Instrument information
• Calibration information

Important:

• Experimental planning
• Environmental parameters
• Laboratory notebook
• Instrument scientist

Project management structures and phases

While the previous sub-section described requirements on DMPs and FAIR data in PaN facilities, this sub-section will introduce a project management method that will later be used to form a strategy for organizing information about RDM in PaN facilities.

PMBOK® (Project Management Body of Knowledge Methodology) helped to structure and phrase the description of our FDM workflow; it is a project management standard and reference of the US-American Project Management Institute, PMI (PMI 2013). In PMBOK®, a project is divided into five process groups: initiation, planning, execution, controlling/monitoring, and closing—creating a basic projects’ workflow. Here, we describe two key characteristics of the method used for the purpose of organizing information.

The first characteristic considers the availability of project knowledge, which increases throughout the project’s runtime and can be divided into four phases. There is initial knowledge; planning knowledge, which can be updated during experiment execution; knowledge generated during the execution of a project; and knowledge generated after a project when it is finalized. With the knowledge generated in the final stage, the organizational knowledge might be updated (Muldoon 2014). How project knowledge about RDM increases during the project’s runtime has been described in Giaretta (2015), cf. Figure 3.

While the first characteristic organizes the knowledge along the project’s runtime, the second characteristic organizes the knowledge by its origin and changeability. In PMBOK®, knowledge to be managed can be divided into: user/project knowledge; organizational knowledge, in PMBOK® called Organizational Process Assets (OPA); and general knowledge concerning laws, policies, and standards produced outside the institution, in PMBOK® called Enterprise Environmental Factors (EEF). EEFs are independent of the organization and evolve over the time, but are quite stable during a project. This knowledge is generated before a project starts. Organizational knowledge is generated in the organization independently from the project, and general knowledge is incorporated into organizational knowledge. Organizational knowledge evolves as instruments, software, and institutional policies change, for example. Organizational knowledge exists before a project is initiated (Muldoon 2014).

PaN RDM lifecycle and project management structures and phases

In this sub-section, information sources and phases for DMP information are described as they were analysed in Görzig et al. (2021). Then, we will explore how the aforementioned project management phases and structures can be used to analyze an update of pre-existing information on research infrastructure and normally created data.

Information sources for DMP creation related to DMP questions have been investigated in Bolmsten et al. (2021) and Görzig et al. (2021). The first paper defined a DMP template suitable for facility users modifying the questionnaire from the Research Data Management Organiser, RDMO (Michaelis et al. 2021), to adapt it to the requirements in PaN RIs. In the latter paper, this template has been reviewed, and suitable information sources for the answers to the questions in the DMP were identified and assigned to different phases in the PaN research lifecycle (see Table 1). The review of information sources shows that a high percentage of the questions could be already filled by reusing pre-existing information available before a project proposal is even submitted.

In the following, the lifecycle of pre-existing information with its rated roles, IT systems, and phases will be elaborated. Applying the knowledge sources and phases from Görzig et al. (2021) to the PMBOK®’s phases results in Table 2. Table 2 structures the information required for RDM in the PMBOK®’s phases with the additional phase ‘Before project’ and related roles. During the project phases initiation, planning, execution, and finalisation, the pre-existing RDM information is mostly used by project personnel to create or execute the DMP, and project specific information is generated, while in the before and after phases, facility personnel are evaluating information generated by the project and updating the pre-existing information collected previously.

The knowledge held by the data manager is mostly about standards, metadata schemata, and policies. Part of the information contributing to the knowledge is independent from the facility and evolves inside the scientific community, with funding regulations, or laws. This knowledge could be shared with other facilities and be classified as EEF. Examples are:

• Funder Policies including FAIR data requirements and Open Access requirements
• Laws like EU General Data Protection Regulation (GPDR)
• Scientific technique specific requirements on (FAIR) data
• General validation schemata for metadata
• Software for dataset usage

The data manager has an overview of e.g., how a specific standard is applied inside the facility and about facilities policies. The latter can evolve as facility’s internal discussions lead to additions and changes, and the knowledge can be classified as OPA. A detailed overview can be found in the next section (cf. Table 3).

The other part of an organization’s internal OPA is the information held by the instrument scientist. Here, the information evolves as changes to the instrument or software are made. Whilst the data managers have an overview about the standards and metadata used in the facility, the instrument scientists know which standards apply to the data measured at their specific instruments. The instrument scientist has knowledge about the typical characteristics of the datasets created by the instruments. A detailed overview can be found in the next section (cf. Tables 4, 5).

For some use cases, especially when automation and reproducibility are related, this information might be very detailed and underlie frequent changes. Therefore, this information often requires updates. How this can be supported by automation will be discussed in section 4.

The following section will focus on data modelling to store the pre-existing information that exists before a project starts and can be reused throughout various projects. The data manager and the instrument scientists are the main actors, holding information that exists before a proposal is submitted. Normally, the facility data policy applies to all projects and can be seen as a source of almost static, pre-existing information. Additionally, to the data policy requirements, other facility-wide guidelines and workflows can contribute to the pre-existing information held by the data managers. The instrument scientists have more concrete information about the instruments and the data they produce. The pre-existing organizational knowledge of data managers and instrument scientists will have to be connected and merged with information that arises during the proposal approval and execution of the experiment.

Data modelling

In this sub-section, data models for facility, dataset, experimental techniques, projects, and policies will be introduced, taking as a starting point the questionnaire discussed in Bolmsten et al. (2021) and Michaelis et al. (2021). In the questionnaire, entries from DMP phase 0 containing information existing before proposal submission were combined with entries where only the RDM team as a supporting source were selected. The following tables hold the most basic entities and their description.

Related ontology: Joining the information

In the next step, the entities described above will be related to each other by creating an ontology describing the DMP information concepts and their relationships (Görzig 2022). Apart from describing these relationships, the ontology will allow future integration with other ontologies and metadata schemata and facilitate the retrieval of information. Therefore, it will still need to be related to terms in standard ontologies. First, the dataset will be described, then the dataset will be listed, and then the project and policies.

DMP Support – Pre-existing information lifecycle – Knowledge transfer and (Semi-) automation

The pre-existing information should be used to pre-fill DMPs. Pre-filling of DMPs or semi-automated DMP creation has already been implemented e.g., at the Radbound University, where the DMP creation has been integrated to the CRIS system (Jetten et al. 2019); and ARGOS (Romanos et al. 2019), which pre-fills DMPs using repository information; and at the University of Vienna, integrating the DMP creation with various IT systems (Cardoso et al. 2021). In these examples, CRIS and data repositories have been used to pre-fill the DMPs. In this paper, pre-existing information from laboratory or instrument infrastructure (previously named Resources) will be used to pre-fill the DMP. To hold the pre-existing information that has been introduced earlier, in this sub-section, the lifecycle of pre-existing information will be presented. Firstly, activities will be shown that are required for the maintenance, usage, and exposition of pre-existing information that is stored in a central knowledge base. Then, the filling and maintenance of the central knowledge base and consequently the usage for DMPs will be described.

The lifecycle of the pre-existing information includes the phases: Before project (OPA/EEF), its initiation, planning, execution, finalisation, and after project (OPA). The central knowledge base will be used for projects’ DMP creation, exposition, and execution. Before a project starts, the central knowledge base needs to be filled with the required information. This information might have to be updated during and after the end of the project. Table 8 lists the phases and related activities:

In order to start filling the central knowledge base for the first time, datasets ingested into the data repository need to be analyzed and relevant information extracted. Relevant information to be found in the repository is: Data types produced at a Resource and their Formats; in case a standard is used, this can be extracted. Also, average quantity and sizes of files can be retrieved. In case standardised formats are used, metadata from the files can be obtained and eventually be related to Scientific techniques, File sizes and quantities. When creating a DMP, this information is frequently reviewed and can be updated in the central knowledge base.

When a DMP is created, project specific information needs to be provided. Therefore, firstly information can be acquired from e.g., the facilities proposal or other administrative systems. In a second step, dataset information from the selected IT systems can be requested from the central knowledge base and be concretized manually. The concretization can be based on e.g., option lists provided by the central knowledge base. In the ExPaNDS deliverable 2.4 (Görzig et al. 2021), the IT systems and roles used as information sources to create a DMP are listed. For creating a DMP, normally a DMP tool such as the Data Stewardship Wizard, DSW (Data Stewardship Wizard), or the RDMO (RDMO) are used. These two DMP tools have been analyzed in the ExPaNDS deliverable 2.8 (Görzig et al. 2022) for having a central data structure. This central data structure is used to allow separate views for filling in the DMP questions and provide DMP information as required e.g., in the funder template. The data structure of the central knowledge base and the proposal or administrative system will need to be mapped to the central data structure of the DMP tool.

Next steps

Future work is proposed in two areas: firstly, the integration of the internal inherent data models of the existing infrastructure with each other’s inclusive the adoption of interfaces to access the information from external systems to present, use, analyze, and enhance the metadata; and secondly, the integration of the presented DMP ontology with standard ontologies and vocabularies.

The components of the DMP system presented here normally work with data models designed for their respective applications; we propose that they should be integrated with each other. Therefore, their internal data models will have to be mapped with the presented DMP ontology, and interfaces for their integration will have to be created. Initial work on this is presented in Görzig et al. (2022).

The proposed DMP ontology is still under development and needs to be integrated with existing data formats and standards and non-discipline specific ontologies. Appropriate concepts for the terms used in the presented DMP ontology can be found in ontologies such as DCAT (Gonzalez-Beltran and Winstanley 2022) and PREMIS (Di Iorio and Caron 2016). These terms will have to be mapped. For integration with DMPs, the RDA DMP common standard (Miksa et al. 2020) can be applied, and on a more PaN specific level, the data model described in Görzig et al. (2022) should be taken further. Other PaN relevant standards that need to be considered are: the the NeXus format standard for measurement files in PaN facilities (Könnecke et al. 2015); related scientific techniques such as for spectroscopy described in Hanson et al. (2022); and analytical chemistry in Rauh et al. (2022).

In the data repositories and their catalogues, different standards are used. For discovery purposes, DataCite metadata, an OAI-PMH interface, and a common search API are normally implemented (Richter et al. 2020). Further, several PaN facilities operate the ICAT as a data catalogue and repository, which uses a common central metadata schema (ICAT; Flannery et al. 2009; Matthews et al. 2009). In addition to the ICAT metadata schema, other standards-based metadata are under development e.g., PaN ontologies NeXus and PaNET (Collins et al. 2021). The data model in ICAT and also SciCAT—another popular repository tool used in PaN sciences (SciCatProject · GitHub, no date)—should be reviewed to maximize the information required for DMPs. For execution and validation of the DMP, the operations in the DMP ontology have been defined and will need to be mapped to a workflow language such as CWL (Crusoe et al. 2021).