FAIR Principles for Research Software (FAIR4RS Principles)

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.

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.

Dear Karin Dassas,

Thank you for your comments on the FAIR4RS Principles.

On behalf of the Ecoinfo* working group on SW ecoconception (Cyrille Bonamy, Cédric Boudinet , Laurent Bourgès, Karin Dassas, Laurent 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!