Re: LANG: Versioning Use Case

In the past year I have given a number of talks on the Semantic Web 
(a list of the 20+ main ones is in the SWCG mailing list archive 
(members only) [A].  Among the top ten questions I'm asked (probably 
in the top 5) is "What do we do about versioning the ontology" -- 
this is also an issue with one of our biggest proposed users - the 
National Cancer Institute is considering releasing their cancer 
vocabulary (used by every NIH-funded cancer researcher among others) 
in OWL.  However, one of their primary concerns is that they release 
monthly updates and want some way to indicate major changes from 
minor ones.  I posit this is a great real world example of Jeff's USE 
case below.  Versioning is also a requirement in our Use Case 
Document.
  I think that I would endorse what Jeff has proposed, but let me make 
a suggestion - why don't we take Jeff's original proposal, but make 
the versioning information extralogical -- in fact, we could put it 
in the owl:ontology declaration, explain the operational semantics, 
and leave it to implementors to decide if they want to deal with it 
in someway -- but the reasoners could ignore them -- essentially 
version, backward-compatible, deprecates, etc. would thus be "human 
readable" comments for now, but in some future release someone could 
consider making them "real"
  I think that would be the easiest way to handle them, but I don't 
think we can go to CR without some versioning construct approved.
  -JH




[A] http://lists.w3.org/Archives/Member/w3c-semweb-cg/2002Sep/0015.html




At 5:27 PM -0400 9/20/02, Jeff Heflin wrote:
>Hello everyone,
>
>At yesterday's telecon I took an action to provide a use case for
>ontology versioning, and in particular backward-compatibility. Here it
>is:
>
>Let's assume that we have an an ontology V0 that has 50 classes. On each
>of 10 different days, we add a new class to this ontology. The proper
>way to do this in OWL (and in RDF, see RDFSS 4.1.2) is to create a new
>namespace for each version. Thus, we now have 11 versions, V0 through
>V10, of our ontology.
>
>I posit that the following two things are desirable:
>
>D1: that we only want to refer to a single namespace in any documents
>that use this ontology. Why? Because, it will be difficult to remember
>which concepts were in which version, and because the alternative
>doesn't scale up well (our documents would keep needing more and more
>namespaces as the Web grows older).
>
>D2: that we would like to be able to integrate resources that committed
>to different versions of this ontology. Since the change is only
>additive, we should be able to merge the graphs of various documents
>that commit to these ontologies and know that a "#Foo" in one version is
>also a "#Foo" in another version. We need to do this because the owners
>of documents that commit to ontologies may be different from the owners
>of the ontologies themselves, and cannot be made to instantly upgrade
>their data. If we don't establish correspondences, then we reduce
>interoperability.
>
>Assuming you agree with these desirable properties, let's examine
>possible solutions to the problem.
>
>Attempt #1:
>Don't have versions at all. Instead simply have each new version import
>the previous version and describe its one new class. However, in this
>alternative, any document that wishes to talk about classes in different
>versions of the ontology must specify the different namespaces for each
>class it mentions. This goes against the first desirable property, D1,
>above. You may ask why should this be any different than when you import
>multiple distinct ontologies. The answer is that in versions, the
>objects are conceptually closely related, and users benefit from keeping
>them organized as such.
>
>Attempt #2:
>Create the new version as a duplicate of the old and add the new class.
>Now, this version has local identifiers for every concept from the old
>ontology, meaning documents can use a single namespace to refer to
>concepts from the ontology (satisfying D1). In order to satisfy D2, we
>have to create links between the concepts in the new version and their
>companions in the prior version. In RDFS, this would be done using
>subClassOf and subPropertyOf (see RDFSS 4.1.3). In OWL, we have the more
>accurate sameClassAs and samePropertyAs. Therefore, the ontology must
>include 50+ sameClassAs statements to specify the correspondence with
>identifiers in the previous version. This is certainly doable, but a
>little unwieldy. It would be very easy to forget one, and becomes
>particularly burdensome if the ontologies are very large.
>
>Attempt #3:
>Provide a simple syntactic sugar for the last part of attempt #2. Call
>this backCompatWith. If an ontology is backCompatWith another ontology,
>then the 50+ sameClassAs statements are implicitly created. Nothing more
>is implied by the semantics, although various advanced application may
>experiment with using this statement in interesting ways. This is
>essentially what I proposed in [1].
>
>Jeff
>
>[1] http://lists.w3.org/Archives/Public/www-webont-wg/2002Sep/0090.html


-- 
Professor James Hendler				  hendler@cs.umd.edu
Director, Semantic Web and Agent Technologies	  301-405-2696
Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
Univ of Maryland, College Park, MD 20742	  240-731-3822 (Cell)
http://www.cs.umd.edu/users/hendler

Received on Friday, 20 September 2002 18:48:48 UTC