BCOeditor Wiki - User contributions [en]

Main Page

2026-04-14T21:44:30Z

Lorikrammer:

{{DISPLAYTITLE:<span style="position: absolute; clip: rect(1px 1px 1px 1px); clip: rect(1px, 1px, 1px, 1px);">{{FULLPAGENAME}}</span>}}
__NOTOC__

<div id="ggw-topbanner" style="clear:both; position:relative; box-sizing:border-box; width:100%; margin:1.2em 0 6px; min-width:47em; border:1px solid #ddd; background-color:#f9f9f9; color:#000;">
<div style="margin:0.4em; text-align:center;">
<div style="font-size:160%; padding:.1em;">Welcome to BioCompute Objects Wiki,</div>
<div style="font-size:100%;">The [https://www.mediawiki.org/wiki/MediaWiki MediaWiki] for the BioCompute Objects project. This wiki system provides complementary information to the [https://www.biocomputeobject.org/ BioCompute portal] and is divided into the following main sections: General information for the [https://www.biocomputeobject.org/ BioCompute portal], [[User Guide|Quick Start and User Guide]], [[FAQs|FAQ]], [[SOP|Curation SOP]], and [[About|About]] for the [https://www.biocomputeobject.org/ BioCompute portal].</div>You can also find the BioCompute White paper [[White Paper|here]].
</div>
</div>
<div style="clear: both;"></div>

<div style="clear: both;"><br />
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;"><div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">

<div id="ggw_row2" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[User Guide|BioCompute Object (BCO) User Guide]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
This document specifies the structure of BioCompute Objects. The specification is split into multiple parts linked to this top-level document and is maintained in a [https://github.com/biocompute-objects/BCO_Specification GitHub repository] where contributions are welcome. This document was created by the [[Main_Page#BioCompute_Object_Consortium_members_(BCOC)|BioCompute Object Consortium members (BCOC)]].

It is offered as support for IEEE-2791-2020: [https://standards.ieee.org/ieee/2791/7337/ IEEE Standard for Bioinformatics Computations and Analyses Generated by High-Throughput Sequencing (HTS) to Facilitate Communication].

Read more: [[Introduction|Introduction to BioCompute Objects]]

</div>
</div>

<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[FAQs|Frequently Asked Questions]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
The FAQ section contains a list of questions asked by users regarding using the portal, pipeline steps, and extensions as well as questions related to the prerequisite, knowledgebase recommendation, and saving and publishing BCOs.

Read more: [[FAQs|Frequently Asked Questions]]

</div>
</div>

<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[SOP|BCO Curation SOP]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
Intended audience: authors and developers

This section is intended to provide guidance on BCO™ creation, versioning, certification and authentication.

Read more: [[SOP|BCO Curation SOP]]

</div>
</div>
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[BCO Pilot Project|Pilot Project]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
We are currently running a pilot project of mock submission to the FDA. The purpose of the pilot is to bring both the sponsors and the FDA to an agreement around BCO usage to streamline and standardize computational workflow submissions and reviews. We expect to obtain first-hand knowledge of submitting computational analyses to the FDA and how to efficiently and effectively ease communication barriers between sponsors and the government agency.
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[BioCompute Conference and Workshop|Workshop]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
We hosted an in-person workshop on May 10, 2024. Learn more [[BioCompute Conference and Workshop|here]].
For all previous workshop materials, click [https://hive.biochemistry.gwu.edu/publications#Multimedia here].
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[About]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
A BioCompute Object (BCO) is an instance of the BioCompute standard and is a computational record of a bioinformatics pipeline. A BCO is not an analysis but is a record of which analyses were executed and in exactly which ways. In this way, a BCO acts as an interface for existing standards. A BCO contains all of the necessary information to repeat an entire pipeline from FASTQ to result and includes additional metadata to identify provenance and usage.

Read more:
*[[About|What is BioCompute?]]
*[[About|Wifi Analogy]]
*[[About|BioCompute Description]]
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[Publications|Publication]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
'''For Citation Purpose:''' Simonyan, V., Goecks, J., & Mazumder, R. (2017). Biocompute Objects — A Step towards Evaluation and Validation of Biomedical Scientific Computations. PDA Journal of Pharmaceutical Science and Technology, 71(2), 136–146. doi: 10.5731/pdajpst.2016.006734

See also full list of [[publications]] about BioCompute Object.

=== Other links ===
# [[CDISC]]
# [[Galaxy]]
# [[RO-Crate]]
# [[CWL|Common Workflow Language (CWL)]]
# [https://fairsharing.org/4293 FAIRsharing]
</div>
</div>

White Paper

2026-04-14T21:44:05Z

Lorikrammer: Created page with "1800x1800px 1680x1680px"

[[File:WhitePaper BCO Page 1.jpg|center|1800x1800px]]
[[File:WhitePaper BCO Page 2.jpg|center|1680x1680px]]

Main Page

2026-04-14T21:43:12Z

Lorikrammer:

{{DISPLAYTITLE:<span style="position: absolute; clip: rect(1px 1px 1px 1px); clip: rect(1px, 1px, 1px, 1px);">{{FULLPAGENAME}}</span>}}
__NOTOC__

<div id="ggw-topbanner" style="clear:both; position:relative; box-sizing:border-box; width:100%; margin:1.2em 0 6px; min-width:47em; border:1px solid #ddd; background-color:#f9f9f9; color:#000;">
<div style="margin:0.4em; text-align:center;">
<div style="font-size:160%; padding:.1em;">Welcome to BioCompute Objects Wiki,</div>
<div style="font-size:100%;">The [https://www.mediawiki.org/wiki/MediaWiki MediaWiki] for the BioCompute Objects project. This wiki system provides complementary information to the [https://www.biocomputeobject.org/ BioCompute portal] and is divided into the following main sections: General information for the [https://www.biocomputeobject.org/ BioCompute portal], [[User Guide|Quick Start and User Guide]], [[FAQs|FAQ]], [[SOP|Curation SOP]], and [[About|About]] for the [https://www.biocomputeobject.org/ BioCompute portal].</div>You can also find the BioCompute White paper [[White paper|here]].
</div>
</div>
<div style="clear: both;"></div>

<div style="clear: both;"><br />
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;"><div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">

<div id="ggw_row2" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[User Guide|BioCompute Object (BCO) User Guide]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
This document specifies the structure of BioCompute Objects. The specification is split into multiple parts linked to this top-level document and is maintained in a [https://github.com/biocompute-objects/BCO_Specification GitHub repository] where contributions are welcome. This document was created by the [[Main_Page#BioCompute_Object_Consortium_members_(BCOC)|BioCompute Object Consortium members (BCOC)]].

It is offered as support for IEEE-2791-2020: [https://standards.ieee.org/ieee/2791/7337/ IEEE Standard for Bioinformatics Computations and Analyses Generated by High-Throughput Sequencing (HTS) to Facilitate Communication].

Read more: [[Introduction|Introduction to BioCompute Objects]]

</div>
</div>

<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[FAQs|Frequently Asked Questions]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
The FAQ section contains a list of questions asked by users regarding using the portal, pipeline steps, and extensions as well as questions related to the prerequisite, knowledgebase recommendation, and saving and publishing BCOs.

Read more: [[FAQs|Frequently Asked Questions]]

</div>
</div>

<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[SOP|BCO Curation SOP]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
Intended audience: authors and developers

This section is intended to provide guidance on BCO™ creation, versioning, certification and authentication.

Read more: [[SOP|BCO Curation SOP]]

</div>
</div>
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[BCO Pilot Project|Pilot Project]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
We are currently running a pilot project of mock submission to the FDA. The purpose of the pilot is to bring both the sponsors and the FDA to an agreement around BCO usage to streamline and standardize computational workflow submissions and reviews. We expect to obtain first-hand knowledge of submitting computational analyses to the FDA and how to efficiently and effectively ease communication barriers between sponsors and the government agency.
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[BioCompute Conference and Workshop|Workshop]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
We hosted an in-person workshop on May 10, 2024. Learn more [[BioCompute Conference and Workshop|here]].
For all previous workshop materials, click [https://hive.biochemistry.gwu.edu/publications#Multimedia here].
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[About]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
A BioCompute Object (BCO) is an instance of the BioCompute standard and is a computational record of a bioinformatics pipeline. A BCO is not an analysis but is a record of which analyses were executed and in exactly which ways. In this way, a BCO acts as an interface for existing standards. A BCO contains all of the necessary information to repeat an entire pipeline from FASTQ to result and includes additional metadata to identify provenance and usage.

Read more:
*[[About|What is BioCompute?]]
*[[About|Wifi Analogy]]
*[[About|BioCompute Description]]
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[Publications|Publication]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
'''For Citation Purpose:''' Simonyan, V., Goecks, J., & Mazumder, R. (2017). Biocompute Objects — A Step towards Evaluation and Validation of Biomedical Scientific Computations. PDA Journal of Pharmaceutical Science and Technology, 71(2), 136–146. doi: 10.5731/pdajpst.2016.006734

See also full list of [[publications]] about BioCompute Object.

=== Other links ===
# [[CDISC]]
# [[Galaxy]]
# [[RO-Crate]]
# [[CWL|Common Workflow Language (CWL)]]
# [https://fairsharing.org/4293 FAIRsharing]
</div>
</div>

Main Page

2026-04-14T21:42:50Z

Lorikrammer:

{{DISPLAYTITLE:<span style="position: absolute; clip: rect(1px 1px 1px 1px); clip: rect(1px, 1px, 1px, 1px);">{{FULLPAGENAME}}</span>}}
__NOTOC__

<div id="ggw-topbanner" style="clear:both; position:relative; box-sizing:border-box; width:100%; margin:1.2em 0 6px; min-width:47em; border:1px solid #ddd; background-color:#f9f9f9; color:#000;">
<div style="margin:0.4em; text-align:center;">
<div style="font-size:160%; padding:.1em;">Welcome to BioCompute Objects Wiki,</div>
<div style="font-size:100%;">The [https://www.mediawiki.org/wiki/MediaWiki MediaWiki] for the BioCompute Objects project. This wiki system provides complementary information to the [https://www.biocomputeobject.org/ BioCompute portal] and is divided into the following main sections: General information for the [https://www.biocomputeobject.org/ BioCompute portal], [[User Guide|Quick Start and User Guide]], [[FAQs|FAQ]], [[SOP|Curation SOP]], and [[About|About]] for the [https://www.biocomputeobject.org/ BioCompute portal].</div>You can also find the BioCompute White paper [[White paper|here]].
</div>
</div>
<div style="clear: both;"></div>

<div style="clear: both;"><br />
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;"><div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">

<div id="ggw_row2" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[User Guide|BioCompute Object (BCO) User Guide]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
This document specifies the structure of BioCompute Objects. The specification is split into multiple parts linked to this top-level document and is maintained in a [https://github.com/biocompute-objects/BCO_Specification GitHub repository] where contributions are welcome. This document was created by the [[Main_Page#BioCompute_Object_Consortium_members_(BCOC)|BioCompute Object Consortium members (BCOC)]].

It is offered as support for IEEE-2791-2020: [https://standards.ieee.org/ieee/2791/7337/ IEEE Standard for Bioinformatics Computations and Analyses Generated by High-Throughput Sequencing (HTS) to Facilitate Communication].

Read more: [[Introduction|Introduction to BioCompute Objects]]

</div>
</div>

<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[FAQs|Frequently Asked Questions]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
The FAQ section contains a list of questions asked by users regarding using the portal, pipeline steps, and extensions as well as questions related to the prerequisite, knowledgebase recommendation, and saving and publishing BCOs.

Read more: [[FAQs|Frequently Asked Questions]]

</div>
</div>

<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[Sop|BCO Curation SOP]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
Intended audience: authors and developers

This section is intended to provide guidance on BCO™ creation, versioning, certification and authentication.

Read more: [[Sop|BCO Curation SOP]]

</div>
</div>
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[BCO Pilot Project|Pilot Project]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
We are currently running a pilot project of mock submission to the FDA. The purpose of the pilot is to bring both the sponsors and the FDA to an agreement around BCO usage to streamline and standardize computational workflow submissions and reviews. We expect to obtain first-hand knowledge of submitting computational analyses to the FDA and how to efficiently and effectively ease communication barriers between sponsors and the government agency.
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[BioCompute Conference and Workshop|Workshop]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
We hosted an in-person workshop on May 10, 2024. Learn more [[BioCompute Conference and Workshop|here]].
For all previous workshop materials, click [https://hive.biochemistry.gwu.edu/publications#Multimedia here].
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[About]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
A BioCompute Object (BCO) is an instance of the BioCompute standard and is a computational record of a bioinformatics pipeline. A BCO is not an analysis but is a record of which analyses were executed and in exactly which ways. In this way, a BCO acts as an interface for existing standards. A BCO contains all of the necessary information to repeat an entire pipeline from FASTQ to result and includes additional metadata to identify provenance and usage.

Read more:
*[[About|What is BioCompute?]]
*[[About|Wifi Analogy]]
*[[About|BioCompute Description]]
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[Publications|Publication]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
'''For Citation Purpose:''' Simonyan, V., Goecks, J., & Mazumder, R. (2017). Biocompute Objects — A Step towards Evaluation and Validation of Biomedical Scientific Computations. PDA Journal of Pharmaceutical Science and Technology, 71(2), 136–146. doi: 10.5731/pdajpst.2016.006734

See also full list of [[publications]] about BioCompute Object.

=== Other links ===
# [[CDISC]]
# [[Galaxy]]
# [[RO-Crate]]
# [[CWL|Common Workflow Language (CWL)]]
# [https://fairsharing.org/4293 FAIRsharing]
</div>
</div>

User Guide

2026-04-14T21:42:05Z

Lorikrammer: /* Quick Links */

'''Go Back to [[Main Page|BioCompute Objects]].'''
== Quick Links ==

*[[Cheatsheet|BioCompute Cheat Sheet]]
*[[Introduction|Introduction to BioCompute Objects]]
*[[BCO Domains]]
*[[Tutorials|General User Tutorial]]
*[https://standards.ieee.org/ieee/2791/7337/ IEEE-2791-2020: IEEE Standard for Bioinformatics Computations and Analyses Generated by High-Throughput Sequencing (HTS) to Facilitate Communication]
*[[BCO Portal Local Deployment|API Tutorial: BCO Portal Local Deployment]]
*[[Creating a BCO on Galaxy]]
*[[Whirl: BCO R package converter|Whirl: An Open-Source R Package for Direct BioCompute Object Generation]]

== BioCompute Domains ==
[[Main Page|BCO]]s are represented in JSON (JavaScript Object Notation) formatted text, adhering to [https://json-schema.org/specification.html JSON schema draft-07]. The JSON format was chosen because it is both human and machine-readable/writable. For a detailed description of JSON see [http://www.json.org 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, and the input and output domains, and the error domain. At the time of creation with actual values compliant with the schema the BCO should be assigned a unique identifier, or [[Top Level Fields|object_id]]. The object could then be assigned a unique digital [[Top Level Fields#ETag_%E2%80%9Cetag%E2%80%9D|etag]].

The BioCompute Object becomes immutable upon assignment of the digital [[Top Level Fields#ETag_%E2%80%9Cetag%E2%80%9D|etag]] and version.
{| class="wikitable"
|+8 Top Level Domains
!Domain
!Description
!Required
|-
|'''Provenance Domain'''
|'''Metadata describing the BCO'''
|'''REQUIRED'''
|-
|'''Usability Domain'''
|'''Free text field for researcher to explain the analysis and relevant details'''
|'''REQUIRED'''
|-
|Extension Domain
|User-defined fields
|OPTIONAL
|-
|'''Description Domain'''
|'''Steps of the analysis, external resources needed for the steps, and the relationship of I/O objects'''
|'''REQUIRED'''
|-
|'''Execution Domain'''
|'''Information about the environment in which the analysis was run'''
|'''REQUIRED'''
|-
|Parametric Domain
|Records any parameters that were changed from default values
|OPTIONAL
|-
|'''Input and Output Domain'''
|'''A list of global input and output files'''
|'''REQUIRED'''
|-
|Error Domain
|Used for describing errors. Can include the limits of detectability, false positives, false negatives, statistical confidence of outcomes, and description of errors
|OPTIONAL
|}

== BCO Examples ==
*[[HCV1a ledipasvir resistance SNP detection]]
*[[WGS Simulation of DUF1220 Regions]]

== External Reference Database List ==
CURIEs (short identifiers) like [taxonomy:31646] in BCOs can be expanded to complete identifiers.

Learn more at [https://docs.biocomputeobject.org/external-references/ external references].

== Title 21 CFR Part 11 ==
Code of Federal Regulations Title 21 Part 11: Electronic Records - Electronic Signatures

BioCompute project is being developed with Title 21 CFR Part 11 compliance in mind. The digital signatures incorporated into the format will provide the basis for the provenance of BioCompute Object integrity using NIST proposed encryption algorithms. Execution domain and parametric domain (that have a potential impact on a result of computation) and identity domain will be used to create hash values and digital signature encryption keys which later can be used for computer or human validation of transmitted objects.

Discussions are now taking place to consider the relevance of BioCompute Objects in relation to Title 21 CFR part 11. We encourage continuous input from BioCompute stakeholders on this subject now and while the concept is becoming more mature and more widely accepted by scientific and regulatory communities.

Relevant document link: [https://www.fda.gov/regulatory-information/search-fda-guidance-documents/part-11-electronic-records-electronic-signatures-scope-and-application Part 11: Electronic Records]

== Compatibility ==

==== ISA for the experimental metadata ====
ISA is a metadata framework to manage an increasingly diverse set of life science, environmental and biomedical experiments that employ one or a combination of technologies. Built around the Investigation (the project context), Study (a unit of research), and Assay (analytical measurements) concepts, ISA helps to provide rich descriptions of experimental metadata (i.e. sample characteristics, technology and measurement types, sample-to-data relationships) so that the resulting data and discoveries are reproducible and reusable. The ISA Model and Serialization Specifications define an Abstract Model of the metadata framework that has been implemented in two format specifications, ISA-Tab and ISA-JSON (http://isa-tools.org/format/specification), both of which have supporting tools and services associated with them, including by a programmable Python AP (http://isa-tools.org) and a varied user community and contributors (http://www.isacommons.org). ISA focuses on structuring experimental metadata; raw and derived data files, codes, workflows, etc are considered external files that are referenced. An example, along with its complementarity with other models and a computational workflow is illustrated in this paper, which shows how to explicitly declare elements of experimental design, variables, and findings: http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0127612

Creating a BCO on Galaxy

2026-04-14T21:41:43Z

Lorikrammer:

== '''Creating a BCO on Galaxy''' ==

Galaxy has an extensive workflow system. They define a [https://galaxyproject.org/learn/advanced-workflow/ workflow] as “.. a series of tools and dataset actions that run in sequence as a batch operation”. An instance of a Galaxy workflow is known as an “invocation”. Since a BCO is a record of a specific instance of computation, the Galaxy invocations are used to generate the Galaxy BCOs.

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 sequential digit and included as the BCO version
*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
[[File:Workflow.png|800px|thumb|center]]

Creating a BCO on Galaxy

2026-04-14T21:41:16Z

Lorikrammer: Created page with "== '''Creating a BCO on Galaxy''' == Galaxy has an extensive workflow system. They define a [https://galaxyproject.org/learn/advanced-workflow/ workflow] as “.. a series of tools and dataset actions that run in sequence as a batch operation”. An instance of a Galaxy workflow is known as an “invocation”. Since a BCO is a record of a specific instance of computation, the Galaxy invocations are used to generate the Galaxy BCOs. The first step in creating a well-doc..."

== '''Creating a BCO on Galaxy''' ==

Galaxy has an extensive workflow system. They define a [https://galaxyproject.org/learn/advanced-workflow/ workflow] as “.. a series of tools and dataset actions that run in sequence as a batch operation”. An instance of a Galaxy workflow is known as an “invocation”. Since a BCO is a record of a specific instance of computation, the Galaxy invocations are used to generate the Galaxy BCOs. The first step in creating a well-documented Galaxy BCO is to follow the [https://planemo.readthedocs.io/en/latest/best%20practices%20workflows.html Best Practices for Maintaining Galaxy Workflows].

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 sequential digit and included as the BCO version
*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
*
[[File:Workflow.png|800px|thumb|center]]

Galaxy Workflow Converter

2026-04-14T21:38:47Z

Lorikrammer: Created page with "Workflows can be directly downloaded from Galaxy but file conversion is needed in order to transfer into BCODB successfully. Please follow the following steps to convert the file and validation: == File conversion == # Download the converter [https://github.com/FDA-ARGOS/data.argosdb/blob/main/lib/galaxy%20converter.py script] from GitHub. # On the local terminal, run the following command <code>python [converter script's name.py] -b [path to the file that needs to be co..."

Workflows can be directly downloaded from Galaxy but file conversion is needed in order to transfer into BCODB successfully. Please follow the following steps to convert the file and validation:
== File conversion ==
# Download the converter [https://github.com/FDA-ARGOS/data.argosdb/blob/main/lib/galaxy%20converter.py script] from GitHub.
# On the local terminal, run the following command <code>python [converter script's name.py] -b [path to the file that needs to be converted] -o [path to the output file]</code>

== Validation ==
# Install Validation Package:
## On the local terminal, clone the repository first by <code>git clone https://github.com/biocompute-objects/bcotool</code>
## Change directory: <code>cd bcotool/</code>
## Go to virtual environment: <code>python -m venv env</code>
## Activate virtual environment: <code>. env/bin/activate</code>
## Install required packages: <code>pip install -r requirements.txt</code>
## Run validation: <code>python bcotool/bco_runner.py validate -b [path to the converted file]</code> (Note: if only run <code>python bcotool/bco_runner.py</code>, more options can be seen.) If passed validation should show as the figure below [[File:Screen Shot 2022-11-09 at 16.38.10.png|800px|thumb|center]]
## If they encountered errors, will show as the figure below: [[File:Screen Shot 2022-11-09 at 16.46.07.png|800px|thumb|center]]
##* Open error log for error description: <code>open error.log</code>

== Upload ==
# Converted JSON file can be uploaded to BCODB through copy/pasting the RAW JSON file directly on BCO Builder or through API, refer to API documentation [[BCO Portal Local Deployment|here]].

External References

2026-04-14T21:38:06Z

Lorikrammer: Created page with "'''Go back to BCO Domains.''' == 3.2 Appendix-II: External reference database list == This list contains the databases that are currently being used in our BCOs. We use the CURIEs that map to URIs maintained by http://identifiers.org/ Identifiers.org is an established resolving system that enables the referencing of data for the scientific community, with a current focus on the Life Sciences domain. Identifiers.org provides direct access to the identified data..."

'''Go back to [[BCO Domains]].'''
== 3.2 Appendix-II: External reference database list ==

This list contains the databases that are currently being used in our BCOs. We use the CURIEs that map to URIs maintained by http://identifiers.org/

Identifiers.org is an established resolving system that enables the referencing of data for the scientific community, with a current focus on the Life Sciences domain. Identifiers.org provides direct access to the identified data using one selected physical location (or resource). Where multiple physical locations are recorded in the registry the most stable one is selected for resolution. This allows the location independent referencing (and resolution if required) of data records."

In the entries below the namespace and identifier combine to become the CURIEs.

Recommended name: Taxonomy
Namespace: taxonomy
Identifier pattern: ^\d+$
Registry identifier: MIR:00000006
URI: http://identifiers.org/taxonomy/

Recommended name: Sequence Ontology
Namespace: so
Identifier pattern: ^SO:\d{7}$
Registry identifier: MIR:00000081
URI: http://identifiers.org/so/

Recommended name: PubMed
Namespace: PubMed
Identifier pattern: ^\d+$
Registry identifier: MIR:00000015
URI: http://identifiers.org/pubmed/

Recommended name: PubChem-compound
Namespace: pubchem.compound
Identifier pattern: ^\d+$
Registry identifier: MIR:00000034
URI: http://identifiers.org/pubchem.compound/

For instance, the inline CURIE [taxonomy:31646] expands to http://identifiers.org/taxonomy/31646 as the namespace taxonomy corresponds to the prefix http://identifiers.org/taxonomy/ to be augmented with the identifier 31646. Resolving the resulting URI will redirect (currently to https://www.ncbi.nlm.nih.gov/Taxonomy/Browser/wwwtax.cgi?mode=Info&id=31646) showing that the term [taxonomy:31646] means Hepatitis C virus subtype 1a in the NCBI Taxonomy browser.

Note that some identifier patterns result in repetition when combined with the prefix, e.g. [so:SO:0000667] expands to http://identifiers.org/so/SO:0000667 where so: is the prefix and SO: is part of the Sequence Ontology identifier.

== References ==

McMurry JA et al: '''Identifiers for the 21st century: How to design, provision, and reuse persistent identifiers to maximize utility and impact of life science data'''. PLoS Biology 15(6): e2001414. https://doi.org/10.1371/journal.pbio.2001414

SCM Extension

2026-04-14T21:36:54Z

Lorikrammer: Created page with "'''Go back to BCO Domains.''' == Extension to External References: Software Configuration Management (SCM) == The external references '''example''' extension to a SCM repository demonstrates how a BioCompute Object software source code can be stored/deposited/downloaded. The BCO would contain links to the SCM repository where the information is stored and easily retrieved. The links to the SCM can be added to the usability domain as well. "extension_domain":{..."

'''Go back to [[BCO Domains]].'''

== Extension to External References: Software Configuration Management (SCM) ==

The external references '''example''' extension to a SCM repository demonstrates how a BioCompute Object software source code can be stored/deposited/downloaded. The BCO would contain links to the SCM repository where the information is stored and easily retrieved. The links to the SCM can be added to the usability domain as well.
"extension_domain":{
"scm_extension": {
"scm_repository": "https://github.com/example/repo1",
"scm_type": "git",
"scm_commit": "c9ffea0b60fa3bcf8e138af7c99ca141a6b8fb21",
"scm_path": "workflow/hive-viral-mutation-detection.cwl",
"scm_preview": "https://github.com/example/repo1/blob/c9ffea0b60fa3bcf8e138af7c99ca141a6b8fb21/workflow/hive-viral-mutation-detection.cwl"
}
}

=== SCM Repository “scm_repository” ===

The base url for the SCM repository.

=== SCM Type “scm_type” ===

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 others.

=== SCM Commit “scm_commit” ===

This field is a reference to a revision within the scm repository. This SHOULD be a repository-wide commit identifier (e.g. afba51a222e199f5b58f9d19450f189055e93c44 or name of a tag (e.g. v1.0.0), but MAY be a name of a branch (e.g. master).

=== SCM Path “scm_path” ===

This is the path from the repository to the source code referenced. scm_path should NOT start with /

=== SCM Preview “scm_preview” ===

The full uri for the source code is referenced by the BioCompute.

Extension Domain

2026-04-14T21:36:11Z

Lorikrammer: /* Extension Domain Examples */

'''Go back to [[BCO Domains]].'''

== Extension Domain ''(extension_domain)'' ==

The ''extension_domain'' is a space for a user to add additional structured information that is not defined in the BioCompute schema. It is '''optional'''. While the extension domain is not defined by IEEE-2791-2020, each extension in this domain must provide a reference to the schema that defines it in order to validate. The extension domain allows a user to define additional fields and is the place to add any additional structured information.

Condensed example:
<pre>
"extension_domain":{
},
</pre>
{| class="wikitable"
|+Components of the Extension Domain
!Field
!Required
|-
|extension_schema
|OPTIONAL
|}

== Domain Components ==

=== Extensions ===
A valid JSON schema for each extension used in this domain is expected to be specified. The schema should be namespaced, and it is recommended that resolving the namespaced URI will provide the extension’s JSON Schema. The URL must be provided in the extension_schema field.

== Extension Domain Examples ==
*[[FHIR Extension]]
*[[SCM Extension]]
We provide an example here that is neither exclusive nor exhaustive. The following example is taken from Extension to [https://github.com/biocompute-objects/extension%20domain/tree/1.1.0/scm External References: Software Configuration Management (SCM) v1.1.0]

"extension_domain":[
{
"extension_schema": "https://w3id.org/biocompute/extension_domain/1.1.0/scm/scm_extension.json",
"scm_extension": {
"scm_repository": "https://github.com/example/repo1",
"scm_type": "git",
"scm_commit": "c9ffea0b60fa3bcf8e138af7c99ca141a6b8fb21",
"scm_path": "workflow/hive-viral-mutation-detection.cwl",
"scm_preview": "https://github.com/example/repo1/blob/c9ffea0b60fa3bcf8e138af7c99ca141a6b8fb21/workflow/hive-viral-mutation-detection.cwl"
}
}
]

=== SCM Repository ''(scm_repository)'' ===
The base url for the SCM repository.

=== SCM Type ''(scm_type)'' ===
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 others.

=== SCM Commit ''(scm_commit)'' ===
This field is a reference to a revision within the scm repository. This SHOULD be a repository-wide commit identifier (e.g. afba51a222e199f5b58f9d19450f189055e93c44 or name of a tag (e.g. v1.0.0), but MAY be a name of a branch (e.g. master).

=== SCM Path ''(scm_path)'' ===
This is the path from the repository to the source code referenced. ''scm_path'' should NOT start with /.

=== SCM Preview ''(scm_preview)'' ===
The full URI for the source code is referenced by the BioCompute Object.

Extension Domain

2026-04-14T21:36:00Z

Lorikrammer: /* Extension Domain Examples */

'''Go back to [[BCO Domains]].'''

== Extension Domain ''(extension_domain)'' ==

The ''extension_domain'' is a space for a user to add additional structured information that is not defined in the BioCompute schema. It is '''optional'''. While the extension domain is not defined by IEEE-2791-2020, each extension in this domain must provide a reference to the schema that defines it in order to validate. The extension domain allows a user to define additional fields and is the place to add any additional structured information.

Condensed example:
<pre>
"extension_domain":{
},
</pre>
{| class="wikitable"
|+Components of the Extension Domain
!Field
!Required
|-
|extension_schema
|OPTIONAL
|}

== Domain Components ==

=== Extensions ===
A valid JSON schema for each extension used in this domain is expected to be specified. The schema should be namespaced, and it is recommended that resolving the namespaced URI will provide the extension’s JSON Schema. The URL must be provided in the extension_schema field.

== Extension Domain Examples ==
*[[FHIR extension]]
*[[SCM extension]]
We provide an example here that is neither exclusive nor exhaustive. The following example is taken from Extension to [https://github.com/biocompute-objects/extension%20domain/tree/1.1.0/scm External References: Software Configuration Management (SCM) v1.1.0]

"extension_domain":[
{
"extension_schema": "https://w3id.org/biocompute/extension_domain/1.1.0/scm/scm_extension.json",
"scm_extension": {
"scm_repository": "https://github.com/example/repo1",
"scm_type": "git",
"scm_commit": "c9ffea0b60fa3bcf8e138af7c99ca141a6b8fb21",
"scm_path": "workflow/hive-viral-mutation-detection.cwl",
"scm_preview": "https://github.com/example/repo1/blob/c9ffea0b60fa3bcf8e138af7c99ca141a6b8fb21/workflow/hive-viral-mutation-detection.cwl"
}
}
]

=== SCM Repository ''(scm_repository)'' ===
The base url for the SCM repository.

=== SCM Type ''(scm_type)'' ===
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 others.

=== SCM Commit ''(scm_commit)'' ===
This field is a reference to a revision within the scm repository. This SHOULD be a repository-wide commit identifier (e.g. afba51a222e199f5b58f9d19450f189055e93c44 or name of a tag (e.g. v1.0.0), but MAY be a name of a branch (e.g. master).

=== SCM Path ''(scm_path)'' ===
This is the path from the repository to the source code referenced. ''scm_path'' should NOT start with /.

=== SCM Preview ''(scm_preview)'' ===
The full URI for the source code is referenced by the BioCompute Object.

FHIR Extension

2026-04-14T21:35:33Z

Lorikrammer: Created page with "'''Go back to BCO Domains.''' == 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..."

'''Go back to [[BCO Domains]].'''

== 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 fhir_extension is defined as an array of endpoints from which to fetch resources.

fhir_endpoint is a string containing the URL of the endpoint of the FHIR server containing the resource. fhir_version must be present showing the FHIR version used.

fhir_resources is an array of resources to fetch from the endpoint, where fhir_resource is a string containing the type of resource used according to the specified version. (a full list of permitted FHIR 3 resources is available at http://hl7.org/fhir/STU3/resourcelist.html) fhir_id is a string containing the server-specific identifier for the resource instance.

The link to FHIR can also be added to the usability domain. More on FHIR Genomics in release 3 of FHIR can be found here: https://www.hl7.org/fhir/genomics.html

SMART on FHIR Genomics provides a framework for EHR-based apps built on FHIR that integrate clinical and genomic information. For more information on how to use the SMART on FHIR Genomics apps, please visit http://projects.iq.harvard.edu/smartgenomics/.

"extension_domain":{
"fhir_extension": [
{
"fhir_endpoint": "http://fhirtest.uhn.ca/baseDstu3",
"fhir_version": "3",
"fhir_resources": [
{
"fhir_resource": "Sequence",
"fhir_id": "21376"
},
{
"fhir_resource": "DiagnosticReport",
"fhir_id": "6288583"
},
{
"fhir_resource": "ProcedureRequest",
"fhir_id": "25544"
},
{
"fhir_resource": "Observation",
"fhir_id": "92440"
},
{
"fhir_resource": "FamilyMemberHistory",
"fhir_id": "4588936"
}
]
}

Contact Us

2026-04-14T21:34:30Z

Lorikrammer: Created page with "Go back to Prefix Registration The best way to get help for any issues is go to '''Contact Us''' on the bottom of the BioCompute web page for a quick response and '''Report Bug or request feature''' for a less immediate problem.center ''<u><big>'''Note a few suggested key points to include in a message:'''</big></u>'' *Issue location and ID if possible (e.g. provide a specific draft URL:https://www.biocomputeobject.org/builder/http..."

Go back to [[Prefix Registration]]
The best way to get help for any issues is go to '''Contact Us''' on the bottom of the BioCompute web page for a quick response and '''Report Bug or request feature''' for a less immediate problem.[[File:Contact us.png|800px|thumb|center]]
''<u><big>'''Note a few suggested key points to include in a message:'''</big></u>''
*Issue location and ID if possible (e.g. provide a specific draft URL:https://www.biocomputeobject.org/builder/https/biocomputeobject.org/BCO_000173/DRAFT)
*Explain the issue (e.g. I am trying to modify this particular BCO but it seems like I don’t have permission to view and modify)
*Other issues: (e.g. unable to search for any BCO under BCO prefix)
*What do you want to achieve (e.g. permissions to view BCOs under ARGOS prefix)

Build a BCO

2026-04-14T21:33:55Z

Lorikrammer:

#Click on '''BCO Builder''' icon on the Navigation Bar:[[File:101.png|center|thumb|1056x1056px]]
#To begin filling out the BCO, click on '''Provenance Domain''' to expand the section. Fill out the information as needed. Red boxes are required fields, and plain boxes are optional fields. Click '''next''' to advancing to the next section.[[File:102.png|center|thumb|1054x1054px]]
#For information to fill out each domain, please refer to the [[BCO Domains]] page. Or, click on the question mark icon on each domain for more information.
#User can also view/edit the BCO in JSON by clicking '''RAW JSON VIEW'''.[[File:103.png|center|thumb|1073x1073px]]
#A BCO draft can be saved at any time of editing. In order to save a draft, go to the top of the page to choose a server. [[File:104.png|center|thumb|1051x1051px]]
#After choosing the proper server, the BCO prefix field will show up. Enter a specific prefix (e.g. BCO, ARGOS, etc.) based on user groups and permissions. The default prefix is '''BCO''', which can be used by all users.[[File:105.png|center|thumb|1014x1014px]]
#Click on '''SAVE AS DRAFT''' to make sure all of the data is saved properly before publishing. A pop-up window will show up and indicate the draft is saved successfully.[[File:106.png|center|thumb|1014x1014px]]
#Before publishing the draft, users need to validate the draft first. To do this, click on '''VALIDATE BCO'''. A new window will pop up with validation results. Please see this [[Common Errors|page]] for common errors and possible solutions.[[File:107.png|center|thumb|1032x1032px]]
# If validation results show ‘“number_of_errors”: 0’, this means the draft has passed validation and it’s ready to publish. Go back to the Builder screen, and now the '''PUBLISH DRAFT''' button should turn blue, click on it to publish the draft.[[File:108.png|center|thumb|982x982px]][[File:107.png|center|thumb|1032x1032px]]
#If any errors were detected during validation, then correct those errors based on the validation results. Revalidation is needed before publishing.
#Other options on the Builder page include '''DOWNLOAD BCO''' in JSON format and '''UPLOAD''' a BCO.[[File:109.png|center|thumb|1008x1008px]]

Common Errors

2026-04-14T21:33:33Z

Lorikrammer: Created page with "Return to the tutorial. Here is showing a list of common errors that a user might encounter while creating a BCO, please see possible solutions below: #Description Domain: autogenerated step numbers are incorrect or not in sequential order most times. #* Solution: Manually change the step numbers starting to 1, 2, 3…… #Description Domain: manually entered step numbers could be considered as strings during validation, which need to be integers. See..."

Return to the [[Tutorials|tutorial]].

Here is showing a list of common errors that a user might encounter while creating a BCO, please see possible solutions below:

#Description Domain: autogenerated step numbers are incorrect or not in sequential order most times.
#* Solution: Manually change the step numbers starting to 1, 2, 3……
#Description Domain: manually entered step numbers could be considered as strings during validation, which need to be integers. See the figure below that under '''TREE VIEW JSON''', the '''step_number''' is considered as a string instead of an integer.[[File:Blank diagram(9).png|800px|thumb|center]]
#* Solution: Go to '''TREE VIEW JSON''', scroll down to '''description_domain''' section. Click on the green text pad icon, and select '''int 1'''. See the figures below.[[File:Blank diagram(8).png|800px|thumb|center]][[File:Blank diagram(7).png|800px|thumb|center]]
#Description Domain: SHA1_Checksum is not a required field but during validation, empty SHA1_Checksum fields can trigger errors. This error can also happen in I/O domain which has SHA1_Checksum fields.
#* Solution: Go to '''TREE VIEW JSON''', navigate to the parts that show '''sha1_checksum''', hover the mouse over it, then click on the red cross button that appeared to delete the line. [[File:Blank diagram(10).png|800px|thumb|center]]
#Execution Domain: '''Environment Variables''' are not highlighted in red but it is mandatory to fill out.
#* Solution: fill out '''Environment Variables''' as a required field.
#Error Domain: error message shows up when starting typing in Error Domain.
#* Solution: the error message won't clear until reaches a proper JSON format so a user needs to a proper JSON format is entered.

Prefix Registration

2026-04-14T21:31:19Z

Lorikrammer: Created page with "To create a Prefix, see the following steps: # Go to '''Prefix Registry''' on the Navigation Bar:800x800px #On the '''Prefix Registry''' page, users can achieve both prefix search and prefix registration functionalities. #*'''Prefix Search:''' users can search prefixes in three ways: '''My Prefixes''', '''Return all''', and '''Search Prefix Name.''' Select the desired searching option. If chose '''Search Prefix Name''', the..."

To create a Prefix, see the following steps:
# Go to '''Prefix Registry''' on the Navigation Bar:[[File:May 2023 prefix icon.png|center|thumb|800x800px]]
#On the '''Prefix Registry''' page, users can achieve both prefix search and prefix registration functionalities.
#*'''Prefix Search:''' users can search prefixes in three ways: '''My Prefixes''', '''Return all''', and '''Search Prefix Name.''' Select the desired searching option. If chose '''Search Prefix Name''', then enter the prefix name in the box below. Finally, click '''SEARCH''' to return results.[[File:May 2023 Prefix search1.png|center|thumb|800x800px]][[File:May 2023 Prefix search2.png|center|thumb|778x778px]]
#To register a new prefix, click on '''Register New Prefix''', enter the prefix name (5 character limits) and description, select to set it as either private or public prefix before '''SUBMIT'''.[[File:May 2023 Prefix registry.png|center|thumb|800x800px]]
#Once submitted, users should be able to see the prefix under '''My Prefix''' search results. In addition, users can see the newly registered prefix in '''GROUPS/PERMISSIONS''' in your '''Account''' information. [[File:May 2023 Account.png|center|thumb|636x636px]]

==Groups/Permissions (Note: only the prefix owner can add a new user to a specific prefix)==
#Click on '''GROUPS/PERMISSIONS'''[[File:May 2023 GroupsPermission.png|center|thumb|659x659px]]In the picture above, TUTOL is the prefix that the user registered so that under '''GROUPS/PERMISSIONS''', both "tutol_drafter" and "tutol_publisher" appeared.
#Click on the groups name that's owned by the user to edit group information and permission.[[File:May 2023 GroupsPermission2.png|center|thumb|660x660px]]
#Add '''Group members''' by entering the user names and edit '''Group Description''' as needed. Once finished, click '''UPDATE GROUP''', otherwise, click on '''CANCEL.'''

Tutorials

2026-04-14T21:30:46Z

Lorikrammer:

Account Registration

2026-04-14T21:30:15Z

Lorikrammer: Created page with "==Account Registration== Before building a BioCompute Object (BCO), please register an account first by following the listed steps: # Go to '''Log in''' on the header:804x804px #For first-time users, please click on “'''Don’t have an account? Sign up'''”, fill out the required information and click '''SUBMIT'''. centerGoogle authentication is also enabled on BioCompute. Users c..."

==Account Registration==
Before building a BioCompute Object (BCO), please register an account first by following the listed steps:
# Go to '''Log in''' on the header:[[File:May 2023 Homepage.png|center|thumb|804x804px]]
#For first-time users, please click on “'''Don’t have an account? Sign up'''”, fill out the required information and click '''SUBMIT'''. [[File:May 2023 Account Register.png|thumb|center]]Google authentication is also enabled on BioCompute. Users can register a BCO account from click on '''Create BCO Portal account with Google.''' [[File:May 2023 Account Register2.png|center|thumb|559x559px]]
#An activation email from object.biocompute@gmail.com should be sent to your entered email address for account activation.
#Log in to the Portal account using your registered username and password or sign in with a Google account or ORCID account.
#After logging in, click on your name on the top right corner of the page to go to the account:[[File:May 2023 Account.png|center|thumb|800x800px]]
# On the Account page, account details can be changed. For example, names, email address, affiliation, ORCID. Click on '''UPDATE PROFILE''' to finalize the changes.
#The BCO databases that the account has access to are shown under '''BCO databases'''. By click on '''GROUPS/PERMISSIONS''', users can view permissions and groups associated with the account.
#BioCompute Team has set up a '''BCODB Sandbox''' server for developers. To add it, please contact BioCompute admin for information.

Main Page

2026-04-14T21:29:22Z

Lorikrammer:

{{DISPLAYTITLE:<span style="position: absolute; clip: rect(1px 1px 1px 1px); clip: rect(1px, 1px, 1px, 1px);">{{FULLPAGENAME}}</span>}}
__NOTOC__

<div id="ggw-topbanner" style="clear:both; position:relative; box-sizing:border-box; width:100%; margin:1.2em 0 6px; min-width:47em; border:1px solid #ddd; background-color:#f9f9f9; color:#000;">
<div style="margin:0.4em; text-align:center;">
<div style="font-size:160%; padding:.1em;">Welcome to BioCompute Objects Wiki,</div>
<div style="font-size:100%;">The [https://www.mediawiki.org/wiki/MediaWiki MediaWiki] for the BioCompute Objects project. This wiki system provides complementary information to the [https://www.biocomputeobject.org/ BioCompute portal] and is divided into the following main sections: General information for the [https://www.biocomputeobject.org/ BioCompute portal], [[User Guide|Quick Start and User Guide]], [[FAQs|FAQ]], [[Sop|Curation SOP]], and [[About|About]] for the [https://www.biocomputeobject.org/ BioCompute portal].</div>You can also find the BioCompute White paper [[White paper|here]].
</div>
</div>
<div style="clear: both;"></div>

<div style="clear: both;"><br />
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;"><div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">

<div id="ggw_row2" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[User Guide|BioCompute Object (BCO) User Guide]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
This document specifies the structure of BioCompute Objects. The specification is split into multiple parts linked to this top-level document and is maintained in a [https://github.com/biocompute-objects/BCO_Specification GitHub repository] where contributions are welcome. This document was created by the [[Main_Page#BioCompute_Object_Consortium_members_(BCOC)|BioCompute Object Consortium members (BCOC)]].

It is offered as support for IEEE-2791-2020: [https://standards.ieee.org/ieee/2791/7337/ IEEE Standard for Bioinformatics Computations and Analyses Generated by High-Throughput Sequencing (HTS) to Facilitate Communication].

Read more: [[Introduction|Introduction to BioCompute Objects]]

</div>
</div>

<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[FAQs|Frequently Asked Questions]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
The FAQ section contains a list of questions asked by users regarding using the portal, pipeline steps, and extensions as well as questions related to the prerequisite, knowledgebase recommendation, and saving and publishing BCOs.

Read more: [[FAQs|Frequently Asked Questions]]

</div>
</div>

<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[Sop|BCO Curation SOP]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
Intended audience: authors and developers

This section is intended to provide guidance on BCO™ creation, versioning, certification and authentication.

Read more: [[Sop|BCO Curation SOP]]

</div>
</div>
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[BCO Pilot Project|Pilot Project]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
We are currently running a pilot project of mock submission to the FDA. The purpose of the pilot is to bring both the sponsors and the FDA to an agreement around BCO usage to streamline and standardize computational workflow submissions and reviews. We expect to obtain first-hand knowledge of submitting computational analyses to the FDA and how to efficiently and effectively ease communication barriers between sponsors and the government agency.
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[BioCompute Conference and Workshop|Workshop]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
We hosted an in-person workshop on May 10, 2024. Learn more [[BioCompute Conference and Workshop|here]].
For all previous workshop materials, click [https://hive.biochemistry.gwu.edu/publications#Multimedia here].
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[About]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
A BioCompute Object (BCO) is an instance of the BioCompute standard and is a computational record of a bioinformatics pipeline. A BCO is not an analysis but is a record of which analyses were executed and in exactly which ways. In this way, a BCO acts as an interface for existing standards. A BCO contains all of the necessary information to repeat an entire pipeline from FASTQ to result and includes additional metadata to identify provenance and usage.

Read more:
*[[About|What is BioCompute?]]
*[[About|Wifi Analogy]]
*[[About|BioCompute Description]]
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[Publications|Publication]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
'''For Citation Purpose:''' Simonyan, V., Goecks, J., & Mazumder, R. (2017). Biocompute Objects — A Step towards Evaluation and Validation of Biomedical Scientific Computations. PDA Journal of Pharmaceutical Science and Technology, 71(2), 136–146. doi: 10.5731/pdajpst.2016.006734

See also full list of [[publications]] about BioCompute Object.

=== Other links ===
# [[CDISC]]
# [[Galaxy]]
# [[RO-Crate]]
# [[CWL|Common Workflow Language (CWL)]]
# [https://fairsharing.org/4293 FAIRsharing]
</div>
</div>

Main Page

2026-04-14T21:28:49Z

Lorikrammer:

{{DISPLAYTITLE:<span style="position: absolute; clip: rect(1px 1px 1px 1px); clip: rect(1px, 1px, 1px, 1px);">{{FULLPAGENAME}}</span>}}
__NOTOC__

<div id="ggw-topbanner" style="clear:both; position:relative; box-sizing:border-box; width:100%; margin:1.2em 0 6px; min-width:47em; border:1px solid #ddd; background-color:#f9f9f9; color:#000;">
<div style="margin:0.4em; text-align:center;">
<div style="font-size:160%; padding:.1em;">Welcome to BioCompute Objects Wiki,</div>
<div style="font-size:100%;">The [https://www.mediawiki.org/wiki/MediaWiki MediaWiki] for the BioCompute Objects project. This wiki system provides complementary information to the [https://www.biocomputeobject.org/ BioCompute portal] and is divided into the following main sections: General information for the [https://www.biocomputeobject.org/ BioCompute portal], [[User Guide|Quick Start and User Guide]], [[FAQs|FAQ]], [[Sop|Curation SOP]], and [[About|About]] for the [https://www.biocomputeobject.org/ BioCompute portal].</div>You can also find the BioCompute White paper [[White paper|here]].
</div>
</div>
<div style="clear: both;"></div>

<div style="clear: both;"><br />
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;"><div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">

<div id="ggw_row2" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[User guide|BioCompute Object (BCO) User Guide]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
This document specifies the structure of BioCompute Objects. The specification is split into multiple parts linked to this top-level document and is maintained in a [https://github.com/biocompute-objects/BCO_Specification GitHub repository] where contributions are welcome. This document was created by the [[Main_Page#BioCompute_Object_Consortium_members_(BCOC)|BioCompute Object Consortium members (BCOC)]].

It is offered as support for IEEE-2791-2020: [https://standards.ieee.org/ieee/2791/7337/ IEEE Standard for Bioinformatics Computations and Analyses Generated by High-Throughput Sequencing (HTS) to Facilitate Communication].

Read more: [[Introduction|Introduction to BioCompute Objects]]

</div>
</div>

<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[FAQs|Frequently Asked Questions]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
The FAQ section contains a list of questions asked by users regarding using the portal, pipeline steps, and extensions as well as questions related to the prerequisite, knowledgebase recommendation, and saving and publishing BCOs.

Read more: [[FAQs|Frequently Asked Questions]]

</div>
</div>

<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[Sop|BCO Curation SOP]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
Intended audience: authors and developers

This section is intended to provide guidance on BCO™ creation, versioning, certification and authentication.

Read more: [[Sop|BCO Curation SOP]]

</div>
</div>
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[BCO Pilot Project|Pilot Project]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
We are currently running a pilot project of mock submission to the FDA. The purpose of the pilot is to bring both the sponsors and the FDA to an agreement around BCO usage to streamline and standardize computational workflow submissions and reviews. We expect to obtain first-hand knowledge of submitting computational analyses to the FDA and how to efficiently and effectively ease communication barriers between sponsors and the government agency.
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[BioCompute Conference and Workshop|Workshop]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
We hosted an in-person workshop on May 10, 2024. Learn more [[BioCompute Conference and Workshop|here]].
For all previous workshop materials, click [https://hive.biochemistry.gwu.edu/publications#Multimedia here].
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[About]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
A BioCompute Object (BCO) is an instance of the BioCompute standard and is a computational record of a bioinformatics pipeline. A BCO is not an analysis but is a record of which analyses were executed and in exactly which ways. In this way, a BCO acts as an interface for existing standards. A BCO contains all of the necessary information to repeat an entire pipeline from FASTQ to result and includes additional metadata to identify provenance and usage.

Read more:
*[[About|What is BioCompute?]]
*[[About|Wifi Analogy]]
*[[About|BioCompute Description]]
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[Publications|Publication]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
'''For Citation Purpose:''' Simonyan, V., Goecks, J., & Mazumder, R. (2017). Biocompute Objects — A Step towards Evaluation and Validation of Biomedical Scientific Computations. PDA Journal of Pharmaceutical Science and Technology, 71(2), 136–146. doi: 10.5731/pdajpst.2016.006734

See also full list of [[publications]] about BioCompute Object.

=== Other links ===
# [[CDISC]]
# [[Galaxy]]
# [[RO-Crate]]
# [[CWL|Common Workflow Language (CWL)]]
# [https://fairsharing.org/4293 FAIRsharing]
</div>
</div>

User Guide

2026-04-14T21:28:26Z

Lorikrammer: Created page with "'''Go Back to BioCompute Objects.''' == Quick Links == *BioCompute Cheat Sheet *Introduction to BioCompute Objects *BCO Domains *General User Tutorial *[https://standards.ieee.org/ieee/2791/7337/ IEEE-2791-2020: IEEE Standard for Bioinformatics Computations and Analyses Generated by High-Throughput Sequencing (HTS) to Facilitate Communication] *BCO Portal Local Deployment|API Tutorial: BCO Portal Local De..."

'''Go Back to [[Main Page|BioCompute Objects]].'''
== Quick Links ==

*[[Cheatsheet|BioCompute Cheat Sheet]]
*[[Introduction|Introduction to BioCompute Objects]]
*[[BCO Domains]]
*[[Tutorials|General User Tutorial]]
*[https://standards.ieee.org/ieee/2791/7337/ IEEE-2791-2020: IEEE Standard for Bioinformatics Computations and Analyses Generated by High-Throughput Sequencing (HTS) to Facilitate Communication]
*[[BCO Portal Local Deployment|API Tutorial: BCO Portal Local Deployment]]
*[[Quick start|Creating a BCO on Galaxy]]
*[[Whirl: BCO R package converter|Whirl: An Open-Source R Package for Direct BioCompute Object Generation]]

== BioCompute Domains ==
[[Main Page|BCO]]s are represented in JSON (JavaScript Object Notation) formatted text, adhering to [https://json-schema.org/specification.html JSON schema draft-07]. The JSON format was chosen because it is both human and machine-readable/writable. For a detailed description of JSON see [http://www.json.org 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, and the input and output domains, and the error domain. At the time of creation with actual values compliant with the schema the BCO should be assigned a unique identifier, or [[Top Level Fields|object_id]]. The object could then be assigned a unique digital [[Top Level Fields#ETag_%E2%80%9Cetag%E2%80%9D|etag]].

The BioCompute Object becomes immutable upon assignment of the digital [[Top Level Fields#ETag_%E2%80%9Cetag%E2%80%9D|etag]] and version.
{| class="wikitable"
|+8 Top Level Domains
!Domain
!Description
!Required
|-
|'''Provenance Domain'''
|'''Metadata describing the BCO'''
|'''REQUIRED'''
|-
|'''Usability Domain'''
|'''Free text field for researcher to explain the analysis and relevant details'''
|'''REQUIRED'''
|-
|Extension Domain
|User-defined fields
|OPTIONAL
|-
|'''Description Domain'''
|'''Steps of the analysis, external resources needed for the steps, and the relationship of I/O objects'''
|'''REQUIRED'''
|-
|'''Execution Domain'''
|'''Information about the environment in which the analysis was run'''
|'''REQUIRED'''
|-
|Parametric Domain
|Records any parameters that were changed from default values
|OPTIONAL
|-
|'''Input and Output Domain'''
|'''A list of global input and output files'''
|'''REQUIRED'''
|-
|Error Domain
|Used for describing errors. Can include the limits of detectability, false positives, false negatives, statistical confidence of outcomes, and description of errors
|OPTIONAL
|}

== BCO Examples ==
*[[HCV1a ledipasvir resistance SNP detection]]
*[[WGS Simulation of DUF1220 Regions]]

== External Reference Database List ==
CURIEs (short identifiers) like [taxonomy:31646] in BCOs can be expanded to complete identifiers.

Learn more at [https://docs.biocomputeobject.org/external-references/ external references].

== Title 21 CFR Part 11 ==
Code of Federal Regulations Title 21 Part 11: Electronic Records - Electronic Signatures

BioCompute project is being developed with Title 21 CFR Part 11 compliance in mind. The digital signatures incorporated into the format will provide the basis for the provenance of BioCompute Object integrity using NIST proposed encryption algorithms. Execution domain and parametric domain (that have a potential impact on a result of computation) and identity domain will be used to create hash values and digital signature encryption keys which later can be used for computer or human validation of transmitted objects.

Discussions are now taking place to consider the relevance of BioCompute Objects in relation to Title 21 CFR part 11. We encourage continuous input from BioCompute stakeholders on this subject now and while the concept is becoming more mature and more widely accepted by scientific and regulatory communities.

Relevant document link: [https://www.fda.gov/regulatory-information/search-fda-guidance-documents/part-11-electronic-records-electronic-signatures-scope-and-application Part 11: Electronic Records]

== Compatibility ==

==== ISA for the experimental metadata ====
ISA is a metadata framework to manage an increasingly diverse set of life science, environmental and biomedical experiments that employ one or a combination of technologies. Built around the Investigation (the project context), Study (a unit of research), and Assay (analytical measurements) concepts, ISA helps to provide rich descriptions of experimental metadata (i.e. sample characteristics, technology and measurement types, sample-to-data relationships) so that the resulting data and discoveries are reproducible and reusable. The ISA Model and Serialization Specifications define an Abstract Model of the metadata framework that has been implemented in two format specifications, ISA-Tab and ISA-JSON (http://isa-tools.org/format/specification), both of which have supporting tools and services associated with them, including by a programmable Python AP (http://isa-tools.org) and a varied user community and contributors (http://www.isacommons.org). ISA focuses on structuring experimental metadata; raw and derived data files, codes, workflows, etc are considered external files that are referenced. An example, along with its complementarity with other models and a computational workflow is illustrated in this paper, which shows how to explicitly declare elements of experimental design, variables, and findings: http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0127612

BCO Domains

2026-04-14T21:27:33Z

Lorikrammer: /* Top Level Fields */

'''Go back to [[Main_Page|BioCompute Objects]].'''

=== BioCompute Objects Visualization ===
An Observable documentation showing a visualization of a BCO object workflow can be found [https://observablehq.com/@neurogenomics/biocompute-objects-visualization-student-workflows here].

=== [[Top Level Fields]] ===

The top-level JSON object of a BCO includes attributes to define the BCO itself.

The remaining top-level fields detail different domains of the BCO, as listed below.

== BCO Domains ==

A [[Main Page|BCO]] JSON object is split into different parts, or domains, detailed below.

Condensed example:
"spec_version" : "https://w3id.org/biocompute/1.3.0/",
"object_id": "https://example.com/bco/9487ae7e-c1aa-4a3c-b18f-3d3695b33ace",
"type": "antiviral_resistance_detection",
"etag": "584C7FE128717E1712426AB19CAAEA8BC1E27365B54285BBEA1221284C7D3A48",
"provenance_domain": {
},
"usability_domain": [
],
"extension_domain":{
},
"description_domain": {
},
"execution_domain": {
},
"parametric_domain": {
},
"io_domain": {
},
"error_domain": {
}

=== [[Provenance Domain|Provenance Domain (<nowiki>''provenance_domain''</nowiki>)]] ===

The provenance_domain defines the history, version and status of this BCO as part of the review process.

=== [[Usability Domain|Usability Domain (''usability_domain'')]] ===

The usability_domain is meant to improve searchability by allowing a free-text description of the BCO.

=== [[Extension Domain|Extension Domain (''extension_domain'')]] ===

The extension_domain is a space for a user to add additional structured information that is not defined in the BioCompute schema. While the extension_domain is not defined by IEEE-2791-2020, each extension in the extension domain must provide a reference to the schema that defines it in order to validate. The extension domain is the place to add any additional structured information. We provide an example here that is neither exclusive nor exhaustive.

=== [[Description Domain|Description Domain (''description_domain'')]] ===

The description_domain contains a structured field for the description of external references, the pipeline steps, and the relationship of I/O objects.

=== [[Execution Domain|Execution Domain (''execution_domain'')]] ===

The execution_domain contains fields for the execution of the BCO.

=== [[Parametric Domain|Parametric Domain (''parametric_domain'')]] ===

The parametric_domain represents the list of parameters customizing the computational flow which can affect the output of the calculations.

=== [[Input and Output Domain|Input and Output Domain (''io_domain'')]] ===

The io_domain represents the list of global input and output files created by the computational workflow.

=== [[Error Domain|Error Domain (''error_domain'')]] ===

The error_domain defines the empirical and algorithmic limits and error sources of the BCO.

Top Level Fields

2026-04-14T21:26:07Z

Lorikrammer: Created page with "'''Go back to BCO Domains.''' == Top Level Fields == These header fields uniquely define this BCO. These fields are required for every BCO and are represented at the top level object. Condensed example: { "object_id": "https://example.com/BCO_948701/1.0", "spec_version" : "https://w3id.org/ieee/ieee-2791-schema/2791object.json", "etag": "d41d8cd98f00b204e9800998ecf8427e", "provenance_domain": {..."

'''Go back to [[BCO Domains]].'''

== Top Level Fields ==
These header fields uniquely define this BCO. These fields are required for every BCO and are represented at the top level object.

Condensed example:

{
"object_id": "https://example.com/BCO_948701/1.0",
"spec_version" : "https://w3id.org/ieee/ieee-2791-schema/2791object.json",
"etag": "d41d8cd98f00b204e9800998ecf8427e",
"provenance_domain": {
},
"...": { }
}

=== BCO version “spec_version” ===

The version of the BCO specification is used to define the BCO. It is recommended that this value is a permalink as defined in the [https://github.com/perma-id/w3id.org/tree/master/biocompute w3id.org/biocompute] repository.

"spec_version": "https://w3id.org/ieee/ieee-2791-schema/2791object.json"

=== BioCompute Object Identifier “object_id” ===

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 [https://datatracker.ietf.org/doc/html/rfc4122 UUID]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 implemented by the [https://github.com/biocompute-objects/bco%20api/releases BCODB]:

The "object_id" consists of four different parts:

| <protocol> | <hostname> | <BCO accession> | <BCO version> |
| ------------ | ---------------------- | ---------------- | -------------- |
| https:// | biocomputeobject.org/ | /BCO_000001 | /1.5 |

#Protocol: It is recommended that this be HTTPS or at least HTTP [https://datatracker.ietf.org/doc/html/rfc3986 see Scheme in RFC 3986] for more detail on protocols.
#Hostname: [https://datatracker.ietf.org/doc/html/rfc3986 see Host in RFC_3986]
#BCO Accession: composed of 2 parts separated by an underscore( _):
#*The BCO Prefix: A 3-5 alphanumeric characters. Preferably one registered via the [[Best Practices|BioCompute Registry]]
#*BCO identifier: a numeric identifier appended to the prefix
#BCO version: This is the version of the BCO, as recorded on the [[Provenance Domain]]
"object_id": "https://biocomputeobject.org/BCO_000001/1.5"

=== ETag “etag” ===

A string-type, read-only value, protects the object from internal or external alterations without proper validation. The string should be generated through the use of an SHA-256 hash function. Everything EXCEPT for the etag, object_id, and spec_version should be included in the generation of the hash. For example:

"provenance_domain": {},
"usability_domain": [],
"extension_domain":{},
"description_domain": {},
"execution_domain": {},
"parametric_domain": [],
"io_domain": {},
"error_domain": {}

will generate the following:

"etag": "584C7FE128717E1712426AB19CAAEA8BC1E27365B54285BBEA1221284C7D3A48"

== Additional domains ==
Additional description about the BCO itself is also provided in the [[Provenance Domain]], [[Description Domain]] and [[Usability Domain]]. Other domains detail areas like execution and error ranges.

BCO Domains

2026-04-14T21:24:16Z

Lorikrammer: /* Error Domain (error_domain) */

'''Go back to [[Main_Page|BioCompute Objects]].'''

=== BioCompute Objects Visualization ===
An Observable documentation showing a visualization of a BCO object workflow can be found [https://observablehq.com/@neurogenomics/biocompute-objects-visualization-student-workflows here].

=== [[Top-level|Top Level Fields]] ===

The top-level JSON object of a BCO includes attributes to define the BCO itself.

The remaining top-level fields detail different domains of the BCO, as listed below.

== BCO Domains ==

A [[Main Page|BCO]] JSON object is split into different parts, or domains, detailed below.

Condensed example:
"spec_version" : "https://w3id.org/biocompute/1.3.0/",
"object_id": "https://example.com/bco/9487ae7e-c1aa-4a3c-b18f-3d3695b33ace",
"type": "antiviral_resistance_detection",
"etag": "584C7FE128717E1712426AB19CAAEA8BC1E27365B54285BBEA1221284C7D3A48",
"provenance_domain": {
},
"usability_domain": [
],
"extension_domain":{
},
"description_domain": {
},
"execution_domain": {
},
"parametric_domain": {
},
"io_domain": {
},
"error_domain": {
}

=== [[Provenance Domain|Provenance Domain (<nowiki>''provenance_domain''</nowiki>)]] ===

The provenance_domain defines the history, version and status of this BCO as part of the review process.

=== [[Usability Domain|Usability Domain (''usability_domain'')]] ===

The usability_domain is meant to improve searchability by allowing a free-text description of the BCO.

=== [[Extension Domain|Extension Domain (''extension_domain'')]] ===

The extension_domain is a space for a user to add additional structured information that is not defined in the BioCompute schema. While the extension_domain is not defined by IEEE-2791-2020, each extension in the extension domain must provide a reference to the schema that defines it in order to validate. The extension domain is the place to add any additional structured information. We provide an example here that is neither exclusive nor exhaustive.

=== [[Description Domain|Description Domain (''description_domain'')]] ===

The description_domain contains a structured field for the description of external references, the pipeline steps, and the relationship of I/O objects.

=== [[Execution Domain|Execution Domain (''execution_domain'')]] ===

The execution_domain contains fields for the execution of the BCO.

=== [[Parametric Domain|Parametric Domain (''parametric_domain'')]] ===

The parametric_domain represents the list of parameters customizing the computational flow which can affect the output of the calculations.

=== [[Input and Output Domain|Input and Output Domain (''io_domain'')]] ===

The io_domain represents the list of global input and output files created by the computational workflow.

=== [[Error Domain|Error Domain (''error_domain'')]] ===

The error_domain defines the empirical and algorithmic limits and error sources of the BCO.

FAQs

2026-04-14T21:23:58Z

Lorikrammer:

'''Go back to [[Main Page|BioCompute Objects]].'''

== General ==
1. '''How can I build a BioCompute Object (BCO)?'''

You have several options for building a BCO. You can use the standalone "builder" tool available [https://biocomputeobject.org/builder here]. Alternatively, if you're using a platform that supports BioCompute, you can utilize tools built into that platform such as DNAnexus/precisionFDA, Galaxy, or Seven Bridges/Cancer Genomics Cloud. You may also choose to build an output into your workflow as a JSON file conforming to the standard.

2. '''What are the minimum requirements for conformance with the BioCompute standard?'''

The minimum requirements include inputs, outputs, data transformation steps, environment details, individuals involved in pipeline development or execution, and a plain text description of the pipeline's objectives. The standard allows for much greater detail if needed, and is extensible to include substantially more. The standard is organized into 8 domains, 5 of which are required and 3 are optional.

3. '''How can I ensure my submission validates against the BioCompute schema?'''

Your submission should validate against the schema, which you can reference directly at the top level domain provided [https://opensource.ieee.org/2791-object/ieee-2791-schema/-/raw/master/2791object.json?ref_type=heads here].

4. '''Where can I find more information about the BioCompute standard and its organization?''' The official repository for the standard is open access and can be found [https://opensource.ieee.org/2791-object/ieee-2791-schema/ here].

5. '''Can you provide an example of a completed BioCompute Object (BCO)?'''

Yes, you can view an example of a completed BCO [https://biocomputeobject.org/viewer?https://biocomputeobject.org/BCO_000452/1.0 here]. You can explore both table and raw JSON views.

6. '''Where would information regarding data sources and standard operating procedures be? Which specific domain?'''

Data sources should be recorded as described by the input_subdomain in the “[[Input and Output Domain]]” and the input_list in the “[[Description Domain]]”. Standard operating procedures and any other information about data transformations SHOULD be elaborated upon in the “[[Usability Domain]]”.

7. '''How can a third-party access URIs in a BCO?'''

URIs can be directed to local paths. In these cases, the necessary files are shared with the parties that will require access. If it is a link to a public domain, it will be easily accessible for all.

8. '''What is a SHA1 Checksum?'''

A SHA-1 checksum, or Secure Hash Algorithm 1 checksum, is a fixed-size output (160 bits) generated from input data to uniquely identify and verify the integrity of files or documents. In BioCompute Objects (BCOs), it serves to ensure the unchanged state of computational workflows by comparing calculated and original checksums. This allows for accuracy in viewing and downloading BCOs.

9. '''How do I sign in with an ORCID/What is an ORCID?'''

[https://orcid.org/ ORCID] stands for Open Researcher and Contributor ID, and is a free, unique identifier assigned to researchers, providing a standardized way to link researchers to their scholarly activities. To sign in with your ORCID, create an account at: https://orcid.org/. Using the credentials associated with your ORCID account you can log in to view and edit BCOs.

== Pipeline Questions ==

1. '''Do pipeline steps have to represent sequentially run steps? How can you represent steps also run in parallel?'''

The standard does not mandate any particular numbering schema, but it’s best practice to pick the most logically intuitive numbering system. For example, a user may run a somatic SNV profiling step at the same time as a structural CNV analysis. So if in the example I mentioned, the alignment is step #2, then you might (arbitrarily) call the SNV profiling step #3, and the CNV analysis step #4. The fact that they pull from the output of the same step (#2) can easily be detected programmatically and represented in whatever way is suitable (e.g. graphically).

2. '''What is the nf-core plugin and how can I test it?'''

The nf-core plugin, designed to facilitate Nextflow workflows, is now available for testing. To enable the BCO (BioCompute Object) format within the plugin, follow these instructions:

* Ensure you have the latest version of the plugin installed.

* Add the following code snippets to your Nextflow configuration file:

plugins {

id 'nf-prov'

}

prov.enabled = true

prov {

formats {

bco {

file = 'bco.json'

overwrite = true

}

}

}

These settings will enable the BCO format and specify the output file as "bco.json". Ensure you include these snippets in your configuration file to activate the BCO format.

For any questions related to Nextflow environment, please ask [https://github.com/nextflow-io/nf-prov/issues here]

== Inputs and Outputs ==

1. '''What is the relationship and difference between input_list in description_domain and I/O Domain? Does input list in I/O domain contain all the input files of all the pipeline steps?'''

Yes. The Input Domain is for global inputs. The input_list/output_list in the pipeline_steps is specific to individual steps and is used to trace data flow if granular detail is needed. If not needed, a user can simply look at the IO domain for the overall view of the pipeline inputs.

2. '''What is the relationship and difference between output_list in description_domain and I/O Domain? Does output list in I/O domain contain all the output files of all the pipeline steps?'''

The Output Domain is for global outputs. The input_list/output_list in the pipeline_steps is specific to individual steps and is used to trace data flow if granular detail is needed. If not needed, a user can simply look at the IO domain for the overall view of the pipeline outputs.

3. '''There is an access_time property for uri, which is referenced by input_list, output_list, input_subdomain, and output_subdomain. What does access_time mean for output files? Aren’t output files generated by pipeline steps?'''

Yes they are, the timestamp is used for creation in those cases.

4. '''Can a script from the execution domain also be considered an input?'''

This is not usually the case, but it is possible for the script to be assessed as an input if it is used in the workflow to bring about an output.

== Extensions ==

1. '''What is the role of extension_domain? How does it relate to other domains? Is it required in some pipeline steps? Or does it affect the execution? Or something else?'''

Extension Domain is never required, it is always optional. It is a user-defined space for capturing anything not already captured in the base BCO. To use it, one generates an extension schema (referenced in the extension_schema), and the associated fields within the BCO. For example, if a user wants to include a specialized ontology with definitions, it can be added here. It’s meant to capture anything idiosyncratic to that workflow not already captured in the standard and is very flexible.

2. '''How can BCOs be used for knowledgebases?'''

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.

BCOs can be generated via a user-friendly instance of a BCO editor and can be maintained and shared through versioned, stable IDs stored under a single domain of that knowledgebase. BCOs not only provide complete transparency to their data submitters (authors, curators, other databases, etc.), collaborators, and users but also provide an efficient mechanism to reproduce the complete workflow through the information stored in different domains (such as description, execution, io, error, etc.) in the machine and human-readable formats.

The most common way of adapting BCOs for use in knowledgebases is by leveraging the Extension Domain. In this example, the Extension Domain is used for calling fields based on column headers. Note that the Extension Domain identifies its own schema, which defines the column headers and identifies them as required where appropriate. Because the JSON format of a BCO is human and machine-readable (and can be further adapted for any manner of display or editing through a user interface), BCOs are amendable to either manual or automatic curation processes, such as the curation process that populates those fields in the above example.

== Prerequisites ==

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 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.

== BCO Scoring System ==

1. '''How is the score calculated?'''

The score is computed based on a few key factors:

* '''Usability Domain''': The length of the ''usability_domain'' field contributed to the base score
* '''Field Length Modifier''': A multiplier (1.2) is applied to the base score to account for field length
* '''Error Domain''': If the ''error_domain'' exist and is inserted correctly, 5 points are added
* '''Parametric Objects''': A multiplier (1.1) is applied to the score for each parametric object in the ''parametric_objects'' list
* '''Reviewer Objects''': Up to 5 points are added, one for each correct ''reviewer_object''

2. '''What happens if the ''usability_domain'' is missing?'''

If the ''usability_domain'' or other required fields are missing the BCO score is immediately set to 0, and the function returns the BCO instance without further calculations.

3. '''What is the purpose of the ''bco_score'' function'''

The ''bco_score'' function calculates and assigns a unique score to each BioCompute Object (BCO) based on specific criteria in its contents. The score is influenced by the presence of characteristics of certain fields like the ''usabiliy_domain'', ''error_domain'', ''parametric_objects'', and ''reviewer_objects''.

4. '''What is the purpose of the ''field_length_modifier'' and ''parametric_object_multiplier''?'''

* ''field_length_modifier'' (1.2): This modifier adjusts the base score according to the length of the usability_domain field.
* ''parametric_object_multiplier'' (1.1): This multiplier increases the score based on the number of parametric objects present in the BCO, reflecting the complexity of the object.

5. '''What is the expected output of the bco_score function?'''

The ''bco_score'' function modifies the BCO instance by assigning a ''score'' attribute based on the criteria mentioned above, the updated BCO instance, with the score added, is then returned following the saving of the BCO draft.

6. '''How does the reviewer count affect the score?'''

For each ''reviewer_object'' present in the BCO (up to maximum of 5 reviewers), the score increases by 1 point. This incentivizes the inclusion of peer review and validation within the object.

7. '''What is the significance of ''entAliases'' in the ''convert_to_ldh'' function?'''

The ''entAliases'' field is a list that stores multiple identifiers for the BioCompute Object. These include the ''object_id,'' its full URL (entIri), and its entity type (entType), ensuring that the object can be referenced in different contexts.

8. '''How and Where does the score appear on the BCO Builder?'''

The score is calculated by the ''bco_score'' function and is displayed within the BioCompute Object (BCO) metadata section of the BCO Builder interface, following the saving of a BCO draft.

== BCO for Knowledgebases ==

1. '''Can BCOs be used for curating databases?'''

Yes. BCOs have been used in this capacity, such as in the [https://data.argosdb.org/ FDA’s ARGOS database of infectious diseases] and the [https://data.glygen.org/ GlyGen database of glycosylation sites]. 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.

BCOs can be generated via a user-friendly instance of a BCO editor and can be maintained and shared through versioned, stable IDs stored under a single domain of that knowledgebase. BCOs not only provide complete transparency to their data submitters (authors, curators, other databases, etc.), collaborators, and users but also provide an efficient mechanism to reproduce the complete workflow through the information stored in different domains (such as description, execution, io, error, etc.) in the machine and human-readable formats.

The most common way of adapting BCOs for use in knowledgebases is by leveraging the Extension Domain. In this example, the Extension Domain is used for calling fields based on column headers. Note that the Extension Domain identifies its own schema, which defines the column headers and identifies them as required where appropriate. Because the JSON format of a BCO is human and machine-readable (and can be further adapted for any manner of display or editing through a user interface), BCOs are amendable to either manual or automatic curation processes, such as the curation process that populates those fields in the above example.

== Saving and Publishing a BCO ==

1. '''Why is my BCO not saved after clicking '''SAVE'''?'''

The '''SAVE''' only saves the entry on the website but it's not saving to the server. For a new draft, after editing, go to '''Tools''', first select a BCODB, then click on '''GET PREFIXES''' to choose a prefix, and lastly, click on '''SAVE PREFIX'''. For an existing draft, to save properly, click on '''SAVE''' first and then under '''Tools''', select '''UPDATE DRAFT'''.

2. '''What are the minimal requirements for validation and publishing with the BioCompute Objects (BCO) standard?'''

A submission simply needs to validate against the [https://opensource.ieee.org/2791-object/ieee-2791-schema/-/raw/master/2791object.json?ref_type=heads schema]. The minimal requirements include inputs, outputs, data transformation steps, environment details, person(s) who wrote or executed the pipeline, and a plain text description of the pipeline and its objectives.

== BCO Validation and Error messages ==

The BCO Portal uses a JSON validator to validate the BCOs, and because of the error messages returned may be a little confusing. Below are some common validation results and an explanation of what they mean and how to address them.

1. '''"[description_domain][pipeline_steps][0][step_number]": "'1' is not of type 'integer'"'''

The '''step_number''' in the BCO JSON needs to be an INTEGER.

This means it can not be in quotes like this:
''' "step_number": "1",'''
Instead, it must be represented like this:
''' "step_number": 1,'''

You may not be able to see this difference in the '''COLOR-CODED''' view, and will have to look in the '''TREE VIEW JSON''' or '''RAW JSON VIEW'''.

=== Error Domain error message ===
The error domain will sometimes give an error message when you try to publish the BCO. The troubleshooting steps are mapped out in the [[Error Domain|Error Domain page]].

== Submitting BCOs to FDA ==

=== Submission Process and Requirements ===
# '''How should I submit a BCO with a regulatory submission?''' Both JSON (the original format of BCO) and plain text (".txt") documents are accepted by the FDA. BCO files can be included as a JSON file under Module 5.3.5.4 and submitted to the FDA as supporting documents in the Electronic Common Technical Document (eCTD) for the submission of bioinformatics workflow data to both CDER (Center for Drug Evaluation and Research) and CBER (Center for Biologics Evaluation and Research) for regulatory reviews. Human Foods Program (HFP; formerly known as the Center for Food Safety and Nutrition, or CFSAN) also accepts BCOs. Please check with your reviewer or review division for logistical details to submit a BCO. BCOs can contain links to files that are submitted via hard drive. File sharing via the FDA-HIVE portal is not currently available.
# '''What is the minimum content requirement for a Sample eCTD Submission to CDER?''' Module 1 and Module 5 (Module 5.3.5.4 especially where the BCO is located) are required. A cover letter (states the purpose of the submission and the intentional submission center) and FDA Form (1571 for IND and 356h for NDA/BLA/ANDA), and BCO file.
# '''Can I submit a BCO without data files?''' Yes, but if the sponsor is submitting a BCO without the data they should seek agreement with the review division prior to submission.
# '''Which center should the eCTD (containing BCO file(s)) be submitted to?''' Both CDER and CBER centers accept eCTD submissions and they both have the ability to review the submission files if requested.
# '''How to submit eCTD?''' eCTD (which contains BCO file) should be submitted via Test Electronic Submission Gateway (ESG) to both CBER and CDER. In order for both centers to receive the submission, sponsors would need to make a submission to each center via the ESG Gateway.
# '''Where should BCO files be placed within the eCTD?''' We recommend including BCO files as part of a study, referenced under a Study Tagging File, under Module 5.3.5.4 (Other Study Reports).

=== Dataset and File Submission Details ===
# '''How to include or indicate dataset information in the BCO and/or ESG submission?''' There are a few options to include the dataset information in the BCO or ESG submission: (Note: it is mandatory to include dataset information in the Cover Letter, however, if you would like to add more clarity, you may choose from the option 2-4 listed below)
## Include in the dataset information in the Cover Letter: State how the datasets are submitted (via ESG or hard drive), the tracking number, estimated delivery date. This option is mandatory for BCO submission to the FDA to help reviewers to track down related datasets.
##Globally, suggest to include datasets information in the Usability Domain and refer to the root of the hard drive, see example below:[[File:Screenshot 2024-11-11 at 16.14.20.png|center|thumb|591x591px]]
##If you prefer to mention the file structure and names in each step, then the datasets information can be included in description domain, see example below:[[File:Screenshot 2024-11-11 at 16.14.05.png|center|thumb|620x620px]]
##If you would like to use the file structure and names from an existing schema, you may enter the schema URL in the extension domain, using the Figure 1 from this [https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1000424 paper] as an example, the JSON schema defines the file structure and names
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "http://json-schema.org/draft-07/schema#",
"title": "Computational Biology Project Structure",
"type": "object",
"properties": {
"level 1": {
"type": "object",
"properties": {
"msms": {
"type": "string",
"description": "Main directory for project data and scripts."
},
"level 2": {
"type": "object",
"properties": {
"doc": {
"type": "object",
"description": "Project documentation",
"properties": {
"paper": {
"type": "string",
"description": "Documents related to the project."
}
}
},
"data": {
"type": "string",
"description": "Directory for data files."
},
"src": {
"type": "string",
"description": "Source code directory."
},
"bin": {
"type": "string",
"description": "Executable files."
},
"results": {
"type": "object",
"description": "Results directory with analysis outputs.",
"properties": {
"2009_01_15": {
"type": "string",
"description": "Data from analysis on 2009-01-15."
},
"2009_01_23": {
"type": "string",
"description": "Data from analysis on 2009-01-23."
}
}
}
}
}
}
},
"level 3": {
"type": "object",
"properties": {
"2009_01_14": {
"type": "object",
"description": "Initial analysis on 2009-01-14.",
"properties": {
"yeast": {
"type": "string",
"description": "Yeast dataset."
},
"worm": {
"type": "string",
"description": "Worm dataset."
}
}
},
"2009_01_15": {
"type": "object",
"description": "Follow-up analysis and summary on 2009-01-15.",
"properties": {
"split1": {
"type": "string",
"description": "First data split."
},
"split2": {
"type": "string",
"description": "Second data split."
},
"split3": {
"type": "string",
"description": "Third data split."
}
}
}
}
}
}
# '''How to submit large I/O files to the FDA?''' Please refer to the [https://www.fda.gov/industry/create-esg-account/frequently-asked-questions#_Q19 FDA site] for the definition of large I/O files. Large I/O files need to be sent on a hard drive to CBER, which FDA-HIVE is nested under CBER. All data will be uploaded/downloaded to HIVE. CDER reviewers will use the CBER HIVE to receive and review this type of data. Please use the following address for the hard drive: <u>U.S. Food and Drug Administration</u> <u>Center for Biologics Evaluation and Research</u> <u>Document Control Center</u> <u>10903 New Hampshire Avenue</u> <u>WO71, G112</u> <u>Silver Spring, MD 20993-0002.</u> Also, please add information of the dataset submission plan or details in the Cover Letter so that the reviewer knows it is coming and when to expect it.
#'''Are there any specific notes or memos that should be included with the hard drive?''' Yes, please ensure that the application number is attached to the hard drive for easier processing and identification. In addition, provide the shipping company name, transit number and expected delivery date when available to DCC (DCCEDR@fda.hhs.gov).
# '''Can I submit BCOs on a portable hard drive if requested by the FDA?''' BCOs can also be stored on a portable<ins> </ins>hard drive and referenced in the eCTD. This allows for easy access and verification of the BCO files during the review process'''.''' The hard drive submitted to HIVE (CBER), CDER would also have access to the data.
# '''How much data needs to be submitted?''' There is no minimum requirement; it depends on the goal of the submission and the scope of the submission.
# '''Is the software used required for submission?''' Software used is not required to be submitted. However, some divisions would want software details; this depends very much on where the submission goes.

=== Tools and Technical Details ===
# '''What is Electronic Submissions Gateway (ESG)?''' The Electronic Submissions Gateway (ESG) is the FDA's primary way to receive electronic regulatory submissions.
# '''What materials are required to register for an ESG account?''' FDA ESG provides two methods, WebTrader and AS2 for making submissions to the FDA. WebTrader is a web-based user interface to send documents and receive receipts and acknowledgments from the FDA with minimal technical expertise. To set up WebTrader, several preparatory steps are needed. First, prepare an electronic Letter of Non-Repudiation Agreement; Second, generate or obtain a free personal digital certificate. These two documents are needed during the account registration step. Other optional preparatory steps include preparing a guidance-compliant test submission and a load test submission. For more details, review the formal FDA documentation [https://www.fda.gov/industry/create-esg-account/setting-webtrader-account-checklist here]. To register the WebTrader account, go to the ESG Account Management Portal at '''''[https://esgportal.fda.gov/ https://esgportal.fd]<nowiki/>[https://esgportal.fda.gov/ a.go][https://esgportal.fda.gov/ v/].''''' Then select "New Account Registration" and follow the '''''<nowiki/>'''''prompts. Please refer to the [https://www.fda.gov/industry/about-esg/esg-account-management-portal-user-guide ESG Account Management Portal User Guide] for instructions. After account registration, users need to set up the local machine. Download the required WebTrader Client Installer (Note: only compatible with Windows machines). AS2 (System-to-System) allows industry partners to have the option to access the Gateway via system-to-system communication. It provides an automated connection to the FDA for submissions, receipts, and acknowledgments, generally used by sponsors that have a high volume of submissions. However, this system requires AS2-compliant software and technical expertise. For more information regarding AS2, refer to the [https://www.fda.gov/industry/create-esg-account/setting-as2-account-checklist Setting up an AS2 Account Checklist].
# '''How much data can ESG (Electronic Submission Gateway) handle?''' The maximum file size for a single file (non-folder) is 100 GB of uncompressed data. The maximum file size for a multi-file (folder) is 100 GB of uncompressed data that contains single files (non-folder) no larger than 6 GB of uncompressed data. ESG recommends that you send an email to [[Mailto:ESGHelpDesk@fda.hhs.gov|ESGHelpDesk@fda.hhs.gov]] for all submissions over 10 GB of uncompressed data. The FDA recommends that submissions greater than 15 GB and less than 25 GB in size be sent overnight starting at 5PM EST to ensure receipt by the targeted FDA Center during the next business day. For large datasets, they need to be submitted via hard drive to CBER, for more information, refer to the FAQ above.
# '''For more ESG-related questions, refer to the official FDA ESG FAQ site [https://www.fda.gov/industry/create-esg-account/frequently-asked-questions#_Q19 here]. If you have questions for CBER, please contact CBER ESUB at esubprep@fda.hhs.goc; if the questions are for CDER, please contact CDER ESUB at esub@fda.hhs.gov; if general ESG-related questions, please contact ESG Help Desk at esghelpdesk@fda.hhs.gov.'''

=== Regulatory Applications and Use Cases ===
# '''For which types of regulatory submissions can BCOs be used?''' BCOs can be applied to the following types of regulatory submission:
#* Biologics license applications (BLAs);
#* Investigational new drug applications (INDs);
#* New drug applications (NDAs);
#* Abbreviated new drug applications (ANDAs).

== Archived Pilot Project Related FAQs ==

=== BCO Test Submission ===

# '''How to submit eCTD?''' eCTD portion of the pilot (which contains BCO file) should be submitted via Test Electronic Submission Gateway (ESG) to both CBER and CDER. In order for both centers to receive the submission, sponsors would need to make a submission to each center via the ESG Test Gateway.
## '''CDER:''' Participants should contact [[Mailto:ESUB-Testing@fda.hhs.gov|ESUB-Testing@fda.hhs.gov]] to request a sample application number to submit a BCO pilot submission. The subject line of the email should be “BCO Pilot”. Once the submission is sent through the ESG Test Gateway, the submitter will receive two gateway acknowledgements. The submitter will need to forward the second gateway acknowledgment which contains the “COR id” number to the ESUB-Testing team so they can locate the submission and notify the FDA Pilot point of contact.
## '''CBER''': Participants should contact [[Mailto:ESUBPREP@fda.hhs.gov|ESUBPREP@fda.hhs.gov]] to request a sample application number to submit a BCO pilot submission. The ESUBPREP team should also be notified when the submission is inbound. The subject line of any email related to the pilot should contain “BCO Pilot.” Once the submission is sent through the ESG Test Gateway, the submitter will receive up to three acknowledgments. The submitter will need to forward the second gateway notification acknowledgment, containing the Core ID number, to the ESUBPREP team (also referencing “BCO Pilot” in the subject line) so the submission can be located and shared with the FDA Pilot point of contact. Please note that if a third acknowledgment is generated containing a rejection notification, it should be ignored by the submitter.

# '''What is Electronic Submission Gateway (ESG)?''' The Electronic Submissions Gateway (ESG) is the FDA's primary way to receive electronic regulatory submissions. The Test ESG is in a pre-production environment and will be used for this pilot.
# '''Are intermediate datasets/files required for the purpose of the pilot project?''' Currently, the intermediate files are not required to be submitted at the initial phase of the pilot project.

=== Communication and Support ===
# '''How should sponsors contact the FDA regarding BioCompute Object submissions?''' We do have points of contact at both CDER and CBER centers. If you have general submission and review questions regarding BCO submissions, please contact [[Mailto:cber-edata@fda.hhs.gov|cber-edata@fda.hhs.gov]] if submitted to CBER; [[Mailto:edata@fda.hhs.gov|edata@fda.hhs.gov]] for CDER.
# '''What should sponsors do if they have general questions about BioCompute Object submissions but do not have a submission in-house?''' If sponsors have general questions about BioCompute Object submissions and do not currently have a submission in-house, they can reach out to the email address industry.biologics@fda.hhs.gov managed by OCOD (Office of Computational and Data Sciences). The request will be triaged and directed to the appropriate individuals to provide assistance and address inquiries.

==Publications==
To explore our publications, please visit [https://hive.biochemistry.gwu.edu/publications this link].

Error Domain

2026-04-14T21:23:16Z

Lorikrammer: Created page with "'''Go back to BCO Domains.''' == Error Domain (''error_domain)'' == This section, also known as the ''acceptable range of variability'', is an optional domain comprised of two subdomains: empirical and algorithmic. The error domain IEEE schema and definition can be found [https://opensource.ieee.org/2791-object/ieee-2791-schema/-/blob/master/error_domain.json here]. The possible keys within each subdomain are workflow-specific, human-readable free text. For data i..."

'''Go back to [[BCO Domains]].'''

== Error Domain (''error_domain)'' ==

This section, also known as the ''acceptable range of variability'', is an optional domain comprised of two subdomains: empirical and algorithmic. The error domain IEEE schema and definition can be found [https://opensource.ieee.org/2791-object/ieee-2791-schema/-/blob/master/error_domain.json here].

The possible keys within each subdomain are workflow-specific, human-readable free text. For data integration, BCOs used to develop knowledge bases, the error domain can, for example, contain rules that determine inclusion in the knowledge base and reference to data that pass and fail the set of rules.

Condensed example:
<pre>
"error_domain": {
"empirical_error": {
},
"algorithmic_error": {
}
}
</pre>
{| class="wikitable"
|+Required Components of the Error Domain
!Domain
!Subdomain
!Required
|-
|error_domain
|
|OPTIONAL
|-
|
|empirical_error
|REQUIRED
|-
|
|algorithmic_error
|REQUIRED
|}

== Empirical Subdomain ==
The empirical subdomain contains empirically determined values such as limits of detectability, false positives, false negatives, statistical confidence of outcomes, etc. This can be measured by running the algorithm on multiple data samples of the usability domain or through the use of carefully designed in-silico data. For example, a set of spiked, well-characterized samples can be run through the algorithm to determine the false positives, negatives, and limits of detection.

== Algorithmic Subdomain ==
The algorithmic subdomain is descriptive of errors that originate by the fuzziness of the algorithms, driven by stochastic processes, in dynamically parallelized multi-threaded executions, or in machine learning methodologies where the state of the machine can affect the outcome. This can be measured by taking a random subset of the data and re-running the analysis, or using some rigorous mathematical modeling of the accumulated errors and providing confidence values. For example, bootstrapping is frequently used with stochastic simulation-based algorithms to accumulate sets of outcomes and estimate statistically significant variability for the results.<pre>
"error_domain": {
"empirical_error": {
"false_negative_alignment_hits": "<0.0010",
"false_discovery": "<0.05"
},
"algorithmic_error": {
"false_positive_mutation_calls": "<0.00005",
"false_discovery": "0.005"
}
}
</pre>

== Error Domain Troubleshooting ==
When using the [https://biocomputeobject.org/ BioCompute Object Portal] to create your own BCO or update an existing one, sometimes a bug in the error domain occurs. The portal will say there is an error when you go to publish the BCO. There is a workaround available for this bug:

1. Navigate to the Error Domain tab on the left-hand side menu.

2. You will see the editable section similar to this:
{
"algorithmic_error": {},
"empirical_error": {}
}
3. Carefully delete just one character, such as , or the } on the bottom, and then immediately put it back in its correct spot. This essentially is telling the portal that 'you made an edit here'.

4. Click on the next arrow. Then click 'Save BCO'.

5. Click on publish BCO, and this should fix the issue.

BCO Domains

2026-04-14T21:22:29Z

Lorikrammer: /* Parametric Domain (parametric_domain) */

'''Go back to [[Main_Page|BioCompute Objects]].'''

=== BioCompute Objects Visualization ===
An Observable documentation showing a visualization of a BCO object workflow can be found [https://observablehq.com/@neurogenomics/biocompute-objects-visualization-student-workflows here].

=== [[Top-level|Top Level Fields]] ===

The top-level JSON object of a BCO includes attributes to define the BCO itself.

The remaining top-level fields detail different domains of the BCO, as listed below.

== BCO Domains ==

A [[Main Page|BCO]] JSON object is split into different parts, or domains, detailed below.

Condensed example:
"spec_version" : "https://w3id.org/biocompute/1.3.0/",
"object_id": "https://example.com/bco/9487ae7e-c1aa-4a3c-b18f-3d3695b33ace",
"type": "antiviral_resistance_detection",
"etag": "584C7FE128717E1712426AB19CAAEA8BC1E27365B54285BBEA1221284C7D3A48",
"provenance_domain": {
},
"usability_domain": [
],
"extension_domain":{
},
"description_domain": {
},
"execution_domain": {
},
"parametric_domain": {
},
"io_domain": {
},
"error_domain": {
}

=== [[Provenance Domain|Provenance Domain (<nowiki>''provenance_domain''</nowiki>)]] ===

The provenance_domain defines the history, version and status of this BCO as part of the review process.

=== [[Usability Domain|Usability Domain (''usability_domain'')]] ===

The usability_domain is meant to improve searchability by allowing a free-text description of the BCO.

=== [[Extension Domain|Extension Domain (''extension_domain'')]] ===

The extension_domain is a space for a user to add additional structured information that is not defined in the BioCompute schema. While the extension_domain is not defined by IEEE-2791-2020, each extension in the extension domain must provide a reference to the schema that defines it in order to validate. The extension domain is the place to add any additional structured information. We provide an example here that is neither exclusive nor exhaustive.

=== [[Description Domain|Description Domain (''description_domain'')]] ===

The description_domain contains a structured field for the description of external references, the pipeline steps, and the relationship of I/O objects.

=== [[Execution Domain|Execution Domain (''execution_domain'')]] ===

The execution_domain contains fields for the execution of the BCO.

=== [[Parametric Domain|Parametric Domain (''parametric_domain'')]] ===

The parametric_domain represents the list of parameters customizing the computational flow which can affect the output of the calculations.

=== [[Input and Output Domain|Input and Output Domain (''io_domain'')]] ===

The io_domain represents the list of global input and output files created by the computational workflow.

=== [[Error-domain|Error Domain (''error_domain'')]] ===

The error_domain defines the empirical and algorithmic limits and error sources of the BCO.

Parametric Domain

2026-04-14T21:22:09Z

Lorikrammer: Created page with "'''Go back to BCO Domains.''' == Parametric Domain (parametric_domain) == This optional domain represents the list of parameters customizing the computational flow which can affect the output of the calculations. These fields can be custom to each kind of analysis and are tied to a particular pipeline implementation. The provenance domain IEEE schema and definition can be found [https://opensource.ieee.org/2791-object/ieee-2791-schema/-/blob/master/parametric_domai..."

'''Go back to [[BCO Domains]].'''

== Parametric Domain (parametric_domain) ==

This optional domain represents the list of parameters customizing the computational flow which can affect the output of the calculations. These fields can be custom to each kind of analysis and are tied to a particular pipeline implementation. The provenance domain IEEE schema and definition can be found [https://opensource.ieee.org/2791-object/ieee-2791-schema/-/blob/master/parametric_domain.json?ref_type=heads here].

Condensed example:
<pre>
"parametric_domain": [
]
</pre>
{| class="wikitable"
|+Required Components of the Provenance Domain
!Field
!Required
|-
|parametric_domain
|OPTIONAL
|}
It is recommended that these fields be generated automatically, but that may not always be possible. Please refer to the documentation of individual scripts and specific BCO descriptions for details. While this domain is not required, it is recommended that it be populated and that the values be '''non-default''' parameters.

== Parametric Domain Example ==
<pre>
"parametric_domain": [
{"param": "seed", "value": "14", "step": "1"},
{"param":"minimum_match_len", "value": "66", "step": "1"},
{"param": "divergence_threshold_percent", "value": 0.30, "step": "1"},
{"param": "minimum_coverage", "value": "15", "step": "2"},
{"param": "freq_cutoff", "value": 0.10, "step": "2"}
]
</pre>

BCO Domains

2026-04-14T21:21:21Z

Lorikrammer: /* Execution Domain (execution_domain) */

'''Go back to [[Main_Page|BioCompute Objects]].'''

=== BioCompute Objects Visualization ===
An Observable documentation showing a visualization of a BCO object workflow can be found [https://observablehq.com/@neurogenomics/biocompute-objects-visualization-student-workflows here].

=== [[Top-level|Top Level Fields]] ===

The top-level JSON object of a BCO includes attributes to define the BCO itself.

The remaining top-level fields detail different domains of the BCO, as listed below.

== BCO Domains ==

A [[Main Page|BCO]] JSON object is split into different parts, or domains, detailed below.

Condensed example:
"spec_version" : "https://w3id.org/biocompute/1.3.0/",
"object_id": "https://example.com/bco/9487ae7e-c1aa-4a3c-b18f-3d3695b33ace",
"type": "antiviral_resistance_detection",
"etag": "584C7FE128717E1712426AB19CAAEA8BC1E27365B54285BBEA1221284C7D3A48",
"provenance_domain": {
},
"usability_domain": [
],
"extension_domain":{
},
"description_domain": {
},
"execution_domain": {
},
"parametric_domain": {
},
"io_domain": {
},
"error_domain": {
}

=== [[Provenance Domain|Provenance Domain (<nowiki>''provenance_domain''</nowiki>)]] ===

The provenance_domain defines the history, version and status of this BCO as part of the review process.

=== [[Usability Domain|Usability Domain (''usability_domain'')]] ===

The usability_domain is meant to improve searchability by allowing a free-text description of the BCO.

=== [[Extension Domain|Extension Domain (''extension_domain'')]] ===

The extension_domain is a space for a user to add additional structured information that is not defined in the BioCompute schema. While the extension_domain is not defined by IEEE-2791-2020, each extension in the extension domain must provide a reference to the schema that defines it in order to validate. The extension domain is the place to add any additional structured information. We provide an example here that is neither exclusive nor exhaustive.

=== [[Description Domain|Description Domain (''description_domain'')]] ===

The description_domain contains a structured field for the description of external references, the pipeline steps, and the relationship of I/O objects.

=== [[Execution Domain|Execution Domain (''execution_domain'')]] ===

The execution_domain contains fields for the execution of the BCO.

=== [[Parametric-domain|Parametric Domain (''parametric_domain'')]] ===

The parametric_domain represents the list of parameters customizing the computational flow which can affect the output of the calculations.

=== [[Input and Output Domain|Input and Output Domain (''io_domain'')]] ===

The io_domain represents the list of global input and output files created by the computational workflow.

=== [[Error-domain|Error Domain (''error_domain'')]] ===

The error_domain defines the empirical and algorithmic limits and error sources of the BCO.

SOP

2026-04-14T21:20:47Z

Lorikrammer: /* Extension domain */

'''Go back to [[Main_Page|BioCompute Objects]].'''

= BCO Curation SOP =

Intended audience: authors and developers

The following recommendations are intended to provide guidance on BCO™ creation, versioning, certification, and authentication.

== BCO IDs and Versioning ==

Intended Audience: BCO authors

*[[Main Page|BioCompute]] IDs are used as persistent URLs. A novel usability domain must result in the creation of a new BCO with a new BCO ID. BCO IDs are immutable upon creation and are never deleted or retired. If the usability domain (UD) remains unchanged, this results in a new version of the BCO. BCO ID example: OMX_000001
*BCO major and minor versions can be incremented based on project/institution documented policies.
*The BioCompute consortium maintains a database of registered authorities. Registered authorities are able to assign their reserved prefixes to their own IDs in the object_id field, such as OMX_000001. We encourage everyone to register a prefix at biocomputeobject.org.

== BioCompute Certification(s) and Authentication ==

Intended Audience: commercial or academic entities looking for additional BCO support

'''Platform certification:''' A BioCompute “audit” will be conducted by the BioCompute Consortium. Requirements include:

*IEEE-2791 conformant BCOs can be created
*Security (ex: immutable upon creation, secure sharing, platform security)
*Data QC processes on input/output

'''Syntactical certification:''' Code is available on GitHub for download and use to ensure standard compliance.

'''Scientific certification:''' BCO consortium members will participate in the certification process; each certification process is projected to take ~ 3 months to 1 year to develop pipelines. Verification Kit: Input+output file(s) (in-silico generated), and Template BCO (tBCO) that includes error domain).

'''Template and Run Authentication:''' The Template BCO (tBCO) is created once along with a Verification Kit. Verification Kit usually includes in silico generated input files, BCO (with error domain) and output files. Run BCOs (rBCO) uses the tBCOs, and the only changes allowed are in the input (excluding reference files/databases) and output files field. tBCOs and rBCOs can be authenticated using secure blockchain technology.

*Template certification requirements: Input + output files
*Run certification requirements: certified template + run BCO (to confirm that parameters and error domain is within range etc.)
[[File:Certification requirements.png|800px|thumb|center]]

== BCO Metadata ==
The three metadata fields are filled out at the time of submission. Validity check fills in the spec_version with the IEEE URL, an option to run a SHA256 (or just input your own hash value) for etag, and object_id is assigned (with the option to choose from any prefix associated with the account).

== Domain-specific guidance ==
=== Execution domain ===

When recording manual curation, the script field of the execution_domain should link to a Google Document or GitHub markdown that describes the steps, either programmatically or in a stepwise fashion. Manual curation steps should ALSO be properly documented in the description_domain. An easy way to conceptualize this is: Description domain is for people, Execution domain is for machine (or programmers).

=== Extension domain ===

Format of how the schema would be defined: [[Extension Domain]]

=== Error domain ===

This domain can support a “QA/QC rules” subdomain which provides rules that, if the output file does not pass the appropriate criteria, then it is flagged as an error.

=== BCO Form-based portal ===

Intended Audience: BCO tool developers and authors

BCOs can be created using any bioinformatics platform that has BCO read and writes functionalities. For users who do not have access to a bioinformatics platform they can use the [https://biocomputeobject.org/builder BCO Builder] in the [https://biocomputeobject.org/ BCO Portal] which has some of the basic API functionalities:

*Create a BCO that is conformant to IEEE-2791.
*Download and install an instance within an organization’s firewall
*View videos and documentation on tool use

=== Versioning ===

Any version previous to the current version of a BCO is considered immutable and should not be edited. For example: Once an analysis has been recorded as a BCO, and has undergone several versioning changes, v1.0 of that BCO cannot be edited.

This documentation is currently in the commenting phase until Sept. 15, 2020. Please send your comments to Jonathon Keeney.

SOP

2026-04-14T21:20:21Z

Lorikrammer: /* Domain-specific guidance */

'''Go back to [[Main_Page|BioCompute Objects]].'''

= BCO Curation SOP =

Intended audience: authors and developers

The following recommendations are intended to provide guidance on BCO™ creation, versioning, certification, and authentication.

== BCO IDs and Versioning ==

Intended Audience: BCO authors

*[[Main Page|BioCompute]] IDs are used as persistent URLs. A novel usability domain must result in the creation of a new BCO with a new BCO ID. BCO IDs are immutable upon creation and are never deleted or retired. If the usability domain (UD) remains unchanged, this results in a new version of the BCO. BCO ID example: OMX_000001
*BCO major and minor versions can be incremented based on project/institution documented policies.
*The BioCompute consortium maintains a database of registered authorities. Registered authorities are able to assign their reserved prefixes to their own IDs in the object_id field, such as OMX_000001. We encourage everyone to register a prefix at biocomputeobject.org.

== BioCompute Certification(s) and Authentication ==

Intended Audience: commercial or academic entities looking for additional BCO support

'''Platform certification:''' A BioCompute “audit” will be conducted by the BioCompute Consortium. Requirements include:

*IEEE-2791 conformant BCOs can be created
*Security (ex: immutable upon creation, secure sharing, platform security)
*Data QC processes on input/output

'''Syntactical certification:''' Code is available on GitHub for download and use to ensure standard compliance.

'''Scientific certification:''' BCO consortium members will participate in the certification process; each certification process is projected to take ~ 3 months to 1 year to develop pipelines. Verification Kit: Input+output file(s) (in-silico generated), and Template BCO (tBCO) that includes error domain).

'''Template and Run Authentication:''' The Template BCO (tBCO) is created once along with a Verification Kit. Verification Kit usually includes in silico generated input files, BCO (with error domain) and output files. Run BCOs (rBCO) uses the tBCOs, and the only changes allowed are in the input (excluding reference files/databases) and output files field. tBCOs and rBCOs can be authenticated using secure blockchain technology.

*Template certification requirements: Input + output files
*Run certification requirements: certified template + run BCO (to confirm that parameters and error domain is within range etc.)
[[File:Certification requirements.png|800px|thumb|center]]

== BCO Metadata ==
The three metadata fields are filled out at the time of submission. Validity check fills in the spec_version with the IEEE URL, an option to run a SHA256 (or just input your own hash value) for etag, and object_id is assigned (with the option to choose from any prefix associated with the account).

== Domain-specific guidance ==
=== Execution domain ===

When recording manual curation, the script field of the execution_domain should link to a Google Document or GitHub markdown that describes the steps, either programmatically or in a stepwise fashion. Manual curation steps should ALSO be properly documented in the description_domain. An easy way to conceptualize this is: Description domain is for people, Execution domain is for machine (or programmers).

=== Extension domain ===

Format of how the schema would be defined: [[Execution Domain]]

=== Error domain ===

This domain can support a “QA/QC rules” subdomain which provides rules that, if the output file does not pass the appropriate criteria, then it is flagged as an error.

=== BCO Form-based portal ===

Intended Audience: BCO tool developers and authors

BCOs can be created using any bioinformatics platform that has BCO read and writes functionalities. For users who do not have access to a bioinformatics platform they can use the [https://biocomputeobject.org/builder BCO Builder] in the [https://biocomputeobject.org/ BCO Portal] which has some of the basic API functionalities:

*Create a BCO that is conformant to IEEE-2791.
*Download and install an instance within an organization’s firewall
*View videos and documentation on tool use

=== Versioning ===

Any version previous to the current version of a BCO is considered immutable and should not be edited. For example: Once an analysis has been recorded as a BCO, and has undergone several versioning changes, v1.0 of that BCO cannot be edited.

This documentation is currently in the commenting phase until Sept. 15, 2020. Please send your comments to Jonathon Keeney.

Execution Domain

2026-04-14T21:19:51Z

Lorikrammer: Created page with "'''Go back to BCO Domains.''' == Execution Domain (''execution_domain'') == This section defines the ''execution_domain'' part of the BCO. The execution domain IEEE schema, and definition can be found [https://opensource.ieee.org/2791-object/ieee-2791-schema/-/blob/master/execution_domain.json here]. The fields required for the execution of the BCO have been encapsulated together in order to clearly separate information needed for deployment, softwa..."

'''Go back to [[BCO Domains]].'''
== Execution Domain (''execution_domain'') ==

This section defines the ''execution_domain'' part of the [[BCO Domains|BCO]]. The execution domain IEEE schema, and definition can be found [https://opensource.ieee.org/2791-object/ieee-2791-schema/-/blob/master/execution_domain.json here].

The fields required for the execution of the BCO have been encapsulated together in order to clearly separate information needed for deployment, software configuration, and running applications in a dependent environment. One byproduct of an accurate BCO definition is the facilitation of reproducibility as defined by the Oxford English Dictionary as “the extent to which consistent results are obtained when produced repeatedly.”

Condensed example:

"execution_domain": {
"script_access_type": "text",
"script": [
],
"script_driver": "manual",
"software_prerequisites": [
],
"external_data_endpoints": [
],
"environment_variables": {
}
}
{| class="wikitable"
|+Required Components of the Execution Domain
!Component
!Sub-Component
!REQUIRED
|-
|'''script'''
|
|'''REQUIRED'''
|-
|
|'''uri'''
|'''REQUIRED'''
|-
|'''script_driver'''
|
|'''REQUIRED'''
|-
|'''software_prerequisites'''
|
|'''REQUIRED'''
|-
|
|'''name'''
|'''REQUIRED'''
|-
|
|'''version'''
|'''REQUIRED'''
|-
|
|'''uri'''
|'''REQUIRED'''
|-
|'''external_data_endpoints'''
|
|'''REQUIRED'''
|-
|
|'''name'''
|'''REQUIRED'''
|-
|
|'''url'''
|'''REQUIRED'''
|-
|'''environment_variables'''
|
|'''REQUIRED'''
|}

== Domain Components ==

=== Script (''script'') ===

The Script field is an array containing pointers to a script object or objects. These can be internal or external references to objects that were used to perform computations for this BCO instance. These may be references to an object in GitHub, a computational service, or any other type of script. (Please note: A valid uri has to have the “protocol.domain.subdomain”. Protocols: HTTP,HTTPS,etc)

"script": [
{
"uri": {
"uri": "https://example.com/workflows/antiviral_resistance_detection_hive.py"
}
}
]

=== Script driver (''script_driver'')===

This field provides a space to indicate what kind of executable can be launched in order to perform a sequence of commands described in the script (see above).

"script_driver": "shell"

=== Algorithmic tools and Software Prerequisites (''software_prerequisites'') ===

An array listing the minimal necessary prerequisites, library, and tool versions needed to successfully run the pipeline described by the BCO. The keys are ''name'', ''version'', and ''uri''.

"software_prerequisites": [
{
"name": "HIVE-hexagon",
"version": "babajanian.1",
"uri": {
"uri": "http://example.com/dna.cgi?cmd=dna-hexagon&cmdMode=-",
"access_time": "2017-01-24T09:40:17-0500",
"sha1_chksum": "d60f506cddac09e9e816531e7905ca1ca6641e3c"
}
},
{
"name": "HIVE-heptagon",
"version": "albinoni.2",
"uri": {
"uri": "http://example.com/dna.cgi?cmd=dna-heptagon&cmdMode=-",
"access_time": "2017-01-24T09:40:17-0500"
}
}
]

=== External Data Endpoints (''external_data_endpoints'') ===

An array listing the minimal necessary domain-specific external data sources accessed in order to successfully run the workflow described by the BCO. The values under this field present the requirements for network protocol endpoints used by a pipeline’s scripts, or other software.

The key url defines an endpoint to be accessed. If the path of the URL is /, then any resource at the given domain may be accessed, while if the path is more specific, only resources whose path prefix matches may be accessed.

The key name should describe the service that is accessed.

"external_data_endpoints": [
{"url": "protocol://domain:port/application/path","name": "generic name"},
{"url": "ftp://data.example.com:21/",
"name": "access to ftp server"},
{"url": "http://eutils.ncbi.nlm.nih.gov/entrez/eutils",
"name": "access to e-utils web service"}
]

=== Environment Variables (''environment_variables'') ===

This is an array of key-value pairs useful to configure the execution environment on the target platform. For example, one might specify the number of computing cores or available memory use of the script. The possible keys are specific to each platform. The “value” should be a JSON string.

The regex is based on the following: [http://pubs.opengroup.org/onlinepubs/000095399/basedefs/xbd%20chap08.html http://pubs.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap08.html] Environment variable names used by the utilities in the Shell and Utilities volume of IEEE Std 1003.1-2001 consist solely of uppercase letters, digits, and the ‘_’ (underscore) from the characters defined in Portable Character Set and do not begin with a digit. Other characters may be permitted by an implementation; applications shall tolerate the presence of such names. Uppercase and lowercase letters shall retain their unique identities and shall not be folded together. The namespace of environment variable names containing lowercase letters is reserved for applications. Applications can define any environment variables with names from this namespace without modifying the behavior of the standard utilities. Note: Other applications may have difficulty dealing with environment variable names that start with a digit. For this reason, the use of such names is not recommended anywhere.

"environment_variables": {
"HOSTTYPE": "x86_64-linux",
"EDITOR": "vim"
}

==== How to set up environment variables on local machine ====
Please refer to [https://www3.ntu.edu.sg/home/ehchua/programming/howto/Environment%20Variables.html how to set environment variables] for more information regarding setting an Environment Variable Permanently in Windows/macOS/Linux
* '''Windows'''
*# press '''''Windows''''' and '''''R''''' key on the keyboard at the same time. Type '''''sysdm.cpl''''' into the blank field and then hit '''''Enter'''''.
*# In the new windows that opens, go to '''''Advanced''''' and click on '''''Environment Variables''''' in the bottom right of the window.
*# In the '''''Environment Variables'''' window, users should be able to see the current variables and create a new user variable on the local machine.

* '''macOS and Linux'''
*# First determine operating system by run <code>echo $SHELL</code> in Terminal
*## The end of the output should indicate the shell you are running. Usually is <code>/bin/bash</code>. This means the operating system is <code>bash</code> shell. It can also be <code>zsh</code> or <code>fish</code>. The following steps are similar for either shell system.
*# To view the list of the current environment variables, use <code>env</code> command.
'''Note: only environment variables related to the workflow need to be mentioned in the BCO instead of the entire environment. If nothing else, please use the PATH variable for where is the executable script is.'''

BCO Domains

2026-04-14T21:18:11Z

Lorikrammer: /* Description Domain (description_domain) */

'''Go back to [[Main_Page|BioCompute Objects]].'''

=== BioCompute Objects Visualization ===
An Observable documentation showing a visualization of a BCO object workflow can be found [https://observablehq.com/@neurogenomics/biocompute-objects-visualization-student-workflows here].

=== [[Top-level|Top Level Fields]] ===

The top-level JSON object of a BCO includes attributes to define the BCO itself.

The remaining top-level fields detail different domains of the BCO, as listed below.

== BCO Domains ==

A [[Main Page|BCO]] JSON object is split into different parts, or domains, detailed below.

Condensed example:
"spec_version" : "https://w3id.org/biocompute/1.3.0/",
"object_id": "https://example.com/bco/9487ae7e-c1aa-4a3c-b18f-3d3695b33ace",
"type": "antiviral_resistance_detection",
"etag": "584C7FE128717E1712426AB19CAAEA8BC1E27365B54285BBEA1221284C7D3A48",
"provenance_domain": {
},
"usability_domain": [
],
"extension_domain":{
},
"description_domain": {
},
"execution_domain": {
},
"parametric_domain": {
},
"io_domain": {
},
"error_domain": {
}

=== [[Provenance Domain|Provenance Domain (<nowiki>''provenance_domain''</nowiki>)]] ===

The provenance_domain defines the history, version and status of this BCO as part of the review process.

=== [[Usability Domain|Usability Domain (''usability_domain'')]] ===

The usability_domain is meant to improve searchability by allowing a free-text description of the BCO.

=== [[Extension Domain|Extension Domain (''extension_domain'')]] ===

The extension_domain is a space for a user to add additional structured information that is not defined in the BioCompute schema. While the extension_domain is not defined by IEEE-2791-2020, each extension in the extension domain must provide a reference to the schema that defines it in order to validate. The extension domain is the place to add any additional structured information. We provide an example here that is neither exclusive nor exhaustive.

=== [[Description Domain|Description Domain (''description_domain'')]] ===

The description_domain contains a structured field for the description of external references, the pipeline steps, and the relationship of I/O objects.

=== [[Execution-domain|Execution Domain (''execution_domain'')]] ===

The execution_domain contains fields for the execution of the BCO.

=== [[Parametric-domain|Parametric Domain (''parametric_domain'')]] ===

The parametric_domain represents the list of parameters customizing the computational flow which can affect the output of the calculations.

=== [[Input and Output Domain|Input and Output Domain (''io_domain'')]] ===

The io_domain represents the list of global input and output files created by the computational workflow.

=== [[Error-domain|Error Domain (''error_domain'')]] ===

The error_domain defines the empirical and algorithmic limits and error sources of the BCO.

Description Domain

2026-04-14T21:17:53Z

Lorikrammer: Created page with "'''Go back to BCO Domains.''' == Description Domain (''description_domain'') == This section defines the fields of the ''description_domain'' part of the BCO structure. The description domain IEEE schema and definition can be found [https://opensource.ieee.org/2791-object/ieee-2791-schema/-/blob/master/description_domain.json here]. Structured field for description of external references, the pipeline steps, and the relationship of I/O objects. Info..."

'''Go back to [[BCO Domains]].'''

== Description Domain (''description_domain'') ==
This section defines the fields of the ''description_domain'' part of the [[BCO Domains|BCO]] structure. The description domain IEEE schema and definition can be found [https://opensource.ieee.org/2791-object/ieee-2791-schema/-/blob/master/description_domain.json here].

Structured field for description of external references, the pipeline steps, and the relationship of I/O objects. Information in this domain is not used for computation. This domain is meant to capture information that is currently being provided in FDA submission in a standardized format. It is possible that some of these fields be automatically generated from the execution_domain information, and that some of them may repeat.

Condensed example:
"description_domain": {
"keywords": [
],
"xref": [
],
"platform": ["HIVE"],
"pipeline_steps": [
{
"step_number": 1,
"name": "HIVE-hexagon",
"description": "Alignment of reads to a set of references",
"version": "1.3",
"prerequisite": [
{
"name": "Hepatitis C virus genotype 1",
"uri": {
"uri": "http://www.ncbi.nlm.nih.gov/nuccore/22129792",
"access_time": "2017-01-24T09:40:17-0500"
}
}
],
"input_list": [
],
"output_list": [
]
}
]
}
{| class="wikitable"
|+Required Components of the Description Domain
!Component
!Sub-Component
!Required
|-
|'''keywords'''
|
|'''REQUIRED'''
|-
|xref
|
|OPTIONAL
|-
|
|namespace
|REQUIRED
|-
|
|name
|REQUIRED
|-
|
|ids
|REQUIRED
|-
|
|access_time
|REQUIRED
|-
|platform
|
|OPTIONAL
|-
|'''pipeline steps'''
|
|'''REQUIRED'''
|-
|
|'''step_number'''
|'''REQUIRED'''
|-
|
|'''name'''
|'''REQUIRED'''
|-
|
|'''description'''
|'''REQUIRED'''
|-
|
|version
|OPTIONAL
|-
|
|prerequisite
|OPTIONAL
|-
|
|'''input_list'''
|'''REQUIRED'''
|-
|
|'''output_list'''
|'''REQUIRED'''
|}

== Domain Components ==

=== Keywords (''keywords'') ===
This is a list of keywords to aid in search-ability and description of the experiment. This is required.

"keywords": [
"HCV1a",
"Ledipasvir",
"antiviral resistance",
"SNP",
"amino acid substitutions"
]<br />
=== External References (''xref'') ===
This field contains a list of the databases and/or ontology IDs that are cross-referenced in the BCO. The external references are used to provide more specificity in the information related to BCO entries. Full path to resource is not necessary, only namespace and identifier. The external references are stored in the form of prefixed identifiers (CURIEs). These CURIEs map directly to the URIs maintained by identifiers.org. Therefore, cross-referenced resources need to be available in the public domain. If external resources were used that do not conform to the criteria for inclusion in the xref field, they should be listed elsewhere (e.g. Extension Domain).

<pre>
"xref": [
{
"namespace": "pubchem.compound",
"name": "PubChem-compound",
"ids": ["67505836"],
"access_time": "2018-13-02T10:15-05:00"
},

{
"namespace": "pubmed",
"name": "PubMed",
"ids": ["26508693"],
"access_time": "2018-13-02T10:15-05:00"
},

{
"namespace": "so",
"name": "Sequence Ontology",
"ids": ["SO:000002", "SO:0000694", "SO:0000667", "SO:0000045"],
"access_time": "2018-13-02T10:15-05:00"
},

{
"namespace": "taxonomy",
"name": "Taxonomy",
"ids": ["31646"],
"access_time": "2018-13-02T10:15-05:00"
}
]
</pre>
=== Platform/Environment (''platform'') ===

The multi-value reference to a particular deployment of an existing platform where this BCO can be reproduced. A platform can be a bioinformatic platform such as Galaxy or HIVE or it can be a software package such as CASAVA or apps that includes multiple algorithms and software. This is for informative purposes only.

"platform": ["HIVE"]

=== Pipeline tools (''pipeline_steps'') ===

This is a required, structured domain for tracing the steps of a pipeline. Each individual tool (or a well-defined and reusable script) is represented as a step, at the discretion of the author (e.g. a spot check of the data may not be officially included in ''pipeline_steps''; however for minor steps like these, it is recommended to mention them in the ''Usability Domain'').

Steps can be run in parallel. While the standard does not mandate any particular numbering schema, it is best practice to pick the most logically intuitive numbering system, and to keep numbering unique (i.e. do not repeat step numbers), such that each step has its own, unique integer. For example, a user may run a somatic SNV profiling step at the same time as a structural CNV analysis. Assume that an alignment is step #2, and that SNV profiling and CNV analysis follow this step. The user might (arbitrarily) call the SNV profiling step #3, and the CNV analysis step #4, instead of number both as #3. The fact that they pull from the output of the same step (#2) can easily be detected programmatically and represented in whatever way is suitable (e.g. graphically), but both still retain a unique numbering value.

==== Step Number (''step_number'') ====
This is a non-negative integer value representing the position of the tool in a one-dimensional representation of the pipeline. The number is a suggestion for a [https://en.wikipedia.org/wiki/Partially%20ordered%20set partial order] for presentation purposes, e.g. parallel computations assigned the same number based on their first possible execution. The actual execution order might differ from the step number. Gaps are allowed (e.g. step 20 follows step 10).

"step_number": 1

==== Name (''name'') ====
Name for the specific tool. This field is a string (A-z, 0-1) and should be a single uniquely identifying word for the tool.

"name": "HIVE-hexagon"

==== Tool Description (''description'') ====
A free text field for describing the specific use/purpose of the tool.

"description": "Alignment of reads to a set of references",

==== Tool Version (''version'') ====
The version assigned to the instance of the tool used corresponding to the upstream release.

"version": "1.3",

==== 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)

"prerequisite": [
{
"name": "Hepatitis C virus genotype 1",
"uri": {
"uri": "http://www.ncbi.nlm.nih.gov/nuccore/22129792",
"access_time": "2017-01-24T09:40:17-0500"
}
},
{
"name": "Hepatitis C virus type 1b complete genome",
"uri": {
"uri": "http://www.ncbi.nlm.nih.gov/nuccore/5420376",
"access_time": "2017-01-24T09:40:17-0500"
}
},
{
"name": "Hepatitis C virus (isolate JFH-1) genomic RNA",
"uri": {
"uri": "http://www.ncbi.nlm.nih.gov/nuccore/13122261",
"access_time": "2017-01-24T09:40:17-0500"
}
},
{
"name": "Hepatitis C virus clone J8CF, complete genome",
"uri": {
"uri": "http://www.ncbi.nlm.nih.gov/nuccore/386646758",
"access_time": "2017-01-24T09:40:17-0500"
}
},
{
"name": "Hepatitis C virus S52 polyprotein gene",
"uri": {
"uri": "http://www.ncbi.nlm.nih.gov/nuccore/295311559",
"access_time": "2017-01-24T09:40:17-0500"
}
}
]

==== Input List (''input_list'') ====
Each tool lists the URIs (expressed as a URN or URL) of the input files. These are a catchall for read files, reference files or any other type of input. All of these fields are optional and for descriptive purposes, therefore the structure here is less rigid than in other fields.

"input_list": [
{
"uri": "https://hive.biochemistry.gwu.edu/dna.cgi?cmd=objFile&ids=514683",
"access_time": "2017-01-24T09:40:17-0500"
},
{
"uri": "https://hive.biochemistry.gwu.edu/dna.cgi?cmd=objFile&ids=514682",
"access_time": "2017-01-24T09:40:17-0500"
}
],

==== Output List (''output_list'') ====
Each tool lists the URIs (expressed as a URN or URL) of the output files for that tool.

"output_list": [
{
"uri": "https://hive.biochemistry.gwu.edudata/514769/allCount-aligned.csv",
"access_time": "2017-01-24T09:40:17-0500"
}
]

BCO Domains

2026-04-14T21:17:08Z

Lorikrammer: /* Extension Domain (extension_domain) */

'''Go back to [[Main_Page|BioCompute Objects]].'''

=== BioCompute Objects Visualization ===
An Observable documentation showing a visualization of a BCO object workflow can be found [https://observablehq.com/@neurogenomics/biocompute-objects-visualization-student-workflows here].

=== [[Top-level|Top Level Fields]] ===

The top-level JSON object of a BCO includes attributes to define the BCO itself.

The remaining top-level fields detail different domains of the BCO, as listed below.

== BCO Domains ==

A [[Main Page|BCO]] JSON object is split into different parts, or domains, detailed below.

Condensed example:
"spec_version" : "https://w3id.org/biocompute/1.3.0/",
"object_id": "https://example.com/bco/9487ae7e-c1aa-4a3c-b18f-3d3695b33ace",
"type": "antiviral_resistance_detection",
"etag": "584C7FE128717E1712426AB19CAAEA8BC1E27365B54285BBEA1221284C7D3A48",
"provenance_domain": {
},
"usability_domain": [
],
"extension_domain":{
},
"description_domain": {
},
"execution_domain": {
},
"parametric_domain": {
},
"io_domain": {
},
"error_domain": {
}

=== [[Provenance Domain|Provenance Domain (<nowiki>''provenance_domain''</nowiki>)]] ===

The provenance_domain defines the history, version and status of this BCO as part of the review process.

=== [[Usability Domain|Usability Domain (''usability_domain'')]] ===

The usability_domain is meant to improve searchability by allowing a free-text description of the BCO.

=== [[Extension Domain|Extension Domain (''extension_domain'')]] ===

The extension_domain is a space for a user to add additional structured information that is not defined in the BioCompute schema. While the extension_domain is not defined by IEEE-2791-2020, each extension in the extension domain must provide a reference to the schema that defines it in order to validate. The extension domain is the place to add any additional structured information. We provide an example here that is neither exclusive nor exhaustive.

=== [[Description-domain|Description Domain (''description_domain'')]] ===

The description_domain contains a structured field for the description of external references, the pipeline steps, and the relationship of I/O objects.

=== [[Execution-domain|Execution Domain (''execution_domain'')]] ===

The execution_domain contains fields for the execution of the BCO.

=== [[Parametric-domain|Parametric Domain (''parametric_domain'')]] ===

The parametric_domain represents the list of parameters customizing the computational flow which can affect the output of the calculations.

=== [[Input and Output Domain|Input and Output Domain (''io_domain'')]] ===

The io_domain represents the list of global input and output files created by the computational workflow.

=== [[Error-domain|Error Domain (''error_domain'')]] ===

The error_domain defines the empirical and algorithmic limits and error sources of the BCO.

Extension Domain

2026-04-14T21:16:47Z

Lorikrammer: Created page with "'''Go back to BCO Domains.''' == Extension Domain ''(extension_domain)'' == The ''extension_domain'' is a space for a user to add additional structured information that is not defined in the BioCompute schema. It is '''optional'''. While the extension domain is not defined by IEEE-2791-2020, each extension in this domain must provide a reference to the schema that defines it in order to validate. The extension domain allows a user to define additional fields and is..."

'''Go back to [[BCO Domains]].'''

== Extension Domain ''(extension_domain)'' ==

The ''extension_domain'' is a space for a user to add additional structured information that is not defined in the BioCompute schema. It is '''optional'''. While the extension domain is not defined by IEEE-2791-2020, each extension in this domain must provide a reference to the schema that defines it in order to validate. The extension domain allows a user to define additional fields and is the place to add any additional structured information.

Condensed example:
<pre>
"extension_domain":{
},
</pre>
{| class="wikitable"
|+Components of the Extension Domain
!Field
!Required
|-
|extension_schema
|OPTIONAL
|}

== Domain Components ==

=== Extensions ===
A valid JSON schema for each extension used in this domain is expected to be specified. The schema should be namespaced, and it is recommended that resolving the namespaced URI will provide the extension’s JSON Schema. The URL must be provided in the extension_schema field.

== Extension Domain Examples ==
*[[Extension-fhir|FHIR extension]]
*[[Extension-scm|SCM extension]]
We provide an example here that is neither exclusive nor exhaustive. The following example is taken from Extension to [https://github.com/biocompute-objects/extension%20domain/tree/1.1.0/scm External References: Software Configuration Management (SCM) v1.1.0]

"extension_domain":[
{
"extension_schema": "https://w3id.org/biocompute/extension_domain/1.1.0/scm/scm_extension.json",
"scm_extension": {
"scm_repository": "https://github.com/example/repo1",
"scm_type": "git",
"scm_commit": "c9ffea0b60fa3bcf8e138af7c99ca141a6b8fb21",
"scm_path": "workflow/hive-viral-mutation-detection.cwl",
"scm_preview": "https://github.com/example/repo1/blob/c9ffea0b60fa3bcf8e138af7c99ca141a6b8fb21/workflow/hive-viral-mutation-detection.cwl"
}
}
]

=== SCM Repository ''(scm_repository)'' ===
The base url for the SCM repository.

=== SCM Type ''(scm_type)'' ===
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 others.

=== SCM Commit ''(scm_commit)'' ===
This field is a reference to a revision within the scm repository. This SHOULD be a repository-wide commit identifier (e.g. afba51a222e199f5b58f9d19450f189055e93c44 or name of a tag (e.g. v1.0.0), but MAY be a name of a branch (e.g. master).

=== SCM Path ''(scm_path)'' ===
This is the path from the repository to the source code referenced. ''scm_path'' should NOT start with /.

=== SCM Preview ''(scm_preview)'' ===
The full URI for the source code is referenced by the BioCompute Object.

BCO Domains

2026-04-14T21:15:47Z

Lorikrammer: /* Usability Domain (usability_domain) */

'''Go back to [[Main_Page|BioCompute Objects]].'''

=== BioCompute Objects Visualization ===
An Observable documentation showing a visualization of a BCO object workflow can be found [https://observablehq.com/@neurogenomics/biocompute-objects-visualization-student-workflows here].

=== [[Top-level|Top Level Fields]] ===

The top-level JSON object of a BCO includes attributes to define the BCO itself.

The remaining top-level fields detail different domains of the BCO, as listed below.

== BCO Domains ==

A [[Main Page|BCO]] JSON object is split into different parts, or domains, detailed below.

Condensed example:
"spec_version" : "https://w3id.org/biocompute/1.3.0/",
"object_id": "https://example.com/bco/9487ae7e-c1aa-4a3c-b18f-3d3695b33ace",
"type": "antiviral_resistance_detection",
"etag": "584C7FE128717E1712426AB19CAAEA8BC1E27365B54285BBEA1221284C7D3A48",
"provenance_domain": {
},
"usability_domain": [
],
"extension_domain":{
},
"description_domain": {
},
"execution_domain": {
},
"parametric_domain": {
},
"io_domain": {
},
"error_domain": {
}

=== [[Provenance Domain|Provenance Domain (<nowiki>''provenance_domain''</nowiki>)]] ===

The provenance_domain defines the history, version and status of this BCO as part of the review process.

=== [[Usability Domain|Usability Domain (''usability_domain'')]] ===

The usability_domain is meant to improve searchability by allowing a free-text description of the BCO.

=== [[Extension-domain|Extension Domain (''extension_domain'')]] ===

The extension_domain is a space for a user to add additional structured information that is not defined in the BioCompute schema. While the extension_domain is not defined by IEEE-2791-2020, each extension in the extension domain must provide a reference to the schema that defines it in order to validate. The extension domain is the place to add any additional structured information. We provide an example here that is neither exclusive nor exhaustive.

=== [[Description-domain|Description Domain (''description_domain'')]] ===

The description_domain contains a structured field for the description of external references, the pipeline steps, and the relationship of I/O objects.

=== [[Execution-domain|Execution Domain (''execution_domain'')]] ===

The execution_domain contains fields for the execution of the BCO.

=== [[Parametric-domain|Parametric Domain (''parametric_domain'')]] ===

The parametric_domain represents the list of parameters customizing the computational flow which can affect the output of the calculations.

=== [[Input and Output Domain|Input and Output Domain (''io_domain'')]] ===

The io_domain represents the list of global input and output files created by the computational workflow.

=== [[Error-domain|Error Domain (''error_domain'')]] ===

The error_domain defines the empirical and algorithmic limits and error sources of the BCO.

FAQs

2026-04-14T21:14:36Z

Lorikrammer:

'''Go back to [[Main Page|BioCompute Objects]].'''

== General ==
1. '''How can I build a BioCompute Object (BCO)?'''

You have several options for building a BCO. You can use the standalone "builder" tool available [https://biocomputeobject.org/builder here]. Alternatively, if you're using a platform that supports BioCompute, you can utilize tools built into that platform such as DNAnexus/precisionFDA, Galaxy, or Seven Bridges/Cancer Genomics Cloud. You may also choose to build an output into your workflow as a JSON file conforming to the standard.

2. '''What are the minimum requirements for conformance with the BioCompute standard?'''

The minimum requirements include inputs, outputs, data transformation steps, environment details, individuals involved in pipeline development or execution, and a plain text description of the pipeline's objectives. The standard allows for much greater detail if needed, and is extensible to include substantially more. The standard is organized into 8 domains, 5 of which are required and 3 are optional.

3. '''How can I ensure my submission validates against the BioCompute schema?'''

Your submission should validate against the schema, which you can reference directly at the top level domain provided [https://opensource.ieee.org/2791-object/ieee-2791-schema/-/raw/master/2791object.json?ref_type=heads here].

4. '''Where can I find more information about the BioCompute standard and its organization?''' The official repository for the standard is open access and can be found [https://opensource.ieee.org/2791-object/ieee-2791-schema/ here].

5. '''Can you provide an example of a completed BioCompute Object (BCO)?'''

Yes, you can view an example of a completed BCO [https://biocomputeobject.org/viewer?https://biocomputeobject.org/BCO_000452/1.0 here]. You can explore both table and raw JSON views.

6. '''Where would information regarding data sources and standard operating procedures be? Which specific domain?'''

Data sources should be recorded as described by the input_subdomain in the “[[Input and Output Domain]]” and the input_list in the “[[Description Domain]]”. Standard operating procedures and any other information about data transformations SHOULD be elaborated upon in the “[[Usability Domain]]”.

7. '''How can a third-party access URIs in a BCO?'''

URIs can be directed to local paths. In these cases, the necessary files are shared with the parties that will require access. If it is a link to a public domain, it will be easily accessible for all.

8. '''What is a SHA1 Checksum?'''

A SHA-1 checksum, or Secure Hash Algorithm 1 checksum, is a fixed-size output (160 bits) generated from input data to uniquely identify and verify the integrity of files or documents. In BioCompute Objects (BCOs), it serves to ensure the unchanged state of computational workflows by comparing calculated and original checksums. This allows for accuracy in viewing and downloading BCOs.

9. '''How do I sign in with an ORCID/What is an ORCID?'''

[https://orcid.org/ ORCID] stands for Open Researcher and Contributor ID, and is a free, unique identifier assigned to researchers, providing a standardized way to link researchers to their scholarly activities. To sign in with your ORCID, create an account at: https://orcid.org/. Using the credentials associated with your ORCID account you can log in to view and edit BCOs.

== Pipeline Questions ==

1. '''Do pipeline steps have to represent sequentially run steps? How can you represent steps also run in parallel?'''

The standard does not mandate any particular numbering schema, but it’s best practice to pick the most logically intuitive numbering system. For example, a user may run a somatic SNV profiling step at the same time as a structural CNV analysis. So if in the example I mentioned, the alignment is step #2, then you might (arbitrarily) call the SNV profiling step #3, and the CNV analysis step #4. The fact that they pull from the output of the same step (#2) can easily be detected programmatically and represented in whatever way is suitable (e.g. graphically).

2. '''What is the nf-core plugin and how can I test it?'''

The nf-core plugin, designed to facilitate Nextflow workflows, is now available for testing. To enable the BCO (BioCompute Object) format within the plugin, follow these instructions:

* Ensure you have the latest version of the plugin installed.

* Add the following code snippets to your Nextflow configuration file:

plugins {

id 'nf-prov'

}

prov.enabled = true

prov {

formats {

bco {

file = 'bco.json'

overwrite = true

}

}

}

These settings will enable the BCO format and specify the output file as "bco.json". Ensure you include these snippets in your configuration file to activate the BCO format.

For any questions related to Nextflow environment, please ask [https://github.com/nextflow-io/nf-prov/issues here]

== Inputs and Outputs ==

1. '''What is the relationship and difference between input_list in description_domain and I/O Domain? Does input list in I/O domain contain all the input files of all the pipeline steps?'''

Yes. The Input Domain is for global inputs. The input_list/output_list in the pipeline_steps is specific to individual steps and is used to trace data flow if granular detail is needed. If not needed, a user can simply look at the IO domain for the overall view of the pipeline inputs.

2. '''What is the relationship and difference between output_list in description_domain and I/O Domain? Does output list in I/O domain contain all the output files of all the pipeline steps?'''

The Output Domain is for global outputs. The input_list/output_list in the pipeline_steps is specific to individual steps and is used to trace data flow if granular detail is needed. If not needed, a user can simply look at the IO domain for the overall view of the pipeline outputs.

3. '''There is an access_time property for uri, which is referenced by input_list, output_list, input_subdomain, and output_subdomain. What does access_time mean for output files? Aren’t output files generated by pipeline steps?'''

Yes they are, the timestamp is used for creation in those cases.

4. '''Can a script from the execution domain also be considered an input?'''

This is not usually the case, but it is possible for the script to be assessed as an input if it is used in the workflow to bring about an output.

== Extensions ==

1. '''What is the role of extension_domain? How does it relate to other domains? Is it required in some pipeline steps? Or does it affect the execution? Or something else?'''

Extension Domain is never required, it is always optional. It is a user-defined space for capturing anything not already captured in the base BCO. To use it, one generates an extension schema (referenced in the extension_schema), and the associated fields within the BCO. For example, if a user wants to include a specialized ontology with definitions, it can be added here. It’s meant to capture anything idiosyncratic to that workflow not already captured in the standard and is very flexible.

2. '''How can BCOs be used for knowledgebases?'''

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.

BCOs can be generated via a user-friendly instance of a BCO editor and can be maintained and shared through versioned, stable IDs stored under a single domain of that knowledgebase. BCOs not only provide complete transparency to their data submitters (authors, curators, other databases, etc.), collaborators, and users but also provide an efficient mechanism to reproduce the complete workflow through the information stored in different domains (such as description, execution, io, error, etc.) in the machine and human-readable formats.

The most common way of adapting BCOs for use in knowledgebases is by leveraging the Extension Domain. In this example, the Extension Domain is used for calling fields based on column headers. Note that the Extension Domain identifies its own schema, which defines the column headers and identifies them as required where appropriate. Because the JSON format of a BCO is human and machine-readable (and can be further adapted for any manner of display or editing through a user interface), BCOs are amendable to either manual or automatic curation processes, such as the curation process that populates those fields in the above example.

== Prerequisites ==

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 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.

== BCO Scoring System ==

1. '''How is the score calculated?'''

The score is computed based on a few key factors:

* '''Usability Domain''': The length of the ''usability_domain'' field contributed to the base score
* '''Field Length Modifier''': A multiplier (1.2) is applied to the base score to account for field length
* '''Error Domain''': If the ''error_domain'' exist and is inserted correctly, 5 points are added
* '''Parametric Objects''': A multiplier (1.1) is applied to the score for each parametric object in the ''parametric_objects'' list
* '''Reviewer Objects''': Up to 5 points are added, one for each correct ''reviewer_object''

2. '''What happens if the ''usability_domain'' is missing?'''

If the ''usability_domain'' or other required fields are missing the BCO score is immediately set to 0, and the function returns the BCO instance without further calculations.

3. '''What is the purpose of the ''bco_score'' function'''

The ''bco_score'' function calculates and assigns a unique score to each BioCompute Object (BCO) based on specific criteria in its contents. The score is influenced by the presence of characteristics of certain fields like the ''usabiliy_domain'', ''error_domain'', ''parametric_objects'', and ''reviewer_objects''.

4. '''What is the purpose of the ''field_length_modifier'' and ''parametric_object_multiplier''?'''

* ''field_length_modifier'' (1.2): This modifier adjusts the base score according to the length of the usability_domain field.
* ''parametric_object_multiplier'' (1.1): This multiplier increases the score based on the number of parametric objects present in the BCO, reflecting the complexity of the object.

5. '''What is the expected output of the bco_score function?'''

The ''bco_score'' function modifies the BCO instance by assigning a ''score'' attribute based on the criteria mentioned above, the updated BCO instance, with the score added, is then returned following the saving of the BCO draft.

6. '''How does the reviewer count affect the score?'''

For each ''reviewer_object'' present in the BCO (up to maximum of 5 reviewers), the score increases by 1 point. This incentivizes the inclusion of peer review and validation within the object.

7. '''What is the significance of ''entAliases'' in the ''convert_to_ldh'' function?'''

The ''entAliases'' field is a list that stores multiple identifiers for the BioCompute Object. These include the ''object_id,'' its full URL (entIri), and its entity type (entType), ensuring that the object can be referenced in different contexts.

8. '''How and Where does the score appear on the BCO Builder?'''

The score is calculated by the ''bco_score'' function and is displayed within the BioCompute Object (BCO) metadata section of the BCO Builder interface, following the saving of a BCO draft.

== BCO for Knowledgebases ==

1. '''Can BCOs be used for curating databases?'''

Yes. BCOs have been used in this capacity, such as in the [https://data.argosdb.org/ FDA’s ARGOS database of infectious diseases] and the [https://data.glygen.org/ GlyGen database of glycosylation sites]. 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.

BCOs can be generated via a user-friendly instance of a BCO editor and can be maintained and shared through versioned, stable IDs stored under a single domain of that knowledgebase. BCOs not only provide complete transparency to their data submitters (authors, curators, other databases, etc.), collaborators, and users but also provide an efficient mechanism to reproduce the complete workflow through the information stored in different domains (such as description, execution, io, error, etc.) in the machine and human-readable formats.

The most common way of adapting BCOs for use in knowledgebases is by leveraging the Extension Domain. In this example, the Extension Domain is used for calling fields based on column headers. Note that the Extension Domain identifies its own schema, which defines the column headers and identifies them as required where appropriate. Because the JSON format of a BCO is human and machine-readable (and can be further adapted for any manner of display or editing through a user interface), BCOs are amendable to either manual or automatic curation processes, such as the curation process that populates those fields in the above example.

== Saving and Publishing a BCO ==

1. '''Why is my BCO not saved after clicking '''SAVE'''?'''

The '''SAVE''' only saves the entry on the website but it's not saving to the server. For a new draft, after editing, go to '''Tools''', first select a BCODB, then click on '''GET PREFIXES''' to choose a prefix, and lastly, click on '''SAVE PREFIX'''. For an existing draft, to save properly, click on '''SAVE''' first and then under '''Tools''', select '''UPDATE DRAFT'''.

2. '''What are the minimal requirements for validation and publishing with the BioCompute Objects (BCO) standard?'''

A submission simply needs to validate against the [https://opensource.ieee.org/2791-object/ieee-2791-schema/-/raw/master/2791object.json?ref_type=heads schema]. The minimal requirements include inputs, outputs, data transformation steps, environment details, person(s) who wrote or executed the pipeline, and a plain text description of the pipeline and its objectives.

== BCO Validation and Error messages ==

The BCO Portal uses a JSON validator to validate the BCOs, and because of the error messages returned may be a little confusing. Below are some common validation results and an explanation of what they mean and how to address them.

1. '''"[description_domain][pipeline_steps][0][step_number]": "'1' is not of type 'integer'"'''

The '''step_number''' in the BCO JSON needs to be an INTEGER.

This means it can not be in quotes like this:
''' "step_number": "1",'''
Instead, it must be represented like this:
''' "step_number": 1,'''

You may not be able to see this difference in the '''COLOR-CODED''' view, and will have to look in the '''TREE VIEW JSON''' or '''RAW JSON VIEW'''.

=== Error Domain error message ===
The error domain will sometimes give an error message when you try to publish the BCO. The troubleshooting steps are mapped out in the [[Error-domain|Error Domain page]].

== Submitting BCOs to FDA ==

=== Submission Process and Requirements ===
# '''How should I submit a BCO with a regulatory submission?''' Both JSON (the original format of BCO) and plain text (".txt") documents are accepted by the FDA. BCO files can be included as a JSON file under Module 5.3.5.4 and submitted to the FDA as supporting documents in the Electronic Common Technical Document (eCTD) for the submission of bioinformatics workflow data to both CDER (Center for Drug Evaluation and Research) and CBER (Center for Biologics Evaluation and Research) for regulatory reviews. Human Foods Program (HFP; formerly known as the Center for Food Safety and Nutrition, or CFSAN) also accepts BCOs. Please check with your reviewer or review division for logistical details to submit a BCO. BCOs can contain links to files that are submitted via hard drive. File sharing via the FDA-HIVE portal is not currently available.
# '''What is the minimum content requirement for a Sample eCTD Submission to CDER?''' Module 1 and Module 5 (Module 5.3.5.4 especially where the BCO is located) are required. A cover letter (states the purpose of the submission and the intentional submission center) and FDA Form (1571 for IND and 356h for NDA/BLA/ANDA), and BCO file.
# '''Can I submit a BCO without data files?''' Yes, but if the sponsor is submitting a BCO without the data they should seek agreement with the review division prior to submission.
# '''Which center should the eCTD (containing BCO file(s)) be submitted to?''' Both CDER and CBER centers accept eCTD submissions and they both have the ability to review the submission files if requested.
# '''How to submit eCTD?''' eCTD (which contains BCO file) should be submitted via Test Electronic Submission Gateway (ESG) to both CBER and CDER. In order for both centers to receive the submission, sponsors would need to make a submission to each center via the ESG Gateway.
# '''Where should BCO files be placed within the eCTD?''' We recommend including BCO files as part of a study, referenced under a Study Tagging File, under Module 5.3.5.4 (Other Study Reports).

=== Dataset and File Submission Details ===
# '''How to include or indicate dataset information in the BCO and/or ESG submission?''' There are a few options to include the dataset information in the BCO or ESG submission: (Note: it is mandatory to include dataset information in the Cover Letter, however, if you would like to add more clarity, you may choose from the option 2-4 listed below)
## Include in the dataset information in the Cover Letter: State how the datasets are submitted (via ESG or hard drive), the tracking number, estimated delivery date. This option is mandatory for BCO submission to the FDA to help reviewers to track down related datasets.
##Globally, suggest to include datasets information in the Usability Domain and refer to the root of the hard drive, see example below:[[File:Screenshot 2024-11-11 at 16.14.20.png|center|thumb|591x591px]]
##If you prefer to mention the file structure and names in each step, then the datasets information can be included in description domain, see example below:[[File:Screenshot 2024-11-11 at 16.14.05.png|center|thumb|620x620px]]
##If you would like to use the file structure and names from an existing schema, you may enter the schema URL in the extension domain, using the Figure 1 from this [https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1000424 paper] as an example, the JSON schema defines the file structure and names
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "http://json-schema.org/draft-07/schema#",
"title": "Computational Biology Project Structure",
"type": "object",
"properties": {
"level 1": {
"type": "object",
"properties": {
"msms": {
"type": "string",
"description": "Main directory for project data and scripts."
},
"level 2": {
"type": "object",
"properties": {
"doc": {
"type": "object",
"description": "Project documentation",
"properties": {
"paper": {
"type": "string",
"description": "Documents related to the project."
}
}
},
"data": {
"type": "string",
"description": "Directory for data files."
},
"src": {
"type": "string",
"description": "Source code directory."
},
"bin": {
"type": "string",
"description": "Executable files."
},
"results": {
"type": "object",
"description": "Results directory with analysis outputs.",
"properties": {
"2009_01_15": {
"type": "string",
"description": "Data from analysis on 2009-01-15."
},
"2009_01_23": {
"type": "string",
"description": "Data from analysis on 2009-01-23."
}
}
}
}
}
}
},
"level 3": {
"type": "object",
"properties": {
"2009_01_14": {
"type": "object",
"description": "Initial analysis on 2009-01-14.",
"properties": {
"yeast": {
"type": "string",
"description": "Yeast dataset."
},
"worm": {
"type": "string",
"description": "Worm dataset."
}
}
},
"2009_01_15": {
"type": "object",
"description": "Follow-up analysis and summary on 2009-01-15.",
"properties": {
"split1": {
"type": "string",
"description": "First data split."
},
"split2": {
"type": "string",
"description": "Second data split."
},
"split3": {
"type": "string",
"description": "Third data split."
}
}
}
}
}
}
# '''How to submit large I/O files to the FDA?''' Please refer to the [https://www.fda.gov/industry/create-esg-account/frequently-asked-questions#_Q19 FDA site] for the definition of large I/O files. Large I/O files need to be sent on a hard drive to CBER, which FDA-HIVE is nested under CBER. All data will be uploaded/downloaded to HIVE. CDER reviewers will use the CBER HIVE to receive and review this type of data. Please use the following address for the hard drive: <u>U.S. Food and Drug Administration</u> <u>Center for Biologics Evaluation and Research</u> <u>Document Control Center</u> <u>10903 New Hampshire Avenue</u> <u>WO71, G112</u> <u>Silver Spring, MD 20993-0002.</u> Also, please add information of the dataset submission plan or details in the Cover Letter so that the reviewer knows it is coming and when to expect it.
#'''Are there any specific notes or memos that should be included with the hard drive?''' Yes, please ensure that the application number is attached to the hard drive for easier processing and identification. In addition, provide the shipping company name, transit number and expected delivery date when available to DCC (DCCEDR@fda.hhs.gov).
# '''Can I submit BCOs on a portable hard drive if requested by the FDA?''' BCOs can also be stored on a portable<ins> </ins>hard drive and referenced in the eCTD. This allows for easy access and verification of the BCO files during the review process'''.''' The hard drive submitted to HIVE (CBER), CDER would also have access to the data.
# '''How much data needs to be submitted?''' There is no minimum requirement; it depends on the goal of the submission and the scope of the submission.
# '''Is the software used required for submission?''' Software used is not required to be submitted. However, some divisions would want software details; this depends very much on where the submission goes.

=== Tools and Technical Details ===
# '''What is Electronic Submissions Gateway (ESG)?''' The Electronic Submissions Gateway (ESG) is the FDA's primary way to receive electronic regulatory submissions.
# '''What materials are required to register for an ESG account?''' FDA ESG provides two methods, WebTrader and AS2 for making submissions to the FDA. WebTrader is a web-based user interface to send documents and receive receipts and acknowledgments from the FDA with minimal technical expertise. To set up WebTrader, several preparatory steps are needed. First, prepare an electronic Letter of Non-Repudiation Agreement; Second, generate or obtain a free personal digital certificate. These two documents are needed during the account registration step. Other optional preparatory steps include preparing a guidance-compliant test submission and a load test submission. For more details, review the formal FDA documentation [https://www.fda.gov/industry/create-esg-account/setting-webtrader-account-checklist here]. To register the WebTrader account, go to the ESG Account Management Portal at '''''[https://esgportal.fda.gov/ https://esgportal.fd]<nowiki/>[https://esgportal.fda.gov/ a.go][https://esgportal.fda.gov/ v/].''''' Then select "New Account Registration" and follow the '''''<nowiki/>'''''prompts. Please refer to the [https://www.fda.gov/industry/about-esg/esg-account-management-portal-user-guide ESG Account Management Portal User Guide] for instructions. After account registration, users need to set up the local machine. Download the required WebTrader Client Installer (Note: only compatible with Windows machines). AS2 (System-to-System) allows industry partners to have the option to access the Gateway via system-to-system communication. It provides an automated connection to the FDA for submissions, receipts, and acknowledgments, generally used by sponsors that have a high volume of submissions. However, this system requires AS2-compliant software and technical expertise. For more information regarding AS2, refer to the [https://www.fda.gov/industry/create-esg-account/setting-as2-account-checklist Setting up an AS2 Account Checklist].
# '''How much data can ESG (Electronic Submission Gateway) handle?''' The maximum file size for a single file (non-folder) is 100 GB of uncompressed data. The maximum file size for a multi-file (folder) is 100 GB of uncompressed data that contains single files (non-folder) no larger than 6 GB of uncompressed data. ESG recommends that you send an email to [[Mailto:ESGHelpDesk@fda.hhs.gov|ESGHelpDesk@fda.hhs.gov]] for all submissions over 10 GB of uncompressed data. The FDA recommends that submissions greater than 15 GB and less than 25 GB in size be sent overnight starting at 5PM EST to ensure receipt by the targeted FDA Center during the next business day. For large datasets, they need to be submitted via hard drive to CBER, for more information, refer to the FAQ above.
# '''For more ESG-related questions, refer to the official FDA ESG FAQ site [https://www.fda.gov/industry/create-esg-account/frequently-asked-questions#_Q19 here]. If you have questions for CBER, please contact CBER ESUB at esubprep@fda.hhs.goc; if the questions are for CDER, please contact CDER ESUB at esub@fda.hhs.gov; if general ESG-related questions, please contact ESG Help Desk at esghelpdesk@fda.hhs.gov.'''

=== Regulatory Applications and Use Cases ===
# '''For which types of regulatory submissions can BCOs be used?''' BCOs can be applied to the following types of regulatory submission:
#* Biologics license applications (BLAs);
#* Investigational new drug applications (INDs);
#* New drug applications (NDAs);
#* Abbreviated new drug applications (ANDAs).

== Archived Pilot Project Related FAQs ==

=== BCO Test Submission ===

# '''How to submit eCTD?''' eCTD portion of the pilot (which contains BCO file) should be submitted via Test Electronic Submission Gateway (ESG) to both CBER and CDER. In order for both centers to receive the submission, sponsors would need to make a submission to each center via the ESG Test Gateway.
## '''CDER:''' Participants should contact [[Mailto:ESUB-Testing@fda.hhs.gov|ESUB-Testing@fda.hhs.gov]] to request a sample application number to submit a BCO pilot submission. The subject line of the email should be “BCO Pilot”. Once the submission is sent through the ESG Test Gateway, the submitter will receive two gateway acknowledgements. The submitter will need to forward the second gateway acknowledgment which contains the “COR id” number to the ESUB-Testing team so they can locate the submission and notify the FDA Pilot point of contact.
## '''CBER''': Participants should contact [[Mailto:ESUBPREP@fda.hhs.gov|ESUBPREP@fda.hhs.gov]] to request a sample application number to submit a BCO pilot submission. The ESUBPREP team should also be notified when the submission is inbound. The subject line of any email related to the pilot should contain “BCO Pilot.” Once the submission is sent through the ESG Test Gateway, the submitter will receive up to three acknowledgments. The submitter will need to forward the second gateway notification acknowledgment, containing the Core ID number, to the ESUBPREP team (also referencing “BCO Pilot” in the subject line) so the submission can be located and shared with the FDA Pilot point of contact. Please note that if a third acknowledgment is generated containing a rejection notification, it should be ignored by the submitter.

# '''What is Electronic Submission Gateway (ESG)?''' The Electronic Submissions Gateway (ESG) is the FDA's primary way to receive electronic regulatory submissions. The Test ESG is in a pre-production environment and will be used for this pilot.
# '''Are intermediate datasets/files required for the purpose of the pilot project?''' Currently, the intermediate files are not required to be submitted at the initial phase of the pilot project.

=== Communication and Support ===
# '''How should sponsors contact the FDA regarding BioCompute Object submissions?''' We do have points of contact at both CDER and CBER centers. If you have general submission and review questions regarding BCO submissions, please contact [[Mailto:cber-edata@fda.hhs.gov|cber-edata@fda.hhs.gov]] if submitted to CBER; [[Mailto:edata@fda.hhs.gov|edata@fda.hhs.gov]] for CDER.
# '''What should sponsors do if they have general questions about BioCompute Object submissions but do not have a submission in-house?''' If sponsors have general questions about BioCompute Object submissions and do not currently have a submission in-house, they can reach out to the email address industry.biologics@fda.hhs.gov managed by OCOD (Office of Computational and Data Sciences). The request will be triaged and directed to the appropriate individuals to provide assistance and address inquiries.

==Publications==
To explore our publications, please visit [https://hive.biochemistry.gwu.edu/publications this link].

Usability Domain

2026-04-14T21:13:09Z

Lorikrammer: Created page with "'''Go back to BCO Domains.''' == Usability Domain ''(usability_domain)'' == This section defines the ''usability_domain'' part of the BCO structure. The associated IEEE schema that contains the definition can be found [https://opensource.ieee.org/2791-object/ieee-2791-schema/-/blob/master/usability_domain.json here]. The usability domain provides a specific scientific use case and a description of the function of the BCO. Condensed example: <pre>..."

'''Go back to [[BCO Domains]].'''

== Usability Domain ''(usability_domain)'' ==

This section defines the ''usability_domain'' part of the [[BCO Domains|BCO]] structure. The associated IEEE schema that contains the definition can be found [https://opensource.ieee.org/2791-object/ieee-2791-schema/-/blob/master/usability_domain.json here].

The usability domain provides a specific scientific use case and a description of the function of the BCO.

Condensed example:
<pre>
"usability_domain": [
],
</pre>

{| class="wikitable"
|+Required Components of the Usability Domain
!Field
!Required
|-
|description (free text)
|'''REQUIRED'''
|}

== Domain Components ==

=== Description ===
The usability domain of a BCO is an array of free text values, or plain language description, of what was done in the workflow and conveys the purpose of the BCO. The usability domain description should align with the actual steps described elsewhere in the BCO and should be consistent with the terminology used in the ''name'', ''external references (xref)'', and ''keywords'' sections. The usability domain, along with keywords, can help determine when and how the BCO can be used. It is recommended that a novel use of a specific BCO would result in the creation of a new BCO with a new usability domain.

A usability domain should read like an abstract and conceptually can be broken down into the following sections.

# Need
# Method
# Results
# How the results can be used/interpreted

== Usability Domain Examples ==
<pre>
"usability_domain": [
"Identify baseline single nucleotide polymorphisms (SNPs)[SO:0000694], (insertions)[SO:0000667], and (deletions)[SO:0000045] that correlate with reduced (ledipasvir)[pubchem.compound:67505836] antiviral drug efficacy in (Hepatitis C virus subtype 1)[taxonomy:31646]",
"Identify treatment-emergent amino acid (substitutions)[SO:1000002] that correlate with antiviral drug treatment failure",
"Determine whether the treatment-emergent amino acid (substitutions)[SO:1000002] identified to correlate with treatment failure involving other drugs against the same virus",
"GitHub CWL example: https://github.com/mr-c/hive-cwl-examples/blob/master/workflow/hive-viral-mutation-detection.cwl#L20"]
]
</pre>
<pre>
"usability_domain": [
"Olduvai protein domains (formerly \"DUF1220\") are the most duplicated protein coding sequence in the human genome (https://doi.org/10.1371/journal.pbio.0020207). They are expressed in many tissues, including strongly in the brain (https://doi.org/10.1126/science.1127980). The copy number of Olduvai domains has been linked to increased brain size (https://doi.org/10.1007/s00429-014-0814-9), and performance on IQ tests (https://doi.org/10.1007/s00439-014-1489-2), as well as neurodiverse states like autism (https://doi.org/10.1371/journal.pgen.1004241).",
"Precise evaluation of copy number in humans has been difficult to achieve, as ratiometric approaches fail to identify small changes when the total number is in the ~300 range, as in humans. Read depth approaches using short read WGS data are promising, but most existing pipelines mask repeats altogether (potentially including these sequences), and those that do measure copy number do it relative to the gene. However, Olduvai domains are known to exist in different number and kind within a family of genes, rendering this approach inoperative. The pipeline described here is used to identify the copy number of genetic sequences independent of the genes in which they occur, and with higher fidelity than existing methods, designed specifically with Olduvai copy number in mind.",
"Approximately 25 individuals were randomly chosen from each of the American (Utah -- Northern and Western European ancestry; CEU), Nigerian (Yoruba; YRI), Han Chinese (Beijing; CHB), Japanese (Tokyo; JPT), Mexican-American (Los Angeles; MXL), Colombian (Medellin; CLM), Puerto Rican (Puerto Rico; PUR), African-American (Southwest US; ASW), Luhya (Webuye, Kenya; LWK), Han Chinese (South China; CHS), Tuscan (Toscana, Italia; TSI), Spanish (Iberian populations; IBS), Finnish (Finland; FIN), and BGR populations for a total of 324 individuals. Where domains were more than 1 kb apart, the boundaries of the domains were extended up to 250 bp to allow the possibility of capturing unique sequence directly adjacent to the domain. No intermediate files were generated because the commands were run executed as a pipe at the command line, so uuids were used for the file IOs in the Description Domain. Relative file paths refer to the local machine on which this pipeline was run. This pipeline was created based on the work of Astling et al. doi: 10.1186/s12864-017-3976-z"
]
</pre>

Tutorials

2026-04-14T21:11:59Z

Lorikrammer:

Main Page

2026-04-14T21:11:39Z

Lorikrammer:

{{DISPLAYTITLE:<span style="position: absolute; clip: rect(1px 1px 1px 1px); clip: rect(1px, 1px, 1px, 1px);">{{FULLPAGENAME}}</span>}}
__NOTOC__

<div id="ggw-topbanner" style="clear:both; position:relative; box-sizing:border-box; width:100%; margin:1.2em 0 6px; min-width:47em; border:1px solid #ddd; background-color:#f9f9f9; color:#000;">
<div style="margin:0.4em; text-align:center;">
<div style="font-size:160%; padding:.1em;">Welcome to BioCompute Objects Wiki,</div>
<div style="font-size:100%;">The [https://www.mediawiki.org/wiki/MediaWiki MediaWiki] for the BioCompute Objects project. This wiki system provides complementary information to the [https://www.biocomputeobject.org/ BioCompute portal] and is divided into the following main sections: General information for the [https://www.biocomputeobject.org/ BioCompute portal], [[User_guide|Quick Start and User Guide]], [[FAQs|FAQ]], [[Sop|Curation SOP]], and [[About|About]] for the [https://www.biocomputeobject.org/ BioCompute portal].</div>You can also find the BioCompute White paper [[White paper|here]].
</div>
</div>
<div style="clear: both;"></div>

<div style="clear: both;"><br />
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;"><div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">

<div id="ggw_row2" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[User guide|BioCompute Object (BCO) User Guide]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
This document specifies the structure of BioCompute Objects. The specification is split into multiple parts linked to this top-level document and is maintained in a [https://github.com/biocompute-objects/BCO_Specification GitHub repository] where contributions are welcome. This document was created by the [[Main_Page#BioCompute_Object_Consortium_members_(BCOC)|BioCompute Object Consortium members (BCOC)]].

It is offered as support for IEEE-2791-2020: [https://standards.ieee.org/ieee/2791/7337/ IEEE Standard for Bioinformatics Computations and Analyses Generated by High-Throughput Sequencing (HTS) to Facilitate Communication].

Read more: [[Introduction|Introduction to BioCompute Objects]]

</div>
</div>

<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[FAQs|Frequently Asked Questions]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
The FAQ section contains a list of questions asked by users regarding using the portal, pipeline steps, and extensions as well as questions related to the prerequisite, knowledgebase recommendation, and saving and publishing BCOs.

Read more: [[FAQs|Frequently Asked Questions]]

</div>
</div>

<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[Sop|BCO Curation SOP]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
Intended audience: authors and developers

This section is intended to provide guidance on BCO™ creation, versioning, certification and authentication.

Read more: [[Sop|BCO Curation SOP]]

</div>
</div>
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[BCO Pilot Project|Pilot Project]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
We are currently running a pilot project of mock submission to the FDA. The purpose of the pilot is to bring both the sponsors and the FDA to an agreement around BCO usage to streamline and standardize computational workflow submissions and reviews. We expect to obtain first-hand knowledge of submitting computational analyses to the FDA and how to efficiently and effectively ease communication barriers between sponsors and the government agency.
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[BioCompute Conference and Workshop|Workshop]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
We hosted an in-person workshop on May 10, 2024. Learn more [[BioCompute Conference and Workshop|here]].
For all previous workshop materials, click [https://hive.biochemistry.gwu.edu/publications#Multimedia here].
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[About]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
A BioCompute Object (BCO) is an instance of the BioCompute standard and is a computational record of a bioinformatics pipeline. A BCO is not an analysis but is a record of which analyses were executed and in exactly which ways. In this way, a BCO acts as an interface for existing standards. A BCO contains all of the necessary information to repeat an entire pipeline from FASTQ to result and includes additional metadata to identify provenance and usage.

Read more:
*[[About|What is BioCompute?]]
*[[About|Wifi Analogy]]
*[[About|BioCompute Description]]
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[Publications|Publication]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
'''For Citation Purpose:''' Simonyan, V., Goecks, J., & Mazumder, R. (2017). Biocompute Objects — A Step towards Evaluation and Validation of Biomedical Scientific Computations. PDA Journal of Pharmaceutical Science and Technology, 71(2), 136–146. doi: 10.5731/pdajpst.2016.006734

See also full list of [[publications]] about BioCompute Object.

=== Other links ===
# [[CDISC]]
# [[Galaxy]]
# [[RO-Crate]]
# [[CWL|Common Workflow Language (CWL)]]
# [https://fairsharing.org/4293 FAIRsharing]
</div>
</div>

Main Page

2026-04-14T21:10:45Z

Lorikrammer:

{{DISPLAYTITLE:<span style="position: absolute; clip: rect(1px 1px 1px 1px); clip: rect(1px, 1px, 1px, 1px);">{{FULLPAGENAME}}</span>}}
__NOTOC__

<div id="ggw-topbanner" style="clear:both; position:relative; box-sizing:border-box; width:100%; margin:1.2em 0 6px; min-width:47em; border:1px solid #ddd; background-color:#f9f9f9; color:#000;">
<div style="margin:0.4em; text-align:center;">
<div style="font-size:160%; padding:.1em;">Welcome to BioCompute Objects Wiki,</div>
<div style="font-size:100%;">The [https://www.mediawiki.org/wiki/MediaWiki MediaWiki] for the BioCompute Objects project. This wiki system provides complementary information to the [https://www.biocomputeobject.org/ BioCompute portal] and is divided into the following main sections: General information for the [https://www.biocomputeobject.org/ BioCompute portal], [[User_guide|Quick Start and User Guide]], [[FAQs|FAQ]], [[Sop|Curation SOP]], and [[About|About]] for the [https://www.biocomputeobject.org/ BioCompute portal].</div>You can also find the BioCompute White paper [[White paper|here]].
</div>
</div>
<div style="clear: both;"></div>

<div style="clear: both;"><br />
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;"><div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">

<div id="ggw_row2" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[User guide|BioCompute Object (BCO) User Guide]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
This document specifies the structure of BioCompute Objects. The specification is split into multiple parts linked to this top-level document and is maintained in a [https://github.com/biocompute-objects/BCO_Specification GitHub repository] where contributions are welcome. This document was created by the [[Main_Page#BioCompute_Object_Consortium_members_(BCOC)|BioCompute Object Consortium members (BCOC)]].

It is offered as support for IEEE-2791-2020: [https://standards.ieee.org/ieee/2791/7337/ IEEE Standard for Bioinformatics Computations and Analyses Generated by High-Throughput Sequencing (HTS) to Facilitate Communication].

Read more: [[Introduction|Introduction to BioCompute Objects]]

</div>
</div>

<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[FAQs|Frequently Asked Questions]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
The FAQ section contains a list of questions asked by users regarding using the portal, pipeline steps, and extensions as well as questions related to the prerequisite, knowledgebase recommendation, and saving and publishing BCOs.

Read more: [[Faq|Frequently Asked Questions]]

</div>
</div>

<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[Sop|BCO Curation SOP]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
Intended audience: authors and developers

This section is intended to provide guidance on BCO™ creation, versioning, certification and authentication.

Read more: [[Sop|BCO Curation SOP]]

</div>
</div>
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[BCO Pilot Project|Pilot Project]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
We are currently running a pilot project of mock submission to the FDA. The purpose of the pilot is to bring both the sponsors and the FDA to an agreement around BCO usage to streamline and standardize computational workflow submissions and reviews. We expect to obtain first-hand knowledge of submitting computational analyses to the FDA and how to efficiently and effectively ease communication barriers between sponsors and the government agency.
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[BioCompute Conference and Workshop|Workshop]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
We hosted an in-person workshop on May 10, 2024. Learn more [[BioCompute Conference and Workshop|here]].
For all previous workshop materials, click [https://hive.biochemistry.gwu.edu/publications#Multimedia here].
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[About]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
A BioCompute Object (BCO) is an instance of the BioCompute standard and is a computational record of a bioinformatics pipeline. A BCO is not an analysis but is a record of which analyses were executed and in exactly which ways. In this way, a BCO acts as an interface for existing standards. A BCO contains all of the necessary information to repeat an entire pipeline from FASTQ to result and includes additional metadata to identify provenance and usage.

Read more:
*[[About|What is BioCompute?]]
*[[About|Wifi Analogy]]
*[[About|BioCompute Description]]
</div>
</div>

<div id="ggw_row3" style="display: flex; flex-flow: row wrap; justify-content: space-between; padding: 0; margin: 0 -5px 0 -5px;">
<div style="flex: 1; margin: 5px; min-width: 210px; border: 1px solid #CCC; padding: 0 10px 10px 10px; box-shadow: 0 2px 2px rgba(0,0,0,0.1); background: #f5faff;">
<h3>[[Publications|Publication]]</h3>
<div style="border-top: 1px solid #CCC; padding-top: 0.5em;">
'''For Citation Purpose:''' Simonyan, V., Goecks, J., & Mazumder, R. (2017). Biocompute Objects — A Step towards Evaluation and Validation of Biomedical Scientific Computations. PDA Journal of Pharmaceutical Science and Technology, 71(2), 136–146. doi: 10.5731/pdajpst.2016.006734

See also full list of [[publications]] about BioCompute Object.

=== Other links ===
# [[CDISC]]
# [[Galaxy]]
# [[RO-Crate]]
# [[CWL|Common Workflow Language (CWL)]]
# [https://fairsharing.org/4293 FAIRsharing]
</div>
</div>

Build a BCO

2026-04-14T21:08:00Z

Lorikrammer:

#Click on '''BCO Builder''' icon on the Navigation Bar:[[File:101.png|center|thumb|1056x1056px]]
#To begin filling out the BCO, click on '''Provenance Domain''' to expand the section. Fill out the information as needed. Red boxes are required fields, and plain boxes are optional fields. Click '''next''' to advancing to the next section.[[File:102.png|center|thumb|1054x1054px]]
#For information to fill out each domain, please refer to the [[BCO Domains]] page. Or, click on the question mark icon on each domain for more information.
#User can also view/edit the BCO in JSON by clicking '''RAW JSON VIEW'''.[[File:103.png|center|thumb|1073x1073px]]
#A BCO draft can be saved at any time of editing. In order to save a draft, go to the top of the page to choose a server. [[File:104.png|center|thumb|1051x1051px]]
#After choosing the proper server, the BCO prefix field will show up. Enter a specific prefix (e.g. BCO, ARGOS, etc.) based on user groups and permissions. The default prefix is '''BCO''', which can be used by all users.[[File:105.png|center|thumb|1014x1014px]]
#Click on '''SAVE AS DRAFT''' to make sure all of the data is saved properly before publishing. A pop-up window will show up and indicate the draft is saved successfully.[[File:106.png|center|thumb|1014x1014px]]
#Before publishing the draft, users need to validate the draft first. To do this, click on '''VALIDATE BCO'''. A new window will pop up with validation results. Please see this [[Common_errors|page]] for common errors and possible solutions.[[File:107.png|center|thumb|1032x1032px]]
# If validation results show ‘“number_of_errors”: 0’, this means the draft has passed validation and it’s ready to publish. Go back to the Builder screen, and now the '''PUBLISH DRAFT''' button should turn blue, click on it to publish the draft.[[File:108.png|center|thumb|982x982px]][[File:107.png|center|thumb|1032x1032px]]
#If any errors were detected during validation, then correct those errors based on the validation results. Revalidation is needed before publishing.
#Other options on the Builder page include '''DOWNLOAD BCO''' in JSON format and '''UPLOAD''' a BCO.[[File:109.png|center|thumb|1008x1008px]]

Tutorials

2026-04-14T21:05:44Z

Lorikrammer:

Build a BCO

2026-04-14T21:05:17Z

Lorikrammer: Created page with " #Click on '''BCO Builder''' icon on the Navigation Bar:1056x1056px #To begin filling out the BCO, click on '''Provenance Domain''' to expand the section. Fill out the information as needed. Red boxes are required fields, and plain boxes are optional fields. Click '''next''' to advancing to the next section.1054x1054px #For information to fill out each domain, please refer to these links: Provenance-domain|Pro..."

#Click on '''BCO Builder''' icon on the Navigation Bar:[[File:101.png|center|thumb|1056x1056px]]
#To begin filling out the BCO, click on '''Provenance Domain''' to expand the section. Fill out the information as needed. Red boxes are required fields, and plain boxes are optional fields. Click '''next''' to advancing to the next section.[[File:102.png|center|thumb|1054x1054px]]
#For information to fill out each domain, please refer to these links: [[Provenance-domain|Provenance Domain]], [[Usability-domain|Usability Domain]], [[Extension-domain|Extension Domain]], [[Description-domain|Description Domain]], [[Execution-domain|Execution Domain]], [[Input and Output Domain|I/O Domain]], [[Parametric-domain|Parametric Domain]], and [[Error-domain|Error Domain]]. Or, click on the question mark icon on each domain for more information.
#User can also view/edit the BCO in JSON by clicking '''RAW JSON VIEW'''.[[File:103.png|center|thumb|1073x1073px]]
#A BCO draft can be saved at any time of editing. In order to save a draft, go to the top of the page to choose a server. [[File:104.png|center|thumb|1051x1051px]]
#After choosing the proper server, the BCO prefix field will show up. Enter a specific prefix (e.g. BCO, ARGOS, etc.) based on user groups and permissions. The default prefix is '''BCO''', which can be used by all users.[[File:105.png|center|thumb|1014x1014px]]
#Click on '''SAVE AS DRAFT''' to make sure all of the data is saved properly before publishing. A pop-up window will show up and indicate the draft is saved successfully.[[File:106.png|center|thumb|1014x1014px]]
#Before publishing the draft, users need to validate the draft first. To do this, click on '''VALIDATE BCO'''. A new window will pop up with validation results. Please see this [[Common_errors|page]] for common errors and possible solutions.[[File:107.png|center|thumb|1032x1032px]]
# If validation results show ‘“number_of_errors”: 0’, this means the draft has passed validation and it’s ready to publish. Go back to the Builder screen, and now the '''PUBLISH DRAFT''' button should turn blue, click on it to publish the draft.[[File:108.png|center|thumb|982x982px]][[File:107.png|center|thumb|1032x1032px]]
#If any errors were detected during validation, then correct those errors based on the validation results. Revalidation is needed before publishing.
#Other options on the Builder page include '''DOWNLOAD BCO''' in JSON format and '''UPLOAD''' a BCO.[[File:109.png|center|thumb|1008x1008px]]

BCO Domains

2026-04-14T21:02:16Z

Lorikrammer: /* Provenance Domain (''provenance_domain'') */

'''Go back to [[Main_Page|BioCompute Objects]].'''

=== BioCompute Objects Visualization ===
An Observable documentation showing a visualization of a BCO object workflow can be found [https://observablehq.com/@neurogenomics/biocompute-objects-visualization-student-workflows here].

=== [[Top-level|Top Level Fields]] ===

The top-level JSON object of a BCO includes attributes to define the BCO itself.

The remaining top-level fields detail different domains of the BCO, as listed below.

== BCO Domains ==

A [[Main Page|BCO]] JSON object is split into different parts, or domains, detailed below.

Condensed example:
"spec_version" : "https://w3id.org/biocompute/1.3.0/",
"object_id": "https://example.com/bco/9487ae7e-c1aa-4a3c-b18f-3d3695b33ace",
"type": "antiviral_resistance_detection",
"etag": "584C7FE128717E1712426AB19CAAEA8BC1E27365B54285BBEA1221284C7D3A48",
"provenance_domain": {
},
"usability_domain": [
],
"extension_domain":{
},
"description_domain": {
},
"execution_domain": {
},
"parametric_domain": {
},
"io_domain": {
},
"error_domain": {
}

=== [[Provenance Domain|Provenance Domain (<nowiki>''provenance_domain''</nowiki>)]] ===

The provenance_domain defines the history, version and status of this BCO as part of the review process.

=== [[Usability-domain|Usability Domain (''usability_domain'')]] ===

The usability_domain is meant to improve searchability by allowing a free-text description of the BCO.

=== [[Extension-domain|Extension Domain (''extension_domain'')]] ===

The extension_domain is a space for a user to add additional structured information that is not defined in the BioCompute schema. While the extension_domain is not defined by IEEE-2791-2020, each extension in the extension domain must provide a reference to the schema that defines it in order to validate. The extension domain is the place to add any additional structured information. We provide an example here that is neither exclusive nor exhaustive.

=== [[Description-domain|Description Domain (''description_domain'')]] ===

The description_domain contains a structured field for the description of external references, the pipeline steps, and the relationship of I/O objects.

=== [[Execution-domain|Execution Domain (''execution_domain'')]] ===

The execution_domain contains fields for the execution of the BCO.

=== [[Parametric-domain|Parametric Domain (''parametric_domain'')]] ===

The parametric_domain represents the list of parameters customizing the computational flow which can affect the output of the calculations.

=== [[Input and Output Domain|Input and Output Domain (''io_domain'')]] ===

The io_domain represents the list of global input and output files created by the computational workflow.

=== [[Error-domain|Error Domain (''error_domain'')]] ===

The error_domain defines the empirical and algorithmic limits and error sources of the BCO.

BCO Domains

2026-04-14T21:01:58Z

Lorikrammer: /* Provenance Domain (provenance_domain) */

'''Go back to [[Main_Page|BioCompute Objects]].'''

=== BioCompute Objects Visualization ===
An Observable documentation showing a visualization of a BCO object workflow can be found [https://observablehq.com/@neurogenomics/biocompute-objects-visualization-student-workflows here].

=== [[Top-level|Top Level Fields]] ===

The top-level JSON object of a BCO includes attributes to define the BCO itself.

The remaining top-level fields detail different domains of the BCO, as listed below.

== BCO Domains ==

A [[Main Page|BCO]] JSON object is split into different parts, or domains, detailed below.

Condensed example:
"spec_version" : "https://w3id.org/biocompute/1.3.0/",
"object_id": "https://example.com/bco/9487ae7e-c1aa-4a3c-b18f-3d3695b33ace",
"type": "antiviral_resistance_detection",
"etag": "584C7FE128717E1712426AB19CAAEA8BC1E27365B54285BBEA1221284C7D3A48",
"provenance_domain": {
},
"usability_domain": [
],
"extension_domain":{
},
"description_domain": {
},
"execution_domain": {
},
"parametric_domain": {
},
"io_domain": {
},
"error_domain": {
}

=== [[Provenance Domain (''provenance_domain'')]] ===

The provenance_domain defines the history, version and status of this BCO as part of the review process.

=== [[Usability-domain|Usability Domain (''usability_domain'')]] ===

The usability_domain is meant to improve searchability by allowing a free-text description of the BCO.

=== [[Extension-domain|Extension Domain (''extension_domain'')]] ===

The extension_domain is a space for a user to add additional structured information that is not defined in the BioCompute schema. While the extension_domain is not defined by IEEE-2791-2020, each extension in the extension domain must provide a reference to the schema that defines it in order to validate. The extension domain is the place to add any additional structured information. We provide an example here that is neither exclusive nor exhaustive.

=== [[Description-domain|Description Domain (''description_domain'')]] ===

The description_domain contains a structured field for the description of external references, the pipeline steps, and the relationship of I/O objects.

=== [[Execution-domain|Execution Domain (''execution_domain'')]] ===

The execution_domain contains fields for the execution of the BCO.

=== [[Parametric-domain|Parametric Domain (''parametric_domain'')]] ===

The parametric_domain represents the list of parameters customizing the computational flow which can affect the output of the calculations.

=== [[Input and Output Domain|Input and Output Domain (''io_domain'')]] ===

The io_domain represents the list of global input and output files created by the computational workflow.

=== [[Error-domain|Error Domain (''error_domain'')]] ===

The error_domain defines the empirical and algorithmic limits and error sources of the BCO.

Input and Output Domain

2026-04-14T20:59:15Z

Lorikrammer: /* Input and Output Domain (io_domain) */

'''Go back to [[BCO Domains]].'''

== Input and Output Domain (''io_domain'') ==
This section defines the io_domain part of the [[BCO Domains|BCO]]. The IEEE io domain schema can be found [https://opensource.ieee.org/2791-object/ieee-2791-schema/-/blob/master/io_domain.json here].

This represents the list of global input and output files created by the computational workflow, excluding the intermediate files. These fields are pointers to objects that can reside in the system performing the computation or any other accessible system. Just like the fields of the parametric domain, these fields are expected to vary depending on the specific BCO implementation and can refer to named input-output arguments of underlying pipelines. Please refer to the documentation of individual scripts and specific BCO descriptions for further details.

Condensed example:
"io_domain": {
"input_subdomain": [
],
"output_subdomain": [
]
}
{| class="wikitable"
|+Required Components of the IO Domain
!Subdomain
!Object
!Field
!Status
|-
|input_subdomain
|
|
|'''REQUIRED'''
|-
|
|uri
|
|'''REQUIRED'''
|-
|
|
|filename
|NOT REQUIRED
|-
|
|
|uri
|'''REQUIRED'''
|-
|
|
|access_time
|NOT REQUIRED
|-
|
|
|sha1_checksum
|NOT REQUIRED
|-
|output_subdomain
|
|
|'''REQUIRED'''
|-
|
|uri
|
|'''REQUIRED'''
|-
|
|
|filename
|NOT REQUIRED
|-
|
|
|uri
|'''REQUIRED'''
|-
|
|
|access_time
|NOT REQUIRED
|-
|
|
|sha1_checksum
|NOT REQUIRED
|-
|
|mediatype
|
|'''REQUIRED'''
|}

== Input Subdomain (''input_subdomain'') ==
This field records the references and input files for the entire pipeline. Each input file is listed as a uri object. This allows the author to be very specific about a particular type of input file if they so choose. For example, reference files have common names, and adding the common name here, in addition to the uri would make this more readable and understandable (eg, "HCV reference version..." or "human reference GRCH38"). For data integration workflows, the input files can be a table downloaded from a specific source which is then filtered for modification using rules described in the BCO.

The URI object and the URI field are both '''required'''.

"input_subdomain": [
{
"uri": {
"filename": "Hepatitis C virus genotype 1",
"uri": "http://www.ncbi.nlm.nih.gov/nuccore/22129792",
"access_time": "2017-01-24T09:40:17-0500"
}
},
{
"uri": {
"filename": "Hepatitis C virus type 1b complete genome",
"uri": "http://www.ncbi.nlm.nih.gov/nuccore/5420376",
"access_time": "2017-01-24T09:40:17-0500"
}
}
]

=== URI Object and Field ===
'''The IO domain includes a required ''URI object''. Within the ''URI object'' is a required ''URI field''.''' The URI field must be included in both the input and output subdomains. Filename, access_time, and sha1_checksum are all optional. These optional values are up to the discretion of the author and the reviewer.
The URI object is defined at the top-level schema because it is used in multiple domains and defines each of its fields as well. See the URI field definition in the [https://opensource.ieee.org/2791-object/ieee-2791-schema/-/blob/master/2791object.json?ref_type=heads IEEE top-level schema] below.
"definitions": {
"object_id": {
"type": "string",
"description": "A unique identifier that should be applied to each IEEE-2791 Object instance, generated and assigned by a IEEE-2791 database engine. IDs should never be reused"
},
"uri": {
"type": "object",
"description": "Any of the four Resource Identifers defined at <nowiki>https://tools.ietf.org/html/draft-handrews-json-schema-validation-01#section-7.3.5</nowiki>",
"additionalProperties": false,
"required": [
"uri"
],
"properties": {
"filename": {
"type": "string"
},
"uri": {
"type": "string",
"format": "uri"
},
"access_time": {
"type": "string",
"description": "Time stamp of when the request for this data was submitted",
"format": "date-time"
},
"sha1_checksum": {
"type": "string",
"description": "output of hash function that produces a message digest",
"pattern": "[A-Za-z0-9]+"
}
}
},

== Output Subdomain (''output_subdomain'') ==
This field records the outputs for the entire pipeline. Each output object is represented as a URI with the addition of a ''mediatype'' object. In the output domain, the URI and mediatype objects are both '''required'''. As mentioned in the ''URI Object and Field'' section, within the URI object, the ''URI field'' is '''required''' but ''filename'', ''access_time'', and ''sha1_checksum'' are not required.
"output_subdomain": [
{
"uri": {
"filename": "Example Domain csv file",
"uri": "http://example.com/data/514769/dnaAccessionBased.csv",
"access_time": "2017-01-24T09:40:17-0500"
},
"mediatype": "text/csv"
},
{
"uri": {
"uri": "http://example.com/data/514801/SNPProfile*.csv",
"access_time": "2017-01-24T09:40:17-0500"
},
"mediatype": "text/tsv"
}
]

=== Mediatype Field ===
The mediatype field is defined in the output domain. It is not required for the input domain. The official list of accepted media types can be found in the description within the definition. The definition can be found in the [https://opensource.ieee.org/2791-object/ieee-2791-schema/-/blob/master/io_domain.json IEEE io schema] below:
"output_subdomain": {
"type": "array",
"title": "output_subdomain",
"description": "A record of the outputs for the entire pipeline.",
"items": {
"type": "object",
"title": "The Items Schema",
"required": [
"mediatype",
"uri"
],
"properties": {
"mediatype": {
"type": "string",
"title": "mediatype",
"description": "https://www.iana.org/assignments/media-types/",
"default": "application/octet-stream",
"examples": [
"text/csv"
],
"pattern": "^(.*)$"
},
"uri": {
"$ref": "2791object.json#/definitions/uri"
}
}
}
}

Provenance Domain

2026-04-14T20:58:06Z

Lorikrammer: /* Provenance Domain (provenance_domain) */

'''Go back to [[BCO Domains]].'''
== Provenance Domain ''(provenance_domain)'' ==

This section defines the fields of the ''provenance_domain'' part of the [[BCO Domains|BCO]] structure. The provenance domain IEEE schema and definition can be found [https://opensource.ieee.org/2791-object/ieee-2791-schema/-/blob/master/provenance_domain.json here].

Condensed example:
<pre>
"provenance_domain": {
"name": "HCV1a ledipasvir resistance SNP detection",
"version": "2.9",
"review": [
],
"obsolete_after" : "2118-09-26T14:43:43-0400",
"embargo" : {
},
"created": "2017-01-24T09:40:17-0500",
"modified": "2018-09-21T14:06:14-0400",
"contributors": [
],
"license": "https://spdx.org/licenses/CC-BY-4.0.html"
},
</pre>
{| class="wikitable"
|+Required Components of the Provenance Domain
!Field
!Required
|-
|name
|'''REQUIRED'''
|-
|version
|'''REQUIRED'''
|-
|review
|NOT REQUIRED
|-
|derived_from
|NOT REQUIRED
|-
|obsolete_after
|NOT REQUIRED
|-
|embargo
|NOT REQUIRED
|-
|created
|'''REQUIRED'''
|-
|modified
|'''REQUIRED'''
|-
|contributors
|'''REQUIRED'''
|-
|license
|'''REQUIRED'''
|}

== Domain Components ==

=== 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, external references (xref), and keywords sections. It is recommended that BCO names be short and easily recognizable. They should also not use special characters (spell things out). This field is '''required'''.

"name": "HCV1a ledipasvir resistance SNP detection"

=== Version ''(version)'' ===

Records the versioning of this BCO instance object. This field is '''required'''.

[https://semver.org/ Semantic Versioning 2.0.0] describes versioning as follows:

Given a version number MAJOR.MINOR.PATCH, increment the:
1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backward-compatible manner, and
3. PATCH version when you make backward-compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

BCO versioning should adhere to semantic versioning. Given the above conditions, a MAJOR version would qualify for a new BCO, and therefore it is recommended that the versioning of a BCO only utilize MINOR and PATCH, or two digits.

"version": "2.1",

=== Review ''(review)'' ===

This is an array to hold reviewer identifiers and a description of the status of an object in the review process. The subtype reviewer contains field(s) for name, affiliation, email, and the contribution type of the reviewer. To further record author information, ORCIDs are included as they allow for the author to curate their information after submission. ORCID identifiers must be valid and must have the prefix https://orcid.org/. The contribution type is a choice taken from PAV ontology: provenance, authoring and versioning, which also maps to the [https://www.w3.org/TR/prov-o/ PROV-O].

The “status” key describes the status of an object in the review process and the following are the possible values:

*unreviewed flag indicates that the object has been submitted, but no further evaluation or verification has occurred.
*in-review flag indicates that verification is underway.
*approved flag indicates that the BCO has been verified and reviewed.
*suspended flag indicates an object that was once valid is no longer considered valid.
*rejected flag indicates that an error or inconsistency was detected in the BCO, and it has been removed or rejected.

The fields from the contributor object are used to populate the reviewer section. Though not required, it is strongly recommended that each BCO have at least one review (ideally by someone not listed with createdBy or authoredBy) upon publication.

"review": [
{
"status": "approved",
"reviewer_comment": "Approved by GW staff. Waiting for approval from FDA Reviewer",
"date": "2017-11-12T12:30:48-0400",
"reviewer": {
"name": "Charles Hadley King",
"affiliation": "George Washington University",
"email": "hadley_king@gwu.edu",
"contribution": "curatedBy",
"orcid": "https://orcid.org/0000-0003-1409-4549"
}
},
{
"status": "approved",
"reviewer_comment": "The revised BCO looks fine",
"date": "2017-12-12T12:30:48-0400",
"reviewer": {
"name": "Eric Donaldson",
"affiliation": "FDA",
"email": "Eric.Donaldson@fda.hhs.gov",
"contribution": "curatedBy"
}
}
]

=== Inheritance/derivation ''(derived_from)'' ===

If the object is derived from another, this field will specify the parent object, in the form of the ‘object_id’. If the object is novel then the field is not included.

"derived_from" : "https://example.com/BCO_948701/1.0"

=== Obsolescence ''(obsolete_after)'' ===

If the object has an expiration date this field will specify that using the ‘datetime’ type which is in ISO-8601 format as clarified by W3C https://www.w3.org/TR/NOTE-datetime. This field is optional.

"obsolete_after" : "2118-09-26T14:43:43-0400"

=== Embargo ''(embargo)'' ===

If the object has a period of time that it is not public, that range can be specified using these fields. Using the datetime type, a start and end time are specified for the embargo. These fields are optional.

"embargo" : {
"start_time": "2000-09-26T14:43:43-0400",
"end_time": "2000-09-26T14:43:45-0400"
},

=== Created ''(created)'' ===

Using the datetime type the time of initial creation of the BCO is recorded in ISO-8601 format as clarified by W3C https://www.w3.org/TR/NOTE-datetime. This field should be 'read only' and is '''required'''.

"created": "2017-01-20T09:40:17-0500"

=== Modification ''(modified)'' ===

Using the datetime type the time of the most recent modification of the BCO is recorded. This field is '''required'''.

"modified": "2018-03-21T18:31:48-0400"

=== Contributors ''(contributors)'' ===

This is a list to hold contributor identifiers and a description of their type of contribution, including a field for ORCIDs to record author information, as they allow for the author to curate their information after submission. ORCID identifiers must be [https://support.orcid.org/hc/en-us/articles/360006897674-Structure-of-the-ORCID-Identifier valid] and must have the prefix https://orcid.org/. The contribution type is a choice taken from [http://pav-ontology.github.io/pav/pav.rdf PAV ontology]: provenance, authoring and versioning, which also maps to the [https://www.w3.org/TR/prov-o/ PROV-O]. This field is '''required'''.
<pre>
"contributors": [
{
"name": "Charles Hadley King",
"affiliation": "George Washington University",
"email": "hadley_king@gwu.edu",
"contribution": ["createdBy", "curatedBy"],
"orcid": "https://orcid.org/0000-0003-1409-4549"
},

{
"name": "Eric Donaldson",
"affiliation": "FDA",
"email": "Eric.Donaldson@fda.hhs.gov",
"contribution": ["authoredBy"]
}
]
</pre>

=== License ''(license)'' ===

A space for Creative Commons license or other license information (text). The default or recommended license can be Creative Commons Attribution 4.0 International identified as https://spdx.org/licenses/CC-BY-4.0.html. This field is '''required'''.

"license": "https://spdx.org/licenses/CC-BY-4.0.html"