Skip to content

Latest commit

 

History

History
94 lines (62 loc) · 4.64 KB

sep_035.md

File metadata and controls

94 lines (62 loc) · 4.64 KB
Raw

SEP 035 -- Interactions and Models on ComponentDefinition

SEP 035
Title Interactions and Models on ComponentDefinition
Authors Jacob Beal ([email protected])
Editor James cLaughlin
Type Data Model
SBOL Version 2.4
Replaces
Status Draft
Created 14-July-2019
Last modified
Issue #80

Abstract

This proposal will add Interactions and Models onto ComponentDefinition, effectively merging ModuleDefinition into ComponentDefinition. This will allow ModuleDefinition and all of its relations to be deprecated.

Motivation

Currently, when describing composition of devices, one typically has to maintain a precisely parallel hierarchy of ComponentDefinition and ModuleDefinition objects. This is confusing and seems unnecessary, as when one composes two designs, both their structure and their function should compose.

Similarly, the boundary between structural and functional composition is often unclear, and can cause miscategorizations that are problematic to correct. For example, we are using ModuleDefinition to represent mixtures (e.g., growth media) while ComponentDefinition is used to represent covalently bonded structures (e.g., DNA, pure chemicals). If you aren't sure if a reagent is a

In short, there doesn't seem to be any value to separating structure and function, so we are going to let one object contain both types of information.

Specification

Adjustments to ComponentDefinition

The ComponentDefinition class will be enhanced by addition of the models and interactions properties, exactly equivalent to how they are currently used in ModuleDefinition.

Additional validation rules to add are:

  • A weak REQUIRED condition for ComponentDefinition: there must only be a sequence or sequenceAnnotation if all components can be linearized onto a single sequence.
  • A weak REQUIRED condition for SequenceConstraint is that the subject and object must both be components with a sequence.

Implications of this elaboration:

  • Physically linking sequences in two devices together is simpler (e.g., the promoter output of a device to the CDS input of another). Instead of being specified with a separate ComponentDefinition, the two can be directly linked via a SequenceConstraint.
  • A combinatorial derivation can now express combinatorial experimental conditions as well, via VariableComponent objects containing different amounts of ingredients in a sample (e.g., different inducers, different co-transfections)

Adjustments to Component and Participation

The direction field from FunctionalComponent is moved up to ComponentInstance, such that it applies to Component as well.

For Participation objects, the participant property is generalized to allow ComponentInstance objects, not just FunctionalComponent.

Deprecation of ModuleDefinition

The child classes used only by ModuleDefinition will also be removed. Those are FunctionalComponent and Module.

At that time, FunctionalComponent will also be removed, removing the need for subclassing Component.

Backwards Compatibility

Adding new fields to ComponentDefinition will not prevent continued use of existing ModuleDefinitions. Any existing ModuleDefinition can also be converted directly into an equivalent ComponentDefinition by

In SBOL 3, ModuleDefinition, FunctionalComponent, and Module will all be deleted, which will obviously not be backward compatible.

Discussion

Competing SEPs

None.

References

Copyright

CC0
To the extent possible under law, SBOL developers has waived all copyright and related or neighboring rights to SEP 035. This work is published from: United States.