Skip to content

Latest commit

 

History

History
99 lines (63 loc) · 4.8 KB

sep_032.md

File metadata and controls

99 lines (63 loc) · 4.8 KB
Raw

SEP 032 -- Do not rename ontologicially defined predicates

SEP 032
Title Do not rename ontologically defined predicates
Authors James Alastair McLaughlin (j.a.mclaughlin@ncl.ac.uk)
Editor
Type Data Model
SBOL Version 3
Replaces
Status Draft
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 already accepted dcterms:title and dcterms:description properties from the Dublin Core ontology. This makes a lot of sense: rather than attempting to define everything from scratch, SBOL builds on decades of semantic web research in creating ontological definitions.

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"

SBOL is likely to adopt new ontologies in the future, and this process should be as easy as possible. Aligning the SBOL specification as closely as possible with the ontologies it references, therefore, is desirable.

Specification

Properties renamed from their respective ontologies, e.g. "name", are changed back to their original names e.g. "title". Statements such as:

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

would be changed to

The title property is OPTIONAL and has a data type of String. It is defined by the Dublin Core ontology and is located in the dcterms namespace.

with a link to the respective ontology. Statements describing "sets" such as:

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

would be changed to more abstract data model definitions such as:

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.