Skip to content

Latest commit

 

History

History
91 lines (59 loc) · 4.27 KB

sep_032.md

File metadata and controls

91 lines (59 loc) · 4.27 KB

SEP 032 -- Do not rename ontologicially defined predicates

SEP 032
Title Do not rename ontologically defined predicates
Authors James Alastair McLaughlin ([email protected])
Editor Hasan Baig
Type Data Model
SBOL Version 3
Replaces
Status Accepted
Issue #74
Created 07-Dec-2019
Last modified 07-Dec-2019

Abstract

SBOL uses many terms from existing ontologies, such as Dublin Core and Prov-O. Currently, the specification is written in a manner such that those terms are given a new "SBOL alias" sometimes, but not always, distinct from the name assigned to them by the ontology. This SEP proposes that the name assigned by the ontology is always used.

Motivation

The SBOL specification intentionally uses terms from existing ontologies where appropriate. For example, instead of SBOL defining the concept of a "title" or "description", it instead uses the dcterms:title and dcterms:description properties from the Dublin Core ontology. However, in the way that the SBOL specification is written, each ontology term first has to be given an "SBOL alias". For example, the dcterms:title property is first introduced as "name":

The name property is OPTIONAL and has a data type of String.

And then later "mapped" to an ontology term in the "Serialization" section:

name is serialized as dcterms:title

This approach has a number of issues:

  • It assumes the SBOL is being serialized at all. In the days of SBOL1 this may have been the case, but with SBOL2 the SBOL is often contained in triplestores (e.g. synbiohub) and queried using SPARQL queries. In this case, there is no "name" alias but only "dcterms:title".
  • It makes serialized SBOL extremely confusing to read, because the ontologically-defined names used in the serialization do not match the specification-defined names used by SBOL libraries
  • As we have adopted new ontologies, it has resulted in clunky names for properties. For example, SBOL renames the prov:wasDerivedFrom property to "wasDerivedFroms" for consistency with other aliases used in the specification.
  • It means that integrating terms from other ontologies requires a two-step process of writing their description as SBOL "aliases" and then writing their "serialization"

Specification

The dcterms:title and dcterms:description properties are replaced with sbol:name and sbol:description.

Statements describing terms from other ontologies including those renamed by SBOL to define "sets" such as:

The wasDerivedFroms property is OPTIONAL and MAY specify a set of URIs.

would be changed to no longer rename the predicate and to provide attribution to their corresponding ontology:

The wasDerivedFrom property is OPTIONAL and MAY be used to specify one or more URIs. It is defined by the Prov-O ontology and is located in the prov namespace.

Backwards Compatibility

This SEP would only change specification wording; serialization would remain identical, and is therefore fully forwards and backwards compatible. However, as it is a widespread change to the wording of the specification it has been provisionally grouped with the SBOL3 SEPs.

Discussion

5.1 Related SEPs

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