Ontology Versions

From OWL
Jump to: navigation, search


<htmlet>hideshow</htmlet>

Intro

Related issues: Issue 15, Issue 21, Issue 24, Issue 90 and Issue 91.


During the December 19th telecon, we discussed two import mechanisms (proposed by Boris Motik and Peter Patel-Schneider).

It seems the main options are to choose between:

  • imports by ontology location
  • imports by ontology name

Is there, or should there be a difference between:

  • importing another ontology and the axioms therein
  • including another ontology and the axioms therein

It was clear from the discussion that choosing between these options has implications for version management. However, wat we mean exactly when we talk about version management is unclear:

  • Should different versions of the same ontology have the same name?
  • What do we consider to be different versions? Different considerations:
    • A change in the axioms contained within the ontology creates a new version
    • Only a `consolidated' or `published' version of an ontology constitutes a version (this is to distinguish between development-time versioning and publication-time versioning).
    • A different location of an ontology is a different version (C:\Temp\... vs. http://www.myuberontologies.org/...)
    • Are equivalent ontologies with different ontology uri's two different versions?
    • Are versions syntactic or semantic?
      • Does stripping an ontology of 'mayIgnore' annotations create a new version?
      • Does stripping a multilingual ontology of rdfs:label's in some language create a new version?
      • A different serialisation of an ontology is a different version (OWL/XML, OWL/RDF, Functional Syntax etc.)
      • Is the OWL Full interpretation of a DL ontology a new version?
  • How do existing version management schemes work?
  • How do tools (TopBraid, Protégé) deal with imports and versions?
  • What does our 'user base' see as versions?
  • How do we express compatibility/incompatibility between ontologies and/or versions of the same ontology (cf. Issue 24)
    • What does compatibility mean? Alternatives:
      • Compatibility corresponds to consistency (two incompatible ontologies in are mutually inconsistent),
      • Compatibility between versions ensures that an importing ontology is not harmed by switching between the two versions. Harm can be anything from inconsistency to untyped resources.

And, what are the current mechanisms (i.e. those available to us from OWL 1.0, RDF, XML) and how do they interact?

  • xml:base
  • Ontology URI
    • Relation between 'Ontology' resource and axioms in RDF serialisation is currently absent
  • default namespace

Goals

Perhaps even more important, what are the goals of this WG wrt. versioning?

  • Provide a normative versioning scheme
  • Provide an analysis of the problem(s), and propose a flexible (maximally compatible) import mechanism
  • Merely clarify the OWL 1.0 versioning and import scheme
  • Complete hands-off

OWL 1.0 Version attributes

Ontology Properties and Annotation Properties

Section 2.1 of the OWL Semantics and Abstract Syntax document (emphasis added):

There are several built-in annotation properties in OWL, namely owl:versionInfo, rdfs:label, rdfs:comment, rdfs:seeAlso, and rdfs:isDefinedBy. In keeping with their definition in RDF, rdfs:label and rdfs:comment can only be used with data literals.

There are also several built-in ontology properties; they are owl:imports, owl:priorVersion, owl:backwardCompatibleWith, and owl:incompatibleWith. Ontology annotations that use owl:imports have the extra effect of importing the target ontology.

Section 7.4 of the OWL Language Reference document states that

  • owl:versionInfo is an annotation property
  • owl:priorVersion, owl:backwardCompatibleWith and owl:incompatibleWith are ontology properties, with owl:Ontology as domain and range

It is clear from this description that these version properties require different versions of an ontology to have different URI's.

Axiom Level Versioning

The OWL Abstract Syntax and Semantics document allows the use of a Deprecated marker on various axioms. These are:

  • OWL Lite class and property axioms, and datatypes:
    • Section 2.3.1.1 Class axioms and datatypes
    • Section 2.3.1.3 Property axioms (both datatype properties and object properties)
    • Annotation and ontology properties cannot be deprecated
    • Restrictions cannot be deprecated (i.e. anonymous classes cannot be deprecated)
  • OWL DL class and property axioms, and datatypes:
    • Section 2.3.2.1 Class axioms and datatypes
    • Section 2.3.2.4 Property axioms (both datatype properties and object properties)
    • Annotation and ontology properties cannot be deprecated
    • Restrictions and descriptions cannot be deprecated (i.e. anonymous classes cannot be deprecated)

Deprecated classes and properties in the Abstract Syntax are mapped onto owl:DeprecatedClass and owl:DeprecatedProperty respectively.

Actually all these deprecations are on the class or property - there are no annotations on axioms in OWL 1.0. (pfps 22:29, 13 January 2008 (EST))

Deprecation does not add semantics, but those committing to an ontology should not use classes marked as deprecated, cf. Section 7.4.5 of the OWL Language Reference document:

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 identifier is said to be of type owl:DeprecatedClass or owl:DeprecatedProperty, where owl:DeprecatedClass is a subclass of rdfs:Class and owl:DeprecatedProperty is a subclass of rdf:Property. By deprecating a 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. 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.

Tool Take-up

OWL Validator

(at [1])

  • An ontology with e.g. an owl:backwardCompatibleWith property is considered OWL Full, as the range (i.e. the compatible ontology) needs to be typed as owl:Ontology.
  • An ontology with deprecated classes and properties is properly recognised as OWL DL/Lite

Pellet

  • An ontology with e.g. a owl:backwardCompatibleWith property is considered OWL Full, as the range (i.e. the compatible ontology) needs to be typed as owl:Ontology (and it usually isn't as it is located in a different .owl file which is not imported).
  • An ontology with deprecated classes and properties is properly recognised as OWL DL/Lite

Protege 4 alpha / OWL API

  • The value of e.g. the owl:backwardCompatibleWith property is asserted as a rdf:Description on save
  • owl:DeprecatedProperty is typed as owl:Class on save, instances of owl:DeprecatedClass lose this type and become 'just' instances of owl:Class

TopBraid Composer

  • Agnostic wrt. ontology properties and class/property deprecation.

Jena

  • (TopBraid uses Jena as RDF/OWL API)


Possible Fixes

Editor's Note: {{{2}}}


In OWL 1.0 each different version has a different URI (cf. ontology versioning properties). We can obtain compatibility by:

  • Adding backwardCompatibleWith, priorVersion, incompatibleWith to OWL 1.1 FS:

ontology := 'Ontology' '(' ontologyURI { import } { compatibility } { annotation } { axiom } ')'
compatibility := backwardCompatible | priorVersion | incompatible
backwardCompatible := 'BackwardCompatible' '(' URI ')'
priorVersion := 'PriorVersion' '(' URI ')'
incompatible := 'Incompatible' '(' URI ')'


  • Convert version properties to a special kind of annotation, e.g.:

Ontology(:thisOntology Annotation(owl:backwardCompatibleWith :previousOntology) Annotation(owl:incompatibleWith :someOtherOntology))

  • If we adopt the annotation space proposal by Bijan, we could define a suggested, non normative version space:

Ontology(:thisOntology AnnotationSpace(http://www.foo.bar/owl-versioning mayIgnore))

EntityAnnotation(Ontology(:thisOntology) Annotation(http://www.foo.bar/owl-versioning owl:backwardCompatibleWith :previousOntology))

EntityAnnotation(Ontology(:thisOntology) Annotation(http://www.foo.bar/owl-versioning owl:incompatibleWith :someOtherOntology))

In OWL 1.0 deprecation only on class, property and datatype, but not on axioms in general. This seriously cripples the deprecation mechanism: axioms (read: anonymous classes) determine most of the semantics.

  • Add DeprecatedClass, DeprecatedProperty and DeprecatedDatatype to FS:

axiom := classAxiom | objectPropertyAxiom | dataPropertyAxiom | fact | declaration | entityAnnotation | deprecatedClassAxiom | deprecatedObjectPropertyAxiom | deprecatedDataPropertyAxiom

... etc.

  • Convert deprecation types to a special kind of annotation.

EntityAnnotation(OWLClass(:DClass) Annotation(rdf:type owl:DeprecatedClass))

EntityAnnotation(ObjectProperty(:dproperty) Annotation(rdf:type owl:DeprecatedProperty))

  • If we adopt the Annotation Space proposal by Bijan, we can (again) use the non normative version space.

Ontology(:thisontology AnnotationSpace(http://www.foo.bar/owl-versioning mayIgnore))

EntityAnnotation(OWLClass(:DClass) Annotation(http://www.foo.bar/owl-versioning rdf:type owl:DeprecatedClass))

EntityAnnotation(ObjectProperty(:dproperty) Annotation(http://www.foo.bar/owl-versioning rdf:type owl:DeprecatedProperty))

Mapping the OWL 1.0 version properties to annotations in 1.1 has the advantage that it allows us to circumvent the tricky (re)interpretation of what owl 1.0 versioning *means*.

Other advantage is that we can define deprecation annotations on axioms. But the disadvantage is that we may lose deprecation information when round tripping between OWL 1.0 and OWL 1.1:

  • If entity annotations in 1.1 are mapped onto regular properties in OWL 1.0, we lose their 'annotation-like' qualities on reinterpreting the 1.0 ontology as 1.1, and the OWL 1.0 ontology may well turn into Full
  • If entity annotations are dropped entirely, well... we lose the annotations.