ISSUE 5.14: Revised proposal to close ontology versioning

Hello everyone,

Based on feedback via e-mail and the telecon of 11/21, here is a revised
proposal for ontology versioning. This message is divided into the core
proposal, and two options about how it should be included in OWL.


CORE PROPOSAL
---------------
I propose to add the following identifiers to the OWL namespace:

priorVersion
backCompatWith
deprecatedClass
deprecatedProperty

In short, none of these identifier will have any additional impact on
the semantics. I will now describe each of these in turn.

priorVersion
-------------
Triple usage: <newdoc> priorVersion <olddoc>

The ontology identified by <olddoc> is a priorVersion of the one
identified by <newdoc>. This has no meaning in the model theoretic
semantics other than that given by the RDF(S) model theory. However, it
may be used by software to organize ontologies by versions.


backCompatWith
---------------
Triple usage: <newdoc> backCompatWith <olddoc>

The ontology identified by <newdoc> is a a later version of the one
identified by <olddoc>, and is backward compatible with it. In
particular, this indicates that all identifiers from the previous
version have the same intended interpretations in the new version. Thus,
it is a hint to document authors that they can safely change their
documents to commit to the new version (by simply updating namespace
declarations and imports statements to refer to the URL of the new
version). If backCompatWith is not declared for two versions, then it
should be assumed that they are incompatible. Like priorVersion, this
has no meaning in the model theoretic semantics other than that given by
the RDF(S) model theory.

Note, this approach does not address the problem described in Section
3.2 of the Requirements Document (under RDF(S) Support). There, we gave
an example where we wanted to "fix" an incorrect definition of Dolphin.
Solving this problem would require versioning capabilities that would
change the model theoretic semantics, but at this time it is not clear
what the correct approach would be. A later version of OWL may address
this issue.


deprecation:
---------------
Triple Usage: 	<classId> rdf:type <owl:DeprecatedClass> or 
		<propertyId> rdf:type <owl:DeprecatedProperty>

Deprecation is a feature commonly used in versioning software (for
example, see the Java programming language) to indicate that a
particular feature is preserved for backward-compatibility purposes, but
may be phased out in the future. Here, a specific identifer is said to
be of type DeprecatedClass or DeprecatedProperty, where DeprecatedClass
is a subclass of rdfs:Class and DeprecatedProperty is a subclass of
rdf:Property. By deprecating the term, it means that the term should not
be used in new documents that commit to the ontology. This allows an
ontology to maintain backward-compatibility while phasing out an old
vocabulary (thus, it only makes sense to use deprecation in combination
with backward compatibility). As a result, it it easier for old data and
applications to migrate to a new version, and thus can increase the
level of adoption of the new version. Once again, this has no meaning in
the model theoretic semantics other than that given by the RDF(S) model
theory. However, authoring tools may use it to warn users when checking
OWL markup.


Example:
--------

<owl:Ontology rdf:about="">
   <rdfs:label>Vehicle Ontology, v. 1.1</rdfs:label>
   <owl:backCompatWith
rdf:resource="http://www.example.org/vehicle-1.0">
   <owl:priorVersion rdf:resource="http://www.example.org/vehicle-1.0">
</owl:Ontology>


<!-- assume Automobile is now the preferred term for Car -->
<owl:DeprecatedClass rdf:ID="Car" />

<owl:Class rdf:ID="Automobile" />
   <owl:sameClassAs rdf:resource="#Car" />
</owl:Class>

<!-- assume hasDriver is obsolete and its inverse drives is preferred
-->
<owl:DeprecatedProperty rdf:ID="hasDriver" />

<owl:Property rdf:ID="drives" >
   <owl:inverseOf rdf:resource="#hasDriver" />
</owl:Property>

<!-- assume a hasWheels property should no longer used (maybe because a
more specific numWheels property is in favor) -->
<owl:DeprecatedProperty ID="hasWheels" />

<!-- other class and property definitions follow -->


Additions to http://www.w3.org/2002/07/owl
--------------------------------------------

<rdf:Property rdf:ID="priorVersion">
   <rdfs:domain rdf:resource="#Ontology" />
   <rdfs:range rdf:resource="#Ontology" />
</rdf:Property>

<rdf:Property rdf:ID="backCompatWith">
   <rdfs:domain rdf:resource="#Ontology" />
   <rdfs:range rdf:resource="#Ontology" />
   <rdfs:subPropertyOf rdf:resource="#priorVersion" />
</rdf:Property>

<rdfs:Class rdf:ID="DeprecatedClass">
   <rdfs:subClassOf resource="Class" />
</rdfs:Class>

<rdfs:Class rdf:ID="DeprecatedProperty">
   <rdfs:subClassOf resource="Property" />
</rdfs:Class>


OPTIONS:
Two options have been suggested for how this proposal would be
incorporated into OWL.

Option #1:
-----------
Make the proposal normative. The reference, guide, and feature synopsis
would be updated appropriately.

Option #2:
----------
Make the proposal non-normative. Include it as an appendix to the
reference. In the guide, recommend that this approach be used when
versioning is important to a user.

I prefer Option #1. If we go with option #2, then we have to demote
Requirement R6 (Versioning information) to an objective. I think this is
a mistake, because I have heard from numerous potential users that they
consider some form of versioning to be essential. Others have also
demonstrated a need for ontology versioning on the Semantic Web. See for
example:

- Klein, M. and Fensel, D. Ontology Versioning on the Semantic Web. In
First International Semantic Web Working Symposium (SWWS'01), 2001. At:
http://www.semanticweb.org/SWWS/program/full/paper56.pdf

They state that it is essential that you be able to know the chain of
versions and which versions are backward-compatible. The priorVersion
and backCompatWith features serve this purpose.

- Dynamics Research Corporation. DRC VES (Versioning) Ontology. At:
http://orlando.drc.com/daml/Ontology/VES/3.2/drc-ves-ont.daml

They define a DAML+OIL ontology for versioning. This ontology includes a
previous property (like the proposed priorVersion) property, and a
deprecated property (although it's mispelled in the ontology).

Additionally, prior versions and backward compatibility are an essential
feature of SHOE [1]. Furthermore, in my experience with SHOE, I
discovered that one of the biggest omissions from the language was
deprecation. 

Finally, the cost of these features to implementors are very low. There
is no required behavior for any tools. Also, users are not required to
do versioning at all. However, by making it normative, we ensure that
users and tools that want to do basic versioning will be compatible.

Jeff

[1] http://www.cs.umd.edu/projects/plus/SHOE/

Received on Monday, 2 December 2002 17:10:21 UTC