Re: Are DeprecatedClasses invisible to DIG Reasoners?

Absolument, Matthew!

My brain hurts as well.

The URI "contract" issue is a major one that the biomedical ontology  
development community has yet to weigh in on.  Right now, some  
projects tend to approach it whatever way they believe balances "good  
community behavior" against cost incurred by them.  Other projects  
don't appear to have given as much thought to the issue.

As to breaking satisfiability, clearly the current  
owl:DeprecatedClass axiom is designed to help avoid such breakage -  
though it relies on "consumers" of an ontology paying head to the  
warning and making an effort to invest in reviewing how loss of the  
soon to be lost set of axioms will impact their use of those axioms -  
and how they might proceed to migrate themselves forward.  Hopefully  
the curating authority for the ontology including the DeprecatedClass  
has invested in providing some means for guiding users on this issue.

Obviously this topic of ontology maintenance/evolution has been a  
major topic of study.  Several of the tools out there - OWL or  
otherwise - have invested a bit in supporting this process. SWOOP has  
some support with a promise for more to come (keeping pace with the  
pending changes to OWL which should also help).  KAON also has quite  
a bit to help with this task, though that functionality doesn't  
appear to me to be ready for use with OWL ontologies.  There are many  
smaller research efforts that provide tools and strategies.

My question is:
	What would be the best way to approach this pressing issue in a  
manner most likely to be commensurate with the way the variety of  
biomedical OWL ontologies are also handling this issue?

I can't really fix on a clear answer to this question.

The Kluge we are using for our BIRNLex OWL file (which is related to  
what is being done on the OBI project) is to follow the GO lead - e.g.:
	- re-assign the "deprecated" class to be of type _deprecated_class
	- remove the axioms, so they won't impact reasoning
	- use a set of AnnotationProperties to track some of these former  
axioms (e.g., former parent class, former child classes, etc.) -  
along with "deprecatied_date" so that the history can be tracked to  
some extent
	- cross your fingers, hope for the best, and take lots of  
prophylactic ibuprofen

The other issue is as these "deprecated/retired" classes accumulate  
in your OWL file, they can begin to detrimentally effect processing  
of the OWL file, so it probably makes sense to move them to a  
separate OWL file, providing that file as  needed to consumers of  
your ontology.

I'm starting to get a headache right now.  Better stop thinking about  
this issue.

Cheers,
Bill



On Aug 20, 2007, at 5:55 PM, Matthew Pocock wrote:

> Perhaps in future, we will need to produce syntax/semantics for  
> managing
> change in ontologies? It's a shame that we have to remove the old  
> (possibly
> broken) axioms when the new ones come along and especially a shame  
> that we
> have to do URI hackery, which in some senses breaks the contract  
> between the
> concept and the URI (assuming the new definition more correctly  
> identifies
> the instances of a concept).
>
> Some combination of URI versioning, and reasoner support so that  
> 'past' axioms
> don't trigger a full unsatisfiable ontology condition? Now my brain  
> hurts.
>
> 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

Bill Bug
Senior Research Analyst/Ontological Engineer

Laboratory for Bioimaging  & Anatomical Informatics
www.neuroterrain.org
Department of Neurobiology & Anatomy
Drexel University College of Medicine
2900 Queen Lane
Philadelphia, PA    19129
215 991 8430 (ph)
610 457 0443 (mobile)
215 843 9367 (fax)


Please Note: I now have a new email - William.Bug@DrexelMed.edu