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]
