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

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

From: Michael F Uschold <uschold@gmail.com>
Date: Tue, 14 Feb 2017 08:42:16 -0800
Message-ID: <CADfiEMOU-oC5tHNYzw+97yqqLDM1rOeOTXXWrUzhA9sDr5m5bg@mail.gmail.com>
To: Martin Hepp <mfhepp@gmail.com>
Cc: "Munson J.E." <J.Munson@soton.ac.uk>, "semantic-web@w3.org" <semantic-web@w3.org>, "Thuermer G." <gefion.thuermer@soton.ac.uk>, Dennis Wisnosky <dennis@wisnosky.net>, Anthony Coates <abcoates@contakt.org>
The different ordering of statements used by different tools is indeed a
problem. The FIBO  team has developed a serializer for this reason. It
works this way:

   1. Authors create ontologies using any tool they like e.g. (Protégé,
   TBC, emacs) and export to RDF/XML
   2. When the do a commit, the serializer code runs that is in the git
   hooks folder runs automatically in the background. It exports whatever mess
   it got from the author's tool of choice and converts it to a standard
   output serialization.
   3. After the commit, you can compare the files in git just as if all the
   humans agreed to used the exact same ordering and conventions.

There were significant challenges getting this to work, especially with
blank nodes, and there are a few kinks still being worked out, but it works
great for the most part and solves a significant problem.  It is available
for use.

Contact Anthony Coates <abcoates@contakt.org> for more information.

On Mon, Jan 30, 2017 at 12:32 AM, Martin Hepp <mfhepp@gmail.com> wrote:

> 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#
>
> and
> - 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
>
>     https://scholar.google.com/scholar?hl=en&q=ontology+
> versioning&btnG=&as_sdt=1%2C5&as_sdtp=
>
> 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.
>
>     http://link.springer.com/article/10.1007%2Fs10115-003-0137-2?LI=true
>
> 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
>
>
>
> -----------------------------------
> 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
> >
> >
> >
> >
> >
> >
> >
>
>
>


-- 

Michael Uschold
   Senior Ontology Consultant, Semantic Arts
   http://www.semanticarts.com
   LinkedIn: www.linkedin.com/in/michaeluschold
   Skype, Twitter: UscholdM
Received on Tuesday, 14 February 2017 16:42:54 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:49 UTC