Skip to content

Latest commit

 

History

History
147 lines (117 loc) · 7.44 KB

sep_027.md

File metadata and controls

147 lines (117 loc) · 7.44 KB
Raw

SEP 027 -- Adding a type field to Activity class

SEP 25
Title Adding a "type" field to Activity class
Authors Ernst Oberortner ([email protected]), Bryan Bartley ([email protected])
Editor Curtis Madsen ([email protected])
Type
SBOL Version <2.3.0>
Replaces
Status Accepted
Created 20-Jun-2018
Last modified 20-Jun-2018
Issue #25

Abstract

In SBOL 2.2.1, the type of a provenance Activity must be inferred via the roles properties of its associated Usage objects. This solution does not enable to explicitly specify the type of an Activity, making it hard to reason or communicate the type of the Activity that transforms Usage objects into wasGeneratedBys Identified objects.

Table of Contents

1. Rationale

SBOL 2.3.0 should enable the explicit specification of the type of a provenance Activity. Previously, SBOL 2.2.1 introduced ontology terms for classification of Activities into the following categories: "design", "build", "test", and "learn". However, this approach is rather indirect in its implementation. The type of an Activity must be inferred indirectly by interpreting terms placed on Usage and Association utility classes. We propose to explicitly label an Activity with a types field. This approach has advantages for future representation of a broader set of Activities, as well as matching how SBOL developers actually describe and think about Activities in practice. In the future, we imagine that ontology-based implementations of SBOL will become more common, and a rich ontology of Activities that include subtypes of "design", "build", "test", and "learn" should become available to users. In the near-term, adopting this approach will also make searching for Activities easier as well. For example, a lab user will be able to easily query the "build" history of a construct without concern for other types of provenance outside their area of expertise, such as modeling.

2. Specification

We propose to add the field types to the Activity class. If the type of the Activity is specified, then the type must refer to a URI, which is ideally an ontology term.

class Activity:
    types [0..*] : URI

Users may define their own types terms though the recommended terms , in accordance with SEP 19, are as follows:

  • http://sbols.org/v2#design describes a process by which a conceptual representation of an engineer's imagined and intended design is derived, possibly from a model or pre-existing design.
  • http://sbols.org/v2#build describes a process by which a sample is derived in accordance with a conceptual design, often from other samples.
  • http://sbols.org/v2#test describes a process by which raw data or observations are derived via experimental measurement of samples.
  • http://sbols.org/v2#learn describes a process by which a theoretical model, analysis, datasheet, etc. is derived, usually from experimental data or another model.

Validation Rules

  • If an Activity has a types value of http://sbols.org/v2#design and also contains an Association, then that Association MUST have a roles value of http://sbols.org/v2#design
  • If an Activity has a types value of http://sbols.org/v2#build and also contains an Association, then that Association MUST have a roles value of http://sbols.org/v2#build
  • If an Activity has a types value of http://sbols.org/v2#test and also contains an Association, then that Association MUST have a roles value of http://sbols.org/v2#test
  • If an Activity has a types value of http://sbols.org/v2#learn and also contains an Association, then that Association MUST have a roles value of http://sbols.org/v2#learn

3. Example or Use Case

In SBOL 2.2.1, a design-to-build transition of a ComponentDefinition is done as follows:

ComponentDefinition:
    id: CD
    type: CDS

Activity:
    id: Build_Activity
    qualifiedUsages:
        Usage: 
            entity: CD
            roles: http://sbols.org/v2#build 

Implementation:
    id: Impl
    built: CD
    wasGeneratedBy: Build_Activity

According to SBOL 2.2.1, in this example

  • it is not explicitly stated that the Build_Activity represents the actual build process of the designed CD component.
  • the Build_Activity is optional

Our proposed solution would look like as follows in SBOL 2.3.0, in order to encode the design-to-build transition:

ComponentDefinition:
    id: CD
    type: CDS

Activity:
    id: Build_Activity
    type: http://sbols.org/v2#build
    qualifiedUsages:
        Usage: 
            entity: CD
            role: http://sbols.org/v2#design 

Implementation:
    id: Impl
    built: CD
    wasGeneratedBy: Build_Activity

In this example, we now

  • explicity specify that the Build_Activity activity is of type http://sbols.org/v2#build, which is a term defined in the SBOL specification.
  • specify that the CD is the designed component (role: http://sbols.org/v2#design) that is being transformed into an Implementation by the Build_Activity activity
  • keep the specification of the Build_Activity still optional

4. Backwards Compatibility

Since the proposed type field is optional ([0..*]), there are no issues regarding backwards compatibility.

5. Discussion

6. Competing SEPs

There are no competing SEPs.

A possible criticism with this approach is that it introduces redundant terms on Association:roles and Activity:types. However, Associations are not a required class which can lead to ambiguous cases when the Association is not specified. Specifying an Activity:types can resolve these ambiguities. Furthermore, this specification intends to be an intermediate stage of development that will lead to a rich ontology of Activity:types, Usage:roles, and Association:roles.

Copyright

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