How to move an RDF vocabulary and deprecate the old one?

IS4 0
Viewed 24

Say I had a vocabulary hosted at the URI http://example.org/a/ but, for some unfortunate reasons, the URI can no longer be used, and instead it has to start with http://example.org/b/. The old URI is no longer dereferenceable, and it is not possible to set up redirects to the new one, therefore it is best, I think, to deprecate the old URI and start using the new one wherever possible.

The question is: how does one link the "new" terms, located under http://example.org/b/, to the old ones, at http://example.org/a/, in a way that signifies:

  1. The two terms are still semantically equivalent, so under OWL, they should be interchangeable. OWL-aware processors should not treat documents using the new vocabulary differently.
  2. Users of the old term should switch to the new one, and should not produce documents using the new one.

In a sense these requirements more or less align with the purpose of HTTP "301 Moved Permanently" status code.

Now for 1. the number one solution would be to use owl:equivalentClass for classes, owl:equivalentProperty for properties, and owl:sameAs for individuals. This pretty much solves it: a member of one class is automatically a member of the other one, one property implies the other, and the two individuals are the same thing. I am pretty satisfied with this solution.

Yet for 2. I am unsure how to express the intention to humans that "the new URI is highly favoured over the old one". There is dcterms:replaces (e.g. <http://example.org/b/Class1> dcterms:replaces <http://example.org/a/Class1>) which reads clearly, but I fear that it means something more like in the example "HTML 4.01 replaces HTML 4.0", i.e. that the resources are different, but the old one is superseded by the new one.

Another possible issue I can think of is with individuals and owl:sameAs. Won't <http://example.org/b/individual1> owl:sameAs <http://example.org/a/individual1> and <http://example.org/b/individual1> dcterms:replaces <http://example.org/a/individual1> essentially mean <http://example.org/b/individual1> dcterms:replaces <http://example.org/b/individual1>, i.e. it replaces itself? Or does it work differently since it is owl:AnnotationProperty? Or should I use something like skos:exactMatch for individuals?

semantic-web rdf owl
1 Answers

You hit upon some important nuanced issues. Yes, you will be protected from unwanted inferences if dcterms:replaces is an annotation property. However, Dublin Core is formally uncommitted regarding an OWL interpretation (see this thread). This means you could in theory get into trouble, but in practice if you have control over the universe of ontologies.

If you did want to be on the safe side you may want to be safe with classes and properties too. Using an object property on a class will induce punning, the resulting entailments may be unusual. However, in practice, it is common to use Dublin Core uncommitted properties with OWL classes as there is a general consensus they should not be declared object or data properties.

Another more serious issue you may encounter with using logical axioms to relate a and b is related to schema evolution. If b evolves independently of a then you risk running into incoherencies if a and b are imported into the same ontology. Even if you guard against ever importing a, you may run into problems if you want to merge two classes in b.

I don’t think there is an authoritative answer but I can tell you what has worked for the Open Bio Ontologies community, which consists of over a hundred interoperating ontologies.

We use annotation properties to link deprecated classes to the classes that replace them. The deprecated classes get a deprecation annotation. The main use case for handling these are non reasoning tools, eg migration assistants, so use of explicit annotation properties has no disadvantages and is generally safe. The protege developers also implemented support for our workflow.

You can read about our deprecation workflow in our OBO academy guide to obsoletion

Chris Mungall0
Related