Skip to content

Latest commit

 

History

History
125 lines (78 loc) · 6.84 KB

sep_042.md

File metadata and controls

125 lines (78 loc) · 6.84 KB
Raw

SEP 042 -- Make Interfaces Explicit

SEP
Title Make Interfaces Explicit
Authors Jacob Beal ([email protected])
Editor
Type Data Model
SBOL Version 3.0
Replaces
Status Accepted
Created 22-Jan-2020
Last modified 22-Jan-2020
Issue #90

Abstract

Information about the recommended interface for a component/module is currently dispersed into the "access" field of ComponentInstance and the "direction" field of FunctionalComponent. This makes the interfaces implicit rather than explicit, scatters the information, and forces premature definition of information about interfaces. This SEP proposes instead collecting the same information into an explicit "Interface" object.

1. Rationale

Information about the recommended interface for a component/module is currently dispersed into the "access" field of ComponentInstance and the "direction" field of FunctionalComponent.

This creates three problems:

  1. Interfaces are declared implicitly rather than explicitly.
  2. Information about an interface is scattered through many different locations, such that it cannot be readily retrieved with a query.
  3. Because "access" and "direction" fields are required, a person is forced to declare information about interfaces immediately upon creation of any ComponentInstance object, even if doing so is premature.

Accordingly, this SEP proposes to instead collect the same information into an explicit "Interface" object.

Note that this SEP assumes that ComponentDefinition and ModuleDefinition will be merged, per SEP 041 or SEP 025. The name "component/module" is used to refer to the class resulting from this merger, whatever its ultimate name might be.

Note that we reference SubComponent for SBOL 3 and ComponentInstance for SBOL 2.

2. Specification

Interface Class

A new class will be added, called Interface, as a subclass of Identified (i.e., it is not a TopLevel, but a child of a component/module).

Interface has three non-inherited properties:

  • input [0..*]: references to a set of SubComponent objects in the same component/module
  • output [0..*]: references to a set of SubComponent objects in the same component/module
  • nondirectional [0..*]: references to a set of SubComponent objects in the same component/module

A SubComponent MUST NOT appear in more than one of these sets: i.e., if something is both an input and an output, then it is nondirectional.

Note that "nondirectional" is suggested rather than "bidirectional" because that word can mean both bidirectional flows and situations where there is no flow per se (e.g., a physical interface).

Changes to SubComponent

The "access" and "direction" properties will be removed from SubComponent and FunctionalComponent, along with all information about these properties.

Changes to Component/Module

The component/module class will have an optional "interface" property added (cardinality 0-1) that refers to an Interface object.

3. Examples

A simple promoter

A simple stand-alone promoter might have no defined Interface at all, as it is just a DNA part without intended functional relationships.

Gander et al. NOR gate

This component/module has four SubComponents: two gRNA inputs, the DNA component that they regulate (comprising two binding sites, a promoter, and a gRNA coding sequence), and the gRNA output.

It would be given an Interface with two input relations (to the input gRNA SubComponents) and one output relation (to the output gRNA SubComponent).

4. Backwards Compatibility

There is a bidirectional mapping from an Interface to a set of "access" and "direction" properties. It will only lose information for FunctionalComponents that have inputs and outputs that are "private", which should not generally happen (i.e., if it's an input or output, it should be part of the public interface).

From SBOL 2 to SBOL 3:

  • For converting from a ModuleDefinition, every FunctionalComponent with a "direction" property that is not "none" is listed in the Interface object (if there are no such, don't create an Interface). The mapping from direction to interface properties is: "in"-->"inputs", "out"-->"outputs", "inout" --> "nondirectional". Finally, every Component with "access"="public" and "direction"="none" is listed as "nondirectional" in the Interface.

  • For converting from a ComponentDefinition, every Component with "access"="public" is listed as "nondirectional" in the Interface.

From SBOL 3 to SBOL 2, every ComponentInstance gets "access"="private" and "direction"="none" (if a FunctionalComponent) unless there is an interface object and it is listed in the Interface object. All elements listed in the interface get "access"="public". If a FunctionalComponent, it also gets a direction corresponding to its set: "inputs"-->"in", "outputs"-->"out", "nondirectional"-->"inout".

Future option: multiple interfaces

The current proposal provides for precisely one interface.

It is possible that in the future multiple interfaces will be judged to be desirable. If so, the cardinality can be changed from [0..1] to [0..*] as a minor revision. Multiple interfaces, however, cannot be correctly translated back down to SBOL 2.

Future option: additional types of interface

This SEP assumes that the number of different types of interface is limited to just the directionalities. If for some reason there is need to expand this significantly in the future, it could be done by changing to a reified description class similar to Participation. This would require a major version change, but there is currently no expectation this is likely to be needed.

5. Discussion

6. Relation to Other SEPs

This SEP assumes that ComponentDefinition and ModuleDefinition will be merged, per SEP 025 or SEP 041.

There are no SEPs competing with this SEP at present.

Copyright

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