Permalink
Browse files

Refactoring and editing figures among SEPs 017, 018, and 019

  • Loading branch information...
nroehner committed Nov 13, 2017
1 parent c951f5d commit cab56aff0d9de7d50773b67f1f5691e146c2c179
View
Binary file not shown.
View
Binary file not shown.
View
Binary file not shown.
View
Binary file not shown.
View
Binary file not shown.
View
Binary file not shown.
File renamed without changes.
File renamed without changes.
View
Binary file not shown.
View
Binary file not shown.
View
Binary file not shown.
View
Binary file not shown.
View
Binary file not shown.
View
Binary file not shown.
View
Binary file not shown.
View

Large diffs are not rendered by default.

Oops, something went wrong.
View
@@ -56,7 +56,7 @@ The size is a long integer indicating the file size in bytes. This may be used b
The hash is a string used to retrieve files from a cache. This field is OPTIONAL.
![attachment](images/sep_019_attachment.png "attachment")
![attachment](images/sep_018_attachment.png "attachment")
**Figure 1:** Diagram of the `Attachment` class and its associated properties
@@ -65,7 +65,7 @@ Examples <a name="examples"></a>
### 3.1 Attachment <a name="example5"></a>
![Attachment example](images/sep_019_attachment_example.png "Attachment example")
![Attachment example](images/sep_018_attachment_example.png "Attachment example")
**Example 1:** `Attachments` wrap an experimental data file and include important meta-data that helps tools interpret the data. This example attaches quality control data in the form of a gel image and sequencing results.
View
@@ -58,21 +58,9 @@ This SEP was initiated in response to the ["Design-Build-Test" thread] on sbol-d
Specification <a name="specification"></a>
----------------------------------------------
Here we define two new classes in the SBOL data model, `Implementation` and `Attachment`. We also define four new SBOL ontology terms (`sbol:design, sbol:build, sbol:test, and sbol:learn) to serve as values for the `hadRole` properties of the PROV-O classes `Usage` and `Association`.
Here we define four new SBOL ontology terms (`sbol:design, sbol:build, sbol:test, and sbol:learn) to serve as values for the `hadRole` properties of the PROV-O classes `Usage` and `Association`. We also present best practices and validation rules associated with the use of these ontology terms and PROV-O to represent design-build-test-learn cycles.
### 2.1 Implementation <a name="impl"></a>
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`) via PROV-O linkages as described in [Section 2.3](#dbtl). An `Implementation` may also link to a `ModuleDefinition` or `ComponentDefinition` that specifies its realized structure and/or function as described in [Section2.1.1](#built).
![Implementation class UML diagram](images/sep_019_implementation.png "Implementation class UML diagram")
**Figure 1:** Diagram of the `Implementation` class and its associated properties
#### 2.1.1 Implementation.built <a name="built"></a>
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.
### 2.2 Design, Build, Test, and Learn <a name="dbtl"></a>
### 2.1 Design, Build, Test, and Learn <a name="dbtl"></a>
The ontology terms `design`, `build`, `test`, and `learn` are defined here to indicate how objects are used in an `Activity` via the `hadRole` property on the `Usage` class. Additionally, these terms are also used to describe the roles that an `Agent` or `Plan`, such as a person, software tool, or protocol, may play in an `Activity` via the `hadRole` property on the `Association` class.
@@ -82,23 +70,23 @@ In natural language, these terms indicate the following:
* A "test" refers to raw data or observations gathered through experimental analysis
* To "learn" describes a process by which a theoretical model, analysis, datasheet, etc is derived from experimental data
### 2.3 Best Practices <a name="best_practices"></a>
### 2.2 Best Practices <a name="best_practices"></a>
#### 2.3.1 Usage Roles <a name="usage_roles"></a>
#### 2.2.1 Usage Roles <a name="usage_roles"></a>
To facilitate data exchange across different domains of synthetic biology, a user SHOULD use one of the terms "design", "build", "test", or "learn" to specify `Usage` roles.
A user MAY also specify additional Usage roles that correspond to their own home-made ontologies for specifying recipes and protocols.
#### 2.3.2 Versioning versus Provenance Semantics <a name="provenance_semantics"></a>
#### 2.2.2 Versioning versus Provenance Semantics <a name="provenance_semantics"></a>
A new object which is the product of an `Activity` links back to the `Activity` which generated it via the `wasGeneratedBy` field. By the W3 PROV-O specification, generation is defined as:
```
...the completion of production of a new entity by an activity. This entity did not exist before generation and becomes available for usage after this generation.
```
Provenance semantics are somewhat different from the versioning semantics defined in the SBOL specification. The SBOL specification defines a new version of an object as an update of a previously published object (and therefore a previously existing object). In contrast, an SBOL object which is "generated" from another SHOULD BE regarded as a new entity, not a new version by the PROV-O specification above. However, this distinction is somewhat subjective (see Theseus paradox). Therefore we RECOMMEND as a best practice that objects linked by Activities not be successive versions of each other, though we leave this at the discretion of users and library developers.
### 2.4 Validation Rules <a name="validation_rules"></a>
### 2.3 Validation Rules <a name="validation_rules"></a>
The design-build-test-learn process generates new SBOL objects in the order of one or more `ModuleDefinitions`, followed by one or more `Implementations`, followed by one or more `Collections`, followed by one or more `Models`. This order of operations is enforced through the following validation rules:

This file was deleted.

Oops, something went wrong.
Oops, something went wrong.

0 comments on commit cab56af

Please sign in to comment.