A perspective on ontology versioning

To paraphrase Jim:  In the past several years I've been building 
ontologies and doing research in the general area of ontology and one of 
the top ten, probably top five, issues that has emerged is versioning.

Regarding how to deal with it in OWL, I find myself on the fence.  I want 
to stress that this is not because I don't care, in fact I care quite a 
bit, but I just don't know at this stage what a good course of action 
would be.  Here are a few notes from my perspective, in case someone is 
interested.   It's constructed as an almost desultory argument with 
myself, but I think it is a fair summary of both sides of the issue:

- Ontology versioning is a very important issue in real world ontology 
use. 

- As Ian has often said of other things, however, it is a current research 
issue and I am a bit reluctant to see us make a committment to something 
that isn't well understood in the research community.

- Still, it would be disappointing if we couldn't do something more than 
simply "a comment" (as Jim proposed), even if that comment is of some 
standard form that we claim we will look at later.  It seems to me the 
capability to make comments exists without OWL.  If this is one of the top 
ten questions asked about OWL, then it seems to me this answer would not 
be very satisfying to those grappling with the problem today.

- But of course, in software, versioning is almost never part of the 
language used to specify the software.  CVS, SCCS, RCS, etc., (kinds of 
version control software) all use extra-language documentation (comments) 
or filesystem features to do fairly course-grained versioning.  It is only 
"by contract" that one version of software component is consistent with 
another (where "by contract" I mean that the author of the software simply 
declares it so).  Such systems, given a standard version tag, could easily 
be made to work with ontology artifacts when viewed as files.

- However, while the issues of ontology versioning are seductively similar 
to those of software versioning,  there are some subtle points where they 
can be differentiated.  If an ontology is taken to be a declarative 
logical and/or deductive specification of meaning (which I note software 
is NOT), then there should be ways in which more information about 
versions can be specified declaratively and provably, FAR easier than with 
software.  Furthermore, if the role of an ontology language is to support 
computational means to enforce and deduce the consequences of the 
specifications, then it also makes sense that a specification of versions 
should fit into a computational framework.

- Nevertheless, ontology versioning is extremely complex, since it 
requires a very difficult distinction between the syntax and the semantics 
of the ontology artifact - what is being versioned, the real-world classes 
and relations the ontology talks about, or the individual statements (or 
collections of them) in the language being used?  How are these 
"versionable units" circumscribed?

- There does seem to be a higher level, more course-grained and tractable 
view, which is basically that proposed by Jeff: treat "Owl:ontology"s as 
versionable artifacts of which you can state one basic provable thing: 
that one version is logically consistent with another.  This seems like a 
fairly useful thing to say, especially if you take the more traditional 
view that an ontology does not generally contain instances (with a few 
exceptions), but merely specifies the classes and relations available to 
describe instances.  Having a consistency guarantee between versions means 
that any data that "worked" with the previous version of the ontology will 
"work" with the new one.

- This is far more difficult than it sounds, however, because the 
association between statements in the new ontology version and statements 
in the old version will not be easy to align.  As a practical matter, it 
seems quite hard, and it doesn't seem as if you'd be gaining anything more 
than you would by simply importing the old version, and stating just the 
monotonic additions in the new version.

- That view unfortunately ignores another practical matter: ontologies, 
even small ones, that are spread out and fragmented as, in this case, a 
chain of imports, are extremely difficult to manage.   There are huge 
maintainability arguments for keeping large chunks together.  Much of this 
could be addressed by tools, but not all.

- This also ignores "prior-version" and "deprecates" since they seem to be 
basically comments (ie their meaning is outside the language).

Finally, much of what I'm saying here is based on my own belief that the 
purpose for an ontology language like OWL is to go beyond "meaning by 
contract".  We already have technology that allows one person to say, 
"this is what I mean by X".  Ontology languages shoudl allow us to more 
precisely define the meaning of terms and then automatically and more 
reliably explore the logical consequences of what we say. 

-Chris

PS I wrote this message rather hastily, so if anything seems disparaging 
it was not intended as such.

Dr. Christopher A. Welty, Knowledge Structures Group
IBM Watson Research Center, 19 Skyline Dr.
Hawthorne, NY  10532     USA 
Voice: +1 914.784.7055,  IBM T/L: 863.7055
Fax: +1 914.784.6078, Email: welty@us.ibm.com

Received on Monday, 23 September 2002 14:23:07 UTC