Add codespell support (config, workflow to detect/not fix) and make it fix few typos

.codespellrc

@@ -0,0 +1,6 @@
+[codespell]
+# Ref: https://github.com/codespell-project/codespell#using-a-config-file
+skip = .git,.gitignore,.gitattributes,*.pdf,*.lock,*.css,.codespellrc
+check-hidden = true
+# ignore-regex = 
+# ignore-words-list =

.github/workflows/codespell.yml

@@ -0,0 +1,23 @@
+# Codespell configuration is within .codespellrc
+---
+name: Codespell
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+permissions:
+  contents: read
+
+jobs:
+  codespell:
+    name: Check for spelling errors
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+      - name: Codespell
+        uses: codespell-project/actions-codespell@8f01853be192eb0f849a5c7d721450e7a467c579  # v2.2

content/_index.md

@@ -37,7 +37,7 @@ After several planning meetings to articulate the problem statement and project
 Since then, the focus has shifted to building an ecosystem of tools, packages, and plugins for working with the standard, including support in the aforementioned bioinformatics platforms. This includes our own open source tool, the [BioCompute Portal](https://biocomputeobject.org/), for creating, editing, sharing, publishing, and viewing BioCompute Objects (BCOs; a BCO is an instance of a workflow written in conformance with the standard), including support for working with BCOs programmitically via API. One of the strongest original use cases was for medical devices, but the project has largely been used in high-throughput sequencing-based workflows, and for knowledgebase documentation (for example, the NIH Common Fund [GlyGen](https://www.glygen.org/) knowledgebase of glycans and glycoconjugates, and the FDA sponsored [Argos](https://data.argosdb.org/) repository of regulatory-grade infectious disease genomes).
 
 ### Citation
-This standard was originaly prepared by The BioCompute Object working group during preparation for the [2017 HTS Computational Standards for Regulatory Sciences Workshop](https://hive.biochemistry.gwu.edu/htscsrs/workshop_2017).
+This standard was originally prepared by The BioCompute Object working group during preparation for the [2017 HTS Computational Standards for Regulatory Sciences Workshop](https://hive.biochemistry.gwu.edu/htscsrs/workshop_2017).
 
 To reference the BCO standards, please use the following
 citations inclusive of the DOI:

content/description-domain.md

@@ -158,7 +158,7 @@ The version assigned to the instance of the tool used corresponding to the upstr
 
 #### 2.4.4.4 Tool Prerequisites "prerequisite"
 
-A list of text values to indicate any packages or prerequisites for running the tool used. This consists of a `name` and `uri`. The `uri` object consists of the `filename`, `uri`, `access_time`, and `sha1_chksum` properties. The `uri` is the only REQUIRED property but it is reccomended that in the `prerequisites` here the `access_time` is used as well. (Please note: a valid `uri` has to have the "protocol.domain.subdomain". Protocols: HTTP,HTTPS,etc)
+A list of text values to indicate any packages or prerequisites for running the tool used. This consists of a `name` and `uri`. The `uri` object consists of the `filename`, `uri`, `access_time`, and `sha1_chksum` properties. The `uri` is the only REQUIRED property but it is recommended that in the `prerequisites` here the `access_time` is used as well. (Please note: a valid `uri` has to have the "protocol.domain.subdomain". Protocols: HTTP,HTTPS,etc)
 
 ```json
     "prerequisite": [

content/examples/UVP.json

@@ -434,7 +434,7 @@
             {
                 "step_number": 7,
                 "name": "IndelRealigner",
-                "description": "Perfoms re-alignment around insertions and deletions",
+                "description": "Performs re-alignment around insertions and deletions",
                 "version": "3.4.0",
                 "prerequisite": [
                     {

content/extension-domain.md

@@ -44,7 +44,7 @@ The base url for the SCM repository.
 
 ## SCM Type "scm_type"
 
-A classifier for the type of SCM database. This feild is a list of predefined values. Third-party scm types can be used, and if so the `other` value MUST be used. The options for this field include `git` (Git, including GitHub/GitLab), `svn` (Subversion), `hg` (mercurial) and `other`.
+A classifier for the type of SCM database. This field is a list of predefined values. Third-party scm types can be used, and if so the `other` value MUST be used. The options for this field include `git` (Git, including GitHub/GitLab), `svn` (Subversion), `hg` (mercurial) and `other`.
 
 ## SCM Commit "scm_commit"
 

content/extension-fhir.md

@@ -4,7 +4,7 @@ _Back to [BCO domains](bco-domains)_
 
 ### 2.3.1 Extension to External References: SMART on FHIR Genomics
 
-The external references **example** extension to FHIR resource demonstrates how specific data elements can be extracted from EHR systems or other secure FHIR endpoints via technologies such as SMART on FHIR Genomics (https://www.ncbi.nlm.nih.gov/pubmed/26198304) without compromising patient and providers’ information. This is because the portions being transferred contain no identifiable information about the patient. Instead there is a reference to the actual resource instance (via FHIR URL) through which all data is accessed.
+The external references **example** extension to FHIR resource demonstrates how specific data elements can be extracted from HER systems or other secure FHIR endpoints via technologies such as SMART on FHIR Genomics (https://www.ncbi.nlm.nih.gov/pubmed/26198304) without compromising patient and providers’ information. This is because the portions being transferred contain no identifiable information about the patient. Instead there is a reference to the actual resource instance (via FHIR URL) through which all data is accessed.
 
 The `fhir_extension` is defined as an array of endpoints from which to fetch resources. 
 

content/extension-scm.md

@@ -23,7 +23,7 @@ The base url for the SCM repository.
 
 #### 2.3.2.2 SCM Type "scm_type"
 
-A classifier for the type of SCM database. This feild is a list of predefined values. Third-party scm types can be used, and if so the `other` value MUST be used. The options for this field include `git` (Git, including GitHub/GitLab), `svn` (Subversion), `hg` (mercurial) and `other`.
+A classifier for the type of SCM database. This field is a list of predefined values. Third-party scm types can be used, and if so the `other` value MUST be used. The options for this field include `git` (Git, including GitHub/GitLab), `svn` (Subversion), `hg` (mercurial) and `other`.
 
 #### 2.3.2.3 SCM Commit "scm_commit"
 

content/faq.md

@@ -88,14 +88,14 @@ Jump To:
 
 1) #### What is the difference between `software_prerequisites` in `execution_domain` and `prerequisites` in the `description_domain`? Is the former global, while the latter only applies to one specific pipeline step?
 
-	Correct, Execution Domain is for anything related to the environment in which the pipeline was executed, and the Description Domain is specific to the softwares in those steps. So if I've written a shell script to run the pipeline, and in one step it includes myScript.py to comb through results and pick out elements of interest, myScript.py might be an Execution Domain prerequisite, and any packages or dependencies called from within the script are Description Domain level prerequisites. Alternatively, if I'm using the HIVE platform, any libraries needed to run HIVE are Execution Domain level.
+	Correct, Execution Domain is for anything related to the environment in which the pipeline was executed, and the Description Domain is specific to the software in those steps. So if I've written a shell script to run the pipeline, and in one step it includes myScript.py to comb through results and pick out elements of interest, myScript.py might be an Execution Domain prerequisite, and any packages or dependencies called from within the script are Description Domain level prerequisites. Alternatively, if I'm using the HIVE platform, any libraries needed to run HIVE are Execution Domain level.
 
 
 ### Knowledgebases
 
 1) #### Can BCOs be used for curating databases?
 
-Yes. BCOs have been used in this capacity, such as in the [FDA's ARGOS database of infectious diseases](https://data.argosdb.org/) and the [GlyGen databse of glycosylation sites](https://data.glygen.org/). The following recommendations are compiled from these use cases. Although these recommendations are built from practical experience, they may not address the needs of every database. Users are free to make modifications at their own discretion.
+Yes. BCOs have been used in this capacity, such as in the [FDA's ARGOS database of infectious diseases](https://data.argosdb.org/) and the [GlyGen database of glycosylation sites](https://data.glygen.org/). The following recommendations are compiled from these use cases. Although these recommendations are built from practical experience, they may not address the needs of every database. Users are free to make modifications at their own discretion.
 
 Using BioCompute's pre-defined fields and standards, knowledgebases can generate a BioCompute Object (BCO) to document the metadata, quality-control, and integration pipelines developed for different workflows. BCOs can be used to document each release. The structured data in a BCO makes it very easy to identify changes between releases (including changes to the curation/data processing pipeline, attribution to curators, or datasets processed), or revert to previous releases.
 

content/introduction.md

@@ -70,7 +70,7 @@ For more information, see the project description on the [FDA Extramural Researc
 * Bioinformatics tool and platform developers who wish to operate in a regulatory environment, including cloud service (PaaS, IaaS, SaaS, FaaS) providers
 * Journals / Scientific Publishing / peer reviewing process
 * US National Institutes of Health (NIH) (particularly initiatives such as NCI/ITCR)
-* Public cloud companies operating in the Life Sciences sector including electronic health record (EHR) systems
+* Public cloud companies operating in the Life Sciences sector including electronic health record (HER) systems
 
 ## 1.5 BCO User stories
 

content/provenance-domain.md

@@ -45,7 +45,7 @@ Condensed example:
 
 ### 2.1.1 Name "name"
 
-Name for the BCO. This public field should take free text value using common biological research terminology supporting the terminology used in the [`usability_domain`](usability_domain.md), external references ([`xref`](/description-domain.md#242-external-references-xref)), and [`keywords`](/description-domain.md#241-keywords-keywords) sections. It is reccomended that BCO names be short and easily recognizable. They should also not use special characters (spell things out).
+Name for the BCO. This public field should take free text value using common biological research terminology supporting the terminology used in the [`usability_domain`](usability_domain.md), external references ([`xref`](/description-domain.md#242-external-references-xref)), and [`keywords`](/description-domain.md#241-keywords-keywords) sections. It is recommended that BCO names be short and easily recognizable. They should also not use special characters (spell things out).
 
 ```json
 "name": "HCV1a ledipasvir resistance SNP detection"

content/quick_start.md

@@ -28,7 +28,7 @@ Proper annotation of the workflow is required BEFORE running it.
 Notice the following in the example below:
 * The Name of the workflow: Becomes the BCO Name
 * The workflow version: Translated to a sequental digit and included as the BCO version
-* The workflow Annnotation block: Becomes the FIRST entry in the BCO Usability Domain
+* The workflow Annotation block: Becomes the FIRST entry in the BCO Usability Domain
     * The annotation from the history (if included) becomes the second entry in the BCO Usability Domain
 * 
 

content/top-level.md

@@ -39,7 +39,7 @@ Condensed example:
 
 ### 2.0.1 BCO version "spec_version"
 
-The version of the BCO specification used to define the BCO. It is recomended that this value be a permalink as defined in the [w3id.org/biocompute](https://github.com/perma-id/w3id.org/tree/master/biocompute) repository. 
+The version of the BCO specification used to define the BCO. It is recommended that this value be a permalink as defined in the [w3id.org/biocompute](https://github.com/perma-id/w3id.org/tree/master/biocompute) repository. 
 
 ```json
 "spec_version": "https://w3id.org/ieee/ieee-2791-schema/2791object.json" 
@@ -49,7 +49,7 @@ The version of the BCO specification used to define the BCO. It is recomended th
 
 A unique identifier that should be applied to each BCO instance. These can be assigned by a BCO database engine or manually generated. IDs should never be reused. It is recommended that the BCO identifier is based on a [UUID](https://tools.ietf.org/html/rfc4122)s (sometimes called GUIDs) to ensure uniqueness, either as a location-independent URN (e.g. `urn:uuid:2bf8397b-9aa8-47f2-80a7-235653e8e824`) or as part of an identifier permalink, (e.g. `http://repo.example.com/bco/2bf8397b-9aa8-47f2-80a7-235653e8e824`). While the UUID is the preferred method, IDs expressed as a URN or URL will satisfy the standard.
 
-The following is the recommended format for a BCO `object_id`, and what has been implementated by the [BCODB](https://github.com/biocompute-objects/bco_api/releases):
+The following is the recommended format for a BCO `object_id`, and what has been implemented by the [BCODB](https://github.com/biocompute-objects/bco_api/releases):
 
 The `"object_id"` consists of four different parts: 
 ````

content/usability-domain.md

@@ -26,7 +26,7 @@ This section defines the `usability_domain` part of the [BCO](/bco-domains) stru
 
 The Usability Domain of an Object is a plain language description of what was done in the workflow.
 This should align with the actual steps described elsewhere in the Object. The Usability Domain
-conveys the purpose of the Object. It is an array of free text values that should be consistant with
+conveys the purpose of the Object. It is an array of free text values that should be consistent with
 terminology used in the [`name`](provenance_domain.md#2.1.1-name-name), external references
 ([`xref`](/description-domain.md#242-external-references-xref)), and
 [`keywords`](/description-domain.md#241-keywords-keywords) sections.
@@ -39,7 +39,7 @@ object. A `usability_domain` should read like an abstract and conceptually can b
 4) How the results can be used/interpreted.
 
 The usability domain along with keywords can help determine when and how the BCO can
-be used. It is recomended that a novel use of a specific BCO would result in the creation of a new
+be used. It is recommended that a novel use of a specific BCO would result in the creation of a new
 entry with a new usability domain. 
 
 ```json

content/user_guide.md

@@ -22,7 +22,7 @@ BioCompute Cheat Sheet can be found [here](/docs/CheatSheet_V07_jgk1_hk1.pdf)
 
 <br> This document was created by the [BioCompute Object Consortium members (BCOC)](#biocompute-object-consortium-members-bcoc).
 
-It is offerd as support for [IEEE-2791-2020: IEEE Standard for Bioinformatics Computations and Analyses Generated by High-Throughput Sequencing (HTS) to Facilitate Communication. ](https://standards.ieee.org/standard/2791-2020.html) <br>
+It is offered as support for [IEEE-2791-2020: IEEE Standard for Bioinformatics Computations and Analyses Generated by High-Throughput Sequencing (HTS) to Facilitate Communication. ](https://standards.ieee.org/standard/2791-2020.html) <br>
 
 ### Table of contents:
   * [Galaxy BioCompute Objects](/quick_start)
@@ -59,7 +59,7 @@ Read more:
 
 ## 2 BioCompute Domains
 
-BCOs are represented in JSON (JavaScript Object Notation) formatted text, adhearing to [JSON schema draft-07](https://json-schema.org/specification.html). The JSON format was chosen because it is both human and machine readable/writable. For a detailed description of JSON see [www.json.org](http://www.json.org).
+BCOs are represented in JSON (JavaScript Object Notation) formatted text, adhering to [JSON schema draft-07](https://json-schema.org/specification.html). The JSON format was chosen because it is both human and machine readable/writable. For a detailed description of JSON see [www.json.org](http://www.json.org).
 
 BioCompute data types are defined as aggregates of the critical fields organized into the following domains: the provenance domain, the usability domain, the extension domain, the description domain, the execution domain, the parametric domain, the input and output domains, and the error domain. At the time of creation with actual values compliant to the schema the BCO should be assigned a unique identifier, a [object_id](/top-level#202-biocompute-object-identifier-object_id). The object could then be assigned a unique digital [etag](/top-level#203-etag-etag).
 

ieee-2791-schema/2791object.json

@@ -21,7 +21,7 @@
         },
         "uri": {
             "type": "object",
-            "description": "Any of the four Resource Identifers defined at https://tools.ietf.org/html/draft-handrews-json-schema-validation-01#section-7.3.5",
+            "description": "Any of the four Resource Identifiers defined at https://tools.ietf.org/html/draft-handrews-json-schema-validation-01#section-7.3.5",
             "additionalProperties": false,
             "required": [
                 "uri"

ieee-2791-schema/execution_domain.json

@@ -27,7 +27,7 @@
         },
         "script_driver": {
             "type": "string",
-            "description": "Indication of the kind of executable that can be launched in order to perform a sequence of commands described in the script in order to run the pipelin",
+            "description": "Indication of the kind of executable that can be launched in order to perform a sequence of commands described in the script in order to run the pipeline",
             "examples": [
                 "hive",
                 "cwl-runner",

ieee-2791-schema/provenance_domain.json

@@ -46,7 +46,7 @@
                     },
                     "reviewer": {
                         "$ref": "2791object.json#/definitions/contributor",
-                        "description": "Contributer that assigns IEEE-2791 review status."
+                        "description": "Contributor that assigns IEEE-2791 review status."
                     },
                     "reviewer_comment": {
                         "type": "string",

scripts/validate.py

@@ -32,5 +32,5 @@ def main():
 #______________________________________________________________________________#
 if __name__ == "__main__":
     main()
-#print a validation mesage 
+#print a validation message 
     print("Schema Valid")