Re: Versioning vs Temporal modeling of Patient State

Vipul,


On 2007-01-12 10:21, "Kashyap, Vipul" <VKASHYAP1@PARTNERS.ORG> 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.
> 
>

Received on Friday, 12 January 2007 16:07:11 UTC