Skip to content

Latest commit

 

History

History
100 lines (71 loc) · 4.8 KB

sep_047.md

File metadata and controls

100 lines (71 loc) · 4.8 KB
Raw

SEP 047 -- Change direction of Namespace references

SEP
Title Change direction of Namespace references
Authors Jake Beal (jakebeal@gmail.com)
Editor James McLaughlin (james@mclgh.net)
Type Data Model
SBOL Version SBOL 3.0.1
Replaces
Status Accepted
Created 16-July-2020
Last modified 19-July-2020
Issue #102

Abstract

SBOL 3.0 set up Namespace to point to objects, which will tend to make Namespace objects extremely large. Instead, objects should point to their Namespace. This SEP proposes to reverse the direction of the relationship.

1. Rationale

In SBOL 3.0, we introduced the concept of a Namespace, which facilitates URI rewriting. During implementation, we realized that it would be useful to make the relationship between a Namespace and an TopLevel object in that Namespace explicit.

As the concept is having TopLevels in Namespaces, we implemented this by having Namespace be a subclass of Collection, with its members being an inventory of the TopLevels in the namespace.

Pragmatically, however, this was a mistake. This will make Namespace objects very large and require them to be updated whenever a new object is added to the Namespace. It will also make it impossible to directly verify if an object is assigned to a Namespace or not, as an object can be created without reference in a Namespace.

This can be readily amended by changing the membership to point the other way, with Namespace just being a placeholder TopLevel, and every TopLevel being required to point to a Namespace.

Notes:

  • There will be no additional storage cost for this proposal: a link between Namespace and TopLevel will still require precisely one triple. The only difference is how this triple is conceived of in relationship to objects.

  • A potential alternative would be to put the link on Identified instead of TopLevel. All Identified objects that are not TopLevel objects, however, are child objects, which are already required to inherit their Namespace from their parent. Thus, putting the link to Namespace on Identified would be redundant.

  • The Namespace convention is REQUIRED even for objects whose URI are not URLs. This is because otherwise it is not possible to convert such an SBOL object into one that does use URLs.

2. Specification

Change to Namespace

The Namespace object will no longer be a subclass of Collection. Instead, it will be a subclass of TopLevel, with no members property.

Change to TopLevel

The TopLevel object will have a new hasNamespace property that is REQUIRED and points to a Namespace object.

Change to SBOL 2->3 Conversion

When converting an SBOL 2.x document to SBOL 3, the Namespace should be handled as follows:

  1. When possible, conversion SHOULD explicitly supply one or more Namespaces for conversion.
  2. If Namespaces are not supplied, then they should be inferred based on the most common URL prefixes in TopLevel objects. At a minimum, this should result in one Namespace per server URL.
  3. If an SBOL 2 object does not use URLs, then Namespace information cannot be inferred and MUST be supplied.

There is no change when converting from SBOL 3 to SBOL 2: Namespace information is still simply discarded.

3. Example or Use Case

4. Backwards Compatibility

This is not backward compatible with the current state of SBOL 3.0, and thus needs to be adopted before the first SBOL 3 implementations are complete.

5. Discussion

6. Competing SEPs

None.

References

None.

Copyright

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