W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > January 2017

Re: Ontologies versioning?

From: Stian Soiland-Reyes <soiland-reyes@manchester.ac.uk>
Date: Thu, 26 Jan 2017 11:15:48 +0000
Message-ID: <20170126111548.GH4798@biggiebuntu>
To: HCLS <public-semweb-lifesci@w3.org>
On Mon, 23 Jan 2017 08:34:46 -0800, Chris Mungall <cjmungall@lbl.gov> wrote:
> Yes, most OBO ontologies derive the version from the ISO-8601 of the 
> date. This is used in the versionIRI, e.g. 
> /obo/releases/YYYY-MM-DD/<artifact> and often in things like github 
> releases tags. See for example:
> https://github.com/EnvironmentOntology/envo/releases
> I like semver for software and can see it working well for schema-type 
> ontologies and upper ontologies.

Agreed, ISO8601-dates makes more sense for database-like knowledge ontologies
(where our understanding of the real world can change under out feet!), and
semver-versions for schema-like ontologies.

It might still make sense for knowledge ontologies to indicate a major version
that corresponds to which schema it is using (in a rough sense) - e.g. an
ontologies describing species could have:

 owl:versionIRI "2.20160529.0"

which could be replaced by a newer:

 owl:versionIRI "3.20160602.0"

Here 3.x indicates that even though the ontology is just a few days older, it
is incompatible in its structure to the former - e.g. your old queries will
most likely break - say it is now using a different upper ontology or schema to
describe relationships between species.  Moving :Dolphin from :SeaCreatures to
:Mammals however would just be an update to the minor version.

(This still complies with semantic versioning, btw - I would keep the patch
version starting with .0, so you can increment it when you 'broke some tiny
thing' in packaging the dated release and need to "re-release".  You know it
can happen!)

Stian Soiland-Reyes
University of Manchester
Received on Thursday, 26 January 2017 11:16:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:22:01 UTC