Skip to content

Latest commit

 

History

History
119 lines (85 loc) · 5.91 KB

sep_017.md

File metadata and controls

119 lines (85 loc) · 5.91 KB

SEP 017 -- Implementation

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

Abstract

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.

Table of Contents

Rationale

  • 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.

Specification

Here we define one new classes in the SBOL data model, Implementation.

2.1 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.

Implementation class UML diagram

Figure 1: Diagram of the Implementation class and its associated properties

2.1.1 Implementation.built

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.

Examples

See Discussion for an in-depth explanation of these examples.

3.1 Derivation of Biological Replicates for iGEM Interlab Study

Object UML diagram for iGEM interlab case study

Example 1:

3.2 Co-Transfection of Constructs for CRISPR Repression Module

Object UML diagram for CRISPR repression case study

Example 2:

Backwards Compatibility

This proposal does not affect backwards compatibility.

Discussion

Example 1

Example 2

Relation to Other SEPs

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.

References

Copyright

CC0
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.