Skip to content

Latest commit

 

History

History
123 lines (78 loc) · 8.11 KB

sep_044.md

File metadata and controls

123 lines (78 loc) · 8.11 KB
Raw

SEP 044 -- Unify Structural Information

SEP
Title Unify Structural Information
Authors Jacob Beal ([email protected])
Editor
Type Data Model
SBOL Version 3.0
Replaces
Status Accepted
Issue #92
Created 25-Jan-2020
Last modified 6-Feb-2020

Abstract

Currently, information about the physical structure of a Component is dispersed across three different places: Locations hold geometric information, while Constraints and Interactions of type Containment hold topological information. This SEP proposes to unify the two types of topological information by adding a set of values for standard topological constraints.

1. Rationale

At present, we have multiple different ways of representing the physical structure of a Component, all located in different places:

  • The exact geometric location of sub-sequences for a Component within a Sequence is expressed via Locations on SubComponents or SequenceFeatures.
  • The ordering of SubComponents in a linear structure is expressed with the constraint property of a Component.
  • The topological containment of one SubComponent within another is expressed with an Interaction of type containment (SBO:0000469).

Following the adoption of SEP 025, both types of topological information are within the same Component class, so there is no reason to continue to keep them separated. Accordingly, this SEP proposes to dispense with containment via Interactions and add a set of values for standard topological constraints.

It is also that case that while every type of Component has geometric or topological structure of interest, many do not have a linear/sequential structure, so the sequenceFeatures property would be better to rename to features, in anticipation of potential future expansion from SequenceFeature to an abstract Feature class that can annotate contextual features on objects without sequential structure.

2. Specification

Rename Component sequenceFeature property to feature

The sequenceFeature property of Component is renamed to the more generic feature.

The SequenceFeature class is explicitly not renamed, as the intention is to allow future creation of an abstract Feature class that will cover both SequenceFeature and a number of sibling classes.

Topological Constraint values

To the existing RECOMMENDED restriction values for the Constraint class, we add a new collection that deals with the spatial relationships of physical objects in general, rather than the special case of directional linear sequences.

These values are based on the set of eight possible topological relationships between two spatial regions without holes [1]. Of these, we derive a set of seven restrictions:

  • Two relationships are omitted as redundant: inside and coveredBy are respectively equivalent to strictlyContains and covers with subject and object swapped.
  • We include a common union relationship, contains, meaning either strictlyContains or covers.
  • The symmetric equal relationship is changed to an asymmetric replaces relationship, allowing resolution of potentially conflicting definitions.
Restriction URI Description
http://sbols.org/v2#disjoint subject and object do not overlap in space. Example: a plasmid is disjoint from a chromosome.
http://sbols.org/v2#strictlyContains subject entirely contains object: they do not share a boundary. Example: a cell contains a plasmid
http://sbols.org/v2#contains subject contains object and they might or might not share a boundary. Example: a cell contains a protein that may or may not bind to its membrane.
http://sbols.org/v2#replaces subject and object occupy the same in space, . Example: the J23101 promoter replaces a generic promoter
http://sbols.org/v2#meets subject and object are connected at a shared boundary. Example: two strains of adherent cells meet at their membranes
http://sbols.org/v2#covers subject contains object but also shares a boundary. Example: a cell covers its transmembrane proteins.
http://sbols.org/v2#overlaps subject and object overlap in space, but portions of each are outside of the other. Example: a transmembrane protein overlaps the cell membrane

Note that in most cases, disjoint is the expected default and does not need to be explicitly expressed.

[1] Egenhofer, M. J. and Herring, J. 1991. "Categorizing binary topological relationships between regions, lines, and points in geographic databases", Technical Report, Department of Surveying Engineering University of Maine.

Non-Recommendation of Containment Interaction

SEP 030 recommends using an Interaction of type containment (SBO:0000469) to represent topological containment. Introduction of the new constraint values renders this obsolete, so this recommentation will be deleted.

The optional use of a physical compartment (SBO:0000290) role to explicitly specify where an Interaction is taking place, however, is still valid.

3. Examples

See above examples in the table of restrictions.

4. Backwards Compatibility

No conversion is strictly needed, as the SBOL 2 relations are still valid in SBOL 3 and the additional relations are allowed in SBOL 2.

However, as a recommended practice, any Interaction of type containment SHOULD be changed to a set of Constraint objects with restriction contains, one for each pair of Participant objects with roles physical compartment (mapping to subject) and contained (mapping to object).

5. Discussion

An enhancement to consider is that Location might be renamed to SequenceLocation since the Location class describes only locations on Sequence objects, not other types of geometric locations. We do not yet have a second type of location information proposed, however, so it is not clear whether this would be useful.

It is also an interesting question whether an analogous transformation or should be made to the location and sourceLocation properties of ComponentInstance. Right now, these only refer to sequences, which makes them dubious, but if Location becomes generalized, then it would be good to keep these properties just as they are.

Previously, this SEP recommended creating a separate class for topological constraints and merging the classes under a new abstract superclass. Since SequenceConstraint is being generalized to Constraint by SEP 037, however, this was judged in discussion to be introducing complexity without value and discarded.

6. Relation to Other SEPs

This SEP is written taking into account the adoption of SEP 025, merging ComponentDefinition and ModuleDefinition into Component, and SEP 010, renaming SequenceAnnotation to SequenceFeature.

This SEP assumes that SEP 037 will be adopted, renaming SequenceConstraint to Constraint.

Some of the constraint names here overlap with SEP 045. If both are adopted, then their descriptions will be merged, clarifying how they are to be interpreted in ordered vs. non-ordered objects.

Copyright

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