W3C home > Mailing lists > Public > semantic-web@w3.org > January 2017

Re: Best practices for versioning and documenting ontologies for Sem Web

From: Martin Hepp <mfhepp@gmail.com>
Date: Mon, 30 Jan 2017 09:32:01 +0100
Cc: "semantic-web@w3.org" <semantic-web@w3.org>, "Thuermer G." <gefion.thuermer@soton.ac.uk>
Message-Id: <59BDA4B6-C7C2-471B-A686-4991C216C124@gmail.com>
To: "Munson J.E." <J.Munson@soton.ac.uk>
I would recommend using

1. a syntax for the ontology like N3/Turtle where changes in the conceptual model are more or less directly equivalent to changes in the serialization. A bad example would be RDF/XML auto-generated from a tool like Protégé. At least in earlier times, the serialization in RDF/XML could vary greatly despite only minor changes in the conceptual model, in particular if you  used different versions of the tool to generate the code.

The underlying reason is that RDF has no defined ordering of statements, so there are many different ways to represent the same RDF graph.

2. a standard version-control system like Git or Mercurial for hosting the code.

This allows a very good documentation of the entire evolution of your model, and this is how we do it at schema.org.

There are a few problems with this approach, though:

1. You will have to encode the ontology using a source-code editior - no neat GUI etc. While this is straightforward for basic RDFS/OWL ontologies, it is a bit complicated for advanced OWL language elements.

2. If you reorganize the code or make minor syntactical changes (like replacing spaces by tabs or vice versa), you will still see changes in a diff that do not reflect changes in the conceptual model, so you need to be very disciplined when coding.

But other than that, I think this is the best way to solve this.

For publishing versions of the ontology, you could use the same mechanism as the W3C for versioning technical documents, i.e.

- one URI for the current version, like

http://foo.org/onto or http://foo.org/onto#

- one URI for each released version, including the date of the release, like

http://foo.org/onto/20170130 or http://foo.org/onto/20170130#

There are of course many proposals to handle ontology versioning with additional meta-data and tooling; for an overview, see


From my top-level understanding, however, the current state of the art is limited to maintaining meta-data about the state and evolution of the ontology, while automatic translation between different versions of the same ontology is still very hard. For the pure documentation of the changes, a version-control system does mainly the same job.

For an introduction to the problems towards ontology versioning and evolution, read e.g.


Also keep in mind that ontologies are by their very nature approximate specifications of a domain model, so there can be changes in the intended meaning of ontology elements that are not reflected in the axiomatic specification of the ontology.

Best wishes


martin hepp  http://www.heppnetz.de
mhepp@computer.org          @mfhepp

> On 30 Jan 2017, at 00:19, Munson J.E. <J.Munson@soton.ac.uk> wrote:
> Dear team
> My name is Jo Munson and I am currently a PhD candidate at the University of Southampton.
> We are currently working with an external organisation looking to put a 'real life' ontology together and am writing to ask whether there are any tools / best practices for
> versioning and documenting from your perspective (for commercial/public use, not just in a research context).
> Many thanks for your time
> Jo
> Web Science PhD Candidate
> University of Southampton
Received on Monday, 30 January 2017 08:32:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 30 January 2017 08:32:40 UTC