Log In Sign Up

Software metadata: How much is enough?

by   Alice Allen, et al.

Broad efforts are underway to capture metadata about research software and retain it across services; notable in this regard is the CodeMeta project. What metadata are important to have about (research) software? What metadata are useful for searching for codes? What would you like to learn about astronomy software? This BoF sought to gather information on metadata most desired by researchers and users of astro software and others interested in registering, indexing, capturing, and doing research on this software. Information from this BoF could conceivably result in changes to the Astrophysics Source Code Library (ASCL) or other resources for the benefit of the community or provide input into other projects concerned with software metadata.


page 1

page 2

page 3

page 4


Software publications with rich metadata: state of the art, automated workflows and HERMES concept

To satisfy the principles of FAIR software, software sustainability and ...

User Manual of Automatic Data Curation Tool(ADCT): A bulk data curator software in Library and Information Science

In library and information science, document storage and user-specific d...

AMV : Algorithm Metadata Vocabulary

Metadata vocabularies are used in various domains of study. It provides ...

Making the Invisible Visible: Risks and Benefits of Disclosing Metadata in Visualization

Accompanying a data visualization with metadata may benefit readers by f...

Digitally Capturing Physical Prototypes During Early-Stage Product Development Projects for Analysis

Aiming to help researchers capture early-stage Product Development (PD) ...

Extensible Data Skipping

Data skipping reduces I/O for SQL queries by skipping over irrelevant da...

Citation method, please? A case study in astrophysics

Software citation has accelerated in astrophysics in the past decade, re...

1 Introduction

That software is used in astronomy research is not news, and questions arise as how best to store, cite, index, discover, and maintain this software, and what information about it to track. These questions are common across all disciplines; the CodeMeta project111 is a cross-disciplinary effort that seeks to provide a way to retain software metadata as it moves across services (codemeta), for example, from Astrophysics Source Code Library (ASCL) to NASA’s Astrophysics Data Service (ADS) or GitHub to Zenodo222Respectively,,,,, by creating and maintaining a crosswalk table for these metadata and the services that use them.

This BoF focuses on what metadata are most useful to astronomers under different circumstances, and is the latest in a series of BoFs that the ASCL has organized at ADASS focused on the needs of software authors and users. Previous sessions dealt with issues around sharing, reusing, crediting, and citing software; though these earlier BoFs touched upon software metadata, this is the first session to have these metadata as a central theme.

2 Opening presentation and breakout groups

Allen opened the session with information on broad efforts across many disciplines to define necessary metadata for software under different use cases. Metadata users typically want as much metadata as they can get, however, the more maintenance of metadata one has to do, the less likely it is that this information will be kept up to date. The ASCL, for example, has kept the amount of metadata it contains to a minimum, as previous other similar efforts, such as the Astronomical Software Directory Service (ASDS) (asds), folded in part because of the difficulties of maintaining metadata sufficiently to keep the resource useful (allenschmidt). Allen noted that the ASCL has often been asked by developers, journals, and users to include much more metadata and that the Journal of Open Source Software (JOSS) (joss), started in 2016, has also adopted a minimal metadata set very similar to that maintained by the ASCL.

She requested that participants break into groups to discuss and define the eight most important metadata elements for four different roles involved in the creation and use of this information. Eight was an admittedly arbitrary number, as any number would be, and was to try to enforce a hierarchy among all possible metadata that might be captured.

Participants were free to choose one of the following groups:

  • Software Developer, moderated by Peter Teuben

  • Software User, moderated by Keith Shortridge

  • Software Indexer, moderated by Kimberly DuPrie

  • Journals, moderated by Alice Allen

The groups met for about 30 minutes and then came back together to share what they had discussed.

3 Results of breakout discussions

Three of the breakout groups started with essentially a clean slate, discussing what the most important/basic information is of interest for the purposes of the role they were discussing. In contrast to this, the Software Indexer group started with a base set of metadata already defined —that currently captured by the ASCL —and discussed what information might be added to this set. Each moderator reported their results, consisting of a list of eight (or more) elements that would be of primary interest to the audience they were representing. These data were captured in a Google document333 that is open for viewing and commenting.

Each of the groups had to determine what use cases they were trying to satisfy. The Journals group spent some time discussing the different use cases journals may have for metadata, including metadata needed to describe methods in the literature, and that for citation or software provenance. Without trying to describe formal use cases, the Users group mainly envisaged situations where someone had located an apparently attractive code, but wanted to know how easy it would be for them to make use of it in practice. They considered metadata that would describe support for the code (e.g., when last updated, name of current maintainer, if any) and ease of installation (e.g., system requirements, dependencies, packaging). The ‘family history’ of a code was thought to be of interest—is this code a descendant of some other code, or conversely, is there another code available that is based on this? Although hard to express in metadata, many codes can be described as “like some other package, but able to do such and such”, and all these things are useful to know. There was also discussion in the Users group about comments and ratings, potentially useful, but clearly controversial, and this group also raised the question “Who supplies the metadata?”.

The Software Indexers group drifted into discussion of metadata that reflected the desires of software authors and users; this is understandable, as the group was composed almost entirely of people who write and use software rather than index it. The information this group shared reinforced the usefulness of metadata elements identified in other groups while also providing unique properties, such as whether a project had been forked. The Software Developers group, the largest of the four groups, identified the requested eight metadata properties, and went on to identify eight additional elements. This group provided a number of elements, such as preferred citation, test results, and API, that were unique in this effort.

It is not surprising there were elements in common identified by the groups (see Table 1 for examples), and also not surprising there were many that were unique to one group (examples are shown in Table 2). This clearly demonstrates the differing needs of the various roles and the difficulty in getting the right amount and the right kind of metadata for the various users of it. What metadata one needs or would like to have is dependent on how that information will be used. The CodeMeta schema has 56 metadata properties in common with’s, and an additional ten properties to help satisfy the needs of all the use cases identified by that project.

dependencies version
license author/developer
maintainer title/name
location/website/repo language
Table 1: Sample of metadata elements identified by more than one group
preferred citation bug tracker
cost category
cited by keywords
ease of installation unique identifier
inputs number of collaborators
Table 2: Sample of unique metadata elements

After each breakout group shared its results, there was general discussion amongst participants and a commitment from the organizers to make the results available, but otherwise, there was no firm conclusion nor action items identified.

4 Conclusion

This meeting provided some idea of the sort of additional data various people would like to see made available, and the discussion was interesting and useful. Some proposed metadata is straightforward, while some is dynamic (current support for a code, for example), and raises questions about the maintenance of metadata. Some, such as comments, represent opinions rather than data as such. It was clear that ASCL itself is not in the business of judging codes, in part because this would inhibit code release (barnes2010), though comments are of interest to users and those looking to build upon existing software.

The ASCL is grateful for financial support provided by the Heidelberg Institute for Theoretical Studies (HITS) and for facilities and services support from Michigan Technological University, the Astronomy Department at the University of Maryland, and the University of Maryland Libraries.