Re: Versioning vs Temporal modeling of Patient State

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 feeling is we should trying to avoid the latter, if we can.

Right now, using CVS and SVN has been an expedient and convenience  
based on tools provided out-of-the-box by such wonderful resources as  
SourceForge.  I think its time to more seriously evaluate the costs &  
benefits of this approach.
>
>
> 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?
I'm certainly be happy to collaborate on this effort.  A correlate of  
Eric M's aphorism might be, "if you're going to take up so much  
bandwidth, you'll eventually have to pay the piper."  ;-)
>
>
> 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.

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