RE: Versioning vs Temporal modeling of Patient State

Recently I had an interesting conversation with Werner Cuesters, professor 
in Bufallo and colleague of Barry Smith. He has some theory about ontology 
maintenance and versioning and it considers both "classes" and 
"instances". Both can change either because you made en error, either you 
view on the world changed, either because the world changed . It turns out 
that you can only handle changes if you know for each change exactly what 
de reason of the change was. That reason should be documented in the 
system. 
I refer to a powerpoint which is available from his site (slides 39-42). 
Maybe it makes sence to dig a little deeper in his publications or contact 
him. 
The presentation is (amongst other topics)  about the quality of an 
ontology (be it on class level or instance level) , the fact that at a 
certain point in time some concepts are rightfully or wrongly present or 
absent and the corrective measures you should take.


______________________________________
Dr. Dirk Colaert MD
Advanced Clinical Application Research Manager
Agfa Healthcare               mobile: +32 497 470 871



"Xiaoshu Wang" <wangxiao@musc.edu> 
Sent by: public-semweb-lifesci-request@w3.org
11/01/2007 23:30

To
"'w3c semweb hcls'" <public-semweb-lifesci@w3.org>
cc
"'w3c semweb hcls'" <public-semweb-lifesci@w3.org>
Subject
RE: Versioning vs Temporal modeling of Patient State








Chimezie, 

> If a class has a particular 'definition' (i.e., the criteria 
> for membership of its instances) at a particular time and 
> that definition 'changes' then we are talking about a 
> different class altogether not a 'version' of the same class 

Yes. That is why I consider the OBO Foundry's wording "the original URI
should still point to the old term or concept, even if it is deprecated"
(From William Bug) is a bit self-contradicted.

In software engineering, if a class or a function is labeled as
"deprecated", it intends to warn the programmers that the 
code/functionality
might not be available some point in the future.

But when crafting an ontology, we present our view on certain reality.  If
the view is wrong or inadequate, there will certainly less cited (i.e.,
linked) by others and eventually die.  Hence, the notion of deprecation
seems not apply if the URI is to be persisted. (I strongly support this 
OBO
policy).

But on the other hand, there is situiations that the crafted ontology is 
due
to errors but not due to different theories or views.  Hence, we need to
"deprecate" certain URIs. I think it is necessary to make distinctions
between the two and give different URI policies.

Xiaoshu