This is a Preprint and has not been peer reviewed. This is version 2 of this Preprint.
This is a Preprint and has not been peer reviewed. This is version 2 of this Preprint.
Research software in the energy domain becomes increasingly important for the analysis, simulation, and optimization of energy systems and supports design decisions in the required transition of energy systems to tackle the climate crisis.
To make energy research software (ERS) more findable, it should be described with metadata following the FAIR (findable, accessible, interoperable, and reusable) criteria and be registered in a common registry.
To this end, we present a concept for a metadata-based registry for ERS which should enable researchers to easily add new ERS as well as to find new ERS.
Data Infrastructure, Data Management Software
Interoperability, Digital Libraries, Energy Research, FAIR, Research Software, Metadata, Open Source Software, Software Reusability, Ontology, Semantic Web, Linked Data, Digital Libraries, Energy Research, FAIR, Research Software, Metadata, Open Source Software, Software Reusability
Published: 2023-03-01 11:35
Invited Review Comment #19 Dorothea Iglezakis @ 2023-03-15 13:46
Summary
The article "Towards Improved Findability of Energy Research Software by Introducing a Metadata-based Registry" of Stephan Ferenz and Astrid Nieße provides a very good overview over existing schemata, ontologies and terminologies for research software and for the energy domain. The article is well written and easy to follow, but lacks details as soon as it comes to the description of the own planned software registry.
Detailed Comments
Chapter 1: Motivation
While there is a sound definition of ERS, the terms software repository (in the sense of a source code repository and in contrast to a data repository) and software registry are not defined but quite central for the article.
The need for FAIR software does not necessarily follow from the problem description in lines 16-21.
The problems described are:
- there is a lot of parallel development, software in the domain is seldom reused
- simulation of energy system is getting more complex because of the growing number of interrelated components
While FAIR software could help solving the first problem, I cannot see how this applies to the second one. Reference 5 also argues that one of the main problems are missing valid models with clear defined interfaces. For this problem, findable and reusable software could really help. But what is the actual state of availability of ERS? How does the community get to know what software already exists? Is software in this domain mainly developed open source? Perhaps add one sentence, why FAIR software and the planned software registry could be the solution of these problems. Why is it not enough to develop open source and publish text publications about software in this domain (if this is the case)
Not sure, if the whole audience is familiar with the meaning of URIs in metadata (l. 52), namely the unique identification of persons and entities.
The selection of properties to compare metadata schemas in table 2 and 3 does not get really clear. Are these quite formal criteria really the most important ones to compare the different approaches? If that's the case, then please argue, why these criteria are crucial to solve the problems in chapter 1. What are the advantages and disadvantages of the different terminologies and ontologies, not only in a formal way, but also in terms of content? What is missing, what is applicable to the energy domain and what is not?
How do you define "Support for URIs" in table 2. As there is a unique identifier property for persons in OntoSoft and OntoSoft is an ontology with sort of built-in support of URIs, I wondered, why OntoSoft does not have support for URIs.
I wouldn't really call CodeMeta a scheme, more a vocabulary to describe research software. In fact, it is also an ontology, but the project aims more in the direction of a scheme to describe software, but OntoSoft goes in a similar direction.
- line 19: add comma between "components" and "ERS"
- line 31: our contribution*s* are oder our contribution is
- line 158: as *a * first step
- line 160: *cor*responding software registry
- line 162, add comma after "software"
- line 162: write additional software -> extend the software or write additional code
- line 163: should be publish*ed*
- line 174: constrain*t*s
- line 180: the one*s*
- page 4: In the legend of table 2 there is one ")" too much.