Top-level: Difference between revisions
(Created page with "Back to BCO domains ==Top Level Fields== These header fields uniquely define this BCO. These fields are required for every BCO and are represented at the top level object. Condensed example: { "object_id": "https://example.com/BCO_948701/1.0", "spec_version" : "https://w3id.org/ieee/ieee-2791-schema/2791object.json", "etag": "d41d8cd98f00b204e9800998ecf8427e", "provenance_domain": {...") |
No edit summary |
||
| Line 1: | Line 1: | ||
Back to [[Bco-domains|BCO domains]] | Back to [[Bco-domains|BCO domains]] | ||
==Top Level Fields== | == 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. | These header fields uniquely define this BCO. These fields are required for every BCO and are represented at the top level object. | ||
| Line 15: | Line 15: | ||
} | } | ||
===BCO version “spec_version”=== | === BCO version “spec_version” === | ||
The version of the BCO specification is used to define the BCO. It is recommended that this value is a permalink as defined in the [https://github.com/perma-id/w3id.org/tree/master/biocompute w3id.org/biocompute] repository. | The version of the BCO specification is used to define the BCO. It is recommended that this value is a permalink as defined in the [https://github.com/perma-id/w3id.org/tree/master/biocompute w3id.org/biocompute] repository. | ||
| Line 21: | Line 21: | ||
"spec_version": "https://w3id.org/ieee/ieee-2791-schema/2791object.json" | "spec_version": "https://w3id.org/ieee/ieee-2791-schema/2791object.json" | ||
===BioCompute Object Identifier “object_id”=== | === BioCompute Object Identifier “object_id” === | ||
A unique identifier that should be applied to each BCO instance. These can be assigned by a BCO database engine or manually generated. IDs should never be reused. It is recommended that the BCO identifier is based on a [https://datatracker.ietf.org/doc/html/rfc4122 UUID]s (sometimes called GUIDs) to ensure uniqueness, either as a location-independent URN (e.g. urn:uuid:2bf8397b-9aa8-47f2-80a7-235653e8e824) or as part of an identifier permalink, (e.g. http://repo.example.com/bco/2bf8397b-9aa8-47f2-80a7-235653e8e824). While the UUID is the preferred method, IDs expressed as a URN or URL will satisfy the standard. | A unique identifier that should be applied to each BCO instance. These can be assigned by a BCO database engine or manually generated. IDs should never be reused. It is recommended that the BCO identifier is based on a [https://datatracker.ietf.org/doc/html/rfc4122 UUID]s (sometimes called GUIDs) to ensure uniqueness, either as a location-independent URN (e.g. urn:uuid:2bf8397b-9aa8-47f2-80a7-235653e8e824) or as part of an identifier permalink, (e.g. http://repo.example.com/bco/2bf8397b-9aa8-47f2-80a7-235653e8e824). While the UUID is the preferred method, IDs expressed as a URN or URL will satisfy the standard. | ||
| Line 37: | Line 37: | ||
#Hostname: [https://datatracker.ietf.org/doc/html/rfc3986 see Host in RFC_3986] | #Hostname: [https://datatracker.ietf.org/doc/html/rfc3986 see Host in RFC_3986] | ||
#BCO Accession: composed of 2 parts separated by an underscore( _): | #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 | #*The BCO Prefix: A 3-5 alphanumeric characters. Preferably one registered via the [[Best practices|BioCompute Registry]] | ||
#*BCO identifier: a numeric identifier appended to the prefix | #*BCO identifier: a numeric identifier appended to the prefix | ||
#BCO version: This is the version of the BCO, as recorded on the [[Provenance-domain|Provenance Domain]] | #BCO version: This is the version of the BCO, as recorded on the [[Provenance-domain|Provenance Domain]] | ||
"object_id": "https://biocomputeobject.org/BCO_000001/1.5" | "object_id": "https://biocomputeobject.org/BCO_000001/1.5" | ||
=== ETag “etag” === | |||
A string-type, read-only value, protects the object from internal or external alterations without proper validation. The string should be generated through the use of an SHA-256 hash function. Everything EXCEPT for the etag, object_id, and spec_version should be included in the generation of the hash. For example: | |||
"provenance_domain": {}, | |||
"usability_domain": [], | |||
"extension_domain":{}, | |||
"description_domain": {}, | |||
"execution_domain": {}, | |||
"parametric_domain": [], | |||
"io_domain": {}, | |||
"error_domain": {} | |||
will generate the following: | |||
"etag": "584C7FE128717E1712426AB19CAAEA8BC1E27365B54285BBEA1221284C7D3A48" | |||
== Additional domains == | |||
Additional description about the BCO itself is also provided in the [[Provenance-domain|provenance domain]], [[Description-domain|description domain]] and [[Usability-domain|usability domain]]. Other domains detail areas like execution and error ranges. | |||
Latest revision as of 18:22, 3 August 2022
Back to BCO domains
Top Level Fields
These header fields uniquely define this BCO. These fields are required for every BCO and are represented at the top level object.
Condensed example:
{
"object_id": "https://example.com/BCO_948701/1.0",
"spec_version" : "https://w3id.org/ieee/ieee-2791-schema/2791object.json",
"etag": "d41d8cd98f00b204e9800998ecf8427e",
"provenance_domain": {
},
"...": { }
}
BCO version “spec_version”
The version of the BCO specification is used to define the BCO. It is recommended that this value is a permalink as defined in the w3id.org/biocompute repository.
"spec_version": "https://w3id.org/ieee/ieee-2791-schema/2791object.json"
BioCompute Object Identifier “object_id”
A unique identifier that should be applied to each BCO instance. These can be assigned by a BCO database engine or manually generated. IDs should never be reused. It is recommended that the BCO identifier is based on a 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 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:// | biocomputeobject.org/ | /BCO_000001 | /1.5 |
- Protocol: It is recommended that this be HTTPS or at least HTTP see Scheme in RFC 3986 for more detail on protocols.
- Hostname: see Host in RFC_3986
- BCO Accession: composed of 2 parts separated by an underscore( _):
- The BCO Prefix: A 3-5 alphanumeric characters. Preferably one registered via the BioCompute Registry
- BCO identifier: a numeric identifier appended to the prefix
- BCO version: This is the version of the BCO, as recorded on the Provenance Domain
"object_id": "https://biocomputeobject.org/BCO_000001/1.5"
ETag “etag”
A string-type, read-only value, protects the object from internal or external alterations without proper validation. The string should be generated through the use of an SHA-256 hash function. Everything EXCEPT for the etag, object_id, and spec_version should be included in the generation of the hash. For example:
"provenance_domain": {},
"usability_domain": [],
"extension_domain":{},
"description_domain": {},
"execution_domain": {},
"parametric_domain": [],
"io_domain": {},
"error_domain": {}
will generate the following:
"etag": "584C7FE128717E1712426AB19CAAEA8BC1E27365B54285BBEA1221284C7D3A48"
Additional domains
Additional description about the BCO itself is also provided in the provenance domain, description domain and usability domain. Other domains detail areas like execution and error ranges.