W3C home > Mailing lists > Public > public-owl-dev@w3.org > July to September 2007

Re: Are DeprecatedClasses invisible to DIG Reasoners?

From: Pat Hayes <phayes@ihmc.us>
Date: Mon, 20 Aug 2007 17:52:35 -0500
Message-Id: <p06230911c2efc8f9d50d@[10.100.0.67]>
To: Matthew Pocock <matthew.pocock@ncl.ac.uk>
Cc: "Ibach, Brandon L" <brandon.l.ibach@lmco.com>, public-owl-dev@w3.org

>Perhaps in future, we will need to produce syntax/semantics for managing
>change in ontologies?

Yes, indeed, and many people are thinking hard about this. But...

>It's a shame that we have to remove the old (possibly
>broken) axioms when the new ones come along

My intuition is that the 'right' thing to do in a semantic web 
setting is simply to publish a new ontology with the new axioms in it 
(and the old, wrong axioms not in it.) It is impossible to 'delete' 
something published on the Web once it has been cast upon the waters, 
so to speak (viz. the number of now-obsolete but still archived Web 
pages). One could even follow the practice used in the W3C document 
chains, of having a fixed URI for the 'latest version' and a 
different URI for the 'this version', with the latter using a date 
convention in the URI name and having a link to the 'previous 
version' which it replaces. This effectively gives an automatic audit 
chain, and enables one to quickly determine if the thing one is 
looking at is the latest, up-to-date, version (and to get to that if 
it isn't).

>and especially a shame that we
>have to do URI hackery, which in some senses breaks the contract between the
>concept and the URI

You don't have to do this. Publishing a new ontology using a new URI 
does not require you to rename any of the concept URIs which occur in 
it. That would be very bad practice (unless the concept had genuinely 
changed, perhaps; but that would need some discussion about what it 
means for a concept to change).

>(assuming the new definition more correctly identifies
>the instances of a concept).

The definition can change without changing the concept URIreference. 
Very important practical point.

>
>Some combination of URI versioning, and reasoner support so that 'past' axioms
>don't trigger a full unsatisfiable ontology condition?

It is easy to make reasoners ignore things, provided some convention 
is adopted to tell them what to ignore. If you publish a new 
ontology, then unless it imports the old version (which would 
obviously be a very bad idea) then no unsatisfiability will get 
triggered. You just use the new ontology instead of the old one, is 
all.

Pat Hayes

>  Now my brain hurts.

PS. Its easier than you think.

>
>C'est la vie.
>
>Matthew
>
>On Monday 20 August 2007, William Bug wrote:
>>  Thanks, Brandon.
>>
>>  Yes - that makes the most sense, and as you say, is commensurate with
>>  the use of deprecation - as in Java - thus leaving it to an
>>  application to decide how to present this info to a user.  For
>>  instance, Protege adds a dark red "D" superscript to deprecated
>>  classes - just as information to the user.  This software development
>>  analogy is made in the OWL specs as well.
>>
>>  Now I more fully understand why the biomedical ontology community
>>  associated with the OBO Foundry and Gene Ontology are not using
>>  owl:DeprecatedClass.  They have the requirement of "retiring"/
>>  deprecating a class when it was necessary to make changes that alter
>>  the semantic entailments of the class or its associated axioms.  The
>>  recommended practice is to clone the old class - giving it a new
>>  unique rdf:ID.  The older class is re-typed to a generic
>>  "_deprecated_class" and all its axioms are removed, so it will be
>>  opaque to reasoners - apart from the class axiom typing it as a
>>  "_deprecated_class".  The newly made clone then is used to make the
>>  changes that alter the underlying entailments associated with that
>>  class.
>>
>>  I was just trying to better understand how owl:DeprecatedClass
>>  relates to this practice.  The answer appears to be - it doesn't.
>>
>>  Thanks again.
>>
>>  Cheers,
>>  Bill


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Monday, 20 August 2007 22:52:55 GMT

This archive was generated by hypermail 2.3.1 : Wednesday, 27 March 2013 09:32:55 GMT