Skip to content

Latest commit

 

History

History
127 lines (83 loc) · 6.3 KB

sep_037.md

File metadata and controls

127 lines (83 loc) · 6.3 KB
Raw

SEP 037 -- Component References

SEP 037
Title Component References
Authors Jacob Beal (jakebeal@ieee.org)
Editor James McLaughlin
Type Data Model
SBOL Version 2.4
Replaces
Status Draft
Created 14-July-2019
Last modified

Abstract

This SEP proposes a ComponentReference object that allows a ComponentInstance to be referenced through children, rather than requiring it to be imported as an immediate child of the containing ComponentDefinition or ModuleDefinition. A new ComponentEquivalence class then takes advantage of this to eliminate the need for MapsTo when linking equivalent components.

Motivation

In the current model, a ComponentDefinition or ModuleDefinition that wants to reference an ComponentInstance inside one of its children must import a copy from the child and link the two of them together with a MapsTo. This is problematic in at least two ways:

  1. This creates extra "duplicate" ComponentInstance objects that are confusing and offer extra opportunities for contradictory information to be added.
  2. A MapsTo can only reach one level deep, so in order to refer more than one layer, the child definition must be modified as well.

This comes up in two cases: Interactions (in particular, the participant property of Participation), and linking equivalent objects via MapsTo (e.g., when instantiating an abstract component).

This figure shows example of one-layer being required in order to instantiate a genetic production relationship from a CDS in a constitutive expression construct, in which both a MapsTo and a FunctionalComponent must be created: examples

Here is an example of a two-layer reference, in which two MapsTo objects and two FunctionalComponents must be created, problematically requiring modification to the I13504 object: examples

Similar problems occur when linking equivalent objects via MapsTo, as shown in this figure: examples

Specification

ComponentReference

A ComponentReference object provides access to ComponentInstance objects that are contained within the children of a ComponentDefinition or ModuleDefinition. Its fields are:

  • inChildOf[1] : URI for a ComponentInstance
  • componentInstance[0..1] : URI for a ComponentInstance
  • componentReference[0..1] : URI for a ComponentReference

The validation rules are:

  • inChildOf must refer to a ComponentInstance pointed directly to by the parent of the ComponentReference (i.e., as a component or ComponentDefinition, a functionalComponent of ModuleDefinition, or an inChildOf of ComponentReference)
  • Preciselty one of componentInstance and componentReference must be defined.
  • If componentInstance is defined, then it must be a child of the ComponentInstance pointed to by inChildOf

Examples of using ComponentReference: examples examples

ComponentEquivalence

A ComponentEquivalence object allows for linking of ComponentInstance objects that refer to the "same" part of a design. Its fields are:

  • refinement[1] : URI, either sbol#verifyIdentical or sbol#merge (from Table 7, MapsTo refinements)
  • component[0..n] : URI for a ComponentInstanceOrReference (see below)

The set of objects in the component field are treated just like they were all linked pairwise by MapsTo local and remote properties.

Example of using ComponentEquivalence: examples

Adjusted fields for ComponentDefinition, ModuleDefinition, and Participation

Everywhere that we can currently refer to a ComponentInstance, we adjust to instead refer to either a ComponentInstance or a ComponentReference. This can be done in one of two ways:

  1. Create a "union" superclass, ComponentInstanceOrReference that covers both ComponentInstance and ComponentReference.
  2. Wherever we can refer to a ComponentInstance, create a second field that can refer to a ComponentReference instead.

The first is recommended as the approach to be adopted, as an "empty" union class is not particularly problematic, yet will make reasoning about cardinalities much simpler.

Deprecation of MapsTo

The MapsTo class is made obsolete by ComponentReference and ComponentEquivalence. as nearly every MapsTo relationship can be transformed into an equivalent set of ComponentReference and ComponentEquivalence relationships.

The only exceptions are MapsTo objects that use the useRemote or useLocal values, since they are asymmetric, and ComponentEquivalence is not. Since these are rarely used, however, their loss is not anticipated to be a problem.

As such, MapsTo is deprecated, for removal in SBOL 3.

Backwards Compatibility

The immediate changes proposed by this SEP are all backward compatible, as they only add material and do not take anything away. During a transition to use of ComponentReference, dual values for MapsTo can be generated as needed.

When SBOL 3 is adopted, MapsTo will be removed, which is obviously not backward compatible.

Discussion

to be recorded

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 037. This work is published from: United States.