D5.1.1.1 Define requirements for metadata schema

Deliverable 5.1.1.1 DEFINE REQUIREMENTS FOR METADATA SCHEMA 24.01.2025 Define requirements for metadata schema Ramiz Qussous 1, Corinna Seiwerth 2, Jan Sören Schwarz 3,4, Nan Liu 5, Philipp Schmurr 5, Zhiyu Pan 6, and Stephan Ferenz 3,4 1University of Freiburg, INATECH, ROR, Emmy-Noether-Str. 2, 79110 Freiburg im Breisgau 2Friedrich-Alexander-Universität Erlangen-Nürnberg, Chair of Computer Science 7 (Computer Networks and Communication Systems), ROR, Martensstraße 3, 91058 Erlangen 3OFFIS, Institute for Information Technology, ROR, Escherweg 2, 26121 Oldenburg 4Carl von Ossietzky Universität Oldenburg, Department of Computing Science, ROR, Ammerländer Heerstraße 114-118, 26129 Oldenburg 5Karlsruhe Institute of Technology, Institute for Automation and Applied Informatics, ROR, Hermann-von-Helmholtz-Platz 1, 76344 Eggenstein-Leopoldshafen 6RWTH Aachen, Institute for Automation of Complex Power Systems, ROR, Mathieustraße 10, 52074 Aachen Published by INATECH, University of Freiburg, ROR, Emmy-Noether-Str. 2, 79110 Freiburg im Breisgau www.inatech.de Acknowledgements The authors of this article have used various preparatory works from the NFDI4Energy to create this portrait, and references have been made where possible. Thanks to all those who are not named. The authors would like to thank the German Federal Government, the German State Governments, and the Joint Science Conference (GWK) for their funding and support as part of the NFDI4Energy consortium. The work was funded by the German Research Foundation (DFG) – 501865131 within the German National Research Data Infrastructure (NFDI, www.nfdi.de). License This document is published under the Attribution 4.0 International (CC BY 4.0). This license allows users to distribute, remix, adapt, and build upon the material in any medium or format, so long as attribution is given to the creator. The license allows for commercial use. This deliverable is archived at Zenodo: DOI: 10.5281/zenodo.17542734. Page 1of 7 Table of Contents General information ................................................................................ 3 Summary........................................................................................ 3 Deliverable 5.1.1.1 within NFDI4Energy....................................................... 3 Deliverable description ............................................................................. 4 Introduction .................................................................................... 4 Registries compared ............................................................................ 4 Requirements Analysis ............................................................................. 5 Core Metadata Requirements .................................................................. 5 Structural Requirements........................................................................ 6 Stakeholder Engagement and Validation....................................................... 6 Conclusion.......................................................................................... 6 Page 2of 7 General information Summary The goal of Measure 5.1 is to establish a structured and comprehensive overview of energy simulation software and methods by developing a metadata schema that effectively categorizes different modeling approaches (e.g., agent-based models, optimization models, heuristic-based models, hybrid approaches). This effort aims to enable researchers to locate, compare, and access various simulation models across different branches of energy research. As an initial step, we defined the requirements for a metadata schema that reflects both functional and non-functional features of a model registry. The requirements collected within this deliverable follow the ”modeling guidelines for metadata requirements” as defined by Measure 4.3 [1]. Deliverable 5.1.1.1 within NFDI4Energy Task Area 5 focuses on supporting interdisciplinary simulation efforts within energy system research. Measure 5.1 addresses the challenge of categorizing energy simulation software to provide more effective access, reuse, and interoperability. This deliverable for Task 5.1.1 is a foundational step toward developing a metadata schema for energy simulation software. Deliverable D5.1.1.1 is concerned with defining requirements for a metadata schema for energy simulation software, laying the groundwork for a structured categorization that can be applied across a wide variety of models. This deliverable feeds directly into the subsequent development of the metadata schema itself (D5.1.1.2) and the stakeholder engagement process for its extension and review (D5.1.1.3). Additionally, it sets the stage for the creation of model registries (Tasks 5.1.2 and 5.1.3), which will build upon this foundational work. This work closely aligns with the efforts in Measure 4.1, which focuses on domain-specific ontologies and metadata. The metadata schema defined here aims to maintain broad applicability while enabling interoperability with the ontology developed in Measure 4.1. By establishing a consistent categorization of energy simulation software, this work facilitates transparency, reusability, and effective knowledge sharing across the energy research community. Page 3of 7 Deliverable description Introduction As a first step, a review of existing software registries, both from the energy domain, and other domains, was carried out to understand current practices and identify requirements for developing a useful metadata schema. The review served as the basis to derive and define the metadata schema requirements, focusing on both functional and non-functional features. The analysis included evaluating different metadata schemes to answer key questions regarding existing software registries: 1. Which attributes are being compared or displayed, and whether a controlled vocabulary is being used; 2. The availability and effectiveness of well-defined filters; 3. The possibility of comparing different entries; 4. Methods for adding software to the registry, such as through a wizard or manual input; 5. The specific domain or sub-branch the registry serves; 6. The ability to reference external resources, like publications or software; 7. The capabilities and user experience of the search functionality; and 8. Platform user-friendliness. These considerations tried to cover aspects such as metadata coverage, user accessibility, interoperability, and adherence to FAIR principles. In addition, we consulted community guidance on research software registries, in particular the article Nine best practices for research software registries and repositories by Garijo et al. (2022) [2]. This work provided valuable principles regarding scope definition, governance, and sustainability, which we used to complement our comparative review of existing registries. Registries compared As part of the requirements definition, we analyzed the following registries to derive insights about their structure, attributes, and user experience: • swMath [3]: Provides a comprehensive overview of mathematical software, aiming to improve findability by categorizing software based on various attributes and connecting it with relevant publications. • bio.tools [4], [5]: A registry that focuses on bioinformatics tools, supporting advanced filtering and search functionality. • RSD (Research Software Directory) [6]: Offers a platform for registering and describing research software, focusing on linking software to related publications and projects. • DOECODE [7]: A repository for software created and funded by the U.S. Department of Energy, emphasizing open access and transparency. • MLflow Model Registry: A platform to manage and organize machine learning models, providing features for versioning and comparison. Page 4of 7 • Open Energy Platform (OEP) [8]: A structured platform for energy system modeling that employs a database schema to organize metadata across seven primary categories including general information, openness, software characteristics, coverage, mathematical properties, model integration, and references. It implements predefined categories for model types (e.g., LP, MILP, Agent-based, System Dynamics) and provides advanced search functionality with tagging capabilities. • OpenMod Initiative [9]: A community-driven platform utilizing MediaWiki templates for organizing energy system model metadata. It covers approximately 80 attributes across seven categories similar to OEP, but with more flexibility in classification.1 • Helmholtz Software Directory [10]: An implementation of the RSD platform specifically tailored for research software developed within the Helmholtz Association, covering domains including energy, earth and environmental sciences, health, and space research. • CoMSES Net (Network for Computational Modeling in Social and Ecological Sciences) [11]: A specialized registry focusing on computational models in social and ecological sciences. It implements the CodeMeta standard and employs the ODD (Overview, Design concepts, and Details) protocol specifically for agent-based modeling documentation. While reviewing registries is valuable for understanding implementation practices and user interaction, it is equally important to examine the underlying metadata schemas that these registries adopt. In this context, we also considered existing schema comparisons such as the overview presented by Ferenz et al. [12], which systematically maps and contrasts metadata elements across different initiatives. Furthermore, results from the WG RSmeta survey [13] provide current community insights into metadata usage, expectations, and gaps. These complementary perspectives ensure that our requirements analysis builds not only on registry implementations but also on schema-level evaluations and practitioner feedback. Requirements Analysis From our review of existing registries, evaluation of domain needs, and earlier works [12], [14], [15], we derived several key requirements for the metadata schema: Core Metadata Requirements • Generic Fields –Basic identification: name, version, authors, contact information –Temporal information: publication date, last modification date –Descriptive content: abstract, purpose, documentation links • Domain-Specific Fields –Model characteristics: simulation type, mathematical approach –Technical specifications: input/output formats, framework compatibility –Implementation details: programming languages, dependencies • Controlled Vocabularies –Software categorization (e.g., framework, model, interpreter) –Model types (e.g., agent-based, optimization) 1The OEP was developed by members of the Open Energy Modelling Initiative (openmod) community as an extension of their efforts to manage and distribute open energy data, explaining the high similarity of model descriptions. Page 5of 7 • Resolvable Identifiers –Research organizations (using ROR identifiers) –Author identification (via ORCID) Structural Requirements • Modular Schema Design –Core metadata module for common fields –Extension modules for specific model types –Flexible addition of domain-specific attributes • Interoperability Features –Standard license identification (using, e.g., SPDX identifiers) –Input/output specification (e.g., compatibility with FMI and DataDesc) –Unique persistent identifiers for software records –Change tracking capabilities Stakeholder Engagement and Validation To validate and refine these metadata requirements, we are organizing an interactive workshop that engages stakeholders from different energy simulation sub-branches. The workshop employs a rotating group format where participants collaboratively identify and document metadata fields specific to their domains, such as agent-based simulations and co-simulations. Through moderated discussions, participants examined unique features essential for their modeling approaches while exploring standardization opportunities across sub-branches. This participatory process aimed to identify gaps in current metadata schemas, assess workflow integration needs, and ensure the schema effectively serves diverse stakeholder requirements while maintaining consistency and interoperability. The workshop outcomes will directly inform the further development of our metadata schema, ensuring it comprehensively addresses the practical needs of the energy simulation research community. Conclusion In the scope of this deliverable, the requirements for an energy simulation software metadata schema have been defined through a comparative analysis of existing registries, and evaluation of domainspecific (energy research software) needs. The requirements ranged from fundamental entity identification fields, to more domain-specific attributes such as modeling approaches with the focus on using controlled vocabulary to ensure interoperability. We followed a modular metadata design approach, which will enable adaptability across various energy research branches. Page 6of 7 References [1] P. Schmurr, N. Liu, A. Wein, et al.,D4.3.1 technical requirements for metadata in nfdi4energy services, Feb. 2025. DOI: 10.5281/zenodo.14937740. [Online]. Available: https://doi. org/10.5281/zenodo.14937740. [2] D. Garijo, C. Jones, and et al., “Nine best practices for research software registries and repositories: A concise guide,” PeerJ Computer Science, vol. 8, e1023, 2022. DOI: 10.7717/peerjcs.1023. [Online]. Available: https://peerj.com/articles/cs-1023/. [3] S. Bönisch, M. Brickenstein, H. Chrapary, G.-M. Greuel, and W. Sperber, Swmath - a new information service for mathematical software, 2013. arXiv: 1306.1036 [cs.DL]. [Online]. Available: https://arxiv.org/abs/1306.1036. [4] J. Ison, K. Rapacki, H. Ménager, et al., “Tools and data services registry: A community effort to document bioinformatics resources,” Nucleic Acids Research, vol. 44, no. D1, pp. D38–D47, Nov. 2015, ISSN: 0305-1048. DOI: 10.1093/nar/gkv1116. eprint: https://academic. oup.com/nar/article-pdf/44/D1/D38/9482499/gkv1116.pdf. [Online]. Available: https://doi.org/10.1093/nar/gkv1116. [5] J. Ison, H. Ienasescu, P. Chmura, et al., “The bio.tools registry of software tools and data resources for the life sciences,” en, Genome Biol., vol. 20, no. 1, p. 164, Aug. 2019. [6] E. J. Cahen, D. Mijatovic, J. G. Gonzalez, et al.,Research software directory (as a service), version v2.25.0, Released on 2024-11-22. Main contributors include Netherlands eScience Center and Helmholtz Centre Potsdam - GFZ German Research Centre for Geosciences. Repository:https://github.com/research-software-directory/RSD-as-a-service., 2024. DOI: 10 . 5281 / zenodo . 6379973. [Online]. Available: https : / / research - software - directory.org. [7] U.S. Department of Energy, Directive 241.1C: Scientific and Technical Information Management, Accessed: 2025-01-15, 2024. [Online]. Available: https://www.directives.doe.gov/ directives-documents/200-series/0241.1-border-c/@@images/file. [8] L. Hülk, M. Glauer, J. Huber, and C. Winger, Open energy family - open energy platform (oep), version 1.0.5, Reiner Lemoine Institut, Otto-von-Guericke-University Magdeburg, Öko-Institut, Nov. 2024. [Online]. Available: https://github.com/OpenEnergyPlatform/oeplatform/. [9] Openmod - Open Energy Modelling Initiative — openmod-initiative.org,https : / / www . openmod-initiative.org/, [Accessed 15-01-2025]. [10] C. Meeßen, M. Rüster, M. Hanisch, and N. Ziegner, Helmholtz research software directory, version hifis-1.5.0, Feb. 2023. DOI: 10.5281/zenodo.7638663. [Online]. Available: https: //doi.org/10.5281/zenodo.7638663. [11] M. A. Janssen, L. N. Alessa, M. Barton, S. Bergin, and A. Lee, “Towards a community framework for agent-based modelling,” Journal of Artificial Societies and Social Simulation, vol. 11, no. 2, p. 6, 2008. [Online]. Available: https://jasss.soc.surrey.ac.uk/11/2/6.html. [12] S. Ferenz, O. Werth, and A. Nieße, “Requirements for a Metadata Scheme to Enable FAIR Energy Research Software,” Electronic Communications of the EASST, vol. 83, Feb. 2025, ISSN: 1863-2122. DOI: 10.14279/eceasst.v83.2594. (visited on 02/24/2025). [13] L. J. Castro, S. Ferenz, H. Hajiabadi, et al.,Results on a survey on research software metadata in the nfdi consortia, Aug. 2024. DOI: 10 . 5281 / zenodo . 12704414. [Online]. Available: https://doi.org/10.5281/zenodo.12704414. [14] S. Ferenz and A. Nieße, “Towards improved findability of energy research software by introducing a metadata-based registry,” 2023. [15] P. Kuckertz, J. Göpfert, O. Karras, et al.,A metadata-based ecosystem to improve the fairness of research software, 2023. arXiv: 2306.10620 [cs.SE]. [Online]. Available: https://arxiv. org/abs/2306.10620. Page 7of 7