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 - [EMAIL PROTECTED]




Reply via email to