SEP | |
---|---|
Title | SEP 017 -- Implementation |
Authors | Bryan Bartley (bartleyba@sbolstandard.org), Jake Beal (jakebeal@gmail.com), Raik Gruenberg (raik.gruenberg@gmail.com), Chris Myers (myers@ece.utah.edu), Nicholas Roehner (nicholasroehner@gmail.com), and Anil Wipat (anil.wipat@newcastle.ac.uk) |
Editor | Nicholas Roehner (nicholasroehner@gmail.com) |
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.