RSMD checklist

Introduction

The Research Software MetaData (RSMD) guidelines are a cross-disciplinary community driven effort to provide standardized and actionable guidance for the metadata collection and curation of research software.

To assist software creators in self-archiving and self-metadata curation, FAIR-IMPACT has created the RSMD checklist as a self contained questionnaire. The RSMD checklist which is addressing all the RSMD guidelines recommendations as a set of questions that can be used by the software creator or the software curator. By using the checklist, software creators can ensure that their software has the necessary metadata to be accessible, discoverable and reusable.

General Metadata Requirements

  • Does the software have metadata that is embedded in the source code (intrinsic metadata)? (RSMD-1.1)
  • Does the software project have a metadata record (extrinsic metadata) which is publicly available on an online scholarly platform? (RSMD-1.2)
    • Is the metadata record licensed as CC0?
  • Is the software also available in a version control system (VCS)? (RSMD-1.3)
    • if it is available online, is the url available in a code repository property in the intrinsic or/and extrinsic metadata?
  • Does the software follow language specific community standards? (RSMD-1.4)
  • Is the machine readable metadata information in a single file? (RSMD-1.5)

Accessibility and preservation

  • Is the software record or/and are the software artifacts accessible and preserved?
    • Is the software source code preserved in the SWH universal source code archive, Software Heritage? (RSMD-2.1)
    • Is the software archived in a scholarly repository (e.g Zenodo, HAL)? (RSMD-2.2)
    • Can it be accessed and downloaded?
  • Is the software registered in a disciplinary or community registry (e.g ascl.net, bio.tools, swMath, RRID portal, RSD, WikiData, DataCite) (RSMD-2.3)
    • Can it be found in a search engine?

Reference and identification

  • Are the software versions clearly identified? (RSMD-3.1)
  • Are intrinsic identifiers available:
    • Can specific algorithms or code fragments be identified? (RSMD-3.2)
    • Can a file or directory be identified? (RSMD-3.2)
    • Can different revisions or releases be identified? (RSMD-3.2)
  • Are extrinsic identifiers available:
    • Can different releases be specifically identified? ( RSMD-3.3)
    • Can the project be identified? (RSMD-3.3)
    • If applicable, can a module be identified? (RSMD-3.3)
  • Is a versioning scheme used? (RSMD-3.4)
  • Is it possible to identify different levels of granularity? (RSMD-3.5)

Description & classification

  • Is the information about the software name and description available (on README file or other intrinsic metadata file)? (RSMD 4.1)
  • Does the metadata record contain descriptive metadata? (RSMD 4.2)
    • Name
    • Description
    • Domain
    • Programming language
    • Date created
    • Date of first publication
    • Keywords
    • Related links
    • Version
  • Is it possible to access articles describing the software via a persistent identifier, or at least, a stable URL? (RSMD 4.3)
  • Is the intrinsic metadata of the software description available in a machine readable file? (RSMD 4.4)
  • Is additional information (e.g. provenance information, functionalities, development status, etc.) on the software available in the README file? (RSMD 4.5)

Attribution & credit

  • Are the authors & contributors identified and acknowledged?
    • Is the author's information available in the source code as intrinsic metadata? (RSMD-5.1)
    • Is the author's information available on the metadata record as extrinsic metadata? (RSMD-5.2)
    • Is the list of authors exhaustive or is a collective author used? (RSMD-5.8)
  • Are people identifiers used? (ORCID, ID-HAL, ID-REF, etc.) (RSMD-5.3)
  • Are the roles of the authors and contributors specified? (RSMD-5.4)
  • Is a citation preference provided? (RSMD-5.5)
  • Is software explicitly cited and included in the bibliography (RSMD-5.6)?
  • If applicable, in the article citing the software, is the appropriate granularity used? (RSMD-5.7)
  • Before choosing a license, did you verify who is the rights holder of the software? (RSMD-6.1)
  • Is the license information available in the source code (intrinsic metadata file)? (RSMD-6.2)
    • If there are several licenses, are all defined in the software source code?
    • In the source code are the following attributes available alongside the license: name of the software, year, copyright holder, contact information (email), license identifier (e.g. SPDX) (RSMD-6.6)
  • Is the license information available in the metadata record? (RSMD-6.3)
    • Is the license information in the code the same as the property on the metadata record?
  • Are external software modules used identified with their authors and license? for compliance purposes, it is necessary to verify licenses compatibility (RSMD-6.4)
  • Are the versions and contributions tracked? Using a VCS is preferable (RSMD-6.5)

Re-execute: Dependencies and execution environment

  • Are the software dependencies described (RSMD-7.1)
    • Is the description of the dependencies available in a machine-actionable format?
  • Are the operating system and relevant environment requirements described? (RSMD-7.2)
  • Are the hardware and relevant hardware platform requirements described? (RSMD-7.3)
  • Are the build instructions available? (RSMD-7.4)
    • If applicable, are the build configuration files for the specific ecosystem (Makefile, Ant files, Dockerfile, etc.) and appropriate test cases provided?
  • Is the user documentation available? (RSMD-7.5)
    • Are the input/output formats specified?
    • Are there examples available?
  • Are the data used and/or produced by the software described or linked? (RSMD-7.6)
    • If applicable, is there a sample provenance trace/log of an execution, including pointers to input data and expected results available?