dataesr/scientific-paragraphs-categorization huggingface dataset:
For instance, we suggest following the PEP 8 Style Guide for Python Code or Google's R Style Guide for R code (https://google. github. io/styleguide/Rguide). Finally, we recommend ensuring that inputs/outputs of the software follow any applicable community standards (e. g. , General Feature Format (GFF) for genomic annotation files) as this is essential for interoperability. We refer to FAIRsharing Registry for finding relevant standards. We leave out recommendations on using container technologies as this is a complex topic that we deem out of the scope of the minimal guidelines we are aiming for here. Category 2: Include metadata. From the reviewed resources, 24 have made a recommendation of metadata files and ontologies to use for research software. A majority of them  6, 8, 10, [12] [13] [14] [17] [18] [19] 24, 25, [31] [32] [33] [34] [35] [36]  suggest following the guidelines of the CodeMeta Project for including metadata in research software.
json and stored in the root directory of the software. The Software Heritage group has developed a CodeMeta generator (https://codemeta. github. io/codemeta-generator) that can be used to create a codemeta. json file or edit an existing one. Similar tools are also available to include a codemeta. json file in R packages  37. Including a citation file following the Citation File Format (CFF) is another popular suggestion amongst the reviewed resources  13, 14, 18, 19, [25] [26] [27] [28] 30, [34] [35] [36]. The CFF was developed by a group of academics assembled under the group "Development and implementation of a standard format for CITATION files"  38. The goal of the CFF is to provide an all-purpose citation format and specifically provide optimized means for the citation of software via the provision of software-specific reference keys and types.
CFF files must be named CITATION. cff, implemented in YAML 1. 2, which is a machine-readable format that optimizes human readability and must be stored in the root directory of the software. The CFF file initializer (https://citation-file-format. github. io/ cff-initializer-javascript) is mentioned by several reviewed resources as a tool for easily generating a CITATION. cff file. Note that the CITATION. cff file integrates with the GitHub citation feature such that if a CITATION. cff file is included in the root folder of a GitHub repository, a "Cite this repository" option is automatically displayed on the repository landing page making it easier to cite a software repository on GitHub. The codemeta. json and CITATION. cff are two general metadata files that can be used for any research software repository.
github. com) or Read the Docs (https://readthedocs. org). Several resources are suggested in the reviewed literature to help with preparing documentation for research software: Write the Docs, Doxygen, Sphinx3, Javadoc (Java code), Roxygen (R code). Documenting changes between versions of software in a CHANGELOG file is also suggested  19. There is clearly a lack of community agreement on metadata files and ontologies to use for documenting research software. As a result, we formulated our recommendations for fulfilling the instructions in Category 2 by combining the findings from this review with our internal assessment and external suggestions received when consensus was lacking. We recommend including both a codemeta. json and a CITATION. cff metadata files in the software code's root directory.
0 lice nses  12, 14, 18, 21, 26, 47. The Software Package Data Exchange (SPDX) (https://spdx. dev), Choose a License (https:// choosealicense. com), and the lesson on license from the 4 Simple Recommendations for Open Source Software (https://softdev4research. github. io/4OSS-lesson/03-use-license/index. html) are some suggested resources for getting help with selecting a suitable license. It is typically suggested to include the license terms in a LICENSE. txt or LICENSE. md file stored in the root directory of the software  21, 22, 24, 28. After analyzing these findings along with our own assessment and external suggestions, we recommend fulfilling the instructions from Category 3 by including the license term in a LICENSE. txt or LICENSE. md file placed in the software's root directory.
Providing an executable  9  and some input/result data  19, 23, 48  when available is also recommended. From the reviewed resources, 27 made a suggestion about repositories to use for sharing research software. Three types of repositories are typically mentioned: archival, deployment, and domain-specific. The Registry of Research Data Repositories (https://www. re3data. org) is often mentioned as a tool for finding a suitable repository. Zenodo (https://zenodo. org) is the most commonly suggested archival repository across all reviewed studies  6, 8, [12] [13] [14] [15] [17] [18] [19] 21, [25] [26] [27] [28] 31, 32, 34, 36, [47] [48] [49] [50]. Funded by the European Commission and developed and hosted by the Centre Européen pour la Recherche Nucléaire (CERN), Zenodo allows any digital resources, including research software, to be shared and preserved in line with the FAIR principles (https://about.
zenodo. org/principles). Zenodo assigns a separate Digital Object Identifier (DOI) for each released version of a software and also creates a high-level DOI that refers to all versions  51. Of the 50,000 plus DOIs registered for software, more than 80% were registered via Zenodo showing its popularity amongst the research software community  32, 52. The integration between GitHub and Zenodo facilitates the automatic archiving on Zenodo for each GitHub release of the software. Figshare (https://figshare. com) is also a highly recommended archival repository  6, 14, 15, 18, 21, 23, 27, [48] [49] [50]. Figshare is a repository supported by Digital Science where researchers can preserve and share any research outputs, including research software, in line with the FAIR principles  53. Archiving GitHub repositories on Figshare is also made easy through a tool developed in collaboration with the Mozilla Science Lab (https://mozillascience.
github. io/code-research-object). Software Heritage (https://www. softwareheritage. org) is a commonly suggested archival repository as well  6, 8, [12] [13] [14] 17, 19, 25, 31, 32, 50, 54. Software Heritage is an international initiative to provide a universal archive and reference system for all software. It automatically and regularly harvests source code from version control system platforms such as GitHub and also allows anyone to initiate the submission of their source code for archival. Software Heritage assigns intrinsic identifiers that follow a standardized format called SoftWare Heritage persistent IDentifiers (SWHIDs). Contrary to Zenodo and Figshare, unique identifiers are assigned to all artifacts over all levels of granularity such as project status, project release, state of source code, and code fragment, which can be useful to unambiguously refer to any component of a software.
Some of the reviewed resources 6,17,18,25,31,50 mention using deployment repositories which are typically language-specific such as PyPI (https://pypi. org) and Conda (https://conda. io) for Python packages, CRAN (https://cran. r-project. org) for R packages  55  , and Dockstore (https://dockstore. org) for Docker-based tools. Only two biomedical-specific repositories were mentioned in the reviewed studies  6, 48  : ModelDB for computational neuroscience models  56  and Bioconductor for R-packages aimed at the analysis of genomics data  57, 58. After considering these findings, our internal assessment, and the external suggestions we received, we have identified three recommendations for meeting the instructions in Category 4. If applicable, we suggest sharing each version of a software on a deployment repository (e.
g. , PyPI or Conda for Python packages, CRAN for R package, Dockstore for Docker-based tools). While such repositories do not provide unique and persistent identifiers as required in the FAIR4RS, this is still useful for increasing the findability and reusability of the software. In addition, we suggest always archiving each version of a software on Zenodo or Figshare as they both allow software to be archived in line with the FAIR4RS principles. Zenodo is preferable due to its popularity for archiving research software. The source code of the software with all the above-mentioned metadata files must be archived. Executables and sample input and out data, if available, must be archived as well. Finally, we suggest archiving the software on Software Heritage directly from your version control system platform as it will automatically assign a unique identifier for all levels of granularity.
Note that there is no community agreement on the identifier (e. g. , DOI or SWHID) to use for software, which is a gap that will need to be addressed by the community. Category 5: Register on a registry. From the reviewed resources, 8 made a suggestion about registries to use for research software  6, 8, 12, 17, 24, 25, 34, 59. The repositories Zenodo, Figshare, Software Heritage, CRAN, PyPI, and Conda are also mentioned as registries in the reviewed literature since they require specific metadata that is used for indexing. bio. tools (https://bio. tools)  43  is the most commonly suggested registry. It is supported by ELIXIR, an intergovernmental organization that brings together life science resources from across Europe and whose goal is to coordinate these resources so that they form a single infrastructure.
tools and the RRID portal to share software metadata and cross-link entries. Based on these findings, combined with our own assessment and external suggestions we received, our recommendation for fulfilling instructions from Category 5 is to register the software on bio. tools. Even if Zenodo and Figshare already act as registries, it is still suggested to register on bio. tools to increase findability and create additional rich metadata about the software following biotoolsSchema. The software can optionally be registered on the RRIDs portal as well. Registering on bio. tools and the RRID portal is only required once but the registry-specific metadata must be updated as needed for each new software version. FAIR Biomedical research software guidelines. To make the above-mentioned recommendations easy to implement, we organized them into step-by-step guidelines that align with the typical software development process.
This led to the FAIR Biomedical Research Software (FAIR-BioRS) guidelines. The first versions of the guidelines (v1. 0. 0 and v1. 0. 1) were based on the FAIR4RS principles v0. 3. They then evolved as we aligned our work with the FAIR4RS principles v1. 0 as presented in the manuscript to the FAIR-BioRS guidelines v2. 0. 0 presented in Table  1. Implementing these guidelines will ensure compliance with the FAIR4RS principles as shown in the crosswalk presented in Supplementary Table  2. We have established a "FAIR-BioRS" organization on GitHub to maintain all the related resources (http://github. com/FAIR-BioRS). These guidelines and the crosswalk are maintained in a GitHub repository called "Guidelines" within that organization. It documents all the versions and is also archived on Zenodo every time a new version is released  61.
This repository will serve as a tool to collect community feedback on the FAIR-BioRS guidelines. New versions of the guidelines, which will be established based on community feedback or the evolution of current standards, will be maintained there. We recommend readers consult it to access the latest versions of the guidelines. FAIRshare. Guidelines typically have little effect and are very unlikely to be adopted without proper tools to support them. Tools and resources are available to implement some steps of the FAIR-BioRS guidelines as mentioned in our recommendations above, but they are dispersed and not logically connected to streamline the process. Therefore, we developed and integrated a workflow to implement the FAIR-BioRS guidelines in our software application called FAIRshare. FAIRshare is aimed at streamlining the processes for making biomedical research data and software FAIR.
When applicable, also provide the following fields: "isPartOf ", "hasPart", and "relatedLink". See the CodeMeta documentation for a definition of the fields. 4. 2. Include a CITATION. cff metadata file in the root directory of the software. The CFF file initializer can be used. Provide, at least, the following fields: "abstract", "identifiers", "keywords", "license", and "date-released" along with "given-names", "family-names" and "affiliation" for each author. See the CFF documentation for a definition of the fields. Step 5. Share software on a repository 5. 1. If applicable, share the software on a deployment repository e. g. , PyPI or Conda for Python packages, npm registry for JavaScript packages, CRAN for R packages or Bioconductors for R-packages aimed at the analysis of genomics data, Dockstore for Docker-based tools, etc.
Do this for each version release of your software. 5. 2. Share the software on the archival repository Zenodo (suggested) or Figshare. The source code of the software with all the abovementioned metadata files must be archived. Executables and sample input and output data must be included as well if available. Do this for each version release of your software. 5. 3. Archive the software repository on Software Heritage directly from your version control system platform. You can use the Software Heritage "save code now" page. This is only required once as Software Heritage will then periodically archive your source code automatically.
3. In step 1, FAIRshare asks the user to select the location of their software directory. FAIRshare provides users with the option to select a directory from their computer or select one of their GitHub repositories. If the user selects GitHub, FAIRshare provides an interface to connect FAIRshare to their GitHub account. In step 2, FAIRshare asks a series of "Yes/No" questions to verify that the user has followed applicable standards and best practices during the development and documentation of the software as dictated by Steps 2 and 3 of the FAIR-BioRS guidelines. Links to the relevant resources on standards and best practices suggested by the FAIR-BioRS guidelines are provided in the interface. In step 3, FAIRshare provides a convenient form-type interface so the user can provide information about their software.
g. , "National Institutes of Health" is suggested for the "Funder" field, "Scientific" is suggested for the "Software type" field, etc. ). If any of the fields require an entry following a controlled vocabulary for the codemeta. json or CITATION. cff metadata files, FAIRshare typically provides a dropdown list of standardized options to select from to ensure metadata files are generated without error. FAIRshare also makes it mandatory to provide inputs for the metadata fields that were deemed essential by the FAIR-BioRS guidelines. In step 4, the user is prompted to select a license for their software if a LICENSE file is not found in their software directory. A dropdown list is provided to select any one of the licenses recommended by the OSI. The "MIT" and "Apache 2. 0" licenses are suggested in the user interface since they have been deemed optimal for making research software FAIR.
The user can read and edit the terms of a selected license directly in the app and can request FAIRshare to include a LICENSE file with associated terms in their software. In step 5, the user is prompted to select an archival repository to share their software files. In the current release, FAIRshare supports sharing on both Zenodo and Figshare. A convenient interface is provided to connect FAIRshare to the user's Zenodo or Figshare account using a token. Upon login, the user is prompted to provide information about the software that is required by the selected repository. FAIRshare provides a form-type interface such that the user can easily input that information. The interface closely mimics the interface from the selected repository platform to  maintain familiarity. Since most of the information required by Zenodo and Figshare is similar to that required in the codemeta.
json file, FAIRshare pre-populates the form based on user inputs during step 3. Step 6 depends on the location of the user's software files as specified during step 1: • If the source files are located on the user's computer, a summary of the user's software files, including files to be generated by FAIRshare, is provided to the user in step 6. Once the user hits the "Start upload" button, FAIRshare creates a draft deposition on the selected archival repository to reserve a DOI, generates the codemeta. json and CITATION metadata files (with the reserved DOI included) and LICENSE file in the software folder, zips the folder, and uploads it in the draft deposition to create a draft software dataset. • If the files are located on a GitHub repository, FAIRshare provides an interface to include any additional files in their archive if desired besides those already on their GitHub repository (e.
g. , executables). Then, a summary of the user's software files, including files to be generated by FAIRshare, is shown to the user in step 6. Once the user hits the "Start upload" button, FAIRshare creates a draft deposition on the selected archival repository to reserve a DOI, generate and push the codemeta. json and CITATION metadata files (with the reserved DOI included) and LICENSE file on their GitHub repository. The GitHub repository content is then downloaded, and any additional files specified by the user are included in the downloaded folder. FAIRshare then zips that software folder and uploads it into the draft deposition to create a draft software dataset. Upon completion, the user is prompted in step 7 to publish their draft dataset on the archival repository, such that it becomes publicly accessible, and is also given the option to create a GitHub release of their software application.
A message is shown to the user after completing step 7 to encourage them to archive their software on Software Heritage and register it on bio. tools. If the user selects to register on their software on bio. tools, an interface is provided in step 8 where the user can connect FAIRshare to their bio. tools account, enter basic metadata required by bio. tools (which is prepopulated based on information already available from the codemeta. json file), and register their software. Besides combining all required resources for making software FAIR into a single interface, FAIRshare also provides some advantages over existing tools. For instance, the Zenodo/GitHub integration allows users to automatically create a Zenodo deposit every time a GitHub release is created. However, it does not allow to get the DOI of the deposit before it is published and therefore it cannot be included in the codemeta.
This workflow is incorporated in FAIRshare, a software application aimed at simplifying the processes for making biomedical research data and software FAIR. FAIRshare takes the user's software-related dataset as input when they are ready to publish a new software version and walks them step-by-step into implementing the FAIR-BioRS guidelines through an intuitive graphical user interface and automation. This way, researchers can implement the FAIR-BioRS guidelines even without prior knowledge of them and in fact learn about these guidelines along the way. FAIRshare is free and open-source to encourage community contributions to keep up with the ever-evolving FAIR guidelines. While establishing the FAIR-BioRS guidelines, we identified several practical gaps and needs for complying with the FAIR4RS principles.
In parallel, we plan to integrate additional resources in FAIRshare such as sharing on Software Heritage, registering on the RRID portal, or working from other version control system platforms than GitHub such as Bitbucket and GitLab. We also plan to include additional automation to further streamline the FAIRshare process for making research software FAIR. These include for instance automatically validating the implementation of language-specific standards or prefilling keywords and descriptions using Natural Language Processing. A major limitation of FAIRshare is that it is intended to help only when a user is ready to publish a new version of their software, when it might be inconvenient for the user to go back and make changes to their source code, e. g. for aligning with language specific standards or adding in code comments.
We are therefore planning the development of a tool that integrates directly with version control system platforms and assists users in complying with the FAIR-BioRS guidelines right from the beginning and throughout the development of their software. As the FAIR-BioRS guidelines, FAIRshare, and other resources related to the FAIR-BioRS guidelines are expected to evolve over time, we have established a dedicated GitHub repository called "Hub" in the FAIR-BioRS organization (https://github. com/FAIR-BioRS/Hub). We refer to that repository to access the latest versions of all resources related to the FAIR-BioRS guidelines and track the interaction between their different versions. By making the FAIR-BioRS guidelines an integral part of their software development practices, we aspire for the biomedical research software community to wholeheartedly embrace FAIR practices.
This includes code, scripts, models, notebooks, libraries, executables, and other forms as long as it fits the previously cited definition. Given that our work was born with the aim of making COVID-19-related data and research software FAIR, our focus was on deriving guidelines for biomedical research software, although some of the findings may be applicable to other fields of research. Deriving concise instructions for fulfilling the FAIR4RS principles. The FAIR4RS principles v1. 0 contain 17 guiding principles for FAIR research software (vs 15 in the original FAIR principles), including 6 for Findability, 4 for Accessibility, 2 for Interoperability, and 5 for Reusability. We analyzed details about each principle provided in the FAIR4RS v1. 0 write-up  11  and its introduction manuscript  12.
• Group 2: Subsequently, we reviewed the resources referenced in studies from group 1 that were deemed relevant based on their title and abstract. • Group 3: We also reviewed resources listed as of February 2023 in the FAIR4Software reading materials (https://www. rd-alliance. org/group/software-source-code-ig/wiki/fair4software-reading-materials), FAIR4RS Subgroup 4 reading list of new research  65  , and the Zenodo community page of the FAIR4RS Working Group (https://zenodo. org/communities/fair4rs) that were deemed relevant based on their title and abstract and were not already encountered in the previous groups. • Group 4: Given our focus on biomedical research software, we also searched literature related to FAIR for research software on PubMed. The start period was set to January 2015 since the concept of FAIR data was introduced then, and the end period was February 2023.
This is available in the "resourcesReview" sheet of the "data. xlsx" file associated with this dataset (c. f. Data Availability section). Subsequently, we only retained keywords such as the name of the suggested metadata file, repository, etc. to facilitate further analysis. Information from any of the topics that applied to only specific fields of research other than biomedical were left out. This is available in the "resourcesReviewKeywords" sheet of the same file. We developed a Jupyter notebook-based script (c. f. Code Availability section) that used scientific packages such as pandas  66, 67  , Matplotlib  68, 69  , and seaborn  70  to analyze our review data. We used findings from the reviewed resources, combined with our own assessment and external suggestions (c. f. Discussion section) when consensus was lacking in the literature, to derive recommendations for fulfilling the instructions from each category.