- From: Alan Ruttenberg <alanruttenberg@gmail.com>
- Date: Wed, 27 Jun 2012 12:36:10 -0400
- 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. -Alan 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