scieee AI-readable full text Open interactive document viewer

Extended service catalogue (NFDI4Earth Milestone MS3.1.2)

Liu, Kemeng; Henzen, Christin; Frickenhaus, Stephan; Müller, Claudia

Abstract

This report presents our progress in establishing a service catalogue within the context of NFDI4Earth. By evaluating upper-level or existing metadata schema for research data management services, we have developed a metadata schema for mapping research data management services into the knowledge graph database (Knowledge Hub) of NFDI4Earth. Additionally, we provide updates on several repositories via re3data, which is considered part of the NFDI4Earth service catalogue.

Full text

Milestone MS3.1.2 Extended service catalogue Kemeng Liu ([email protected]), Christin Henzen , Stephan Frickenhaus , Claudia Müller 2024-12 DOI: 10.5281/zenodo.17584787 nfdi4earth.de Citation Kemeng Liu, Christin Henzen, Stephan Frickenhaus, Claudia Müller. 2025. Extended service catalogue (NFDI4Earth Milestone MS3.1.2) (NFDI4Earth Deliverable MS3.1.2). NFDI4Earth Community on Zenodo. https://doi.org/10.5281/zenodo.17584787 License This work is licensed under a Creative Commons “Attribution 4.0 International” license. Acknowledgement This work has been funded by the German Research Foundation (DFG) through the project NFDI4Earth (DFG project no.460036893, https://www.nfdi4earth.de/) within the German National Research Data Infrastructure (NFDI, https://www.nfdi.de/). NFDI4Earth MS3.1.2 Executive summary This report presents our progress in establishing a service catalogue within the context of NFDI4Earth. By evaluating upper-level or existing metadata schema for research data management services, we have developed a metadata schema for mapping research data management services into the knowledge graph database (Knowledge Hub) of NFDI4Earth. Additionally, we provide updates on several repositories via re3data, which is considered part of the NFDI4Earth service catalogue. Extended service catalogue (MS3.1.2) Contents 1. Introduction 1 2. Updated Repository Information 1 3. RDM services 2 3.1.ServiceCatalogue................................. 3 3.2. NFDI4Earth Metadata Schema for RDM Services . . . . . . . . . . . . . . . . . 3 4. Outlook 5 Acknowledgements 5 A. Appendix 1 6 A.1. NFDI4Earth Service Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 B. Appendix 2 8 B.1.ServiceTypeEnum................................. 8 B.2. ServiceCategoryEnum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 B.3.ServiceLevelEnum................................. 11 B.4. ServiceAccessTypeEnum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 B.5.KPIType...................................... 12 Extended service catalogue (MS3.1.2) List of Tables 1. Overview of selected updated repositories . . . . . . . . . . . . . . . . . . . . 1 Extended service catalogue (MS3.1.2) 1. Introduction Within NFDI4Earth, managing information on research data management (RDM) services is a key task. In our previous report on the “NFDI4Earth Service Catalogue and Gap Analysis”1, we outlined initial ideas for shaping the service catalogue and identified gaps between our goal of achieving FAIRness and the existing services that cannot fulfill these requirements. Building on the previous work, we have now developed a metadata schema that describes RDM service instances more comprehensively and enables better interoperability with existing upper-level schemas. 2. Updated Repository Information NFDI4Earth has deepened its collaboration with re3data (Registry of Research Data Repositories)2,3, which serves as the project’s primary source of repository information. Since we have published our report “NFDI4Earth Service Catalogue and Gap Analysis”, the information on several repositories was updated at re3data. As described in the report, NFDI4Earth collaborates with re3data by forwarding information on missing or incorrect metadata fields and outdated repository entries. When a repository is identified that is not yet registered with re3data, NFDI4Earth consults the repository providers in the registration process with re3data. In this way, re3data and the NFDI4Earth have established a very successful and timely exchange of updated information. In the following table a selection of repositories is highlighted that have been updated in re3data in 2025 (Tab. 1). However, many more NFDI4Earth-related repositories regularly update their records. Table 1: Overview of selected updated repositories Infrastructure (repository) URL Status ATTO https://www.attodata.org/home/Start Registered at re3data on 2024-07-24 GDI-DE (Geodatenkatalog) https://gdk.gdi-de.org/gdi-de/srv/eng/catalog.se arch#/home Registered at re3data on 2024-05-15 HCDC https://hcdc.hereon.de/datasearch/ Registered at re3data on 2023-11-21 GEOROC https://georoc.eu/ and https://data.goettingen-r esearch-online.de/dataverse/digis Information updated at re3data on 2024-09-13 1Müller, C. M., & Frickenhaus, S. (2023). NFDI4Earth Service Catalogue and Gap Analysis (Version 1). Zenodo. https://doi.org/10.5281/zenodo.8344438 2https://www.re3data.org/ 3Frickenhaus, S., Grieb, J., Henzen, C., Müller, C., Protopopova-Kakar, V., & Weiland, C. (2025). NFDI4Earth Cooperation - re3data (NFDI4Earth White Paper). NFDI4Earth Community on Zenodo. https://doi.org/10.528 1/zenodo.15095431 1 Extended service catalogue (MS3.1.2) A full list of repositories is available in our NFDI4Earth-developed services OneStop4All4and Knowledge Hub5. 3. RDM services The concept of Research Data Management (RDM) describes a process of handling research data from creation to dissemination and archiving, encompassing the research data lifecycle in a structured way6. In the community of Earth System Science (ESS), just as in many other scientific domains, research data management is seen as essential for verifying research results and fostering future research based on existing knowledge6. Research data management is generally supported by various RDM services. In the NFDI, RDM services are understood as a “technical-organisational solution including storage and computing services, software, processes, and workflows, as well as the necessary personnel support for different service desks”7,8 . There are also other definitions of RDM services available in a broader sense. For example, EOSC encompasses RDM services in the broader category of EOSC resources9, which include services that support data management, preservation, access, and reuse. While for example NASA’s Earth Science Data Systems (ESDS)10 employs a “Level of Service model”, which consistently stewards data across its archives. According to the NASA concept, it depends on the level (basic, standard, comprehensive), and services include data ingestion, preservation, documentation, distribution, usability, user support, outreach, and long-term preservation. There are some examples, where institutions refer to the term “RDM services” as “Support Services”, as for example the University of Freiburg, where such services are collected as a RDM Services Catalogue along the Research Data Life Cycle11. 4https://onestop4all.nfdi4earth.de/search?resourcetype=Repository+%26+Archive&sort= 5https://knowledgehub.nfdi4earth.de/ 6Whyte, A., Tedds, J. (2011). ‘Making the Case for Research Data Management’. DCC Briefing Papers. Edinburgh: Digital Curation Centre. Available Online: https://www.dcc.ac.uk/guidance/briefing-papers/making-case-rdm 7 7 Henzen, C., Brauer, A., Degbelo, A., Frickenhaus, S., Grieb, J., Hachinger, S., Klammer, R., Müller, C., Munke, J., Niers, T., Nüst, D., Weiland, C., & Wellmann, A. (2024). NFDI4Earth Software Architecture Documentation. Zenodo. https://doi.org/10.5281/zenodo.14534839 8 8 Konsortialversammlung des Vereins Nationale Forschungsdateninfrastruktur (NFDI) e.V. (2022). Stellungnahme der NFDI-Konsortien zu Basisdiensten. Zenodo. https://doi.org/10.5281/zenodo.6091657 9https://www.openaire.eu/rdm-service-development-checklist 10 https://www.earthdata.nasa.gov/engage/submit-data/level-service-model 11 https://uni-freiburg.de/cdf-en/rdm-catalogue/ 2 Extended service catalogue (MS3.1.2) 3.1. Service Catalogue In the NFDI4Earth project, we aim to promote FAIRness and openness in future Earth System Science (ESS) research, thus we are committed to providing a portfolio overview of RDM services in the ESS community and supporting diverse stakeholders in conducting FAIR research data management. As one of the means to approach this goal, we are developing a Service Catalogue12 that encompasses a comprehensive collection of community services. It is part of NFDI4Earth’s service products and will be maintained in the Knowledge Hub. In an early attempt during the project, we summarised an overview of institution-based RDM services and categorised them into consulting services, training services, and tools for RDM13. We also compiled a collection of services used for creating data management plans (DMPs)14. In response to requests from some of our pilot project partners, the Interest Group High-Performance Computing (IG HPC)15 presented an initial collection of HPC services provided by NFDI4Earth members16. During the development of the service schema, as a pilot implementation, we harvested service information from the Helmholtz DataHub17 into the Knowledge Hub using a simplified schema. We believe that the development of metadata schema is an iteratively evolving process. As of this writing, we have substantially expanded our initial approach and developed a metadata schema (Appendix 1) for RDM services. An extensive data collection via a survey has been initiated and is in progress. Along with this procedure, we will also evaluate, adjust and improve the schema, e.g., with the service providers' feedback. 3.2. NFDI4Earth Metadata Schema for RDM Services The presented schema is defined for a new entity class “Service” in the Knowledge Hub and encompasses 35 attribute fields, where 20 of them are required and the rest are optional. Since it is a subclass of an overarching class “Thing”, “Service” inherits all attributes from “Thing”, including name, description, keywords, URL, etc. The attributes specific to “Service” describes an object by its access (e.g. access type, technical and credential requirements), maintenance (e.g. business model, user support contact), data security (e.g. data processing and storage 12 https://nfdi4earth.de/2interoperate/architecture-synthesis 13 https://nfdi4earth.pages.rwth-aachen.de/livinghandbook/livinghandbook/RDM-Services/ 14 https://nfdi4earth.pages.rwth-aachen.de/livinghandbook/livinghandbook/DMP-Services/ 15 https://nfdi4earth.pages.rwth-aachen.de/livinghandbook/livinghandbook/IG-HPC/ 16 https://nfdi4earth.pages.rwth-aachen.de/livinghandbook/livinghandbook/HPC-Services/ 17 https://earth-data.de/ 3 Extended service catalogue (MS3.1.2) plan, data protection and backup strategy), and some other parameters (e.g. service level, key performance indicators). he schema, we defined two attributes for classifying services. Attribute “serviceType” was defined to classify services based on their delivery method and user interface. To maintain consistency with existing standards and serve the purpose of (NFDI-wide) reporting, the terminology for “serviceType” is aligned with the service categories defined in de.NBI18 and NFDIcore Ontology19, which is based on the common agreement across NFDI consortia20. The defined service types include: “Storage”, “Data Curation”, “Database”, “Web Application”, “Library/API”, “Workflow/Pipeline”, “Support/Consulting”, “Training”, and “Tool/Application”. For user-centric categorisation, attribute “serviceCategory” was defined to group services by the research data life cycle stage(s) they support. These categories encompass: “Data Ingestion and Curation”, “Data Storage and Management”, “Data Publication, Discovery and Access”, “Data Analysis and Visualisation”, “Interoperability and Integration”, and “User support and Training”. The definitions of individual service types and categories are available in Appendix 2. The metadata schema for RDM service is expected to fulfil internal requirements as well as meet basic demand of interoperability with other schemas of the same type. In result, three attribute fields have been drawn from the EOSC service profile21: “serviceLevel”, “securityIncidentContact”, and “serviceFees”. Attribute “serviceAccessType” originates from the re3data schema22. The rest of the attribute fields were adapted from the HIFIS schema23 or based on agreements with Base4NFDI24. An overview of the service schema is presented in Appendix 1. For attributes requiring a controlled vocabulary, i.e. “serviceType”, “serviceCategory”, “serviceLevel”, “tangibleKPI”, “serviceAccessType”, the terms and their definitions are presented in Appendix 2. 18 18 Turewicz, M., Scholz, U., Glöckner, F. O., Dammann-Kalinowski, T., &Wittchen, M. (2022). de.NBI servicecategoryspecific KPI selection and criteria. Zenodo. https://doi.org/10.5281/zenodo.6597826 19 https://ise-fizkarlsruhe.github.io/nfdicore/ 20 Amelung, L., Anthofer, V., Danabalan, R., Demandt, É., Ebert, B., Elschner, E., Espinoza, S., Eufinger, J., Fuchsloch, S., Götz, B., Henzen, C., Hunold, J., Idda, T., Jansen, L., Krieger, U., Rodrigues, C. M., Meister, M., Miller, B., Pitroff, S., Zinke, W. (2023). White Paper: Interim Report Reference. Zenodo. https://doi.org/10.5281/zenodo.10101412 21 https://eosc-service-profile.readthedocs.io/en/5.0/elementsOfService.html 22 22 Trecker, D., Axtmann, A., Bertelmann, R., Cousijn, H., Elger, K., Ferguson, L. M., Fichtmueller, D., Jones, C., Lindenmann, I., Neidiger, C. Nguyen, T. B., Pal, J. K., Pampel, H., Petras, V., Schnepf, E., Semrau, A., Ulrich, R., Upmeier, A., Vierkant, P., Wang, H., Weickert, G., Weisweiler, N. L., Williams, S. C., Witt, M & Wright, S. J. (2023). Metadata Schema for the Description of Research Data Repositories : version 4.0. https://doi.org/10.48440/re3.0 14 23 https://hifis.net/doc/ 24 Schäfer-Neth, C., Grudskaja, A., Chen, T., & Giesler, A. (2025). Report on Base4NFDI service integration procedures (D2.1.1) (Version 1). Zenodo. https://doi.org/10.5281/zenodo.15235864 4 Extended service catalogue (MS3.1.2) B.3. ServiceLevelEnum Text Description trl1 - basic principles observed Scientific research has led to observation and reports of basic principles which has evolved to applied research and development. trl2 - technology concept formulated Practical applications for the observed basic physical principles are found and reported. trl3 - experimental proof of concept The most critical functions of the new technology are validated by using both analytical and experimental methods. trl4 - technology validated in lab The concept is tested to assure that the technical elements can be integrated together and achieve the desired performance, at a component and/or breadboard level. trl5 - technology validated in relevant environment The components making up the concept is tested individually in realistic environment. trl6 - technology demonstrated in relevant environment A model or prototype of the concept, not individual components, is tested in a relevant environment. trl7 - system prototype demonstration in operational environment A prototype is tested in the environment in which the final product will operate. trl8 - system complete and qualified The technology is built to the specifications of the final product and is tested in the operational environment alongside all systems it will interact with. trl9 - actual system proven in operational environment At this level all technology development has been completed, and the technology is performing as intended in the real-world environment. Source: EOSC Service Profile v.5.037 37 https://eosc-service-profile.readthedocs.io/en/5.0//_vocabularies/TRL.html 11 Extended service catalogue (MS3.1.2) B.4. ServiceAccessTypeEnum Text Description Open Access There are no access barriers. Restricted Access External users can overcome access barriers, e.g. by creating a user account. Closed Access External users cannot overcome access barriers. Source: re3data Metadata Schema v.4.038 B.5. KPI Type The required KPI type is related to the type of the service Service Type Related KPI Type (KPITypeEnum39) Database Total number of visits Library/API Total number of downloads Workflow/Pipeline Total number of executions Tool/Application Total number of downloads Web Application Total number of visits Data Curation Total number of datasets curated Training Total number of training activities Storage Total amount of provided space in GB 38 https://gfzpublic.gfz-potsdam.de/rest/items/item/_5022309/_4/component/file/_5022681/content 39 https://nfdi4earth.pages.rwth-aachen.de/knowledgehub/nfdi4earth-kh-schema/KPITypeEnum/ 12