From BCOeditor Wiki
Jump to navigation Jump to search

Back to BCO domains

Top Level Fields

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

Condensed example:

           "object_id": "",
           "spec_version" : "",
           "etag": "d41d8cd98f00b204e9800998ecf8427e",    
           "provenance_domain": {
           "...": { }

BCO version “spec_version”

The version of the BCO specification is used to define the BCO. It is recommended that this value is a permalink as defined in the repository.

       "spec_version": ""

BioCompute Object Identifier “object_id”

A unique identifier that should be applied to each BCO instance. These can be assigned by a BCO database engine or manually generated. IDs should never be reused. It is recommended that the BCO identifier is based on a 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. While the UUID is the preferred method, IDs expressed as a URN or URL will satisfy the standard.

The following is the recommended format for a BCO object_id, and what has been implemented by the BCODB:

The "object_id" consists of four different parts:

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

  1. Protocol: It is recommended that this be HTTPS or at least HTTP see Scheme in RFC 3986 for more detail on protocols.
  2. Hostname: see Host in RFC_3986
  3. BCO Accession: composed of 2 parts separated by an underscore( _):
    • The BCO Prefix: A 3-5 alphanumeric characters. Preferably one registered via the BioCompute Registry
    • BCO identifier: a numeric identifier appended to the prefix
  4. BCO version: This is the version of the BCO, as recorded on the Provenance Domain
   "object_id": ""

ETag “etag”

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

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

will generate the following:

   "etag": "584C7FE128717E1712426AB19CAAEA8BC1E27365B54285BBEA1221284C7D3A48"

Additional domains

Additional description about the BCO itself is also provided in the provenance domain, description domain and usability domain. Other domains detail areas like execution and error ranges.