-
Notifications
You must be signed in to change notification settings - Fork 1
FAIRness assessment for software
Table of contents
- FAIRness assessment for software
- Background
- BioHackathon
In this project we want to figure it out how the FAIR principles apply to software, i.e., applications and tools, and how the FAIR metrics should be interpreted for this case. We want to find answers to the following questions:
- Question 1. What is the scope we want to cover? Could/Should all sort of software be FAIR? We could consider here research software, programming languages, web services, commercial software, etc.
- Question 2. What FAIR principles can be directly adopted?
- Question 3. What FAIR principles should be adapted and how?
- Question 4. Anything on the principles that should be dismissed?
- Question 5. What should be added to the principles for the software case?
These recommendations aim to improve the quality and sustainability of research software. These recommendations should be applied following existing and complementary guidelines like best practices, manifestos and principles that describe more specific procedures on how to develop and manage software. The 4OSS recommendations are:
- Make source code publicly open from day one
- Make software easy to discover by providing software metadata via a popular community registry
- Adopt a license and comply with the license of third-party dependencies
- Define clear and transparent contribution, governance and communication processes
Citation: Jiménez RC, Kuzak M, Alhamdoosh M et al. Four simple recommendations to encourage best practices in research software [version 1; referees: 3 approved]. F1000Research 2017, 6:876 (https://doi.org/10.12688/f1000research.11407.1)
These 10 things are the result of a 2-day brainstorming session with people from the Carpentires:
- Findability
- Add a description
- Register it
- Use unique persistent identifiers
- Accessibility
- Provide a download
- Interoperability
- Explain functionality
- Use standard formats to describe input/output
- Reusability
- Provide documentation
- Use a license
- Add "how to cite"
- Follow best practices
FAIR principles rely on community agreements; therefore, a community should be created and define what FAIR principles apply to it and what stadards are required. The FAIR evaluation tool (under developement during this BioHackathon), will allow communities to register, select those principles that apply to them, and point to their standards validation services.
The FAIR evaluation tool will assess resources against those principles selected by a community. In this sense, resources will not be universally FAIR but FAIR according to a registered community.
Research software accross multiples sciences, using the Life Sciences domain as an initial example. We will need to assess later whether a community per science is advisable/required. Research software in this context could be open source or not, desktop or web service, freely available or via memmbership or payment. The main condition is that it has been developed targetting problems pertaining to a particular science domain.
Why? Reproducibility is crucial for sciences therefore, required metadata for research software might differ (be more strict) from commercial stadards where software can be seen more as product than a supporting scientific object.
- Metadata
Because of A2 "metadata should be accessible even when the data is no longer availabe", you should register your software, i.e., data in this case, somewhere else. There are some possibilities here, for instance:
- Use a DOI provider so you automatically get metadata via content negotiation; you will not be able to decide which metadata is provided though, your metadata identifier will be that DOI
- Use Zenodo to link to a GitHub repository for a particular release, it will automatically add some metadata as schem.org markup on their web pages, you have no control on the metadata provided. It will also assign a DOI to your software so you will also get that metadata, still your metadata identifier will be that DOI
- Register your software in a specialized registry agreed by your community so the metadata will be that one also agreed on, your metadata identifier will be provided by the chosen registry
- Provide metadata together with your data together
- Data
- Register (so far for free) a PURL for your organization/team/group/your software and create an entry for the software you are describing
- Use a URL; as far as that domain is alive, it will be unique and "persistence". This URL sould point wither to your source code or to a dowload page
- Metadata and data
- Provide a web page explaining your policy regading globality, unicity and persistence for your metadata and data identifiers. If you are using an external place for your metadata, you should link to their policy, for your data identifier you will have to provide your data
- Provide a link to a page explaining the schema behind your identifiers (so you show you are aware of it and its implications), you can use FAIRsharing for this purpose
- FAIR validator should provide the properties to be used to link to those policy pages
- Communtiy needs to define what rich metadata should be included
- Community needs to provide a validator against their metadata specification/guidelines
- Community will decide the property required to include the data identifier
- Metadata
- If you used a DOI provider or a registry, use their search capabilities. Make sure you can use the identifier on their to find your metadata
- If you provide your metadata together with your data, a search engine could fulfill this requirement but the FAIR validator might not be able to check it due to search engine restrictions
- Data
- See considerations above for metadata
- FAIR validator should define the properties to indicate what the protocol is and whether it is A1.1. or A1.2. for both metadata and data
- If a community agreed registry is used, it should take care of comply to such property for the metadata case
- If DOI is used, the community should at least try to reach DOI providers for them to include the metadata property required by the FAIR validator
- Metadata
- Either DOI or registry URL, both of them can be retrieve via HTTP or HTTPS
- Data
- As URLs are in used here, retrievable via either HTTP or HTTPS
- FAIR validator should provide the properties to indicate authentication and authorization procedures
- In this case, no validation regarding data will be done, only for metadata
I1. (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation.
- Not applicable for software
- Not applicable for software
- Community will agree on what properties use to refer to other software or digital resources
- FAIR validator should provide the property to be used in this case for both metadata and data
- If a community agreed registry is used, it should take care of comply to such property for the metadata case
- If DOI is used, the community should at least try to reach DOI providers for them to include the metadata property required by the FAIR validator
- FAIR validator should provide the property to be used in this case for both metadata and data
- If a community agreed registry is used, it should take care of comply to such property for the metadata case
- If DOI is used, the community should at least try to reach DOI providers for them to include the metadata property required by the FAIR validator