updated 2.0.0 added

versions/v2.0.0/README.md

@@ -18,15 +18,15 @@
 
 ## 3. Document software 
 
-3.1. Maintain the documentation in a file called "README" using plain text or markdown syntax. Locate it in the root directory of the software. Mature/complex software may require additional, more sophisticated documentation that can be developed e.g. using tools such as [GitHub pages](https://pages.github.com/), [Read the Docs](https://readthedocs.org/), or [Docusaurus](https://docusaurus.io/). The following aspects must be documented as applicable
+3.1. Maintain the documentation in a file called "README" using plain text or markdown syntax. Locate it in the root directory of the software. Mature/complex software may require additional, more sophisticated documentation that can be developed e.g. using tools such as [GitHub pages](https://pages.github.com/) or [Read the Docs](https://readthedocs.org/). The following aspects must be documented as applicable
  - Overall description of the software (e.g., in an “About” section)
  - High-level dependencies of the software (e.g., Node or Python version)
  - Inputs and outputs of the software, parameters and data required to run the software
  - The standards followed
  - How to contribute to the software
  - How to cite the software
 
-In addition, follow any community agreed standard documentation approach when available (e.g., the [Common Workflow Language (CWL)](https://www.commonwl.org/) for describing command line tools).
+In addition, follow any community-agreed standard documentation approach when available (e.g., the [Common Workflow Language (CWL)](https://www.commonwl.org/) for describing command line tools).
 
 3.2. Document changes between different versions of the software in a file called “CHANGELOG” using plain text or markdown syntax. Locate it in the root directory of the software. We suggest following the “[Keep a changelog](https://keepachangelog.com/)” conventions for the content of the CHANGELOG file and the [Semantic Versioning v2.0.0](https://semver.org/spec/v2.0.0.html) for version numbers.
 

versions/v2.0.0/compliance-with-FAIR4RS-principles.md → versions/v2.0.0/crosswalk-with-FAIR4RS-principles.md

@@ -11,68 +11,68 @@
 <tbody>
 
 <tr>
-<td>F1. Sofware is assigned a globally unique and persistent identifier.</td>
-<td>Archiving the software on Zenodo/Figshare (step 5.2) will assign a Digital Object Identifier (DOI) which is a unique and persistent identifier. Archiving the software on Software Heritage (step 5.3) will assign a SoftWare Heritage persistent IDentifier (SWHID) which is also a unique and persistent identifier. Bio.tools/RRID Portal will issue a unique and persistent identifier as well (bio.tools ID and RRID, respectively) when the software is registered (step 6).&nbsp;</td>
+<td>F1. Software is assigned a globally unique and persistent identifier.</td>
+<td>Archiving the software on Zenodo/Figshare (step 5.2) will assign a Digital Object Identifier (DOI) which is a unique and persistent identifier. Archiving the software on Software Heritage (step 5.3) will assign a SoftWare Heritage persistent IDentifier (SWHID) which is also a unique and persistent identifier. Bio.tools/RRID Portal will issue a unique and persistent identifier as well (bio.tools ID and RRID, respectively) when the software is registered (step 6).</td>
 </tr>
 <tr>
-<td>F1.1. Components of the software representing levels of granularity are assigned distinct identifiers.&nbsp;</td>
+<td>F1.1. Components of the software representing levels of granularity are assigned distinct identifiers.</td>
 <td>Bio.tools/RRID Portal (step 6) will assign a unique identifier for the entire software. Archiving each version of the software on Zenodo/Figshare (step 5.2) will assign a distinct identifier (DOI) for each version. Archiving the software on Software Heritage (step 5.3) will assign a distinct identifier (SWHID) to any level of granularity of the software (software, releases, files, commits, code fragments, etc.).</td>
 </tr>
 <tr>
-<td>F1.2. Different versions of the software are assigned distinct identifiers.&nbsp;</td>
+<td>F1.2. Different versions of the software are assigned distinct identifiers.</td>
 <td>Archiving each version of the software on Zenodo/Figshare (step 5.2) will assign a distinct identifier (DOI) for each version. Archiving on Software Heritage (step 5.3) will assign a distinct identifier for each version release of the software as well. Changes between versions will be documented in the CHANGELOG file (step 3.2).</td>
 </tr>
 <tr>
-<td>F2. Software is described with rich metadata.&nbsp;</td>
-<td>Rich metadata covering a variety of aspects will be provided through the code-level documentation (step 2.1), the dependencies recording (step 2.2), the instructed documentation (step 3), the prescribed metadata files (step 4), the repository-specific metadata on Zenodo/Figshare (step 5.2), and the registry-specific metadata on bio.tools/RRID Portal (step 6).&nbsp;</td>
+<td>F2. Software is described with rich metadata.</td>
+<td>Rich metadata covering a variety of aspects will be provided through the code-level documentation (step 2.1), the dependencies recording (step 2.2), the instructed documentation (step 3), the prescribed metadata files (step 4), the repository-specific metadata on Zenodo/Figshare (step 5.2), and the registry-specific metadata on bio.tools/RRID Portal (step 6).</td>
 </tr>
 <tr>
-<td>F3. Metadata clearly and explicitly include the identifier of the software they describe.&nbsp;</td>
-<td>The README file will include the DOI from Zenodo/Figshare in a &ldquo;How to cite&rdquo; or similar section (step 3.1). The codemeta.json and CITATION.cff files (step 4) will include the DOI from Zenodo/Figshare in their <span style="color: #1f2328;">"identifier" and "identifiers" fields, respectively.</span> The DOI from Zenodo/Figshare is always included in that repository&rsquo;s metadata (step 5.2). The DOI will also be included in the bio.tools/RRID portal&rsquo;s metadata which also includes their respective IDs (step 6).</td>
+<td>F3. Metadata clearly and explicitly include the identifier of the software they describe.</td>
+<td>The README file will include the DOI from Zenodo/Figshare in a "How to cite"; or similar section (step 3.1). The codemeta.json and CITATION.cff files (step 4) will include the DOI from Zenodo/Figshare in their "identifier" and "identifiers" fields, respectively. The DOI from Zenodo/Figshare is always included in that repository's metadata (step 5.2). The DOI will also be included in the bio.tools/RRID portal's metadata which also includes their respective IDs (step 6).</td>
 </tr>
 <tr>
-<td>F4. Metadata are FAIR, searchable and indexable.&nbsp;</td>
+<td>F4. Metadata are FAIR, searchable and indexable.</td>
 <td>FAIR, searchable, and indexable metadata that follow community standards and use controlled vocabularies are provided through Zenodo (aligns with DataCite's Metadata Schema minimum and recommended terms, with a few additional enrichments)/Figshare (aligns with DataCite's Metadata Schema) (step 5.2), Software Heritage (follows the CodeMeta vocabulary) (step 5.3), and Bio.tools (uses the biotoolsSchema and EDAM ontology)/RRID Portal (follows the Resource Description Framework (RDF) and aligns with the Biomedical Resource Ontology (BRO) and the Eagle-i Resource Ontology (ERO) along with few additions) (step 6). The prescribed license documentation (step 1.2), development best practices (steps 2.1 and 2.2), documentation of the software (step 3), and prescribed metadata files (step 4) will contain additional metadata that also follow community standards, use controlled vocabularies, and is typically searchable through the suggested version system control platforms (step 1.1).</td>
 </tr>
 <tr>
 <td>A1. Software is retrievable by its identifier using a standardised communications protocol.</td>
 <td>The software archive can be retrieved by the DOI generated by Zenodo/Figshare (step 5.2) using HTTP, which is a standardized protocol. The software will be retrievable through the version control system platform (step 1.1), the deployment repository if applicable (step 5.1), and Software Heritage (Step 5.3) also using HTTP.</td>
 </tr>
 <tr>
-<td>A1.1. The protocol is open, free, and universally implementable.&nbsp;</td>
+<td>A1.1. The protocol is open, free, and universally implementable.</td>
 <td>The HTTP protocol is open, free, and universally implementable.</td>
 </tr>
 <tr>
-<td>A1.2. The protocol allows for an authentication and authorization procedure, where necessary.&nbsp;</td>
-<td>Version control systems platforms (step 1.1), deployment repositories (step 5.1), and Zenodo/Figshare (step 5.2) have a process in place to allow for an authentication and authorization procedure for software shared under closed/restricted access. Everything on Software Heritage (Step 5.3) is open access and does not require any authentication or authorization.&nbsp;</td>
+<td>A1.2. The protocol allows for an authentication and authorization procedure, where necessary.</td>
+<td>Version control systems platforms (step 1.1), deployment repositories (step 5.1), and Zenodo/Figshare (step 5.2) have a process in place to allow for an authentication and authorization procedure for software shared under closed/restricted access. Everything on Software Heritage (Step 5.3) is open access and does not require any authentication or authorization.</td>
 </tr>
 <tr>
-<td>A2. Metadata are accessible, even when the software is no longer available.&nbsp;</td>
-<td>Once archived on Zenodo or Figshare (step 5.2) and on Software Heritage (step 5.3) both the software and metadata will always be available and accessible for the lifetime of these repositories. Moreover, Zenodo and Figshare send metadata from the software to DataCite for generating a DOI and that metadata will always remain accessible through the DataCite&rsquo;s registry. Additionally, Zenodo keeps metadata stored in high-availability database servers separate from the software files. Bio.tools/RRID Portal (step 6) will also keep the metadata accessible even if the software is no longer available e.g., on the version control system platform or any of the archiving repository.</td>
+<td>A2. Metadata are accessible, even when the software is no longer available.</td>
+<td>Once archived on Zenodo or Figshare (step 5.2) and on Software Heritage (step 5.3) both the software and metadata will always be available and accessible for the lifetime of these repositories. Moreover, Zenodo and Figshare send metadata from the software to DataCite for generating a DOI and that metadata will always remain accessible through DataCite's registry. Additionally, Zenodo keeps metadata stored in high-availability database servers separate from the software files. Bio.tools/RRID Portal (step 6) will also keep the metadata accessible even if the software is no longer available e.g., on the version control system platform or any of the archiving repositories.</td>
 </tr>
 <tr>
-<td>I1. Software reads, writes and exchanges data in a way that meets domain-relevant community standards.&nbsp;</td>
-<td>Step 2.4 will ensure that the inputs/outputs of the software follow any applicable community standards. Those standards will be documented in the README file under a &ldquo;Standards followed&rdquo; or similar section (step 3.1). They can also be documented in the bio.tools metadata using the EDAM ontology to specify the nature and format of the input and output data.</td>
+<td>I1. Software reads, writes and exchanges data in a way that meets domain-relevant community standards.</td>
+<td>Step 2.4 will ensure that the inputs/outputs of the software follow any applicable community standards. Those standards will be documented in the README file under a "Standards followed" or similar section (step 3.1). They can also be documented in the bio.tools metadata using the EDAM ontology to specify the nature and format of the input and output data.</td>
 </tr>
 <tr>
-<td>I2. Software includes qualified references to other objects.&nbsp;</td>
-<td>The README file/documentation will contain qualified references to other objects associated with the software under a &ldquo;Parameters and data required to run the software&rdquo; or similar section (step 3.1) . The fields &ldquo;isPartOf&rdquo;, &ldquo;hasPart&rdquo;, and &ldquo;relatedLink&ldquo; of the codemeta.json file (step 4.1) will also provide qualified references to other objects. The Zenodo metadata (step 5.2) include a &ldquo;Related identifiers&rdquo; field that can be used to provide qualified references to other objects.&nbsp;</td>
+<td>I2. Software includes qualified references to other objects.</td>
+<td>The README file/documentation will contain qualified references to other objects associated with the software under a "Parameters and data required to run the software" or similar section (step 3.1) . The fields "isPartOf", "hasPart", and "relatedLink" of the codemeta.json file (step 4.1) will also provide qualified references to other objects. The Zenodo metadata (step 5.2) include a "Related identifiers" field that can be used to provide qualified references to other objects.</td>
 </tr>
 <tr>
-<td>R1. Software is described with a plurality of accurate and relevant attributes.&nbsp;</td>
+<td>R1. Software is described with a plurality of accurate and relevant attributes.</td>
 <td>The software will be described with a plurality of accurate and relevant attributes through the development history captured by the version control system platform (step 1.1.), the prescribed documentation (step 3), the prescribed metadata files (step 4), the repository-specific metadata (step 5), and the registry-specific metadata (step 6), which all have several overlapping elements.</td>
 </tr>
 <tr>
-<td>R1.1. Software is given a clear and accessible license.&nbsp;</td>
+<td>R1.1. Software is given a clear and accessible license.</td>
 <td>The software will be given a clear and accessible license through step 1.2 which instructs selecting a license and including a LICENSE file with usage terms. The metadata of the software repository in the version control system platform (step 1.1), the metadata files (step 4), the repository-specific metadata (step 5), and the registry-specific metadata (step 6) will all include the name of the license.</td>
 </tr>
 <tr>
-<td>R1.2. Software is associated with detailed provenance.&nbsp;</td>
-<td>Detailed provenance (why and how the software came to be, as well as who contributed what, when and where, etc.) will be provided in several ways: in the development history maintained by the version control system platform (step 1.1.) that will also get archived in Software Heritage (step 5.3), in the README through an &ldquo;Overall description of the software&rdquo; and a &ldquo;How to cite&rdquo; or similar sections (step 3.1), in the codemeta.json file through several fields such as Software description/abstract (&ldquo;description&rdquo;) and Authors (&ldquo;givenName&rdquo;, &ldquo;familyName&rdquo;) with their Organization name (&ldquo;affiliation&rdquo;) (step 4.1), in the CITATION.cff file through several fields such as Authors ("given-names", &ldquo;family-names") with their Organization name (&ldquo;affiliation&rdquo;)&nbsp; (step 4.2), in the repository-specific metadata (step 5), and the registry-specific metadata (step 6).</td>
+<td>R1.2. Software is associated with detailed provenance.</td>
+<td>Detailed provenance (why and how the software came to be, as well as who contributed what, when and where, etc.) will be provided in several ways: in the development history maintained by the version control system platform (step 1.1.) that will also get archived in Software Heritage (step 5.3), in the README through an "Overall description of the software" and a "How to cite" or similar sections (step 3.1), in the codemeta.json file through several fields such as Software description/abstract ("description") and Authors ("givenName", "familyName") with their Organization name ("affiliation") (step 4.1), in the CITATION.cff file through several fields such as Authors ("given-names", "family-names") with their Organization name ("affiliation") (step 4.2), in the repository-specific metadata (step 5), and the registry-specific metadata (step 6).</td>
 </tr>
 <tr>
-<td>R2. Software includes qualified references to other software.&nbsp;</td>
-<td>The software dependencies file (step 2.2) will contain qualified references to other software required to run the source code. Following language-specific best practices (step 2.3) will also allow including dependencies in the code (e.g., imports in Python code). The README files (step 3.1) will contain qualified references to other software under a &ldquo;High-level dependencies of the software&rdquo; or similar section. The fields &ldquo;isPartOf&rdquo;, &ldquo;hasPart&rdquo;, and &ldquo;relatedLink&ldquo; of the codemeta.json file (step 4.1) will provide qualified references to other software. The Zenodo metadata (Step 5.2) also includes a &ldquo;Related identifiers&rdquo; field that can be used to provide qualified references to other software. The bio.tools metadata (step 6) include a &ldquo;Relations&rdquo; class that can be used to provide qualified references to other software registered on bio.tools.</td>
+<td>R2. Software includes qualified references to other software.</td>
+<td>The software dependencies file (step 2.2) will contain qualified references to other software required to run the source code. Following language-specific best practices (step 2.3) will also allow including dependencies in the code (e.g., imports in Python code). The README files (step 3.1) will contain qualified references to other software under a "High-level dependencies of the software" or similar section. The fields "isPartOf", "hasPart", and "relatedLink" of the codemeta.json file (step 4.1) will provide qualified references to other software. The Zenodo metadata (Step 5.2) also includes a "Related identifiers" field that can be used to provide qualified references to other software. The bio.tools metadata (step 6) include a "Relations" class that can be used to provide qualified references to other software registered on bio.tools.</td>
 </tr>
 <tr>
 <td>R3. Software meets domain-relevant community standards.</td>