+
+
+
+### What is BioCompute?
+
+Tremendous insights can be found in genome data, and many of these insights are being used to drive personalized medicine. But the hundreds of millions of reads that come from a gene sequencer represent small, nearly random fragments of the genome that's being sequenced, and there are countless ways in which that data can be transformed to yield insights into cancer, ancestry, microbiome dynamics, metagenomics, and many other areas of interest.
+
+Because there are so many different platforms and so many different scripts and tools to analyze genome data, there is a great need to standardize the way in which these steps are communicated. The more analysis steps and the more complicated a pipeline, the greater the need for a standardized mechanism of communication. The BioCompute standard brings clarity to an analysis, making it clear and reproducible.
+
+
+
+
+
+
+
+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.
+
+### WiFi Analogy
+
+The [802.11 standard](https://en.wikipedia.org/wiki/IEEE_802.11) (more commonly called "WiFi") is a way of standardizing communication between vastly different products on a wireless network. If a product manufacturer wants a product to be able to communicate on a wireless internet network, they can configure the device to use the WiFi standard and it will be able to communicate with most commercial routers, regardless of whether the product is a Mac, a PC, a cell phone, or a smart toaster.
+
+
+
+
+
+
+
+BioCompute fills a similar need. BioCompute is not an automation or a new programming language, it is a way of collecting and communicating information between two entities. Rather than a latop and a router, it may be between a pharmaceutical company and the FDA, or between two clinicians, or between a clinician and a researcher. In much the same way that WiFi does not standardize the data that's being transmitted -- allowing you to use Apple's Facetime, Microsoft's Internet Explorer, or your favorite cell phone app -- BioCompute does not standardize the platforms or tools that are used for genome analysis. You continue to use your favorite platforms and tools, whether it's [HIVE](https://hive.biochemistry.gwu.edu/dna.cgi?cmd=main), [Galaxy](https://galaxyproject.org/), [Seven Bridges](https://www.sevenbridges.com/), [DNAnexus](https://www.dnanexus.com/), or others. Also like WiFi, BioCompute can be layered with other privacy or security protocols depending on usage. So clinical trial data can be secured and HIPAA-compliant, while government-funded data sets shared between researchers can be completely open access.
+
+Because BioCompute acts like an envelope for an entire analysis pipeline, it is compatible with other existing standards, including [FHIR Genomics](https://www.hl7.org/fhir/genomics.html) and [GA4GH](https://www.ga4gh.org/).
+
+### BioCompute Description
+
+BioCompute is written in [Javascript Object Notation (JSON)](https://json.org/example.html), which is simply a set of key:value pairs (meaning that raw files can be read without any knowledge of programming). Information within the BCO is organized into "domains." The domains within a BCO record are Provenance, Usability, Extension, Description, Execution, Input/Output, and Parametric Domains. For more information on the domains, please see the [BioCompute Schema](https://gitlab.com/IEEE-SA/2791/ieee-2791-schema).
+
+BioCompute was built through a collaboration between The George Washington University and the FDA to improve communication of bioinformatics pipelines, and has since been expanded and refined through the participation or collaboration of hundreds of participants from throughout the public and private sectors. While we welcome interest and membership from anyone, most users will fall into one of three categories:
+
+- [Research Community](/research)
+ The Biocompute standard can help substantially improve replicability, making it possible to repeat a pipeline on a different sample with high fidelity and high confidence.
+
+- [Clinical Community](/clinical)
+ As BioCompute Objects become tested and validated, they can be applied in the clinic to identify risk factors, flag pharmakogenetic information, and much more.
+
+- [Pharma, Biotech and Regulatory Pipeline](/regulatory)
+ Protracted communications with the FDA can extend the review process by months. A standardized method of communicating HTS data may help repeat results more quickly and without the need for additional communication.
+
+Research, clinical, and regulatory groups are key drivers of personalized medicine that is based on next generation sequencing, but there are barriers between these groups. BioCompute reduces these hurdles and brings transparency to the workflow, making it more clear what was done, and clearly delineating expectations for data sharing. The BioCompute specification can be layered with other privacy and security protocols to guard sensitive data, or be made open source depending on the needs of the user.
+
+The BioCompute project has generated two publications, three workshops, FDA funding, contributions from over 300 participants, and FDA submissions. The project has worked with individuals from NIH, Harvard, several biotech and pharma companies, EMBL-EBI, Galaxy Project, and many more, and can be integrated with any existing standard for HTS data. The project is expected to be both an IEEE and ISO recognized standard within 8-10 months.
+
+More information about The current BioCompute standard can be found on the [Open Science Foundation website](https://osf.io/h59uh/) (where the standard is developed and maintained), the [HIVE](https://hive.biochemistry.gwu.edu/htscsrs/biocompute) website, and the [Research Objects discussion of BioCompute](http://www.researchobject.org/2017-11-27-biocompute-objects/).
+
+
+
+
+
+
+
+
+
+**Milestones in the BioCompute Program**
+
+The major milestones of the BioCompute Partnership and future goals are paving the way for a consensus-driven, widely adopted standard. The FDA's Genomics Working Group (GWG) originally articulated the challenges of communicating genomic analysis pipelines in a regulatory context in 2013. Since then, the project has accumulated tremendous momentum, a testament to the GWG's efforts in describing communication challenges. More recently, the second BioCompute publication has recently been published, the 4th Workshop is scheduled, and the next major goal is the formal launch of the BioCompute Public Private Partnership. The [Executive Committee](https://www.biocomputeobject.org/leadership.html) will formalize the future roadmap beyond these goals.
+
+
+
+
+
+Welcome! This is the BioCompute Events page. Workshops are listed on the schedule below. For any questions, comments, or for a BioCompute Informational Session (15 minute WebEx) click [here](/contact)
+
+
+
+
+
+
+
+
+
Previous Workshops
+
2021
+
Towards Interoperability: Generating BioCompute Objects on Cloud-Based Platforms for Advancing Precision Medicine
+
+Date: Wednesday July 28 at 11:00AM-12:30PM ET
+
+Purpose: The purpose of this workshop is to understand the value of interoperability in both research and regulatory review for scientists in the public or private spaces, and especially from the perspective of FDA personnel. As part of the larger goal of smoothing communication between the FDA and private sector to reduce organization burden on both ends, this workshop will first introduce how the cloud computing platform Seven Bridges can package BioCompute Objects (BCOs) for workflow capture and reproducibility. Following the introduction, we will describe several previously observed use cases to solicit feedback on their relevance to attendees, potentially from image processing (for diagnosis), machine-learning (for communicating and exchanging models with training data), and/or multi-modal data applications. Agenda can be found on the registration page.
+
+Speaker: Dr. Dennis A. Dean, II is a Principal Investigator at Seven Bridges. He manages and builds interdisciplinary teams that develop complex tools and conduct data analyses from conception to deployment/completion. He leads the Translational Science and Analytics Team that includes data scientists, bioinformaticians, and genomic data scientists. He is responsible for the success of his team members across commercial, government, and internal projects. He leads collaborations with the U.S. Food and Drug Administration (FDA), the U.S. Department of Veteran Affairs Million Veteran Program (MVP) and collaborates with large pharmaceutical companies. Dr. Dean trained as a research fellow in medicine at the Harvard Medical School and Brigham and Women’s Hospital in the Program for Sleep Epidemiology and the Program for Sleep and Cardiovascular Medicine. He earned his Ph.D. in biomedical engineering and biotechnology and M.S. in computer science from the University of Massachusetts. He earned his B.S. in computer science from SUNY, Empire State College.
+
+
+
+
Workflow Preservation and Reproducibility with BCO-RO
+
+Date: Wednesday May 12 at 11:00AM-12:30PM ET
+
+
+Purpose: Training session showing how Research Objects (RO) can package BioCompute Objects (BCO) for Digital Preservation and Reproducibility. Research Objects (RO) are a machine-readable digital preservation effort that aims to package all constituent elements of an analysis together into one archive with very detailed provenance. Here, Stian Soiland-Reyes, a Technical Architect on the Research Objects project, will describe an example that packages the workflow as a descriptive, human-readable report in the form of a BioCompute Object (BCO), and which bundles everything in an RO "Crate." Stian will explain the Research Objects project, and introduce a tutorial for building an RO-BCO archive. RO-BCOs can be efficient solutions for scaling up data analyses, both for internal record keeping and logistics, and for communicating workflows to outside groups.
+
+
+
2020
+
+
Introduction to workflow portability with BCO-CWL
+
+Date: Friday November 20th at 12-2PM ET
+
+
+Purpose: BioCompute Objects (BCOs) were developed to aid in communicating a more thorough understanding of computational analyses. While BCOs can be leveraged for re-execution within the context of specific platforms that have integrated them, they are not used for cross platform implementations. Common Workflow Language (CWL) was developed to assist in the portability of execution, meaning the ability to reproduce a pipeline in a different computational environment. The BCO and CWL teams have partnered over the last year to develop a joint mechanism that enables both portability of execution and strong human- and machine-readable documentation through metadata records. New functionality of BCO-CWL means that a reviewer may be able to independently run a computational pipeline used by a sponsor if using a command line environment, or on a platform that supports CWL. This presentation will go over the project by introducing the concept of portability of execution, the concept of a CWL file, and demonstrate the initial draft of a BCO-CWL implementation.
+
+
+
BioCompute Advisory Boards Workshop
+
+Date: Wednesday March 18, 2020 2-4pm ET
+
+Purpose: The purpose of this workshop is to facilitate dialogue between Advisory Board(s) members on BioCompute applications, vocabulary, and current + future progression of the project through a hands-on approach. These discussions are a means to obtain feedback, introduce potential use-cases, and bring everyone up to speed about BioCompute.
+
+
+
BioCompute Workshop for Reviewers: Tool for Communicating Sequencing Analysis
+
+Date: Wednesday June 24, 2020 10am-12pm ET
+
+Purpose: The purpose of this workshop is to facilitate dialogue and show BCO utility specifically for FDA reviewers. We will be briefly discussing BioCompute applications, vocabulary, current + future progression of the project in addition to a hands-on approach to reviewing a BCO for. These discussions are a means to introduce BCO as a tool for submission evaluation mechanism obtain feedback.
+
+
+
Slide deck available [here](/docs/ReviewerWorkshop_24June2020_Deck.pdf)
+
Quick reference guide can be found [here](/docs/BCOCheatSheet.pdf) (PDF)
+
Post-workshop attendee survey available [here](https://www.surveymonkey.com/r/Q9LXSC6)
+
+
+
+
BioCompute Objects: Methods for communicating provenance of data and analysis
+
+Date: Thursday September 24, 9am PT, 12pm ET, 5pm CET
+
+Organizers: Charles Hadley King, Raja Mazumder, Jonathon Keeney; George Washington University
+
+Purpose: Inform about BioCompute Object use and purpose and offer tutelage in the creation and use of BCOs
+
+
BioCompute Objects: Tools for Communicating NGS Data and Analysis
+
+Date: Tuesday May 14, 2019
+
+Organizers: [FDA Center for Biologics Evaluation and Research (CBER)](https://www.fda.gov/about-fda/fda-organization/center-biologics-evaluation-and-research-cber)
+
+**Purpose:** The BioCompute project has resulted in three prior workshops, two publications, several collaborations, and is currently undergoing formal balloting to become an official IEEE standard. The upcoming Workshop will engage more stakeholders in creating and using BioCompute for NGS and other bioinformatics data analysis communications with the FDA. Specifically, the Workshop will have two components: use case examples, and hands on & demonstrations of new tools that leverage BioCompute. A new Precision FDA-BioCompute Challenge will also be launched at the event.
+
+
+
+
\ No newline at end of file
diff --git a/content/extension-scm.md b/content/extension-scm.md
index 1359127..b526c83 100644
--- a/content/extension-scm.md
+++ b/content/extension-scm.md
@@ -1,5 +1,5 @@
---
-title: "BCO Introduction"
+title: "Extension to External References: Software Configuration Management (SCM)"
menu: "main"
---
diff --git a/content/news.md b/content/news.md
new file mode 100644
index 0000000..0c5f775
--- /dev/null
+++ b/content/news.md
@@ -0,0 +1,94 @@
+---
+title: "News"
+menu: "main"
+---
+
+
+
+
+
+
+
+**July 22nd, 2020**
+
+FDA announces support for BioCompute! The July 22nd, 2020 edition of the Federal Register [announced](https://www.federalregister.gov/documents/2020/07/22/2020-15771/electronic-submissions-data-standards-support-for-the-international-institute-of-electrical-and) that the FDA now supports BioCompute (officially known as IEEE 2791-2020), and that the standard will be added to the [Data Standards Catalog](https://www.fda.gov/industry/fda-resources-data-standards).
+
+**June 24th, 2020**
+
+BioCompute training for FDA Reviewers and administrators took place today virtually. The workshop introduced the core concepts of BioCompute, terminology, and walked through usage examples in the context of regulatory submission filings, taken from sample use cases organized with FDA Reviewers. The training was constructed with input from advisory boards, and was focused on receiving a BCO as part of a regulatory filing, rather than technical details. What kinds of information is included in a BCO, where to find relevant information in certain scenarios, and ways to use additional optional fields to include or ask for more information were presented. Supplemental training material like the [quick reference guide](/docs/BCOCheatSheet.pdf) (PDF) was also provided.
+
+**May 14th, 2020**
+
+The IEEE Standard, now known as 2791-2020, has [officially published](https://standards.ieee.org/content/ieee-standards/en/standard/2791-2020.html). The standard can be purchased through the IEEE website, and the open source Schema referred to in the standard can be accessed [here](https://opensource.ieee.org/2791-object/ieee-2791-schema).
+
+**March 18th, 2020**
+
+Training for FDA personnel begins! The BioCompute team met with FDA reviewers and administrators to discuss the needs of FDA personnel and how best to implement BioCompute training. In a series of workshops, tutorials, demonstrations, and other training exercises, the BioCompute team will work with FDA Reviewers and administrators to understand BCOs and interpret information in BCO format, and will discuss the Extension Domains for acquiring extra information.
+
+**January 30th, 2020**
+
+The IEEE Standards Association (IEEE SA) has officially approved P2791 for publication. This marks formal acceptance as a standard, and clears the way for publishing. P2791 is one of the first standards to go through the IEEE Open Source Pilot Project, meaning the source for the entire project is open source (currently available [here](https://gitlab.com/IEEE-SA/2791/ieee-2791-schema)). Updates will be posted when the standard is officially published.
+
+**January 8th, 2020**
+
+The Review Committee (RevCom) for the Institute of Electrical and Electronics Engineers (IEEE) voted to recommend approving P2791, the proposed standard that embodies the BioCompute specification. The [specification](/specification) is an open source document (viewable [here](https://gitlab.com/IEEE-SA/2791/ieee-2791-schema)) that describes the propsed standard, and the vote to approve is major milestone in the project's development. The next step is for the Standards Association (IEEE SA) to vote on the proposed standard based on this recommendation. In the event that it is approved, P2791 will become a formal, IEEE recognized standard!
+
+**October 18th, 2019**
+
+The BCO Challenge on PrecisionFDA has closed. Reviewers are currently evaluating both the beginner and advanced tracks, and will report their top performers on the [PrecisionFDA website](https://precision.fda.gov/challenges/7/view/results). Congratulations to all who participated, and thank you for helping to build the BioCompute project!
+
+**September 23rd, 2019**
+
+We're excited to announce a new program to build a BioComputeDB for the FDA. The database will be a publicly accessible mechanism to facilitate better scientific communication of workflows with little additional communication, outside of the initial submission. As part of the program, we will gather input regarding needs and use cases from FDA personnel that will be used to build the database, and we will train FDA reviewers and researchers. Initial workshops will begin at the FDA in early 2020.
+
+**July 14th, 2019**
+
+BioCompute will be represented at the 52nd annual [Association of Pathology Chairs](https://www.apcprods.org/) Meeting in Boston, MA July 21 - 24. To learn how BioCompute can help support innovation in pathology, please email Jonathon Keeney at keeneyjg@gwu.edu to speak in person, or visit the table near registration, where information will be available. [#APC19Boston](https://twitter.com/hashtag/APC19Boston)
+
+**May 14th, 2019**
+
+The [2019 BioCompute Workshop](https://www.fda.gov/vaccines-blood-biologics/workshops-meetings-conferences-biologics/biocompute-objects-tools-communicating-ngs-data-and-analysis-public-workshop-05142019-05152019) was hosted at the FDA on May 14th, 2019. The workshop featured presentations from FDA reviewers, private sector bioinformatics companies and analysis platforms, a patient advocacy representative, and academic researchers, including discussions of integrating other standards like [Common Workflow Language](https://www.commonwl.org/) and [FHIR Genomics](https://www.hl7.org/fhir/genomics.html). The 2019 Workshop also had an outstanding discussion panel that explored the current challenges in communicating NGS analysis pipelines, and how BioCompute might help address those challenges, and kicked off a [BioCompute Challenge on the PrecisionFDA platform](https://precision.fda.gov/challenges/7).
+
+**March 27th, 2019**
+
+We're excited to announce that a proposal to expand BioCompute usage through the development of BCOs in a cloud computing environment for Galaxy [has been accepted by the National Science Foundation](https://internet2.edu/cloud/exploring-clouds-for-acceleration-of-science/e-cas-research-projects/)! The proposal will create a library of BCOs describing bioinformatic workflows on Amazon Web Services through the open source platform [Galaxy](https://galaxy.aws.biochemistry.gwu.edu/). The proposal is part of Internet2's cooperative agreement with the National Science Foundation, called [Exploring Clouds for Acceleration of Science Project](https://www.nsf.gov/news/news_summ.jsp?cntn_id=297193).
+
+**March 7th, 2019**
+
+The 2019 BioCompute Workshop registration site is live! The United States Food and Drug Administration (FDA) has partnered with the George Washington University [to host](https://www.fda.gov/vaccines-blood-biologics/workshops-meetings-conferences-biologics/biocompute-objects-tools-communicating-ngs-data-and-analysis-public-workshop-05142019-05152019) the 4th BioCompute Workshop. More details can be found [on the FDA's website](https://www.fda.gov/BiologicsBloodVaccines/NewsEvents/WorkshopsMeetingsConferences/ucm632914.htm).
+
+**February 28th, 2019**
+
+The IEEE draft specification of P2791 has passed the Mandatory Editorial Coordination (MEC) review and was approved by the [EMB Standards Committee](http://standards.embs.org/). This has moved the draft specification to the ballot phase, and ballot invitations have been sent out. If you would like to participate in the balloting phase, please contact the P2791 Secretary, Jonathon Keeney, at keeneyjg@gwu.edu. The first iteration of the specification is a descriptive standard that will underpin all future, computationally integrated specifications.
+
+**January 17th, 2019**
+
+The [PLoS Bio paper](https://journals.plos.org/plosbiology/article?id=10.1371/journal.pbio.3000099) describing the BioCompute project [has been featured on the PLoS Open Source Toolkit](https://channels.plos.org/open-source-toolkit)! The Open Source Toolkit is a global forum for open source hadware and software. Its forum helps BioCompute reach a wider audience and cement its status as an invaluable specification for the communication of high throughput sequencing analysis. The paper is currently the first paper in "Featured Research."
+
+**December 31st, 2018**
+
+Several members of the BioCompute community, in both the public and private sectors, have joined together to [publish a manuscript](https://journals.plos.org/plosbiology/article?id=10.1371/journal.pbio.3000099) describing the BioCompute project. The theory, utility, and implementation of the BioCompute specification are described, along with use cases.
+
+**December 23rd, 2018**
+
+The [P2791 Working Group](http://sites.ieee.org/sagroups-2791/) to build an IEEE BioCompute standard has formally voted to move ahead with the process. This means that the IEEE Sponsor will review the document, followed by an official Ballot Group review, and a public comment period. This is exciting news, and a major step for BioCompute. Standardization of BioCompute will create a formal mechanism for creating, commenting on, and using a way to communicate next generation sequencing data in a consensus-driven way.
+
+**October 1st, 2018**
+
+In order to explore the possibility of joining the Open Source Pilot Project, the BioCompute IEEE Working Group (P2791) meeting originally scheduled for October 5th has been postponed to October 22nd, 2018, at 1PM Eastern. The meeting will be held by WebEx at that time. This meeting is open to the public.
+
+**September 19th, 2018**
+
+2019 BioCompute Workshop announced! The next BioCompute Workshop will be held on March 25th, 2019 at the FDA's White Oak campus. A Scientific Advisory Board will be formed and convened to discuss the agenda and speakers.
+
+**September 11th, 2018**
+
+BioCompute is [presented](https://twitter.com/NeuroGenomics/status/1039643176267669505) at the IEEE Standards Association Workshop: Standards for Digital Data in Ehealth. The workshop, hosted by the [IEEE Standards Association](https://standards.ieee.org/), explored standards in cutting edge technologies being deployed in healthcare. As a mechanism to bridge efforts between researchers, clinicians, and the regulatory pipeline, BioCompute helps to advance personalized medicine by enabling better communication between these key drivers.
+
+**August 29th, 2018**
+
+Kickoff meeting for the IEEE Working Group convened! The IEEE Working Group, P2791, has held its first meeting. The meeting was well attended by representatives from the FDA, as well as several universities, biotech, and pharmaceutical enterprises. With a core constituency of voting members established, future Working Group meetings will work to establish Version 1.3 of the [Specification Document](https://github.com/biocompute-objects/BCO_Specification) into a formal IEEE Standard.
+
+**July 24th, 2018**
+
+As part of its efforts to host NIH funded data sets through the [STRIDES](https://commonfund.nih.gov/data) program, Google [today announced](https://www.blog.google/products/google-cloud/building-a-global-biomedical-data-ecosystem-with-the-national-institutes-of-health/) that it will use the BioCompute standard to help make these datasets more accessible. BioCompute helps build transparency and reproducibility into work flows in the high throughput sequencing space, and will improve the utility of NIH funded datasets.
diff --git a/public/404.html b/public/404.html
new file mode 100644
index 0000000..b300993
--- /dev/null
+++ b/public/404.html
@@ -0,0 +1,73 @@
+
+
+
+
+
+
+ 404 Page not found - BioCompute Object Documentation
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The extension_domain is a space for a user to add additional structured information that is not defined in the BioCompute shcema. The extension_domain section is not evaluated by checks for BCO validity or computational correctness and as such is the place to add ANY type of additional structured information. We provide two examples that are neither exclusive nor exhaustive.
The required domains are defined by the IEEE . However, a BioCompute Object is considered complete when an Error Domain exists.
+
Versioning is allowed, but only if the changes do not affect the workflow or output. BCO versioning follows a minor.patch schema, no major versions are allowed (substantial changes result in a new BCO). Minor changes are things like a change of contact information for a contributor, patch changes are things like spelling and grammar fixes.
+
In general, any step that does not transform data does not need to be included in the Description Domain as a formal step, and can be described instead in the Usability Domain. For example, arranging rows and columns in a table, or formatting a figure. Steps that transform data should comprise their own step in the Description Domain.
+
The Usability Domain should contain enough information to enable a naïve user generally skilled in bioinformatics to understand the analysis. This means that references to commonly used resources (such as basic Unix commands, well known databases like NCBI, basic terms like “alignment,” etc.) do not need to be explained, but references to less well known resources (such as obscure python packages, etc.) should be described. Description should be tailored to the intended audience, and BCOs intended for public consumption should assume a basic level of bioinformatics proficiency.
+
+
BioCompute Registry
+
The BioCompute Registry is a domain registry for BCO IDs in which users can register their institution or organization. Similar to a website registry, this will allow the owner of that domain to use any domain organization of their choosing, and prevent naming collisions between groups. For example, the owner of “GW” can build BCOs GW_0001.1, GW01A, GW_, or any other naming system of their preference, and these will not conflict with another registered domain, such as FDA_0001.1, etc. The BCO Registry registration numbers may not exceed five characters, and are recommended to be three characters. Any alphanumeric characters are acceptable.
+
A BCO may be registered only by the author of the object, and the domain must be approved by the domain holder. Until automated systems are in place, register a BCO by sending the BCO ID and email of the registrant to the BioCompute Team. The following institutional domains have been reserved:
+
+
GWU
+
FDA
+
NIH
+
CDC
+
NCI
+
+
Preferred Ontologies
+
Semantic Versioning
+
BCO versioning should adhere to semantic versioning to establish how version numbers are assigned and incremented. Given a version number MAJOR.MINOR.PATCH, when versioning a BCO increment the:
+
+
MAJOR version when you make incompatible API changes,
+
MINOR version when you add functionality in a backwards-compatible manner, and
+
PATCH version when you make backwards-compatible bug fixes.
+Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
+
+
PAV Ontology and PROV-O
+
To preserve the provenance of each BCO, the contribution type of the reviewers and contributors is a choice taken from PAV ontology: provenance, authoring and versioning, which also maps to the PROV-O. The following are possible values for the status of an object in the review process:
+
+
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.
+
+
Namespace: CURIE
+
External references 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. Cross-referenced resources need to be available in the public domain. The external references are stored in the form of prefixed identifiers (CURIEs). These CURIEs map directly to the URIs maintained by identifiers.org. See Section 3.5 for a list of the CURIEs used in this example.
+
General
+
+
The required domains are defined by the IEEE . However, a BioCompute Object is considered complete when an Error Domain exists.
+
Versioning is allowed, but only if the changes do not affect the workflow or output. BCO versioning follows a minor.patch schema, no major versions are allowed (substantial changes result in a new BCO). Minor changes are things like a change of contact information for a contributor, patch changes are things like spelling and grammar fixes.
+
In general, any step that does not transform data does not need to be included in the Description Domain as a formal step, and can be described instead in the Usability Domain. For example, arranging rows and columns in a table, or formatting a figure. Steps that transform data should comprise their own step in the Description Domain.
+
The Usability Domain should contain enough information to enable a naïve user generally skilled in bioinformatics to understand the analysis. This means that references to commonly used resources (such as basic Unix commands, well known databases like NCBI, basic terms like “alignment,” etc.) do not need to be explained, but references to less well known resources (such as obscure python packages, etc.) should be described. Description should be tailored to the intended audience, and BCOs intended for public consumption should assume a basic level of bioinformatics proficiency.
This section defines the fields of the description_domain part of the BCO structure.
+
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 journal format. It is possible that in the future this field can be semi-automatically generated from the execution_domain information.
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. Cross-referenced resources need to be available in the public domain. The external references are stored in the form of prefixed identifiers (CURIEs). These CURIEs map directly to the URIs maintained by identifiers.org. See Appendix-II for a list of the CURIEs used in this example.
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"]
+
2.4.4 Pipeline tools “pipeline_steps”
+
This is an optional structured domain for recording the specifics of a pipeline. Each individual tool (or a well defined and reusable script) is represented as a step, at the discretion of the author. Parallel processes are given the same step number. This is required.
+
2.4.4.1 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 partial order for presentation purposes, e.g. parallel computations assigned the same number based on their first possible execution. Actual execution order might differ from the step number. Gaps are allowed (e.g. step 20 follows step 10).
+
"step_number":1
+
2.4.4.2 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"
+
2.4.4.2 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",
+
2.4.4.3 Tool Version “version”
+
The version assigned to the instance of the tool used corresponding to the upstream release.
+
"version":"1.3",
+
2.4.4.4 Tool Prerequisites “prerequisite”
+
A list of text values to indicate any packages or prerequisites for running the tool used. This consists of a name and uri. The uri object consists of the filename, uri, access_time, and sha1_chksum properties. The uri is the only REQUIRED property but it is reccomended that in the prerequisites here the access_time is used as well.
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.
2.8 Error Domain, acceptable range of variability “error_domain”
+
The error domain can be used to determine what range of input returns outputs that are within the tolerance level defined in this subdomain and therefore can be used to optimize algorithm. It consists of two subdomains: empirical and algorithmic.
+
The empirical error 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.
+
The algorithmic subdomain is descriptive of errors that originate by 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.
+
For data integration BCOs used to develop knowledgebases, the error domain can, for example, contain rules that determine inclusion in the knowledgebase and reference to data that pass and fail the set of rules.
+
The possible keys within each subdomain are workflow-specific, free text which should be readable for a human.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/public/examples/index.xml b/public/examples/index.xml
new file mode 100644
index 0000000..db08176
--- /dev/null
+++ b/public/examples/index.xml
@@ -0,0 +1,22 @@
+
+
+
+ Examples on BioCompute Object Documentation
+ /examples/
+ Recent content in Examples on BioCompute Object Documentation
+ Hugo -- gohugo.io
+ en-us
+
+
+ /examples/readme/
+ Mon, 01 Jan 0001 00:00:00 +0000
+
+ /examples/readme/
+ BCO Examples A repository for BCO example flat files.
+Table of Contents: HCV1a - This BCO was developed with the Reproducibility and Interpretation use case in mind. This is the archetypal BCO example and is in the BCO Specification repository.
+ glycosylation-sites-UniCarbKB - This BCO was developed with the Data integration use case in mind. The full repository is available here
+ UVP - This BCO was developed with the Accountability use case in mind.
+
+
+
+
diff --git a/public/examples/readme/index.html b/public/examples/readme/index.html
new file mode 100644
index 0000000..b128e59
--- /dev/null
+++ b/public/examples/readme/index.html
@@ -0,0 +1,194 @@
+
+
+
+
+
+
+ - BioCompute Object Documentation
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
This section defines the execution_domain part of the BCO.
+
The fields required for 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 facilitation of reproducibility as defined by the Oxford English Dictionary as “the extent to which consistent results are obtained when produced repeatedly.”
The Script field points to internal or external references to a script object that was used to perform computations for this BCO instance. This may be a reference to an object in GitHub, a computational service or any other type of script.
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) in order to run the pipeline.
+
"script_driver":"shell"
+
2.5.3 Algorithmic tools and Software Prerequisites “software_prerequisites”
+
An optional multi-value field listing the minimal necessary prerequisites, library, tool versions needed to successfully run the script to produce BCO. The keys are name, version, and uri.
2.5.4 External Data Endpoints “external_data_endpoints”
+
An optional multi-value field listing the minimal necessary domain specific external data source access in order to successfully run the script to produce 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 than only resources which path prefix matches may be accessed.
+
The key name should describe the service that is accessed.
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 compute 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_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 name space of environment variable names containing lowercase letters is reserved for applications. Applications can define any environment variables with names from this name space 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, use of such names is not recommended anywhere.
2.3.1 Extension to External References: SMART on FHIR Genomics
+
The external references example extension to FHIR resource demonstrates how specific data elements can be extracted from EHR systems or other secure FHIR endpoints via technologies such as SMART on FHIR Genomics (https://www.ncbi.nlm.nih.gov/pubmed/26198304) without compromising patient and providers’ information. This is because the portions being transferred contain no identifiable information about the patient. Instead there is a reference to the actual resource instance (via FHIR URL) through which all data is accessed.
+
The 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/.
2.3.2 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.
A classifier for the type of SCM database. This feild is a list of predefined values. Third-party scm types can be used, and if so the other value MUST be used. The options for this field include git (Git, including GitHub/GitLab), svn (Subversion), hg (mercurial) and other.
+
2.3.2.3 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).
+
2.3.2.4 SCM Path “scm_path”
+
This is the path from the repository to the source code referenced. scm_path should NOT start with /
+
2.3.2.5 SCM Preview “scm_preview”
+
The full uri for the source code referenced by the BioCompute.
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 the 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.
Note that some identifier patterns result in a 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 Biology15(6): e2001414.
+https://doi.org/10.1371/journal.pbio.2001414
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/public/images/certification_requirements.png b/public/images/certification_requirements.png
new file mode 100644
index 0000000..eb88ff5
Binary files /dev/null and b/public/images/certification_requirements.png differ
diff --git a/public/images/favicon.png b/public/images/favicon.png
new file mode 100644
index 0000000..3267b2c
Binary files /dev/null and b/public/images/favicon.png differ
diff --git a/public/images/logo.about.png b/public/images/logo.about.png
new file mode 100644
index 0000000..8f948f6
Binary files /dev/null and b/public/images/logo.about.png differ
diff --git a/public/images/logo.helix_only.png b/public/images/logo.helix_only.png
new file mode 100644
index 0000000..914338a
Binary files /dev/null and b/public/images/logo.helix_only.png differ
diff --git a/public/index.html b/public/index.html
new file mode 100644
index 0000000..82e689d
--- /dev/null
+++ b/public/index.html
@@ -0,0 +1,212 @@
+
+
+
+
+
+
+
+ BioCompute Object Documentation
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Because of the many different ways to organize data, a major goal of the BioCompute project is to build and maintain a formal standard through recognized, accredited standards setting organizations like the Institute for Electrical and Electronics Engineers (IEEE) and the International Standards Organization (ISO). A formal, consensus-based standard builds predictability and even more stability into the way in which bioinformatic methods are communicated.
+
The standard, officially known as 2791-2020, has two parts: the standards document and the schema, which is maintained in an open source repository:
+
+
The current version of the standard can be found here.
Since the base BioCompute schema is maintained as an open source repository, it can be cloned and integrated into an organization in unique ways, which allows organizations to build off of this schema to create dependent standards for specific applications. This is similar to the different versions of WiFi based on usage, such as the 802.11a standard for fast speed, but high cost and shorter range, or the 802.11b for slower top speed, but lower cost, etc. — all of which are built on the 802.11 base standard. It can also be used to further extend the schema, such as for handling proprietary, internal content, while still being compatible with the base standard. The open source schema also enables individuals or organizations to suggest changes to be incorporated into future versions the standard.
To reference the BCO standards, please use the following
+citation inclusive of the DOI:
+
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
A permissive license similar to the BSD 2-Clause License, but with a 3rd clause that prohibits others from using the name of the project or its contributors to promote derived products without written consent.
+
+
Mailing List
+
As a subscriber to the BCO mailing list, you can post to it by sending a message tobiocomputels@hermes.gwu.edu (using the email address that is subscribed). This list is semi-automated and will send your message for review.
+
To subscribe or unsubscribe, please visit https://hermes.gwu.edu/cgi-bin/wa?A0=BIOCOMPUTELS and click Subscribe or Unsubscribe on the lower right. You can also unsubscribe from the list at any time by sending an email to listserv@hermes.gwu.edu, in which the body says: unsubscribe biocomputels
+
This repository is in support of 2791-2020 - IEEE Approved Draft Standard for Bioinformatics Computations and Analyses Generated by High-Throughput Sequencing (HTS) to Facilitate Communication. Please also see our OSF page or our main page
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/public/index.xml b/public/index.xml
new file mode 100644
index 0000000..e73374e
--- /dev/null
+++ b/public/index.xml
@@ -0,0 +1,217 @@
+
+
+
+ Home on BioCompute Object Documentation
+ /
+ Recent content in Home on BioCompute Object Documentation
+ Hugo -- gohugo.io
+ en-us
+
+
+ /examples/readme/
+ Mon, 01 Jan 0001 00:00:00 +0000
+
+ /examples/readme/
+ BCO Examples A repository for BCO example flat files.
+Table of Contents: HCV1a - This BCO was developed with the Reproducibility and Interpretation use case in mind. This is the archetypal BCO example and is in the BCO Specification repository.
+ glycosylation-sites-UniCarbKB - This BCO was developed with the Data integration use case in mind. The full repository is available here
+ UVP - This BCO was developed with the Accountability use case in mind.
+
+
+
+
+ /release_protocol/
+ Mon, 01 Jan 0001 00:00:00 +0000
+
+ /release_protocol/
+ BioCompute Release Protocol Prep
+ Create a release issue: release_1.4.0. Set freeze date freeze date [1/24/2020]. Branch Release (on or around freeze date)
+ Ensure all blocking milestone issues have been closed. Merge the latest release into dev and push upstream. Deploy and Test Release
+ Review issues and ensure they all have a milestones attached. Link Checkout release branch. Run schemas/validate.py on each of the examples in examples/*, updating if necessary.
+
+
+
+ BCO Best Practice
+ /best_practices/
+ Mon, 01 Jan 0001 00:00:00 +0000
+
+ /best_practices/
+ ((window.gitter = {}).chat = {}).options = { room: 'biocompute-objects/BCO_Specification' }; BioCompute Objects Best Practice General The required domains are defined by the IEEE . However, a BioCompute Object is considered complete when an Error Domain exists. Versioning is allowed, but only if the changes do not affect the workflow or output. BCO versioning follows a minor.patch schema, no major versions are allowed (substantial changes result in a new BCO).
+
+
+
+ BCO Curation SOP
+ /sop/
+ Mon, 01 Jan 0001 00:00:00 +0000
+
+ /sop/
+ ((window.gitter = {}).chat = {}).options = { room: 'biocompute-objects/BCO_Specification' }; BCO Curation SOP Author: BioCompute Consortium Version: 2.0 Effective Date: Aug 2020 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
+ 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 Domains
+ /bco-domains/
+ Mon, 01 Jan 0001 00:00:00 +0000
+
+ /bco-domains/
+ ((window.gitter = {}).chat = {}).options = { room: 'biocompute-objects/BCO_Specification' }; This document is part of the BioCompute Object User Guide
+BCO domains A 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":{ "fhir_extension": [ ], "scm_extension": { } }, "description_domain": { }, "execution_domain": { }, "parametric_domain": { }, "io_domain": { }, "error_domain": { } } 2.
+
+
+
+ BCO Introduction
+ /extension-fhir/
+ Mon, 01 Jan 0001 00:00:00 +0000
+
+ /extension-fhir/
+ ((window.gitter = {}).chat = {}).options = { room: 'biocompute-objects/BCO_Specification' }; This document is part of the BioCompute Object User Guide
+Back to BCO domains
+2.3.1 Extension to External References: SMART on FHIR Genomics The external references example extension to FHIR resource demonstrates how specific data elements can be extracted from EHR systems or other secure FHIR endpoints via technologies such as SMART on FHIR Genomics (https://www.ncbi.nlm.nih.gov/pubmed/26198304) without compromising patient and providers’ information.
+
+
+
+ BCO Introduction
+ /introduction/
+ Mon, 01 Jan 0001 00:00:00 +0000
+
+ /introduction/
+ ((window.gitter = {}).chat = {}).options = { room: 'biocompute-objects/BCO_Specification' }; This document is part of the BioCompute Object User Guide
+1 Introduction to BioCompute Objects BioCompute is a paradigm and a BioCompute Object (BCO) is an instance of that paradigm. High-throughput sequencing (HTS), also referred to as next-generation sequencing (NGS) or massively parallel sequencing (MPS), has increased the pace at which we generate, compute and share genomic data in biomedical sciences.
+
+
+
+ Description Domain
+ /description-domain/
+ Mon, 01 Jan 0001 00:00:00 +0000
+
+ /description-domain/
+ ((window.gitter = {}).chat = {}).options = { room: 'biocompute-objects/BCO_Specification' }; This document is part of the BioCompute Object User Guide
+Back to BCO domains
+2.4 Description Domain “description_domain” This section defines the fields of the description_domain part of the BCO structure.
+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 journal format.
+
+
+
+ Error Domain
+ /error-domain/
+ Mon, 01 Jan 0001 00:00:00 +0000
+
+ /error-domain/
+ ((window.gitter = {}).chat = {}).options = { room: 'biocompute-objects/BCO_Specification' }; This document is part of the BioCompute Object User Guide
+Back to BCO domains
+2.8 Error Domain, acceptable range of variability “error_domain” The error domain can be used to determine what range of input returns outputs that are within the tolerance level defined in this subdomain and therefore can be used to optimize algorithm. It consists of two subdomains: empirical and algorithmic.
+
+
+
+ Execution Domain
+ /execution-domain/
+ Mon, 01 Jan 0001 00:00:00 +0000
+
+ /execution-domain/
+ ((window.gitter = {}).chat = {}).options = { room: 'biocompute-objects/BCO_Specification' }; This document is part of the BioCompute Object User Guide
+Back to BCO domains
+2.5 Execution Domain “execution_domain” This section defines the execution_domain part of the BCO.
+The fields required for 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.
+
+
+
+ Extension to External References: Software Configuration Management (SCM)
+ /extension-scm/
+ Mon, 01 Jan 0001 00:00:00 +0000
+
+ /extension-scm/
+ ((window.gitter = {}).chat = {}).options = { room: 'biocompute-objects/BCO_Specification' }; This document is part of the BioCompute Object User Guide
+Back to BCO domains
+2.3.2 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.
+
+
+
+ External References
+ /external-references/
+ Mon, 01 Jan 0001 00:00:00 +0000
+
+ /external-references/
+ ((window.gitter = {}).chat = {}).options = { room: 'biocompute-objects/BCO_Specification' }; This document is part of the BioCompute Object User Guide
+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 the enables the referencing of data for the scientific community, with a current focus on the Life Sciences domain.
+
+
+
+ I/O Domain
+ /io-domain/
+ Mon, 01 Jan 0001 00:00:00 +0000
+
+ /io-domain/
+ ((window.gitter = {}).chat = {}).options = { room: 'biocompute-objects/BCO_Specification' }; This document is part of the BioCompute Object User Guide
+Back to BCO domains
+2.7 Input and Output Domain “io_domain” This section defines the io_domain part of the BCO.
+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.
+
+
+
+ Parametric Domain
+ /parametric-domain/
+ Mon, 01 Jan 0001 00:00:00 +0000
+
+ /parametric-domain/
+ ((window.gitter = {}).chat = {}).options = { room: 'biocompute-objects/BCO_Specification' }; This document is part of the BioCompute Object User Guide
+Back to BCO domains
+2.6 Parametric Domain “parametric_domain” This represents the list of NON-default 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 parametric_domain is not used for running/reproducing a bco e.
+
+
+
+ Provenance Domain
+ /provenance-domain/
+ Mon, 01 Jan 0001 00:00:00 +0000
+
+ /provenance-domain/
+ ((window.gitter = {}).chat = {}).options = { room: 'biocompute-objects/BCO_Specification' }; This document is part of the BioCompute Object User Guide
+Back to BCO domains
+2.1 Provenance Domain “provenance_domain” This section defines the fields of the provenance_domain part of the BCO structure.
+Condensed example:
+"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.
+
+
+
+ Top Level Domains
+ /top-level/
+ Mon, 01 Jan 0001 00:00:00 +0000
+
+ /top-level/
+ ((window.gitter = {}).chat = {}).options = { room: 'biocompute-objects/BCO_Specification' }; This document is part of the BioCompute Object User Guide
+Back to BCO domains
+2.0 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:
+{ "spec_version" : "https://w3id.org/ieee/ieee-2791-schema/", "object_id": "https://example.com/bco/9487ae7e-c1aa-4a3c-b18f-3d3695b33ace", "etag": "d41d8cd98f00b204e9800998ecf8427e", "provenance_domain": { }, "...": { } } 2.
+
+
+
+ Usability Domain
+ /usability-domain/
+ Mon, 01 Jan 0001 00:00:00 +0000
+
+ /usability-domain/
+ ((window.gitter = {}).chat = {}).options = { room: 'biocompute-objects/BCO_Specification' }; This document is part of the BioCompute Object User Guide
+Back to BCO domains
+2.2 Usability Domain “usability_domain” This section defines the usability_domain part of the BCO structure.
+This field provides a space for the author to define the usability domain of the BCO. It is an array of free text values that should be consistant with terminology used in the name, external references (xref), and keywords sections.
+
+
+
+ User Guide
+ /user_guide/
+ Mon, 01 Jan 0001 00:00:00 +0000
+
+ /user_guide/
+ ((window.gitter = {}).chat = {}).options = { room: 'biocompute-objects/BCO_Specification' }; This document was created by the BioCompute Object Consortium members (BCOC) BioCompute Object (BCO) User Guide This version: draft-2.0.0 This version is offerd as support for 2791-2020 - IEEE Approved Standard for Bioinformatics Computations and Analyses Generated by High-Throughput Sequencing (HTS) to Facilitate Communication. Previous version: 1.4.0
+Latest release: https://github.com/biocompute-objects/BCO_Specification/releases/latest Latest editor’s draft: https://github.com/biocompute-objects/BCO_Specification/tree/dev Note that unless you are viewing a release this is a draft subject to change.
+
+
+
+
diff --git a/public/introduction/index.html b/public/introduction/index.html
new file mode 100644
index 0000000..6ed954d
--- /dev/null
+++ b/public/introduction/index.html
@@ -0,0 +1,250 @@
+
+
+
+
+
+
+ BCO Introduction - BioCompute Object Documentation
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
BioCompute is a paradigm and a BioCompute Object (BCO) is an instance of that paradigm. High-throughput sequencing (HTS), also referred to as next-generation sequencing (NGS) or massively parallel sequencing (MPS), has increased the pace at which we generate, compute and share genomic data in biomedical sciences. As a result, scientists, clinicians and regulators are now faced with a new data paradigm that is less portable, more complex and most of all poorly standardized. BCOs use a simple implementation of the JSON schema to encode important information on the execution of computational pipelines, or for the creation of knowledgebases. BioCompute can be process oriented (for software pipelines) and/or product oriented (for knowledge bases). The goal of using a BCO is to streamline communication of these details between stakeholders in academia, industry and regulatory agencies.
+
The US Food and Drug Administration (FDA) and George Washington University (GW) have partnered to establish a framework for community-based standards development and harmonization of HTS computations and data formats. Standardized HTS data processing and data formats will promote interoperability and simplify the verification of bioinformatics protocols. To do this, a schema has been developed to represent instances of computational analysis as a BCO. A BCO includes:
+
+
Information about parameters and versions of the executable programs in a pipeline
+
Reference to input and output test data for verification of the pipeline
+
A usability domain
+
Keywords
+
A list of agents involved along with other important metadata, such as their specific contribution
+
+
Knowledge of input data is intended to be captured according to existing efforts, including MIRAGE, MIAPE, and STRENDA, and to be in accordance with Minimum Information Standards. In addition to all the information captured in the BCO, the BCO itself must be independent of the execution environment, whether it is a local high-performance or a cloud-based infrastructure.
Develop BioCompute Objects that will facilitate communication of HTS computational analysis details with the FDA.
+
Develop a community of stakeholders to create a versatile data harmonization framework that allows the standardized definition of platform-independent bioinformatics pipelines for execution, and is easily read by humans AND machines.
+
Facilitate the development of tools and facilities implementing data typing, instantiation, deposition, storage, and distribution of validated BioCompute Objects through a BioCompute database, in order to enable reproducible scientific research and regulatory submissions of data and computations.
+
Facilitate portability of pipelines for execution on Public Cloud infrastructure.
+
+
1.2 Motivation
+
The unpredictability of tangible physical, chemical, and biological experiments due to the multitude of environmental and procedural factors is well documented. What is often systematically overlooked is that computational biology algorithms are affected by a multiplicity of parameters and are no less volatile. The complexities of computation protocols and interpretation of outcomes is only part of the challenge; there are also virtually no standardized and industry-accepted metadata schemas for reporting the computational pipelines and parameters together with their results. Thus, it is often impossible to reproduce the results of a previously performed computation due to missing information on parameters, versions, arguments, conditions, and procedures of application launch. The BCO concept has been developed specifically to satisfy regulatory research needs for evaluation, validation, and verification of bioinformatics pipelines; however, there is potential utility of BCO within the larger scientific community. This utility can be increased through the creation of a BCO database comprising records relevant to the U.S. Food and Drug Administration.
+
A BioCompute Object database record will be similar to a GenBank record in form; however, instead of describing a sequence, the BioCompute record will include information related to parameters, dependencies, usage, and other information related to the specific computational instance. This mechanism will extend similar efforts and also serve as a collaborative ground to ensure interoperability between different platforms, industries, scientists, regulators, and other stakeholders interested in biocomputing.
At the initial stages of BioCompute development, we address the challenges of HTS (NGS) bioinformatics.
+
BCOs could very easily be extended to other types of computational analysis, and at this stage, we are limiting our focus to HTS analysis and database creation.
+
+
1.3 Audience for this document
+
+
Users performing HTS analysis with a regulatory science perspective
+
HTS Platform Developers
+
HTS related standard developers
+
+
1.4 Potential Stakeholders for the BioCompute project
+
+
US Food and Drug Administration, as well as other Regulatory Agencies
Bioinformatics tool and platform developers who wish to operate in a regulatory environment, including cloud service (PaaS, IaaS, SaaS, FaaS) providers
+
Journals / Scientific Publishing / peer reviewing process
+
US National Institutes of Health (NIH) (particularly initiatives such as NCI/ITCR)
+
Public cloud companies operating in the Life Sciences sector including electronic health record (EHR) systems
+
+
1.5 BCO User stories
+
Reproducibility and Interpretation use case
+
A pharmaceutical company is submitting NGS data and the FDA conducts a reanalysis of the data. The reanalysis does not concur with the original results. It can be very lengthy and costly to figure out the location of the discrepancies. Attaching a BioCompute Object with the initial submission would prevent most of the ambiguity surrounding the discrepancies.
+
Reusability use case
+
A regulatory decision has been made where a computational analysis has been used as evidence. New data emerges after the product has been on the market over a year and the regulators cannot reproduce the original environment with the configuration of tools and parameters of pipelines to reanalyze the initial submission data or replicate the initial conclusion.
+
Collaboration use case
+
Authors and pharmaceutical scientists are unaware of how the regulatory industry is using workflows to analyze data. Openness and transparency are hindered by the lack of ability to communicate, not a lack of willingness. Scientific merit is compromised as a result of not having a common “language” for communicating computations.
+
Accountability use case
+
A bioinformatics platform provider can use BCO as part of its verification and validation process. A customer submits NGS data provided by a third party sequencing provider. The sequencing data is poor quality. Reproducible pipelines, validated and verified as a “BCO”, were used to demonstrate the fault lies in the sequencing step and not the bioinformatics pipeline.
+
Versioning use case
+
One potential use case related to this is one of ‘differential impact’ of how different choices in the workflow affect the outcome of the computational analysis/experiment (e.g. changing expression estimation procedure).
+
Provenance use case
+
BCOs can serve as a history of what was computed. An example pertaining to provenance, from experience: data are generated and QC’ed as far as possible, and then passed on for analysis. The analysis diagnoses a problem with one or more samples (e.g., cryptic relatedness), which are then locally excluded from the analysis. But that exclusion is not reflected back to the original data, and the same bad samples are included in the next analysis. In this way, a record exists of which samples can be excluded in future analysis.
+
Data integration use case
+
A BCO can be used to provide clarity and transparency of the data integration process to both the new and existing collaborators. When new data is integrated into the existing data model, BCO can be used to describe data source information (eg- authors/contributors, data version etc), a QC workflow, data content, data modification if any. The BCO also allows reuse of the same workflow to integrate new data with same structure and source. BCO also provides a way to access and track data records which were eliminated in the integration/QC process due to rules or restrictions of the existing data model. Knowledgebases using BCOs in the form of ‘readme’ can provide provenance for every piece of data that is collected and presented to the user. Such granular tracking facilitates fair sharing of data and provides mechanisms for adherence to licensing requirements associated with specific datasets.
+
1.6 BCO community
+
The BioCompute Object working group facilitates a means for different stakeholders in the HTS communities to provide input on current practices on the BCO. This working group was formed during preparation for the 2017 HTS Computational Standards for Regulatory Sciences Workshop, and was initially made up of the workshop participants, both speakers and panelists. There has been a continual growth of the BCO working group as a direct result of the interaction between the stakeholders interested in standardization of computational HTS data processing.
This section defines the io_domain part of the BCO.
+
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 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 documentation of individual scripts and specific BCO descriptions for further details.
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 modified using rules described in the BCO. It is recommended that the values here include filename, uri, and access_time.
This represents the list of NON-default 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 parametric_domain is not used for running/reproducing a bco e.g. not used by the execution_domain. It is recommended these fields be generated automatically, but that may not always be possible. Please refer to documentation of individual scripts and specific BCO descriptions for details. While this domain is NOT required, it is recommended that it be populated.
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.
+
"name":"HCV1a ledipasvir resistance SNP detection"
+
2.1.2 Version “version”
+
Records the versioning of this BCO instance object. Semantic Versioning 2.0.0 describes versioning as follows:
+
+
Given a version number MAJOR.MINOR.PATCH, increment the:
+
+
MAJOR version when you make incompatible API changes,
+
MINOR version when you add functionality in a backwards-compatible manner, and
+
PATCH version when you make backwards-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 RECCOMENDED that the versioning of a BCO only utilize MINOR and PATCH, or two digits.
+
"version":"2.1",
+
2.1.3 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, ORCID IDs 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 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 (described in section 2.1.9) are used to populate the reviewer section. Each BCO SHOULD have at least one review.
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 than the field is not included.
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"
+
2.1.6 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.
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 readOnly.
+
"created":"2017-01-20T09:40:17-0500"
+
2.1.8 Modification “modified”
+
Using the datetime type the time of most recent modification of the BCO is recorded
+
"modified":"2018-03-21T18:31:48-0400"
+
2.1.9 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 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 PROV-O.
A space for Creative Commons licence or other license information (text). The default or recommended licence can be Creative Commons Attribution 4.0 International identified as https://spdx.org/licenses/CC-BY-4.0.html
The following recommendations are intended to provide guidance on BCO™ creation, versioning, certification and authentication.
+
BCO IDs and Versioning
+
Intended Audience: BCO authors
+
+
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 that everyone registers 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 for the development of 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 includes usually 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 input (excluding reference files/databases) and output files field. tBCOs and rBCOs can be authenticated using secure blockchain technology.
Run certification requirements: certified template + run BCO (to confirm that parameters and error domain are within range etc.)
+
+
+
+
+
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 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).
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 write functionalities. For users who do not have access to a bioinformatics platform they can use the BCO Consortium Editor tool which has some of the basic API functionalities:
+
+
Create a BCO that is conformant to IEEE-2791.
+
Upload BCOs in batch mode. The tool runs QA/QC processes on those uploads and create unique IDs
+
Search for existing BCOs by author/title/usability/keywords
+
Download and install an instance within an organization’s firewall
+
View videos and documentation on tool use
+
+
This documentation is currently in the comment phase until Sept. 15, 2020. Please send your comments to Jonathon Keeney.
The version of the BCO specification used to define the BCO. It is recomended that this value be a permalink as defined in the w3id.org/biocompute repository.
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 UUIDs (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 are also acceptable.
A string-type, read-only value, protecting the object from internal or external alterations without proper validation. The string should be generated through the use of a 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:
This section defines the usability_domain part of the BCO structure.
+
This field provides a space for the author to define the usability domain of the BCO. It is an array of free text values that should be consistant with terminology used in the name, external references (xref), and keywords sections. The usability_domain can accept template language to indicate values from the external_references. The template takes the form of:
+
+
(SNP)[SO:0000694]
+
+
where ($term) and [$identifier] are an entry in the external_references section.
+
This field is to aid in search-ability and provide a specific scientific use case and a description of the function of the object. The usability domain along with keywords can help determine when and how the BCO can be used. It is recomended that a novel use of a specific BCO would result in the creation of a new entry with a new usability domain.
+
"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 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"]
+]
+
This document specifies the structure of BioCompute Objects.
+The specification is split into multiple parts linked to from this
+top-level document and are maintained in a
+GithHub repository
+where contributions are welcome.
BCOs are represented in JSON (JavaScript Object Notation) formatted text, adhearing to 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 www.json.org.
+
BioCompute data types are defined as aggregates of the critical fields organized into the following domains: the provenance domain, the usability domain, the extension domain, the description domain, the execution domain, the parametric domain, the input and output domains, and the error domain. At the time of creation with actual values compliant to the schema the BCO should be assigned a unique identifier, a object_id. The object could then be assigned a unique digital etag.
+
Three of the domains in a BioCompute Object SHOULD become immutable upon assignment of the digital etag:
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 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 relevance of BioCompute Objects with 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.
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 as external file that are referenced. An example, along 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
+
3.5 Appendix VI Acknowledgements
+
This document began development during the 2017 HTS-CSRS workshop. The discussion during the workshop led to the refinement and completion of this document. The workshop participants were a major part of the initial BCO community, and the comments and suggestions collected during the sessions were incorporated into this document. The people who participated in the 2017 workshop, and therefore made significant contributions are listed here: https://osf.io/h59uh/
+
BioCompute Object Consortium members (BCOC)
+
FDA: Vahan Simonyan, Mark Walderhaug, Ruth Bandler, Eric Donaldson, Elaine Thompson, Alin Voskanian, Anton Golikov, Konstantinos Karagiannis, Elaine Johanson, Adrian Myers, Errol Strain, Khaled Bouri, Tong Weida, Wenming Xiao, Md Shamsuzzaman
+
GW: Raja Mazumder, Charles Hadley S. King IV, Amanda Bell, Jeet Vora, Krista M. Smith, Robel
+Kahsay
+
Documentation Community: Gil Alterovitz (Boston Children’s Hospital/Harvard Medical School, SMART/FHIR/HL7, GA4GH), Michael R. Crusoe (CWL), Marco Schito (C-Path), Konstantinos
+Krampis (CUNY), Alexander (Sasha) Wait Zaranek (Curoverse), John Quackenbush (DFCI/Harvard), Geet Duggal (DNAnexus), Singer Ma (DNAnexus), Yuching Lai (DDL), Warren Kibbe (Duke), Tony, Burdett (EBI), Helen Parkinson (EBI), Stuart Young (Engility Corp), Anupama Joshi (Epinomics), Vineeta Agarwala (Flatiron Health), James Hirmas (GenomeNext), David Steinberg (UCSC), Veronica Miller (HIV Forum), Dan Taylor (Internet 2), Paul Duncan (Merck), Jianchao Yao (Merck & Co., Inc., Boston, MA USA), Marilyn Matz (Paradigm4), Ben Busby (NCBI), Eugene Yaschenko (NCBI), Zhining Wang (NCI), Hsinyi (Steve) Tsang (NCI), Durga Addepalli (NCI/Attain), Heidi Sofia (NIH), Scott Jackson (NIST), Paul Walsh (NSilico Life Science), Toby Bloom (NYGC), Hiroki Morizono (CNMC), Jeremy Goecks (Oregon Health and Science University), Srikanth Gottipati (Otsuka-US), Alex Poliakov (Paradigm4), Keith Nangle (Pistoia Alliance), Jonas S Almeida (Stony Brook Univ, SUNY), Dennis A. Dean, II (Seven Bridges Genomics), Dustin Holloway (Seven Bridges Genomics), Nisha Agarwal (Solvuu), Stian Soiland-Reyes (UNIMAN), Carole Goble (UNIMAN), Susanna-Assunta Sansone (University of Oxford), Philippe Rocca-Serra (University of Oxford), Phil Bourne (Univ. of Virginia), Joseph Nooraga (Fred Hutchinson Cancer Research Center)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/static/docs/BCOCheatSheet.pdf b/static/docs/BCOCheatSheet.pdf
new file mode 100644
index 0000000..6b43af6
Binary files /dev/null and b/static/docs/BCOCheatSheet.pdf differ
diff --git a/static/docs/ReviewerWorkshop_24June2020_Deck.pdf b/static/docs/ReviewerWorkshop_24June2020_Deck.pdf
new file mode 100644
index 0000000..a627452
Binary files /dev/null and b/static/docs/ReviewerWorkshop_24June2020_Deck.pdf differ
diff --git a/static/images/Almeida.jpg b/static/images/Almeida.jpg
new file mode 100644
index 0000000..0a9c098
Binary files /dev/null and b/static/images/Almeida.jpg differ
diff --git a/static/images/Alterovitz.png b/static/images/Alterovitz.png
new file mode 100755
index 0000000..62089c5
Binary files /dev/null and b/static/images/Alterovitz.png differ
diff --git a/static/images/Crusoe.jpg b/static/images/Crusoe.jpg
new file mode 100644
index 0000000..e5c8c23
Binary files /dev/null and b/static/images/Crusoe.jpg differ
diff --git a/static/images/Dean.png b/static/images/Dean.png
new file mode 100644
index 0000000..4f11e27
Binary files /dev/null and b/static/images/Dean.png differ
diff --git a/static/images/Goble.png b/static/images/Goble.png
new file mode 100755
index 0000000..ec056a4
Binary files /dev/null and b/static/images/Goble.png differ
diff --git a/static/images/Goecks.png b/static/images/Goecks.png
new file mode 100644
index 0000000..f3a7785
Binary files /dev/null and b/static/images/Goecks.png differ
diff --git a/static/images/Golikov.jpg b/static/images/Golikov.jpg
new file mode 100644
index 0000000..c4605df
Binary files /dev/null and b/static/images/Golikov.jpg differ
diff --git a/static/images/Karagiannis.jpg b/static/images/Karagiannis.jpg
new file mode 100644
index 0000000..8b4265d
Binary files /dev/null and b/static/images/Karagiannis.jpg differ
diff --git a/static/images/Keeney.png b/static/images/Keeney.png
new file mode 100644
index 0000000..cf369de
Binary files /dev/null and b/static/images/Keeney.png differ
diff --git a/static/images/King.png b/static/images/King.png
new file mode 100644
index 0000000..3880230
Binary files /dev/null and b/static/images/King.png differ
diff --git a/static/images/Krampis.jpg b/static/images/Krampis.jpg
new file mode 100644
index 0000000..5c9826e
Binary files /dev/null and b/static/images/Krampis.jpg differ
diff --git a/static/images/Mazumder.png b/static/images/Mazumder.png
new file mode 100755
index 0000000..fb9439c
Binary files /dev/null and b/static/images/Mazumder.png differ
diff --git a/static/images/Patel.jpg b/static/images/Patel.jpg
new file mode 100644
index 0000000..3465efb
Binary files /dev/null and b/static/images/Patel.jpg differ
diff --git a/static/images/Simonyan.png b/static/images/Simonyan.png
new file mode 100755
index 0000000..19b17b4
Binary files /dev/null and b/static/images/Simonyan.png differ
diff --git a/static/images/Soiland-Reyes.jpg b/static/images/Soiland-Reyes.jpg
new file mode 100644
index 0000000..2c8d0e9
Binary files /dev/null and b/static/images/Soiland-Reyes.jpg differ
diff --git a/static/images/Soranzo.jpg b/static/images/Soranzo.jpg
new file mode 100644
index 0000000..efe6d27
Binary files /dev/null and b/static/images/Soranzo.jpg differ
diff --git a/static/images/Taylor.jpg b/static/images/Taylor.jpg
new file mode 100644
index 0000000..928132a
Binary files /dev/null and b/static/images/Taylor.jpg differ
diff --git a/static/images/Thompson.jpg b/static/images/Thompson.jpg
new file mode 100644
index 0000000..b4cb5b5
Binary files /dev/null and b/static/images/Thompson.jpg differ
diff --git a/static/images/Travis.jpg b/static/images/Travis.jpg
new file mode 100644
index 0000000..e7e4fa7
Binary files /dev/null and b/static/images/Travis.jpg differ
diff --git a/static/images/about.2.png b/static/images/about.2.png
new file mode 100644
index 0000000..c1e3cd8
Binary files /dev/null and b/static/images/about.2.png differ
diff --git a/static/images/about.3.png b/static/images/about.3.png
new file mode 100644
index 0000000..2c97b93
Binary files /dev/null and b/static/images/about.3.png differ
diff --git a/static/images/about.4.png b/static/images/about.4.png
new file mode 100644
index 0000000..b498cfd
Binary files /dev/null and b/static/images/about.4.png differ
diff --git a/static/images/about.8.png b/static/images/about.8.png
new file mode 100644
index 0000000..9466de3
Binary files /dev/null and b/static/images/about.8.png differ
diff --git a/static/images/clinical.1.png b/static/images/clinical.1.png
new file mode 100755
index 0000000..4c47d64
Binary files /dev/null and b/static/images/clinical.1.png differ
diff --git a/static/images/landing.1.png b/static/images/landing.1.png
new file mode 100644
index 0000000..b5905a3
Binary files /dev/null and b/static/images/landing.1.png differ
diff --git a/static/images/landing.2-original.png b/static/images/landing.2-original.png
new file mode 100644
index 0000000..be443dc
Binary files /dev/null and b/static/images/landing.2-original.png differ
diff --git a/static/images/landing.2.png b/static/images/landing.2.png
new file mode 100644
index 0000000..36475ed
Binary files /dev/null and b/static/images/landing.2.png differ
diff --git a/static/images/landing.4-original.png b/static/images/landing.4-original.png
new file mode 100644
index 0000000..ed0d75b
Binary files /dev/null and b/static/images/landing.4-original.png differ
diff --git a/static/images/landing.4.png b/static/images/landing.4.png
new file mode 100644
index 0000000..75a8334
Binary files /dev/null and b/static/images/landing.4.png differ
diff --git a/static/images/landing.5.png b/static/images/landing.5.png
new file mode 100644
index 0000000..914338a
Binary files /dev/null and b/static/images/landing.5.png differ
diff --git a/static/images/logo.Argentys.png b/static/images/logo.Argentys.png
new file mode 100644
index 0000000..68e0194
Binary files /dev/null and b/static/images/logo.Argentys.png differ
diff --git a/static/images/logo.Embleema.png b/static/images/logo.Embleema.png
new file mode 100644
index 0000000..dc8f399
Binary files /dev/null and b/static/images/logo.Embleema.png differ
diff --git a/static/images/logo.MilliporeSigma.png b/static/images/logo.MilliporeSigma.png
new file mode 100644
index 0000000..7988b5a
Binary files /dev/null and b/static/images/logo.MilliporeSigma.png differ
diff --git a/static/images/logo.OpenHealthSystemsLaboratory.png b/static/images/logo.OpenHealthSystemsLaboratory.png
new file mode 100644
index 0000000..8ffcc7f
Binary files /dev/null and b/static/images/logo.OpenHealthSystemsLaboratory.png differ
diff --git a/static/images/logo.clinical.png b/static/images/logo.clinical.png
new file mode 100755
index 0000000..11a785d
Binary files /dev/null and b/static/images/logo.clinical.png differ
diff --git a/static/images/logo.regulatory.png b/static/images/logo.regulatory.png
new file mode 100755
index 0000000..b93f83e
Binary files /dev/null and b/static/images/logo.regulatory.png differ
diff --git a/static/images/logo.research.png b/static/images/logo.research.png
new file mode 100755
index 0000000..b040ce6
Binary files /dev/null and b/static/images/logo.research.png differ
diff --git a/static/images/logo.workshop.png b/static/images/logo.workshop.png
new file mode 100644
index 0000000..0eaa690
Binary files /dev/null and b/static/images/logo.workshop.png differ
diff --git a/static/images/organization.2.png b/static/images/organization.2.png
new file mode 100644
index 0000000..7d8f8cb
Binary files /dev/null and b/static/images/organization.2.png differ
diff --git a/static/images/powered-by-aws.png b/static/images/powered-by-aws.png
new file mode 100644
index 0000000..0e299a8
Binary files /dev/null and b/static/images/powered-by-aws.png differ
diff --git a/static/images/ppp.png b/static/images/ppp.png
new file mode 100644
index 0000000..d545c15
Binary files /dev/null and b/static/images/ppp.png differ
diff --git a/static/images/services.1.png b/static/images/services.1.png
new file mode 100644
index 0000000..f6b94db
Binary files /dev/null and b/static/images/services.1.png differ
diff --git a/static/images/services.2.png b/static/images/services.2.png
new file mode 100644
index 0000000..336961a
Binary files /dev/null and b/static/images/services.2.png differ
diff --git a/static/images/services.3.png b/static/images/services.3.png
new file mode 100644
index 0000000..020c0ba
Binary files /dev/null and b/static/images/services.3.png differ
diff --git a/static/images/services.4.png b/static/images/services.4.png
new file mode 100644
index 0000000..10b1007
Binary files /dev/null and b/static/images/services.4.png differ
+
+
+
+
+
+
+