- From: Pat Hayes <phayes@ihmc.us>
- Date: Mon, 20 Aug 2007 17:52:35 -0500
- 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 UTC