W3C home > Mailing lists > Public > public-lod@w3.org > June 2012

Re: Evolving vocabularies

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Date: Wed, 27 Jun 2012 12:36:10 -0400
Message-ID: <CAFKQJ8k-8krhG=Ev83BAAtZdxbSRKFPjbMCS58DMrej4vg3Ztg@mail.gmail.com>
To: Carsten Keßler <carsten.kessler@uni-muenster.de>
Cc: public-lod@w3.org, Chad Hendrix <hendrix@un.org>, perrin.v@gmail.com
The gene ontology, and more recently OBI and other OBO Foundry
ontologies, have a well established policy on how to handle this.
Roughly, terms are updated only if their intended referent does not
change. So fixes to clarify or remove ambiguity, or to fix logical
axioms are fine as long as the change is not to make the term mean
something different.

If a term is found to be broken - it doesn't refer well, or it doesn't
refer to something one wants to refer to, it can be obsoleted with
notice and change for commentary from the community of users. URIs for
such terms are marked as so, but not removed "cool uris, etc".

Periodic release are made. At each release there is a dated PURL for
the ontology as a whole. The "latest" version URI is then updated to
point to this version. The versionIRI records the URI of the version.
Clients can then choose to import the latest version of an ontology or
a particular version depending on their needs.

You might have a look at
- http://obofoundry.org/id-policy.shtml
- http://obi-ontology.org/page/OBI_ID_Policy

I see you like having readable URIs. I don't want to start a general
discussion of this (again) but I will say that we have decided that
there are longer legs to opaque numerical ids and that you might want
to consider that.

I also note that you are embedding a date in the URIs for a term.
Based on experience in a number of projects we've come to the
conclusion that this makes life unpleasant for users and so avoid it.

Finally, making the deprecation policy explicit and known to your
users, and stating when it will start taking effect is helpful. In the
case of OBI we said we would institute the policy once our first
release candidate was released. Before that we made no guarantee that
terms would remain stable or that they would not disappear, though we
did ensure that an ID was never reused, even if it was removed during
that stage.


On Wed, Jun 27, 2012 at 4:11 AM, Carsten Keßler
<carsten.kessler@uni-muenster.de> wrote:
> Dear LODers,
> I have already bugged this list with our Humanitarian eXchange Language project a couple times, and I'd like to hear your opinion on the following problem.
> We are constantly working on the vocabulary (see http://hxl.humanitarianresponse.info/ for the latest version), so it gets revised fairly often, sometimes several times a week. While we are doing that, we are also developing our tools around the vocabulary, and we have started producing some data (you can already query the endpoint at http://hxl.humanitarianresponse.info/sparql, although there is not much there yet).
> When we are producing data, we always use the latest version of the vocabulary; obviously, that will create problems over time, say if you want to query all Camps (http://hxl.humanitarianresponse.info/ns-2012-06-14/#Camp) out of the triple store, independent of the vocabulary version. So far, each version of the vocabulary is linked to the previous version via dc:replaces, but this does not really solve our problem.
> We are working towards a stable first "release" of the vocabulary at some point, but until then, we will have to work around this issue somehow. Is there any best practice for that kind of problem? Would it make sense to apply dc:replaces to every class/property that is carried over from a previous version?
> Cheers,
> Carsten
> ---
> http://carsten.io
Received on Wednesday, 27 June 2012 16:37:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:21:25 UTC