| SEP | |
|---|---|
| Title | Experimental implementations and replicates |
| Authors | Raik Gruenberg (raik.gruenberg at gmail com) |
| Editor | |
| Type | Data Model |
| SBOL Version | 2.3 |
| Replaces | SEP 014 |
| Status | Withdrawn, replaced by SEP 20 |
| Created | 04-Sep-2017 |
| Last modified | 07-Nov-2017 |
| Issue | #35 |
We propose to introduce a new class, Implementation, to represent different
replicates of physical design realizations. In practice, Implementation will
mostly identify cell clones or experimental batches of
material. Implementation will allow to collate experimental results as they
are recorded for one particular clone or biological replicate. Implementation
will serve as the connection point between experimental results with theoretical
design. A more detailed description of the system as it was actually built can be optionally linked in.
- 1. Rationale
- 2. Specification
- 3. Example or Use Case
- 4. Backwards Compatibility
- 5. Discussion
- 6. Competing SEPs
- References
- Copyright
The assembly of plasmids or genome engineering experiments always lead to multiple clones of cells that need to be validated against the original design. Each clone may or may not adhere to the design and, independent of that, may have further unique characteristics such as, for example, novel mutations outside the region of interest. For this reason, bioengineers routinely identify and track which clones of cells or which batch of protein or other material they are working with. Experimental results need to be interpreted in the context of the biological replicate from which they were obtained. For example, a plasmid sequencing result only applies to cells derived from the same bacterial colony during a DNA assembly experiment.
Assigning experimental results directly to a given theoretical design is therefore not a good general solution as it skips over the fact that different replicates may behave differently. We therefore need to be able to uniquely identify a biological replicate or batch in order to properly assign experimental results.
Batches of DNA or protein as well as bacterial clones and mammalian cell lines are commonly exchanged between labs or purchased from commercial providers. Also in this context it may be important to identify batches or clones.
SBOL currently has no notion of biological replicates. The rational behind the Implementation class is to provide exactly this. It represent, in the most abstract sense, one identifyable instance of the physical realization of a design. Experimental data can then be aggregated on this implementation as long as they were obtained from the same cell line or clone or batch of biomaterial. Implementation can also be useful to exchange information about yet unvalidated clones and help automating the process of validation itself. In particular it can help to compare intended design with the actual sequence information recorded for a given clone.
We propose the introduction of a new class Implementation which represents one particular physical realization of a design. A given instance of Implementation may identify one particular bacterial colony picked from a transformation plate (and all cell culture samples beloning to this clone), or it may identify one particular batch of plasmid DNA derived from one such clone, or one batch of a synthetic protein expressed and purified in one particular lab.
The class is derived from sbol:TopLevel giving it the following fields (please verify):
- displayID
- name
- description
In addition, Implementation defines the following new fields:
-
design[mandatory, 1..1] -- link to aComponentDefinitionor aModuleDefinitiondescribing the design to which this replicate is supposed to adhere. This does not strictly imply that the replicate or clone actually correctly implements the design.designgives direct access to the sequence information against which different clones or replicates can be validated. -
built[optional, 0..1] -- optional link to aComponentDefinitionorModuleDefinitionwhich describes the actual composition (e.g. in most cases sequence) recorded for this particular replicate. If given, this should be a best-effort summary of what is currently known about the clone in terms of its actual sequence or other structural features. This may deviate from the original design (e.g. an unintended mutation invalidating this clone) or it may add additional detail that falls outside the scope of the design (e.g. the random DNA sequence flanking a genomic insert) and which distinguishes this particular clone from other replicates. -
implementationStatus-- a summary of the (structural) implementation status. One of:planning,construction,validatedCorrect,validatedIncorrect,validatedAmbiguous,notValidated,abandonned
Information about people or labs involved in the construction or experimental methods used can be provided by provO activity records. Several Implementation instances can point to the same activity record. Details of this provenance annotation are to be described elsewhere (e.g. SEP 19).
SBOL currently has no concept for physical samples in the lab. Implementation is meant to represent clones or batches which, in many cases, will encompass more than one sample. Ultimately, practical use will show where the boundary between different batches is drawn.
provO vocabulary can be used to track relationships between clones and batches.
Since this is a new class, no backwards compatibility issues are expected.
Instead of providing direct links to ComponentDefinition/ModuleDefinition, it has been proposed to wrap every such connection in provO activity records. This view emphasizes transactions over the actual status of a clone. In particular, a given clone would be "generated from" a design with varying amounts of experimental (assembly) detail given in the provenance records. The current SEP argues for a, perhaps more pragmatic, "factual" data model where intended and recorded sequence are immediately available. This appears more fitting because each Implementation (clone, batch) is a phyiscally existing end point which may end up in a lab-to-lab shipment or repository for future studies. Transactional / historic meta data can be added on top of this factual layer using a restricted provO vocabulary.
It was argued that Implementation should only have one link to ComponentDefinition / ModuleDefinition. The link to the original design will then be completely replaced by the more detailed or actual "built" information as it becomes available. The original design could remain linked indirectly to the "built" ComponentDefnition via provenance (provO) records. We argue against this solution: (1) The intended design plus the information whether or not the clone fulfills this design is arguably the most important thing to know about a given clone. Even when additional clone-specific information becomes available, the original (typically more abstract or perhaps "idealized") design is still highly valuable. It should remain easily accessible.
SEP #19 currently provides a conflicting definition of Implementation
- TODO
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.