diff --git a/.codespellrc b/.codespellrc new file mode 100644 index 0000000..cbfdb82 --- /dev/null +++ b/.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 = diff --git a/.github/workflows/codespell.yml b/.github/workflows/codespell.yml new file mode 100644 index 0000000..6e996fd --- /dev/null +++ b/.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 diff --git a/content/_index.md b/content/_index.md index f1af83a..563326a 100644 --- a/content/_index.md +++ b/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: diff --git a/content/description-domain.md b/content/description-domain.md index ca83f21..f065978 100644 --- a/content/description-domain.md +++ b/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": [ diff --git a/content/examples/UVP.json b/content/examples/UVP.json index 124d483..7d20e4d 100644 --- a/content/examples/UVP.json +++ b/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": [ { diff --git a/content/extension-domain.md b/content/extension-domain.md index b2bb9f3..df826d1 100644 --- a/content/extension-domain.md +++ b/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" diff --git a/content/extension-fhir.md b/content/extension-fhir.md index c00e5ce..d2a4a12 100644 --- a/content/extension-fhir.md +++ b/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. diff --git a/content/extension-scm.md b/content/extension-scm.md index 5d2e80c..0bae9c4 100644 --- a/content/extension-scm.md +++ b/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" diff --git a/content/faq.md b/content/faq.md index e8da215..38edb7b 100644 --- a/content/faq.md +++ b/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. diff --git a/content/introduction.md b/content/introduction.md index b04de17..8d1537b 100644 --- a/content/introduction.md +++ b/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 diff --git a/content/provenance-domain.md b/content/provenance-domain.md index 022683f..0bb4f2d 100644 --- a/content/provenance-domain.md +++ b/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" diff --git a/content/quick_start.md b/content/quick_start.md index f5d75cd..5c0333e 100644 --- a/content/quick_start.md +++ b/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 * diff --git a/content/top-level.md b/content/top-level.md index 4f8d09a..2d6f441 100644 --- a/content/top-level.md +++ b/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: ```` diff --git a/content/usability-domain.md b/content/usability-domain.md index dfad6d4..8e07844 100644 --- a/content/usability-domain.md +++ b/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 diff --git a/content/user_guide.md b/content/user_guide.md index 83cc193..0c1a28d 100644 --- a/content/user_guide.md +++ b/content/user_guide.md @@ -22,7 +22,7 @@ BioCompute Cheat Sheet can be found [here](/docs/CheatSheet_V07_jgk1_hk1.pdf)
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)
+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)
### 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). diff --git a/ieee-2791-schema/2791object.json b/ieee-2791-schema/2791object.json index 1fe4e01..f347d01 100644 --- a/ieee-2791-schema/2791object.json +++ b/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" diff --git a/ieee-2791-schema/execution_domain.json b/ieee-2791-schema/execution_domain.json index 858cad2..c475b32 100644 --- a/ieee-2791-schema/execution_domain.json +++ b/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", diff --git a/ieee-2791-schema/provenance_domain.json b/ieee-2791-schema/provenance_domain.json index 0c1aa5a..4174b09 100644 --- a/ieee-2791-schema/provenance_domain.json +++ b/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", diff --git a/scripts/validate.py b/scripts/validate.py index 76e6d60..19ad89f 100755 --- a/scripts/validate.py +++ b/scripts/validate.py @@ -32,5 +32,5 @@ def main(): #______________________________________________________________________________# if __name__ == "__main__": main() -#print a validation mesage +#print a validation message print("Schema Valid") \ No newline at end of file