FAIR Principles for Research Software (FAIR4RS Principles)

16
Mar
2022

FAIR Principles for Research Software (FAIR4RS Principles)

By Neil Chue Hong


FAIR for Research Software (FAIR4RS) WG
Group co-chairs: Michelle BarkerPaula Andrea MartinezLeyla GarciaDaniel S. KatzNeil Chue Hong, Jennifer Harrow, Fotis Psomopoulos, Carlos Martinez-Ortiz, Morane Gruenpeter

Recommendation Title: FAIR Principles for Research Software (FAIR4RS Principles)

Authors: Neil P. Chue Hong*, Daniel S. Katz*, Michelle Barker*; Anna-Lena Lamprecht, Carlos Martinez, Fotis E. Psomopoulos, Jen Harrow, Leyla Jael Castro, Morane Gruenpeter, Paula Andrea Martinez, Tom Honeyman; Alexander Struck, Allen Lee, Axel Loewe, Ben van Werkhoven, Catherine Jones, Daniel Garijo, Esther Plomp, Francoise Genova, Hugh Shanahan, Joanna Leng, Maggie Hellström, Malin Sandström, Manodeep Sinha, Mateusz Kuzak, Patricia Herterich, Qian Zhang, Sharif Islam, Susanna-Assunta Sansone, Tom Pollard, Udayanto Dwi Atmojo; Alan Williams, Andreas Czerniak, Anna Niehues, Anne Claire Fouilloux, Bala Desinghu, Carole Goble, Céline Richard, Charles Gray, Chris Erdmann, Daniel Nüst, Daniele Tartarini, Elena Ranguelova, Hartwig Anzt, Ilian Todorov, James McNally, Javier Moldon, Jessica Burnett, Julián Garrido-Sánchez, Khalid Belhajjame, Laurents Sesink, Lorraine Hwang, Marcos Roberto Tovani-Palone, Mark D. Wilkinson, Mathieu Servillat, Matthias Liffers, Merc Fox, Nadica Miljković, Nick Lynch, Paula Martinez Lavanchy, Sandra Gesing, Sarah Stevens, Sergio Martinez Cuesta, Silvio Peroni, Stian Soiland-Reyes, Tom Bakker, Tovo Rabemanantsoa, Vanessa Sochat, Yo Yehudi, FAIR4RS WG

(*) Lead authors with equal contributions

Impact: Adoption and implementation of the FAIR for Research Software principles will create significant benefits for many stakeholders, including increased research reproducibility for research organizations, better practices and more software usage for its developers, clarity for funders around their own policies and requirements for software investments, and guidelines for publishers on sharing requirements.

This work will be of value to software project owners, researchers, users of research data and software, the scientific community, research software engineers, software developers who publish their software, software catalog maintainers, repository managers, software preservation and archival experts, policymakers who are responsible for defining digital policies, and organizations that create, modify, manage, share, protect, and preserve research software, funders of research, and others with an interest in the FAIR principles for research software.

DOI: 10.15497/RDA00068

Citation and download: Chue Hong, N. P., Katz, D. S., Barker, M., Lamprecht, A-L, Martinez, C., Psomopoulos, F. E., Harrow, J., Castro, L. J., Gruenpeter, M., Martinez, P. A., Honeyman, T., et al. (2022). FAIR Principles for Research Software version 1.0. (FAIR4RS Principles v1.0). Research Data Alliance. DOI: https://doi.org/10.15497/RDA00068

 

This output supersedes the FAIR Principles for Research Software (FAIR4RS Principles) DOI: 10.15497/RDA00065

Abstract:

To improve the sharing and reuse of research software, the FAIR for Research Software (FAIR4RS) Working Group has applied the FAIR Guiding Principles for scientific data management and stewardship to research software, bringing together existing and new community efforts. Many of the FAIR Guiding Principles can be directly applied to research software by treating software and data as similar digital research objects. However, specific characteristics of software — such as its executability, composite nature, and continuous evolution and versioning — make it necessary to revise and extend the principles.

This document presents the first version of the FAIR Principles for Research Software (FAIR4RS Principles), and includes explanatory text to aid adoption. It is an outcome of the FAIR for Research Software Working Group (FAIR4RS WG) based on community consultations that started in 2019.

The FAIR for Research Software Working Group is jointly convened as a Research Data Alliance (RDA) Working Group, FORCE11 Working Group, and Research Software Alliance (ReSA) Task Force.

Maintenance and Retirement Plan:

  1. The FAIR4RS principles were the outcome of broad, inclusive and extensive public consultation, co-lead by members of the Research Data Alliance, Research Software Alliance and FORCE1 Any revisions or changes to the principles will require a similar process. No single institution or body has ownership over recommendations of the FAIR4RS working group.
  2. The RDA Software Source Code Interest Group is the maintenance home for the principles. Concerns or queries about the principles can be raised at RDA plenary events organised by the SSC IG, where there may be opportunities for adopters to report back on progress.
  3. In order to better facilitate adoption, the form of the principles will remain fixed for 2 years from the release of a 1.0 version.
  4. After 2 years, a broadly consultative and open review will be conducted to consider if the form of the principles are still appropriate and meeting the aims of the community. ReSA has agreed to lead this review effort, in collaboration with RDA  and FORCE11 members and any additional bodies relevant at that time

If a review finds that the principles are no longer meeting the needs of the community, the explanatory text against the reference form of the principles will be updated to indicate that the principles are being abandoned or replaced and why.

 

Output Status: 
Recommendations with RDA Endorsement in Process
Review period start: 
Monday, 21 March, 2022 to Thursday, 21 April, 2022
Group content visibility: 
Public - accessible to all site users
Primary Domain/Field of Expertise: 
Social Sciences, Natural Sciences, Engineering and Technology, Medical and Health Sciences, Agricultural Sciences, Humanities
Domain Agnostic: 
Domain Agnostic
File: 
AttachmentSize
PDF icon FAIR4RS principles v1.0.pdf340.97 KB
  • Dorothea Iglezakis's picture

    Author: Dorothea Iglezakis

    Date: 31 Mar, 2022

    Totally agree with the FAIR4RS principles, only two small comments:

    • The purpose and use of a software seems to be a quite central information that should be part of the (rich, vocabulary using) metadata asked for in F2 and R1. And I am not sure how this could be done via qualified references to other objects (I2) as stated in R1. From my point of view, the information about purpose and use of a software is even more important (at least for searching, but also for reusing) than provenance information about the software. As far as I can tell, this is not really addressed in existing schemata and standards like CodeMeta and Citation File Format. Knowledge Graphs using well known Ontologies, though perfectly suited for this task, are cumbersome and expensive to create and use.
    • As provenance information is for sure important for research software, the recommendation stays quite vague about what exactely is meant by provenance information for software and which target group gets what kind of benefit from this information.

  • Neil Chue Hong's picture

    Author: Neil Chue Hong

    Date: 22 Apr, 2022

    Dear Dorothea Iglezakis,

    Thank you for your comments on the FAIR4RS Principles.

    The purpose and use of a software seems to be a quite central information that should be part of the (rich, vocabulary using) metadata asked for in F2 and R1. And I am not sure how this could be done via qualified references to other objects (I2) as stated in R1. From my point of view, the information about purpose and use of a software is even more important (at least for searching, but also for reusing) than provenance information about the software. As far as I can tell, this is not really addressed in existing schemata and standards like CodeMeta and Citation File Format. Knowledge Graphs using well known Ontologies, though perfectly suited for this task, are cumbersome and expensive to create and use.

     

    Qualified references (I2) are only one part of the metadata that help make software FAIR. As you note, metadata describing the purpose and use (function) of a piece of software is important to improve its findability and reusability. Here, we expect that different community schema and standards continue to evolve, as they have for FAIR data. Citation File Format is solving the specific problem of capturing author metadata. CodeMeta is more expansive, but could be seen as being used in conjunction with other schemas and standards. The FAIR Principles suggest the approach that should be taken, but necessarily cannot prescribe a single way of implementing them. The authors of the principles hope that as adopters of the FAIR4RS principles share theeir experiences, different communities will develop and settle on particular metadata schema and standards for describing software. This may be helped by research software catalogues and directories.

    As provenance information is for sure important for research software, the recommendation stays quite vague about what exactely is meant by provenance information for software and which target group gets what kind of benefit from this information.

    As you have highlighted, provenance information is important but with research software there is still not standardisation about what it means to different groups. Here, we envisage provenance as being the human and machine understandable record of the decisions that led to a version of a piece of software. This might encompass a record of contributors, the code that has been changed or why a change has been made. There is not a specific level of provenance information that we are recommending, as what is useful will change depending on the software. However, we believe that the primary purpose of provenance information is to improve reusability of software by helping establish trust and helping understand how the software was developed.

     

  • Vincent Fazio's picture

    Author: Vincent Fazio

    Date: 08 Apr, 2022

    In "R", the standard requires software to be "understood, modified, built upon" etc. but there is scant attention paid to the role of software documentation, particularly source code documentation. Without documentation of internals it is difficult for software to be "understood, modified, built upon".

    "R3. Software meets domain-relevant community standard" only pushes the issue on to the communities, but not every piece of software has a relevant community, and not every community standard is adequate terms of software documentation.

    I think your approach would be better served by requiring that if the source code is available then the internals of that software should be documented in some shape or form.

  • Neil Chue Hong's picture

    Author: Neil Chue Hong

    Date: 22 Apr, 2022

    Dear Vincent Fazio,

    thank you for your comments on the FAIR4RS Principles.

    In "R", the standard requires software to be "understood, modified, built upon" etc. but there is scant attention paid to the role of software documentation, particularly source code documentation. Without documentation of internals it is difficult for software to be "understood, modified, built upon".

    "R3. Software meets domain-relevant community standard" only pushes the issue on to the communities, but not every piece of software has a relevant community, and not every community standard is adequate terms of software documentation.

    I think your approach would be better served by requiring that if the source code is available then the internals of that software should be documented in some shape or form.

     

    As you point out, software documentation is an important requirement for making software reusable but not every software has a relevant research community standard for documentation. Nevertheless, as we note in the document, there are also standards and guidance based on the programming language that can be followed to improve software documentation, there are more general software documentation guidelines which can be applied to research software along with checklists from research software initiatives like JOSS, rOpenSci and PyOpenSci, and we expect more research communities to develop guidance (see, for example, guidance for the earth sciences).

    In general, we have tried to recommend, rather than require, in the FAIR4RS Principles recognising that, for most, the implementation of the principles is an incremental process of gradual but continued improvement.

  • Karin Dassas's picture

    Author: Karin Dassas

    Date: 21 Apr, 2022

    On behalf of the Ecoinfo* working group on SW ecoconception (Cyrille BonamyCédric Boudinet , Laurent BourgèsKarin DassasLaurent Lefèvre, Benjamin Nimassi, Francis Vivat), I would like to add a point on the environmental impact of the software. 

    Making the SW FAIR could avoid redevelopping and running again software unnecessarily, what is not neutral from an environmental point of view.

    This aspect could be maybe highlighted in the introduction of the document. 

    CO2 emission of SW execution is indeed not negligible. More information on this subject can be found there : 
    https://hal.archives-ouvertes.fr/hal-03009741/

    Notice that FAIR4RS reference will be added in the next version of this brochure (available in may).
    Any help to translate the next brochure will be welcomed :-)

    *EcoInfo is a french service group of the CNRS (Centre Natoional de la Recherche Scientifique), spread throughout the country. It offers services online or in the form of support and/or auditing with the general objective of evaluating and reducing the impact of IT in Higher Education and Research (ESR), whatever the thema.

     

  • Neil Chue Hong's picture

    Author: Neil Chue Hong

    Date: 22 Apr, 2022

    Dear Karin Dassas,

    Thank you for your comments on the FAIR4RS Principles.

    On behalf of the Ecoinfo* working group on SW ecoconception (Cyrille BonamyCédric Boudinet , Laurent BourgèsKarin DassasLaurent Lefèvre, Benjamin Nimassi, Francis Vivat), I would like to add a point on the environmental impact of the software. 

    Making the SW FAIR could avoid redevelopping and running again software unnecessarily, what is not neutral from an environmental point of view.

    This aspect could be maybe highlighted in the introduction of the document. 

    Indeed, this is a good point to make and by making software FAIR other people may be more likely to use and contribute to existing software which could have the effect of increasing the amouont of effort available to help optimise the software and reduce the environmental impact of the software. As this is a benefit that is a couple of steps removed from the principles, it may not make sense to highlight in this document, but a use case of how the adoption of the FAIR4RS principles has helped reduce the environmental impact of a specific piece of software would be a very good thing to present at a future Software Source Code IG session, which is where future conversation on the FAIR4RS Principles will take place once this working group concludes.

     

    Notice that FAIR4RS reference will be added in the next version of this brochure (available in may).
    Any help to translate the next brochure will be welcomed :-)

    That is wonderful, thank you. We also understand the effort it takes to translate documents - perhaps some of our French-speaking contributors might be interested in volunteering!

submit a comment