| SEP | |
|---|---|
| Title | SEP 017 -- Implementation |
| Authors | Bryan Bartley ([email protected]), Jake Beal ([email protected]), Raik Gruenberg ([email protected]), Chris Myers ([email protected]), Nicholas Roehner ([email protected]), and Anil Wipat ([email protected]) |
| Editor | Nicholas Roehner ([email protected]) |
| Type | Data Model |
| SBOL Version | 2.3 |
| Replaces | N/A |
| Status | Withdrawn |
| Created | 10-Nov-2017 |
| Last modified | 13-Nov-2017 |
| Issue | #38 |
We propose to add a new class, Implementation, to allow users to represent physical realizations of biological designs. For example, an Implementation could be used to represent an aliquot of DNA, a cell clone, or a lysate. The Implementation class is meant to serve as a connection point between theoretical designs of biological systems and descriptions of their actual structure and/or function following their physical construction. In addition, an Implementation can eventually be linked to experimental data that characterize its performance or confirm its physical structure, etc.
- 1. Rationale
- 2. Specification
- 3. Examples
- 4. Backwards Compatibility
- 5. Discussion
- 6. Relation to Other SEPs
- References
- Copyright
- Provide an SBOL representation of biological instances of a design that can link to LIMS systems.
This SEP was initiated in response to the ["Design-Build-Test" thread] on sbol-dev.
Here we define one new classes in the SBOL data model, Implementation.
An Implementation represents a real, physical instance of a synthetic biological construct which may be associated with a laboratory sample. An Implementation describes the thing which was built during the Build phase of a D-B-T-L workflow. An Implementation may be linked back to its original design (either a ModuleDefinition or ComponentDefinition) using the wasDerivedFrom property inherited from the Identified superclass. An Implementation may also link to a ModuleDefinition or ComponentDefinition that specifies its realized structure and/or function as described in Section2.1.1.
Figure 1: Diagram of the Implementation class and its associated properties
The built property is OPTIONAL and MAY contain a URI that MUST refer to a TopLevel object that is either a ComponentDefinition or ModuleDefinition. This ComponentDefinition or ModuleDefinition is intended to describe the actual physical structure and/or functional behavior of the Implementation. When the built property refers to a ComponentDefinition that is also linked to the Implementation via PROV-O properties such as wasDerivedFrom, it can be inferred that the actual structure and/or function of the Implementation matches its original design. When the built property refers to a different ComponentDefinition, it can be inferred that the Implementation has deviated from the original design. For example, the latter could be used to document when the DNA sequencing results for an assembled construct do not match the original target sequence.
See Discussion for an in-depth explanation of these examples.
Example 1:
Example 2:
This proposal does not affect backwards compatibility.
This proposal overlaps with the Implementation class presented in SEP 016, but adoption of SEP 017 does not preclude the future adoption of SEP 016.
To the extent possible under law,
SBOL developers
has waived all copyright and related or neighboring rights to
SEP 007.
This work is published from:
United States.