Re: Versioning vs Temporal modeling of Patient State

[dirk . colaert]

Personally I don't see too much of a difference between versioning of 
models and versioning of instances. The former is needed to  bundle a 
couple of *updates* of our world model (stamped with a version number), 
the latter is needed because also instance data change and previous values 
still keep being important. You can discuss wether a new version of an 
instance is really a new version or a new instance (maybe with a link to 
the previous instance). To me it doesn't matter and looks like an 
implentation issue.
We have to realize that versioning is an artifact anyway. The real world 
keeps on going and doesn't hold its breath to take snapshots. It is our 
need to document the world at a certain point in time that creates the 
need of snapshots: for example documenting your assessment of a patient by 
giving a diagnosis. Keeping track of previous *versions* of instances is 
very important in medicin, not at least for legal issues.

When you look at implementations of electronic patient records you see 
that different approaches are chosen: the more simple (simplistic?) 
approach is to take each patient encounter as a container and put all your 
instances of clinical data in it (diagnoses, medication, procedures, etc 
...). This gives you an easy way of handling changes over time. In the 
next encounter the diagnosis is changed an you just add a new instance of 
the diagnosis in the new container. While escaping from the versioning 
problems you loose information. In the real world there is an *evolution* 
of the patient condition and you didn't capture that.
Other implementations consider a diagnosis as something pertaining to the 
patient and evolving. At a certain moment in time they link the current 
*version* of that diagnosis to the encounter. In a next encounter you can 
again link the - maybe changed- diagnosis to the new encounter. The result 
is that for any encounter you have captured the current state of the 
patient and you have a nice way of looking at the evolution of that state 
by looking at the different versions.

What do we learn from that?
In both ways you try to capture the ever changing world by introducing a 
time concept: the encounter. In the first approach you make time 
containers and put instances in it, in the second approach you make time 
stamped versions and link them to time containers. I perfer the second 
approach because of the added information.
The point is that versioning means: adding a temporal concept to the 
snapshots of the world. Because the history matters (both for models and 
instances) we better model that temporal aspect as well. It will enable us 
to reason about it.
As for the difference between *update* and *version*: my intuitive feeling 
is that an update means a atomic change and a version means a bundled and 
officially relleased collection of these changes. And indeed the latter 
will be more appropriate for models than for instances.

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



Ora Lassila <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
12/01/2007 17:06

To
"Kashyap, Vipul" <[EMAIL PROTECTED]>, w3c semweb hcls 

cc
Trish Whetzel <[EMAIL PROTECTED]>, kc28 <[EMAIL PROTECTED]>, Alan 
Ruttenberg <[EMAIL PROTECTED]>, Nigam Haresh Shah 
<[EMAIL PROTECTED]>
Subject
Re: Versioning vs Temporal modeling of Patient State








Vipul,


On 2007-01-12 10:21, "Kashyap, Vipul" <[EMAIL PROTECTED]> wrote:

>> my experience is that issues of versioning are quite different from the
>> issues of temporl modeling. Often in the former case, we don't have to
>> concern ourselves with what changes have taken place, whereas in the
>> latter
>> case, we often need to focus on the changes themselves (i.e., questions 
of
>> what changes, how, and *when* are critical).
> 
> [VK] That is a good way to distinguish the issues. Unfortunately, the 
few use
> cases that were provided to me suggested issues of versioning were 
confounded
> with issues of temporal data modeling.
> 
> The latter notion of versioning is from the content management 
perspective,
> where the notion of what.why,who changed it is important, i.e., 
provenance.
> 
> This underlines the need for a clear definition of versioning and 
provenance
> in
> the life sciences context.

[OL] Hmm... still, from the content management perspective, you may not
*reason* over the changes or (more generally) the temporal extent of 
things.
In a way, there is a different whether you are modeling the real world, or
modeling the documents that contain models that represent the real world.

Confusing the various (meta)levels can quickly mess up your head. :-) 
There
are multiple dimensions all of which may have to be represented: the
temporal 

Re: Versioning vs Temporal modeling of Patient State

[Ora Lassila]

Vipul,


On 2007-01-12 10:21, "Kashyap, Vipul" <[EMAIL PROTECTED]> wrote:

>> my experience is that issues of versioning are quite different from the
>> issues of temporal modeling. Often in the former case, we don't have to
>> concern ourselves with what changes have taken place, whereas in the
>> latter
>> case, we often need to focus on the changes themselves (i.e., questions of
>> what changes, how, and *when* are critical).
> 
> [VK] That is a good way to distinguish the issues. Unfortunately, the few use
> cases that were provided to me suggested issues of versioning were confounded
> with issues of temporal data modeling.
> 
> The latter notion of versioning is from the content management perspective,
> where the notion of what.why,who changed it is important, i.e., provenance.
> 
> This underlines the need for a clear definition of versioning and provenance
> in
> the life sciences context.

[OL] Hmm... still, from the content management perspective, you may not
*reason* over the changes or (more generally) the temporal extent of things.
In a way, there is a different whether you are modeling the real world, or
modeling the documents that contain models that represent the real world.

Confusing the various (meta)levels can quickly mess up your head. :-) There
are multiple dimensions all of which may have to be represented: the
temporal dimension, the stack of metalevels (models, models of models,
etc.), perhaps others.

>> This is an old and difficult problem with systems employing complex
>> representations of the world. It is often not sufficient to operate within
>> a
>> mere snapshot of the world. One has to ask whether time (or the changes
>> over
>> time) matter, or whether at any moment it is sufficient to consider a
>> snapshot.
> 
> [VK] The key is how you support this functional requirement. Either you could
> create an appropriate temporal model that provides the framework acquisition
> and
> querying of this data; or
> you could fall back on versioning functionality to get this information.
> IMHO, there is more value in taking the former approach as it can be fed into
> versioning systems that compute the changes or "diffs"

[OL] Regardless of how you do this, you have to decide whether you really
are reasoning over/about the changes (in time). The information (about
changes) may be *acquired* from the versioning system, but then has to be
modeled *outside* the versioning system. Acquisition vs. processing is an
important distinction.

>> One might draw analogies to "compile-time vs. run-time" considerations
>> often
>> occurring in computer science... in fact, the question of "class changes
>> vs.
>> instance changes" is exactly that.
> 
> [VK] Agree. However whether an instance is actually changing or whether a
> particular property of the individual is naturally modeled as a dynamic time
> varying data type need to be identified.

[OL] This may or may not be a relevant distinction, depending on how you
implement thing, what tools you use, etc. But generally, I agree.

Regards,

- Ora


>> BTW, there is a paper that points out that temporal modeling/reasoning is
>> re-invented/re-implemented over and over because of the lack of "built-in"
>> support for it in KR systems:
>> 
>> Thomas L. Dean and Drew McDermott. Temporal Data Base Management.
>> Artificial
>> Intelligence, 32(1):1­55, 1987.
> 
> [VK] Thanks for the above info.
> 
> ---Vipul
> 
> 
> 
> 
> THE INFORMATION TRANSMITTED IN THIS ELECTRONIC COMMUNICATION IS INTENDED ONLY
> FOR THE PERSON OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN CONFIDENTIAL
> AND/OR PRIVILEGED MATERIAL.  ANY REVIEW, RETRANSMISSION, DISSEMINATION OR
> OTHER USE OF OR TAKING OF ANY ACTION IN RELIANCE UPON, THIS INFORMATION BY
> PERSONS OR ENTITIES OTHER THAN THE INTENDED RECIPIENT IS PROHIBITED.  IF YOU
> RECEIVED THIS INFORMATION IN ERROR, PLEASE CONTACT THE SENDER AND THE PRIVACY
> OFFICER, AND PROPERLY DISPOSE OF THIS INFORMATION.
> 
> 

Re: Versioning vs Temporal modeling of Patient State

[Olivier Bodenreider]

Kashyap, Vipul wrote:

Is there any work in the literature related to:

- Defining what and when a version is?
- Do all updates necessarily lead to a new version?
- Is there a utility to instance versioning?

The observation about the utility of knowledge base update and revision is an
astute one. IMHO the utility of instance versioning is not clear either.

Just my 2 cents,

  
A couple of classical references in medical informatics about evolution 
of biomedical terminologies:


Oliver DE, Shahar Y.
Change management of shared and local versions of health-care terminologies.
Methods Inf Med. 2000 Dec;39(4-5):278-90. Review.
PMID: 11191695 [PubMed - indexed for MEDLINE]

Oliver DE, Shahar Y, Shortliffe EH, Musen MA.
Representation of change in controlled medical terminologies.
Artif Intell Med. 1999 Jan;15(1):53-76. Review.
PMID: 9930616 [PubMed - indexed for MEDLINE]

Oliver DE.
Synchronization of diverging versions of a controlled medical terminology.
Proc AMIA Symp. 1998;:850-4.
PMID: 9929339 [PubMed - indexed for MEDLINE]

Hartel FW, Fragoso G, Ong KL, Dionne R.
Enhancing quality of retrieval through concept edit history.
AMIA Annu Symp Proc. 2003;:279-83.
PMID: 14728178 [PubMed - indexed for MEDLINE]

--
Dr. Olivier Bodenreider Staff Scientist National Library of Medicine 
8600 Rockville Pike - MS 3841 (Bldg 38A, Rm B1N28U) Bethesda, MD 20894 - 
USA phone: 301 435-3246 - fax: 301 480-3035

RE: Versioning vs Temporal modeling of Patient State

[Kashyap, Vipul]

> my experience is that issues of versioning are quite different from the
> issues of temporal modeling. Often in the former case, we don't have to
> concern ourselves with what changes have taken place, whereas in the
> latter
> case, we often need to focus on the changes themselves (i.e., questions of
> what changes, how, and *when* are critical).

[VK] That is a good way to distinguish the issues. Unfortunately, the few use
cases that were provided to me suggested issues of versioning were confounded
with issues of temporal data modeling. 

The latter notion of versioning is from the content management perspective,
where the notion of what.why,who changed it is important, i.e., provenance.

This underlines the need for a clear definition of versioning and provenance in
the life sciences context.

> This is an old and difficult problem with systems employing complex
> representations of the world. It is often not sufficient to operate within
> a
> mere snapshot of the world. One has to ask whether time (or the changes
> over
> time) matter, or whether at any moment it is sufficient to consider a
> snapshot.

[VK] The key is how you support this functional requirement. Either you could
create an appropriate temporal model that provides the framework acquisition and
querying of this data; or
you could fall back on versioning functionality to get this information.
IMHO, there is more value in taking the former approach as it can be fed into
versioning systems that compute the changes or "diffs"

> One might draw analogies to "compile-time vs. run-time" considerations
> often
> occurring in computer science... in fact, the question of "class changes
> vs.
> instance changes" is exactly that.

[VK] Agree. However whether an instance is actually changing or whether a
particular property of the individual is naturally modeled as a dynamic time
varying data type need to be identified.

> BTW, there is a paper that points out that temporal modeling/reasoning is
> re-invented/re-implemented over and over because of the lack of "built-in"
> support for it in KR systems:
> 
> Thomas L. Dean and Drew McDermott. Temporal Data Base Management.
> Artificial
> Intelligence, 32(1):1­55, 1987.

[VK] Thanks for the above info.

---Vipul




THE INFORMATION TRANSMITTED IN THIS ELECTRONIC COMMUNICATION IS INTENDED ONLY 
FOR THE PERSON OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN CONFIDENTIAL 
AND/OR PRIVILEGED MATERIAL.  ANY REVIEW, RETRANSMISSION, DISSEMINATION OR OTHER 
USE OF OR TAKING OF ANY ACTION IN RELIANCE UPON, THIS INFORMATION BY PERSONS OR 
ENTITIES OTHER THAN THE INTENDED RECIPIENT IS PROHIBITED.  IF YOU RECEIVED THIS 
INFORMATION IN ERROR, PLEASE CONTACT THE SENDER AND THE PRIVACY OFFICER, AND 
PROPERLY DISPOSE OF THIS INFORMATION.

Re: Versioning vs Temporal modeling of Patient State

[Ora Lassila]

Vipul et al,

my experience is that issues of versioning are quite different from the
issues of temporal modeling. Often in the former case, we don't have to
concern ourselves with what changes have taken place, whereas in the latter
case, we often need to focus on the changes themselves (i.e., questions of
what changes, how, and *when* are critical).

This is an old and difficult problem with systems employing complex
representations of the world. It is often not sufficient to operate within a
mere snapshot of the world. One has to ask whether time (or the changes over
time) matter, or whether at any moment it is sufficient to consider a
snapshot.

One might draw analogies to "compile-time vs. run-time" considerations often
occurring in computer science... in fact, the question of "class changes vs.
instance changes" is exactly that.

BTW, there is a paper that points out that temporal modeling/reasoning is
re-invented/re-implemented over and over because of the lack of "built-in"
support for it in KR systems:

Thomas L. Dean and Drew McDermott. Temporal Data Base Management. Artificial
Intelligence, 32(1):1­55, 1987.

(My comments have to understood in the context that I have a lot of
experience in KR for scheduling and course-of-action planning, where the
problems are predominantly about time and state changes.)

Regards,

- Ora

-- 
Ora Lassila  mailto:[EMAIL PROTECTED]  http://www.lassila.org/
Research Fellow, Nokia Research Center Cambridge
Visiting Scientist, MIT/CSAIL



On 2007-01-11 16:28, "Kashyap, Vipul" <[EMAIL PROTECTED]> wrote:

> 
> 
> Nigam,
> 
> This is an interesting example...
> 
>> Have an example for this one: If the instance is of a the class "Tumor"
>> then
>> on giving treatment it changes in size, shape etc, and might ultimately
>> disappear. On each visit we are observing a different version of the tumor
>> instance [in Tom].
> 
> [VK] Clearly there is a longitudinal aspect to this as the state of the tumor
> changes over time
> 
> This could be modeled in two ways:
> 
> Tumor1.state = X at time T1
> Tumor1.state = Y at time T2
> ...
> Tumor1.state = "Non-existent" at time Tn
> 
> Essentially you are modeling state as a multivalued property or as a ternary
> relationship (Tumor, state, Time)
> 
> Alternatively,
> 
> Tumor1, v1.state = X
> Tumor1, v2.state = Y
> ...
> Tumor1, vN.state = "Non-existent"
> 
> 
> IMHO, the former representation conveys more information and meaning...
> So, it may make sense not to confound versioning with temporal progression...
> 
> Look forward to the commounities thoughts on the issue.
> 
> Cheers,
> 
> ---Vipul
> 
> 
> 
> 
> 
> 
> THE INFORMATION TRANSMITTED IN THIS ELECTRONIC COMMUNICATION IS INTENDED ONLY
> FOR THE PERSON OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN CONFIDENTIAL
> AND/OR PRIVILEGED MATERIAL.  ANY REVIEW, RETRANSMISSION, DISSEMINATION OR
> OTHER USE OF OR TAKING OF ANY ACTION IN RELIANCE UPON, THIS INFORMATION BY
> PERSONS OR ENTITIES OTHER THAN THE INTENDED RECIPIENT IS PROHIBITED.  IF YOU
> RECEIVED THIS INFORMATION IN ERROR, PLEASE CONTACT THE SENDER AND THE PRIVACY
> OFFICER, AND PROPERLY DISPOSE OF THIS INFORMATION.
> 
> 
> 

Re: Versioning vs Temporal modeling of Patient State

[William Bug]

On Jan 12, 2007, at 8:28 AM, Kashyap, Vipul wrote:






The IFOMIS work Dirk, Kirsten, and others have cited on referent  
tracking is definitely important work to review in this light.  I'd  
not been familiar with the model theoretic work Bijan mentions, but  
clearly that is important.




Werner Ceusters also has a list - a Google list I believe - on  
referent tracking.




[VK] We need some clarity on the various issues coming up –  
updates, revisions, referent tracking and versioning. I think part  
of the problem is that we are all using these terms from different  
perspectives and a good clear definition of these terms would be  
very useful.
I agree there is a need for some very specific examples to provide a  
clear sense of how these impact the overall issue of ontology changes/ 
evolution.



This work - and related work on "speech acts" - is most definitely  
relevant to this discussion and very specifically is designed to  
address ABox.  As the citations given indicate, most of this work  
has been done in the clinical domain with a focus on patient  
records, which was the origin of this thread and would be directly  
relevant to the Use Case Nigam put out there.


[VK] Could you give us some examples of how speech acts could be  
used in the context of Nigam’s Use Case?

I can't, but probably Nigam, Chris Mungall, or Fabian Neuhaus could.



Standard source version control systems - e.g., CVS, SVN, etc. -  
just make the problem worse in my opinion.  This is where I'd  
differ with the point Vipul makes.  It's not that there are NO  
aspects of the software version process relevant to this issue.   
It's just I believe there are complex issues in this domain - some  
of which Bijan mentioned - some of which I mention below regarding  
application the traditional approach to employing CVs for  
literature annotation - that extend greatly beyond what the common  
practice in software version control is intended to support.  In  
that domain, highly granular version management has been required,  
and I believe something like it will be required in the ontology  
development space as well.  Perhaps that's just a qualification and  
rewording of the point Vipul was trying to make.


[VK] Yes. I did not imply that the techniques for software  
versioning (still predominantly text based) carry over to knowledge  
versioning…

I kinda expected this was true.  :-)

My sense is you are thinking more about how one models the software  
versioning process.  I agree there are aspects of how you'd model  
that process that can help to inform the process of managing ontology  
evolution.


My misgivings regarding the use of VCSs to manage the community  
ontology development process are totally utilitarian and based on  
more practical concerns.  Having been - and being - both a heavy user  
- and administrator - of an SVN system, I really think its very  
counter productive to use an ASCII-based diff mechanism to manage the  
evolution of a knowledge graph represented using the ASCII-XML-RDF- 
OWL layered serialization.  For instance, if you look at the  
serialization created of a specific OWL file by two different tools -  
e.g., Protege-OWL and SWOOP - they can be very very different, though  
both still hold to the RDF spec and represent an identical OWL  
graph.  I've found one tool doesn't necessarily accommodate the  
serialization idiosyncrasies of another tool in this domain.  So,  
unlike a C/C++ or Java source file where what you see in your  
development environment or text editor is what you get, with an  
ontology editor tool, it's rarely appropriate for the tool to present  
the "raw" RDF/XML to a user, so the tools perform a great deal of  
processing of the serialized file just to present it to a user.  if a  
group of ontology developers are using different tools to edit the  
same file - even if they are working on totally distinct portions -  
when they try to open an OWL file serialized with another tool, their  
tool of choice.  For instance, some developers may prefer an XML- 
oriented tool such as oXygen - there's not necessarily anyway to  
prevent them from doing that.  However, by focussing on that level of  
the ASCI--->OWL layer cake, there's nothing to constrain you from  
creating a layout incompatible with Protege-OWL.


This gets much much worse when multiple people are trying to edit the  
same area of the graph.


This means projects using this approach need to develop a complex  
usage policy on how developers must interact with the OWL file must  
of which comes down to just one or a select few are allowed to work  
directly on the OWL file, and they all agree to use the same version  
of the same tool.


These sort of convoluted requirements partly related to the limits of  
the OWL editor tools, partly due to the complexity of the OWL  
formalism, and partly due to the idiosyncrasies and pitfalls of using  
an ASCII-diff-based change management system.


My 

RE: Versioning vs Temporal modeling of Patient State

[Kashyap, Vipul]

 

 

The IFOMIS work Dirk, Kirsten, and others have cited on referent tracking is
definitely important work to review in this light.  I'd not been familiar with
the model theoretic work Bijan mentions, but clearly that is important. 

 

Werner Ceusters also has a list - a Google list I believe - on referent
tracking. 

 

[VK] We need some clarity on the various issues coming up - updates, revisions,
referent tracking and versioning. I think part of the problem is that we are all
using these terms from different perspectives and a good clear definition of
these terms would be very useful.

 

This work - and related work on "speech acts" - is most definitely relevant to
this discussion and very specifically is designed to address ABox.  As the
citations given indicate, most of this work has been done in the clinical domain
with a focus on patient records, which was the origin of this thread and would
be directly relevant to the Use Case Nigam put out there.

[VK] Could you give us some examples of how speech acts could be used in the
context of Nigam's Use Case?

 

Standard source version control systems - e.g., CVS, SVN, etc. - just make the
problem worse in my opinion.  This is where I'd differ with the point Vipul
makes.  It's not that there are NO aspects of the software version process
relevant to this issue.  It's just I believe there are complex issues in this
domain - some of which Bijan mentioned - some of which I mention below regarding
application the traditional approach to employing CVs for literature annotation
- that extend greatly beyond what the common practice in software version
control is intended to support.  In that domain, highly granular version
management has been required, and I believe something like it will be required
in the ontology development space as well.  Perhaps that's just a qualification
and rewording of the point Vipul was trying to make.

[VK] Yes. I did not imply that the techniques for software versioning (still
predominantly text based) carry over to knowledge versioning...

 

As you can tell, this is just a suggestion which OBI, BIRNLex, and a few other
ontology developers have just begun to implement, so this is most definitely a
work-in-progress.  

 

Having a review of the topic, as Vipul suggests, at this stage in the game by
the several folks who've provided valuable pointers and feedback, would be a
wonderful idea, I think.

 

[VK] Bill, as Eric Miller used to say, "No good deed goes unpunished!" Could you
lead a discussion on this topic at one of the BIONT Telcons possibly in
collaboration with Dirk Colaert and Kerstin Forsberg?

 

Thanks for all the work and information.

 

Cheers,

 

---Vipul





THE INFORMATION TRANSMITTED IN THIS ELECTRONIC COMMUNICATION IS INTENDED ONLY 
FOR THE PERSON OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN CONFIDENTIAL 
AND/OR PRIVILEGED MATERIAL.  ANY REVIEW, RETRANSMISSION, DISSEMINATION OR OTHER 
USE OF OR TAKING OF ANY ACTION IN RELIANCE UPON, THIS INFORMATION BY PERSONS OR 
ENTITIES OTHER THAN THE INTENDED RECIPIENT IS PROHIBITED.  IF YOU RECEIVED THIS 
INFORMATION IN ERROR, PLEASE CONTACT THE SENDER AND THE PRIVACY OFFICER, AND 
PROPERLY DISPOSE OF THIS INFORMATION.

Re: Versioning vs Temporal modeling of Patient State

[William Bug]

use a CV greatly improves the F- 
measure of the search system used to mine the resulting inverted  
indexes.  However, I know from time working with the creators of  
the Biological Abstracts, that it took months of training for the  
"indexers" to get good at consistently applying CV terms - and a  
lot of QA/QC was still needed to constantly monitor the output.   
The reason really comes down to the lack of complete, detailed  
definitions and lack of a formal, semantic graph really left way  
too much leeway for indexers, even when a moderate amount of effort  
was dedicated to incentivizing indexers.  Having said that, when  
highly specific definitions were used, it was found indexers both  
greatly slowed in the annotation output AND use of CV terms went  
way down, both of which are really at odds to the intended goal of  
the process (back to F-measure), which is to provide maximal  
annotation given according to a CV.  Even with this work, BIOSIS  
(publishers of the Biological Abstracts) and really all the A&I  
vendors I knew of, still required a huge educational staff that  
would constantly travel the world providing demos and updates to  
librarians, so they could be kept informed on how best to use the  
resulting CV indexes.


It was still clearly an art to maximize F-measure - one that very  
much depended on quality and structure of the CV/classification  
scheme/taxonomy, the talents of the indexers applying the CVs in  
the annotation process and the talents of the info. retrieval  
experts/librarians in constructing queries. By far the most  
confounding aspect of this process was the need to alter indexer  
and searcher practice, as CV changes were introduced - as was of  
course inevidible - both due to changes in the *world* and changes  
in *knowledge representation*, as Bijan describes it below.  It was  
partly because of this, that various CV curatorial practices were  
developed that again are partially represented in SKOS - fields  
such as "scope notes", "history notes", etc., which all relate to  
the versioning issue in this context, but, of course, are designed  
for human consumption and are not particularly useful to KE/KR  
algorithms.


My sense - as you can see in that OBI Wiki page I cited - is there  
is a need to provide such curation support in the ontology  
development process both to address the lexical issues as has been  
historically done in info. science/library science, as well as to  
address semantic graph evolution.  Both of these requirements arise  
due both to changes in *world* and QA/QC performed on the KR  
(changes in *knowledge*).  My sense is in providing this first  
simple step - a shared collection of AnnotationProperties used  
across the community when building OWL-based ontologies - we  
provide the structure required to develop software tools to help  
automate the process.  Nothing extending to the complexity of  
automatic reasoning, but just something to address the need quickly  
- a structured model for these processes, if you will, that can  
evolve toward the more complex "referent tracking" and "speech act"  
formalism.  This stop-gap isn't nearly enough to fully address this  
complex issue, but it should be relatively easy to implement and to  
put into practice (with a minimal amount of automated support for  
ontology curators), and if done correctly, should be something that  
can migrate to the more complex approach later.  Providing too  
complex a strategy for addressing this versioning issue now might  
prohibitively slow the ontology development process as it is being  
carried out by various community biomed. ontology development  
projects.


As you can tell, this is just a suggestion which OBI, BIRNLex, and  
a few other ontology developers have just begun to implement, so  
this is most definitely a work-in-progress.


Having a review of the topic, as Vipul suggests, at this stage in  
the game by the several folks who've provided valuable pointers and  
feedback, would be a wonderful idea, I think.


Cheers,
Bill


On Jan 12, 2007, at 6:26 AM, Kashyap, Vipul wrote:




Is there any work in the literature related to:

- Defining what and when a version is?
- Do all updates necessarily lead to a new version?
- Is there a utility to instance versioning?

The observation about the utility of knowledge base update and  
revision is an
astute one. IMHO the utility of instance versioning is not clear  
either.


Just my 2 cents,

---Vipul



-Original Message-
From: [EMAIL PROTECTED] [mailto:public-semweb- 
lifesci-

[EMAIL PROTECTED] On Behalf Of Bijan Parsia
Sent: Friday, January 12, 2007 5:28 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; 'w3c semweb hcls'; public-semweb-lifesci-
[EMAIL PROTECTED]
Subject: Re: Versioning vs Temporal modeling of Patient State


On Jan 12, 2007, at 9:36 AM, [EMAIL PROTECTED] wrote:


Recently I had an inter

Re: Versioning vs Temporal modeling of Patient State

[William Bug]

o provide maximal annotation given according to a CV.  Even with  
this work, BIOSIS (publishers of the Biological Abstracts) and really  
all the A&I vendors I knew of, still required a huge educational  
staff that would constantly travel the world providing demos and  
updates to librarians, so they could be kept informed on how best to  
use the resulting CV indexes.


It was still clearly an art to maximize F-measure - one that very  
much depended on quality and structure of the CV/classification  
scheme/taxonomy, the talents of the indexers applying the CVs in the  
annotation process and the talents of the info. retrieval experts/ 
librarians in constructing queries. By far the most confounding  
aspect of this process was the need to alter indexer and searcher  
practice, as CV changes were introduced - as was of course inevidible  
- both due to changes in the *world* and changes in *knowledge  
representation*, as Bijan describes it below.  It was partly because  
of this, that various CV curatorial practices were developed that  
again are partially represented in SKOS - fields such as "scope  
notes", "history notes", etc., which all relate to the versioning  
issue in this context, but, of course, are designed for human  
consumption and are not particularly useful to KE/KR algorithms.


My sense - as you can see in that OBI Wiki page I cited - is there is  
a need to provide such curation support in the ontology development  
process both to address the lexical issues as has been historically  
done in info. science/library science, as well as to address semantic  
graph evolution.  Both of these requirements arise due both to  
changes in *world* and QA/QC performed on the KR (changes in  
*knowledge*).  My sense is in providing this first simple step - a  
shared collection of AnnotationProperties used across the community  
when building OWL-based ontologies - we provide the structure  
required to develop software tools to help automate the process.   
Nothing extending to the complexity of automatic reasoning, but just  
something to address the need quickly - a structured model for these  
processes, if you will, that can evolve toward the more complex  
"referent tracking" and "speech act" formalism.  This stop-gap isn't  
nearly enough to fully address this complex issue, but it should be  
relatively easy to implement and to put into practice (with a minimal  
amount of automated support for ontology curators), and if done  
correctly, should be something that can migrate to the more complex  
approach later.  Providing too complex a strategy for addressing this  
versioning issue now might prohibitively slow the ontology  
development process as it is being carried out by various community  
biomed. ontology development projects.


As you can tell, this is just a suggestion which OBI, BIRNLex, and a  
few other ontology developers have just begun to implement, so this  
is most definitely a work-in-progress.


Having a review of the topic, as Vipul suggests, at this stage in the  
game by the several folks who've provided valuable pointers and  
feedback, would be a wonderful idea, I think.


Cheers,
Bill


On Jan 12, 2007, at 6:26 AM, Kashyap, Vipul wrote:




Is there any work in the literature related to:

- Defining what and when a version is?
- Do all updates necessarily lead to a new version?
- Is there a utility to instance versioning?

The observation about the utility of knowledge base update and  
revision is an
astute one. IMHO the utility of instance versioning is not clear  
either.


Just my 2 cents,

---Vipul



-Original Message-
From: [EMAIL PROTECTED] [mailto:public-semweb- 
lifesci-

[EMAIL PROTECTED] On Behalf Of Bijan Parsia
Sent: Friday, January 12, 2007 5:28 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; 'w3c semweb hcls'; public-semweb-lifesci-
[EMAIL PROTECTED]
Subject: Re: Versioning vs Temporal modeling of Patient State


On Jan 12, 2007, at 9:36 AM, [EMAIL PROTECTED] wrote:


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.

[snip]

The standard lingo for this is that a change to the knowledge base
due to a change in the *world* is called an *update* whereas a change
in your knowledge base due to a change in *your knowledge* of the
(current static) world is called a *revision*. The locus classicus
for this, IMHO, is:
<http://citeseer.ist.psu.edu/417296.html>

Following there model theoretic a

RE: Versioning vs Temporal modeling of Patient State

[Kashyap, Vipul]

Is there any work in the literature related to:

- Defining what and when a version is?
- Do all updates necessarily lead to a new version?
- Is there a utility to instance versioning?

The observation about the utility of knowledge base update and revision is an
astute one. IMHO the utility of instance versioning is not clear either.

Just my 2 cents,

---Vipul


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:public-semweb-lifesci-
> [EMAIL PROTECTED] On Behalf Of Bijan Parsia
> Sent: Friday, January 12, 2007 5:28 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; 'w3c semweb hcls'; public-semweb-lifesci-
> [EMAIL PROTECTED]
> Subject: Re: Versioning vs Temporal modeling of Patient State
> 
> 
> On Jan 12, 2007, at 9:36 AM, [EMAIL PROTECTED] wrote:
> 
> > 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.
> [snip]
> 
> The standard lingo for this is that a change to the knowledge base
> due to a change in the *world* is called an *update* whereas a change
> in your knowledge base due to a change in *your knowledge* of the
> (current static) world is called a *revision*. The locus classicus
> for this, IMHO, is:
>   <http://citeseer.ist.psu.edu/417296.html>
> 
> Following there model theoretic accounts, there is a spate of work
> defining reasoning services that compute the updated or revisied
> knowledge base given a proposed update or revision. E.g., recently:
>   <http://lat.inf.tu-dresden.de/~clu/papers/archive/kr06c.pdf>
> 
> The utility of model oriented revision and update for expressive
> logics is, IMHO, not fully established, though it is conceptually
> useful in my experience. There is, of course, a large chunk of work
> on revising (and even updating) belief *bases*, that is, attending
> primarily to the *asserted* set of formulae.
> 
> Hope this helps.
> 
> Cheers,
> Bijan.
> 
> 





THE INFORMATION TRANSMITTED IN THIS ELECTRONIC COMMUNICATION IS INTENDED ONLY 
FOR THE PERSON OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN CONFIDENTIAL 
AND/OR PRIVILEGED MATERIAL.  ANY REVIEW, RETRANSMISSION, DISSEMINATION OR OTHER 
USE OF OR TAKING OF ANY ACTION IN RELIANCE UPON, THIS INFORMATION BY PERSONS OR 
ENTITIES OTHER THAN THE INTENDED RECIPIENT IS PROHIBITED.  IF YOU RECEIVED THIS 
INFORMATION IN ERROR, PLEASE CONTACT THE SENDER AND THE PRIVACY OFFICER, AND 
PROPERLY DISPOSE OF THIS INFORMATION.

RE: Versioning vs Temporal modeling of Patient State

[Kashyap, Vipul]

Kerstin and Dirk:

Would it be possible for either of you to lead a discussion on this important
issue on one of the BIONT Telcons?
The idea would be to look at the current Tumor use case by Nigam and show
how the techniques mentioned below can be applied to the use case.

Thanks,

---Vipul

===
Vipul Kashyap, Ph.D.
Senior Medical Informatician
Clinical Informatics R&D, Partners HealthCare System
Phone: (781)416-9254
Cell: (617)943-7120
http://www.partners.org/cird/AboutUs.asp?cBox=Staff&stAb=vik
 
To keep up you need the right answers; to get ahead you need the right questions
---John Browning and Spencer Reiss, Wired 6.04.95
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:public-semweb-lifesci-
> [EMAIL PROTECTED] On Behalf Of Forsberg, Kerstin L
> Sent: Friday, January 12, 2007 5:54 AM
> To: public-semweb-lifesci@w3.org
> Subject: RE: Versioning vs Temporal modeling of Patient State
> 
> 
> This is a very good and required discussion.
> 
> And I totally agree with Dirk, that Werner Ceuster's and Barry Smith's
> work around "referent tracking" is highly applicable. Both for evolvable
> "instances of uniquely identified representational units of real world
> entities" such as patient records and the recordings of clinical acts of
> observations. As well as for evolvable "representational units designating
> classes and types in ontologies".
> 
> Excellent paper regarding managing evolving ontologies that explains in
> more details the slides Dirk refers to in the AMIA presentationen: A
> Realism-Based Approach to the Evolution of Biomedical Ontologies, that
> explains the tables Dick refers to in Werner's presentation:
> http://ontology.buffalo.edu/bfo/Versioning.pdf
> 
> And also more on referent tracking in the domain of Electronic Health
> Records: A Realism-Based Approach to the Evolution of Biomedical
> Ontologies
> http://ontology.buffalo.edu/medo/Tracking_referents.pdf
> 
> See also the comprehensive paper I think we all can benefit from setting a
> common terminology (such as the quoted above) in the HCLS group: Towards a
> Reference Terminology for Ontology Research and Development in the
> Biomedical Domain:
> http://ontology.buffalo.edu/bfo/Terminology_for_Ontologies.pdf
> 
> Regards
> 
> Kerstin Forsberg
> AstraZeneca
> 
> 
> 
> 
> 
> 





THE INFORMATION TRANSMITTED IN THIS ELECTRONIC COMMUNICATION IS INTENDED ONLY 
FOR THE PERSON OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN CONFIDENTIAL 
AND/OR PRIVILEGED MATERIAL.  ANY REVIEW, RETRANSMISSION, DISSEMINATION OR OTHER 
USE OF OR TAKING OF ANY ACTION IN RELIANCE UPON, THIS INFORMATION BY PERSONS OR 
ENTITIES OTHER THAN THE INTENDED RECIPIENT IS PROHIBITED.  IF YOU RECEIVED THIS 
INFORMATION IN ERROR, PLEASE CONTACT THE SENDER AND THE PRIVACY OFFICER, AND 
PROPERLY DISPOSE OF THIS INFORMATION.

RE: Versioning vs Temporal modeling of Patient State

[Forsberg, Kerstin L]

This is a very good and required discussion.

And I totally agree with Dirk, that Werner Ceuster's and Barry Smith's work 
around "referent tracking" is highly applicable. Both for evolvable "instances 
of uniquely identified representational units of real world entities" such as 
patient records and the recordings of clinical acts of observations. As well as 
for evolvable "representational units designating classes and types in 
ontologies". 

Excellent paper regarding managing evolving ontologies that explains in more 
details the slides Dirk refers to in the AMIA presentationen: A Realism-Based 
Approach to the Evolution of Biomedical Ontologies, that explains the tables 
Dick refers to in Werner's presentation:
http://ontology.buffalo.edu/bfo/Versioning.pdf

And also more on referent tracking in the domain of Electronic Health Records: 
A Realism-Based Approach to the Evolution of Biomedical Ontologies
http://ontology.buffalo.edu/medo/Tracking_referents.pdf 

See also the comprehensive paper I think we all can benefit from setting a 
common terminology (such as the quoted above) in the HCLS group: Towards a 
Reference Terminology for Ontology Research and Development in the Biomedical 
Domain:
http://ontology.buffalo.edu/bfo/Terminology_for_Ontologies.pdf 

Regards

Kerstin Forsberg
AstraZeneca

Re: Versioning vs Temporal modeling of Patient State

[Bijan Parsia]

On Jan 12, 2007, at 9:36 AM, [EMAIL PROTECTED] wrote:

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.

[snip]

The standard lingo for this is that a change to the knowledge base  
due to a change in the *world* is called an *update* whereas a change  
in your knowledge base due to a change in *your knowledge* of the  
(current static) world is called a *revision*. The locus classicus  
for this, IMHO, is:



Following there model theoretic accounts, there is a spate of work  
defining reasoning services that compute the updated or revisied  
knowledge base given a proposed update or revision. E.g., recently:



The utility of model oriented revision and update for expressive  
logics is, IMHO, not fully established, though it is conceptually  
useful in my experience. There is, of course, a large chunk of work  
on revising (and even updating) belief *bases*, that is, attending  
primarily to the *asserted* set of formulae.


Hope this helps.

Cheers,
Bijan.

RE: Versioning vs Temporal modeling of Patient State

[dirk . colaert]

this is the presentation i referred to in my previous mail:

http://www.org.buffalo.edu/RTU/papers/ImageAMIA2006.ppt


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



"Xiaoshu Wang" <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
11/01/2007 23:30

To
"'w3c semweb hcls'" 
cc
"'w3c semweb hcls'" 
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 

RE: Versioning vs Temporal modeling of Patient State

[dirk . colaert]

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" <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
11/01/2007 23:30

To
"'w3c semweb hcls'" 
cc
"'w3c semweb hcls'" 
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 

RE: Versioning vs Temporal modeling of Patient State

[Kashyap, Vipul]

> I need to go, but just want to quickly add another biological example
> that involves DNA sequences (instances of the Sequence class) that have
> been submitted to GenBank. GenBank uses version numbers to keep track of
> the submissions by the same or different labs of the same reference
> sequence. Again, version to a biologist may not be the same as version
> to a computer scientist. What is the context of version?

[VK] I think the last statement is key to this debate. I would model the above
as "source" information associated with each sequence. This in some sense
buttresses my point that content-management notion of versioning doesn't apply
to instances. If we look at the various use cases, it turns out that a rigorous
modeling of information will eliminate the need for versioning.

---Vipul

> 
> Cheers,
> 
> -Kei
> 
>   Kashyap, Vipul wrote:
> 
> >Nigam,
> >
> >This is an interesting example...
> >
> >
> >
> >>Have an example for this one: If the instance is of a the class "Tumor"
> >>then
> >>on giving treatment it changes in size, shape etc, and might ultimately
> >>disappear. On each visit we are observing a different version of the
> tumor
> >>instance [in Tom].
> >>
> >>
> >
> >[VK] Clearly there is a longitudinal aspect to this as the state of the
> tumor
> >changes over time
> >
> >This could be modeled in two ways:
> >
> >Tumor1.state = X at time T1
> >Tumor1.state = Y at time T2
> >...
> >Tumor1.state = "Non-existent" at time Tn
> >
> >Essentially you are modeling state as a multivalued property or as a
> ternary
> >relationship (Tumor, state, Time)
> >
> >Alternatively,
> >
> >Tumor1, v1.state = X
> >Tumor1, v2.state = Y
> >...
> >Tumor1, vN.state = "Non-existent"
> >
> >
> >IMHO, the former representation conveys more information and meaning...
> >So, it may make sense not to confound versioning with temporal
> progression...
> >
> >Look forward to the commounities thoughts on the issue.
> >
> >Cheers,
> >
> >---Vipul
> >
> >
> >
> >
> >
> >
> >THE INFORMATION TRANSMITTED IN THIS ELECTRONIC COMMUNICATION IS INTENDED
> ONLY FOR THE PERSON OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN
> CONFIDENTIAL AND/OR PRIVILEGED MATERIAL.  ANY REVIEW, RETRANSMISSION,
> DISSEMINATION OR OTHER USE OF OR TAKING OF ANY ACTION IN RELIANCE UPON,
> THIS INFORMATION BY PERSONS OR ENTITIES OTHER THAN THE INTENDED RECIPIENT
> IS PROHIBITED.  IF YOU RECEIVED THIS INFORMATION IN ERROR, PLEASE CONTACT
> THE SENDER AND THE PRIVACY OFFICER, AND PROPERLY DISPOSE OF THIS
> INFORMATION.
> 
> >
> >
> >
> >
> 





THE INFORMATION TRANSMITTED IN THIS ELECTRONIC COMMUNICATION IS INTENDED ONLY 
FOR THE PERSON OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN CONFIDENTIAL 
AND/OR PRIVILEGED MATERIAL.  ANY REVIEW, RETRANSMISSION, DISSEMINATION OR OTHER 
USE OF OR TAKING OF ANY ACTION IN RELIANCE UPON, THIS INFORMATION BY PERSONS OR 
ENTITIES OTHER THAN THE INTENDED RECIPIENT IS PROHIBITED.  IF YOU RECEIVED THIS 
INFORMATION IN ERROR, PLEASE CONTACT THE SENDER AND THE PRIVACY OFFICER, AND 
PROPERLY DISPOSE OF THIS INFORMATION.

RE: Versioning vs Temporal modeling of Patient State

[Kashyap, Vipul]

> We are not talking about the Class here. Nothing is happening to the class
> definition and its criteria for membership for an instance are unchanged.
> It is the instance that changes its characteristics and now has
> characteristics that can make it a member of a different class. The two
> classes in question are unchanged.

[VK] True, but Chimezie's question still remains valid. I wonder if someone has
developed guidelines on when something is a version vs a new class?
> 
> So, my example still stands. The next version of the instance now belongs
> to
> a different class (it is still Tom's tumor, now it might be TNM 3 instead
> of
> TNM 1) it is this change in instances that needs to be tracked.

[VK] The only difference is I do not view it as a version in the content
management sense. IMHo, it's more appropriate to view and model as a dynamic
state variable changing over time.

---Vipul
.




THE INFORMATION TRANSMITTED IN THIS ELECTRONIC COMMUNICATION IS INTENDED ONLY 
FOR THE PERSON OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN CONFIDENTIAL 
AND/OR PRIVILEGED MATERIAL.  ANY REVIEW, RETRANSMISSION, DISSEMINATION OR OTHER 
USE OF OR TAKING OF ANY ACTION IN RELIANCE UPON, THIS INFORMATION BY PERSONS OR 
ENTITIES OTHER THAN THE INTENDED RECIPIENT IS PROHIBITED.  IF YOU RECEIVED THIS 
INFORMATION IN ERROR, PLEASE CONTACT THE SENDER AND THE PRIVACY OFFICER, AND 
PROPERLY DISPOSE OF THIS INFORMATION.

RE: Versioning vs Temporal modeling of Patient State

[Kashyap, Vipul]

> It is not as though the state 'non-existent' is replaced with
> another state with a new name, at least that is how I am thinking of
> versioning. The instance data to describe the state of the tumor is
> different based on some action, e.g. passing of time.

[VK] I agree with the above.. I was rather loose in the modeling aspects and
just wanted to convey the basic idea. I wouldn't consider this as versioning
though!




THE INFORMATION TRANSMITTED IN THIS ELECTRONIC COMMUNICATION IS INTENDED ONLY 
FOR THE PERSON OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN CONFIDENTIAL 
AND/OR PRIVILEGED MATERIAL.  ANY REVIEW, RETRANSMISSION, DISSEMINATION OR OTHER 
USE OF OR TAKING OF ANY ACTION IN RELIANCE UPON, THIS INFORMATION BY PERSONS OR 
ENTITIES OTHER THAN THE INTENDED RECIPIENT IS PROHIBITED.  IF YOU RECEIVED THIS 
INFORMATION IN ERROR, PLEASE CONTACT THE SENDER AND THE PRIVACY OFFICER, AND 
PROPERLY DISPOSE OF THIS INFORMATION.

RE: Versioning vs Temporal modeling of Patient State

[Kashyap, Vipul]

In our work on BIRNLex - and even more so in the work the OBI group has been
doing, as well as work from the GO Consortium and the NCI Thesaurus - an effort
to define a set of AnnotationProperties to handle versioning in the TBox is
being assembled and put to use.

[VK] It will be great if you could post a list of these properties on the BIONT
wiki?

 

I'm not at all certain what versioning means in the ABox apart from the sort of
versioning one would apply to all identified resources such as that provided via
LSID, which as we all know here has its pros and cons.

 

[VK] I am of the opinion that ABox versioning isn't required if your domain
model is rich enough and models state and time appropriately ...

 

---Vipul





THE INFORMATION TRANSMITTED IN THIS ELECTRONIC COMMUNICATION IS INTENDED ONLY 
FOR THE PERSON OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN CONFIDENTIAL 
AND/OR PRIVILEGED MATERIAL.  ANY REVIEW, RETRANSMISSION, DISSEMINATION OR OTHER 
USE OF OR TAKING OF ANY ACTION IN RELIANCE UPON, THIS INFORMATION BY PERSONS OR 
ENTITIES OTHER THAN THE INTENDED RECIPIENT IS PROHIBITED.  IF YOU RECEIVED THIS 
INFORMATION IN ERROR, PLEASE CONTACT THE SENDER AND THE PRIVACY OFFICER, AND 
PROPERLY DISPOSE OF THIS INFORMATION.

Re: Versioning vs Temporal modeling of Patient State

[William Bug]

On Jan 11, 2007, at 5:30 PM, Xiaoshu Wang wrote:


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.


Just to be clear, I was quoting Dirk here from his post to this  
thread, not the OBO Foundry.  The wording of the related OBO Foundry  
principles (http://obofoundry.org/) is:


"3. The ontology possesses a unique identifier space within OBO."

"4. The ontology provider has procedures for identifying distinct  
successive versions."


This wording was kept purposefully vague, because there was  
apparently much discussion no real consensus regarding exactly what  
to recommend as an implementation strategy, and strategies might  
differ according the formalism being used (OBO vs. OWL vs. RDF, for  
instance).  At least that was my understanding.


This is very much similar to the strategies that have been devised  
over the last several decades for managing controlled vocabularies 
(CVs).  The A&I industry that uses CVs to index academic literature  
must deal with term deprecation and have done over the years.  One of  
the problems when you are dealing with CVs is, since there is a lack  
of consistent, formally sound underlying semantic framework, even if  
you've developed a means of tracking changes in the CV, and all the  
annotations you've created with the terms - annotations of the  
scientific literature or experimental data repositories - have been  
dated so you can track the chronology of usage relative to the  
evolution of the CV, there is still no clear way to address the issue  
Vipul mentioned, namely how has the change made to a term in the CV  
effected the semantic entailments.  Though CV and thesaurus curators  
have tried to develop best practices over the ages to address this  
specific question (some of which are in SKOS), just as Vipul  
mentions, these are for human consumption at best (and don't really  
do a very effective and consistent job of communicating the changes  
in entailed meaning to humans very well, for that matter).  They most  
definitely do provide what is needed for automatic reasoners to  
negotiate the change in semantic entailment.


Explicit semantic frameworks are designed to over come some of this  
deficit, with their focus on DEFINITIONS.  Many terms in CVs  
completely lacked definitions or when they had them, lacked a  
consistent means to express the intended meaning and usage of a  
term.  The biomedical ontology community has slowly come to recognize  
- with input from applied, formal ontologists, medical  
informaticists, and various C.S. investigators such as logic  
programming & DL experts and computational linguists contributing to  
this field - that there must be a primacy given to definitions (think  
"defined class" in OWL).  Of course, we are still working on the  
preferred means of provided consistent definitions, and it's not at  
all clear where the field currently stands on this issue.   
Practitioners from the fields I list in the previous sentence have  
different ways of specifying what a definition is - though one does  
hope they can all ultimately be kept commensurate (a pipe dream?).


The point Trish was making regarding how this is dealt with  
effectively across formalisms (OBO vs. OWL, for instance) is well  
taken.  I don't believe this has been worked on directly.


However, creating metadata tags to track the evolution of the  
semantic graph is a task OBI has begun to tackle directly (https:// 
www.cbil.upenn.edu/fugowiki/index.php/ 
RepresentationalUnitMetadataTable).  There are many properties -  
still under discussion, as Trish says - this is very much a work in  
progress - specifically designed to track the evolution of the  
underlying semantic graph.  If you search on "Bill Bug follow-up",  
you'll clearly see what I'm referring to.  I group these as the  
AnnotationProperties concerned with details related to "CLASS_ID/ 
CLASS AXIOMS//CLASS ASSERTIONS".  The more I've thought through what  
is presented on that OBO Wiki page - much of it coming from the MSI,  
NCIT, BIRN, & MAGE communities within OBI - the more I think there's  
a need for a even a few more of these properties to track a bit more  
detail on the semantic graph as it evolves over time.


I'm pretty much convinced there's a need to provide this highly  
granular versioning within the TBox.  I completely agree with  
Chimezie's point.  In the ABox, things are completely different,  
though as Kei pointed out, versioning of accession numbers for  
GENBANK entries is certainly an major issue.  To my mind, you can  
think of a GENBANK entry as having a place both in the ABox and the  
TBox, depending on how you believe the implied semantics in that  
artifact are best represented.  There is the experimental evidence  
that led to the original submission of a particular sequence of  
whatever sort and creati

RE: Versioning vs Temporal modeling of Patient State

[Trish Whetzel]

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.
My understanding of the OBO Foundry's wording is that if a term is 
deprecated, it is not recommended for use (because it was split, 
merged, replaced or no longer necessary). However, the deprecated term 
continues to exist in the ontology  and therefore the URI for the 
term persists. Not all data producers, repositories etc. update the 
annotations of their data when an ontology is updated.


With the ontologies from OBO that I am familiar with, when the resource 
is in production use any terms that are deprecated still exist in the 
ontology, but are marked in some way as being deprecated. Perhaps it is 
the notion of what deprecation of a term means WRT to it's URI that is at 
question?


Trish

RE: Versioning vs Temporal modeling of Patient State

[Xiaoshu Wang]

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

Re: Versioning vs Temporal modeling of Patient State

[Kei Cheung]

I need to go, but just want to quickly add another biological example 
that involves DNA sequences (instances of the Sequence class) that have 
been submitted to GenBank. GenBank uses version numbers to keep track of 
the submissions by the same or different labs of the same reference 
sequence. Again, version to a biologist may not be the same as version 
to a computer scientist. What is the context of version?


Cheers,

-Kei

 Kashyap, Vipul wrote:


Nigam,

This is an interesting example...

 


Have an example for this one: If the instance is of a the class "Tumor"
then
on giving treatment it changes in size, shape etc, and might ultimately
disappear. On each visit we are observing a different version of the tumor
instance [in Tom].
   



[VK] Clearly there is a longitudinal aspect to this as the state of the tumor
changes over time

This could be modeled in two ways:

Tumor1.state = X at time T1
Tumor1.state = Y at time T2
...
Tumor1.state = "Non-existent" at time Tn

Essentially you are modeling state as a multivalued property or as a ternary
relationship (Tumor, state, Time)

Alternatively,

Tumor1, v1.state = X
Tumor1, v2.state = Y
...
Tumor1, vN.state = "Non-existent"


IMHO, the former representation conveys more information and meaning...
So, it may make sense not to confound versioning with temporal progression...

Look forward to the commounities thoughts on the issue.

Cheers,

---Vipul






THE INFORMATION TRANSMITTED IN THIS ELECTRONIC COMMUNICATION IS INTENDED ONLY 
FOR THE PERSON OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN CONFIDENTIAL 
AND/OR PRIVILEGED MATERIAL.  ANY REVIEW, RETRANSMISSION, DISSEMINATION OR OTHER 
USE OF OR TAKING OF ANY ACTION IN RELIANCE UPON, THIS INFORMATION BY PERSONS OR 
ENTITIES OTHER THAN THE INTENDED RECIPIENT IS PROHIBITED.  IF YOU RECEIVED THIS 
INFORMATION IN ERROR, PLEASE CONTACT THE SENDER AND THE PRIVACY OFFICER, AND 
PROPERLY DISPOSE OF THIS INFORMATION.


 

Re: Versioning vs Temporal modeling of Patient State

[Nigam Haresh Shah]

> On Thu, 11 Jan 2007, Kashyap, Vipul wrote:
> > Nigam,
> >
> > This is an interesting example...
> >
> >> Have an example for this one: If the instance is of a the class
> "Tumor"
> >> then
> >> on giving treatment it changes in size, shape etc, and might
> ultimately
> >> disappear. On each visit we are observing a different version of the
> tumor
> >> instance [in Tom].
> >
> > [VK] Clearly there is a longitudinal aspect to this as the state of the
> tumor
> > changes over time
>
>   .. snip ..
>
> > IMHO, the former representation conveys more information and meaning...
> > So, it may make sense not to confound versioning with temporal
> progression...
>
> Spot on. I myself have had a hard time trying to grapple with the notion
> of allowing 'content' revision control to trickle into formal knoweldge
> representation and have yet to come across a scenario that demonstrates
> where this makes any sense.
>
> 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 - the extension of both
> classes are no longer the same.  Unless the definition change is
> annotative only and doesn't really have any 'logical' consequences.  In
> which case a SKOS, time-stamped annotation for a human reader is
> sufficient and what we really have in mind.

Hi Chimezie,

We are not talking about the Class here. Nothing is happening to the class
definition and its criteria for membership for an instance are unchanged.
It is the instance that changes its characteristics and now has
characteristics that can make it a member of a different class. The two
classes in question are unchanged.

So, my example still stands. The next version of the instance now belongs to
a different class (it is still Tom's tumor, now it might be TNM 3 instead of
TNM 1) it is this change in instances that needs to be tracked.

Regards,
Nigam.

Re: Versioning vs Temporal modeling of Patient State

[Trish Whetzel]

Hi Bill,

Interesting point.

I'm pretty certain the nature, granularity, and meaning of versioning will 
differ between the TBox and the ABox - at least that's my sense of things and 
the way we've been proceeding on BIRNLex.  What I mean by that is I have a 
pretty good sense of what an appropriate versioning policy is for the TBox. 
In our work on BIRNLex - and even more so in the work the OBI group has been 
doing, as well as work from the GO Consortium and the NCI Thesaurus - an 
effort to define a set of AnnotationProperties to handle versioning in the 
TBox is being assembled and put to use.
Can I point you back to a mail sent yesterday requesting more information 
on how BIRNLex is handling term deprecation and is the date that a term is 
deprecated critical versus the ontology release version in which it was 
deprecated? Have you had a chance to peruse the policy developed (with 
input from Gilberto) for MO? I'm curious to learn of similarities to 
that for BIRNLex. WRT to OBI, I am not aware that the OBI group has 
discussed term deprecation yet since this resource is still in the 
development versus production phase.


Also the resources you mention above are in different ontology 
representations, OWL vs OBO format. What work is the GO Consortium doing 
towards this issue? I am not familiar with the ability to traverse the 
graph to find replacement terms for deprecated terms in the OBO format 
ontologies.


Thanks,
Trish

I'm not at all certain what versioning means in the ABox apart from the sort 
of versioning one would apply to all identified resources such as that 
provided via LSID, which as we all know here has its pros and cons.

Re: Versioning vs Temporal modeling of Patient State

[Trish Whetzel]

Have an example for this one: If the instance is of a the class "Tumor"
then
on giving treatment it changes in size, shape etc, and might ultimately
disappear. On each visit we are observing a different version of the tumor
instance [in Tom].


[VK] Clearly there is a longitudinal aspect to this as the state of the tumor
changes over time

This could be modeled in two ways:

Tumor1.state = X at time T1
Tumor1.state = Y at time T2
...
Tumor1.state = "Non-existent" at time Tn

Essentially you are modeling state as a multivalued property or as a ternary
relationship (Tumor, state, Time)

Alternatively,

Tumor1, v1.state = X
Tumor1, v2.state = Y
...
Tumor1, vN.state = "Non-existent"


IMHO, the former representation conveys more information and meaning...
So, it may make sense not to confound versioning with temporal progression...
Yes, I agree. It seems as though the various states of the tumor can 
exist, but whether they are the same state over time is a different 
question. It is not as though the state 'non-existent' is replaced with 
another state with a new name, at least that is how I am thinking of 
versioning. The instance data to describe the state of the tumor is 
different based on some action, e.g. passing of time.


Trish

Re: Versioning vs Temporal modeling of Patient State

[William Bug]

This brings up an additional aspect of the versioning problem.

I'm pretty certain the nature, granularity, and meaning of versioning  
will differ between the TBox and the ABox - at least that's my sense  
of things and the way we've been proceeding on BIRNLex.  What I mean  
by that is I have a pretty good sense of what an appropriate  
versioning policy is for the TBox.  In our work on BIRNLex - and even  
more so in the work the OBI group has been doing, as well as work  
from the GO Consortium and the NCI Thesaurus - an effort to define a  
set of AnnotationProperties to handle versioning in the TBox is being  
assembled and put to use.


I'm not at all certain what versioning means in the ABox apart from  
the sort of versioning one would apply to all identified resources  
such as that provided via LSID, which as we all know here has its  
pros and cons.


Just my $0.02 on this issue.

Cheers,
Bill

On Jan 11, 2007, at 4:28 PM, Kashyap, Vipul wrote:




Nigam,

This is an interesting example...

Have an example for this one: If the instance is of a the class  
"Tumor"

then
on giving treatment it changes in size, shape etc, and might  
ultimately
disappear. On each visit we are observing a different version of  
the tumor

instance [in Tom].


[VK] Clearly there is a longitudinal aspect to this as the state of  
the tumor

changes over time

This could be modeled in two ways:

Tumor1.state = X at time T1
Tumor1.state = Y at time T2
...
Tumor1.state = "Non-existent" at time Tn

Essentially you are modeling state as a multivalued property or as  
a ternary

relationship (Tumor, state, Time)

Alternatively,

Tumor1, v1.state = X
Tumor1, v2.state = Y
...
Tumor1, vN.state = "Non-existent"


IMHO, the former representation conveys more information and  
meaning...
So, it may make sense not to confound versioning with temporal  
progression...


Look forward to the commounities thoughts on the issue.

Cheers,

---Vipul






THE INFORMATION TRANSMITTED IN THIS ELECTRONIC COMMUNICATION IS  
INTENDED ONLY FOR THE PERSON OR ENTITY TO WHOM IT IS ADDRESSED AND  
MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED MATERIAL.  ANY REVIEW,  
RETRANSMISSION, DISSEMINATION OR OTHER USE OF OR TAKING OF ANY  
ACTION IN RELIANCE UPON, THIS INFORMATION BY PERSONS OR ENTITIES  
OTHER THAN THE INTENDED RECIPIENT IS PROHIBITED.  IF YOU RECEIVED  
THIS INFORMATION IN ERROR, PLEASE CONTACT THE SENDER AND THE  
PRIVACY OFFICER, AND PROPERLY DISPOSE OF THIS INFORMATION.






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, PA19129
215 991 8430 (ph)
610 457 0443 (mobile)
215 843 9367 (fax)


Please Note: I now have a new email - [EMAIL PROTECTED]

Re: Versioning vs Temporal modeling of Patient State

[Chimezie Ogbuji]

On Thu, 11 Jan 2007, Kashyap, Vipul wrote:

Nigam,

This is an interesting example...


Have an example for this one: If the instance is of a the class "Tumor"
then
on giving treatment it changes in size, shape etc, and might ultimately
disappear. On each visit we are observing a different version of the tumor
instance [in Tom].


[VK] Clearly there is a longitudinal aspect to this as the state of the tumor
changes over time


 .. snip ..


IMHO, the former representation conveys more information and meaning...
So, it may make sense not to confound versioning with temporal progression...


Spot on. I myself have had a hard time trying to grapple with the notion 
of allowing 'content' revision control to trickle into formal knoweldge 
representation and have yet to come across a scenario that demonstrates 
where this makes any sense.


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 - the extension of both 
classes are no longer the same.  Unless the definition change is 
annotative only and doesn't really have any 'logical' consequences.  In 
which case a SKOS, time-stamped annotation for a human reader is 
sufficient and what we really have in mind.


Chimezie Ogbuji
Lead Systems Analyst
Thoracic and Cardiovascular Surgery
Cleveland Clinic Foundation
9500 Euclid Avenue/ W26
Cleveland, Ohio 44195
Office: (216)444-8593
[EMAIL PROTECTED]