Skip to content

Latest commit

 

History

History
120 lines (82 loc) · 5.94 KB

sep_038.md

File metadata and controls

120 lines (82 loc) · 5.94 KB

SEP 038 -- SBOL3 Identity and URIs

SEP 037
Title SBOL3 Identity URIs
Authors Jacob Beal ([email protected])
Editor Hasan Baig
Type Data Model
SBOL Version 3.0
Replaces
Status Accepted
Issue #85
Created 22-Nov-2019
Last modified

Abstract

This SEP proposes to modify the relationship between Identified objects and URIs to simplify name management and to disentangle object identity from knowledge graph versioning.

Motivation

URIs in SBOL 2 have several problems:

  • URIs are too unconstrained, yet compliance is confusing
  • Version location in URIs causes trouble with RDF tooling
  • URI-suffix versioning is too granular (at object level, when changes are often made across many objects in a design) but also too contagious (changing an object version requires making duplicate copies of everything that points to it as well).
  • URI "flattening" is encouraged (e.g., in the current implementation of SynBioHub), which makes name conflicts more difficult to avoid.

Specification

Identified

Remove the persistentIdentity and version fields.

NameSpace

The new NameSpace object makes a space of disjoint prefixes explicit. This object has two fields:

  • identity[1]: URI for the object. MUST NOT match any other known NameSpace [identity]/*
  • members [0..n]: optional links to all known TopLevel objects in the name-space. All linked objects must have a URI prefix matching that of the NameSpace.

Membership of objects in a NameSpace is recommended but not required.

Required URI Structure

Required identity URL structure for all cases where a URI is a URL:

  • TopLevel: [namespace]/[local]/[displayId] May not match any other [TopLevel]/*
  • Child: [parent]/[displayId] Multiple layers of Child objects are allowed.

Since displayId values are restricted to alphanumeric and underscores, they will never include delimiters such as '#', ':', and '/'."

Note that this explicitly allows URIs (such as UUIDs) for which a namespace would not be well defined, since these are not strictly URLs.

Recommended ("Compliant") URI Structure

  • TopLevel: [domain]/[root]/[collection structure]/[displayId]
  • Child: [parent]/[ChildType][ChildTypeCounter]
    • (e.g., [parent]/SequenceAnnotation37)
    • A new child gets max(ChildTypeCounter for class in parent object)+1
    • Note that numbering is independent for each type, so you can have both SubComponent37 and SequenceConstraint37.

Approaches to versioning are explicitly not specified, being left for experimentation across different tools. This allows version information to be included in the root (e.g., GitHub style: "igem/HEAD/"), collection structure (e.g., "promoters/constitutive/2/"), in tool-specific conventions on displayId (e.g., "BBa_J23101_v2") or in information outside of the URI (e.g., by attaching custom version properties).

Backwards Compatibility

Identified objects under the proposed change will have field values and URIs legal under SBOL 2 as well. URIs will not be compliant, but can be transformed into compliant URIs by adding '/1' for version 1.

SBOL 2 Identified objects can be converted to match SBOL 3 requirements by discarding their persistentIdentity and version fields. Compliant URIs can be converted by using persistentIdentity for version 1 objects. Objects with other versions are extremely rare and could be handled in one of two ways:

  • Append the version into the name (e.g., "-version-[version]"), probably giving a warning of potential conflict.
  • Throw a conversion exception and request that the user rename and reversion manually.

NameSpace objects are new, and thus have no backwards compatibility issue.

Discussion

Version information was originally proposed to be part of the compliant URI structure, but has been dropped as being constraining on the experimentation with versioning that this SEP aims to enable in tooling.

The requirement only applies to URLs, since there are some other classes of URIs (e.g., UUIDs) that we want to allow, but which don't need to be restricted in their structure.

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