Living in the XML and RDF world

Tags

HistoryEdited Apr 15, 2010 2:42 PM by Living in the XML and RDF world…

Where OWL fails, another OWL arises

What happened previously


In the SKOS spec you find a list of Class & Property Definitions and Integrity Conditions numbered from S1 to S62.
Most of these definitions and constraints are already covered by the existing SKOS OWL1 ontologies (available in Full and DL versions).
However some definitions and conditions could not be expressed in OWL1.

This is the list:
  • S13: skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties .
  • S14: A resource has no more than one value of skos:prefLabel per language tag .
  • S27: skos:related is disjoint with the property skos:broaderTransitive.
  • S46 : skos:exactMatch is disjoint with each of the properties skos:broadMatch and skos:relatedMatch .
  • S55: The property chain (skosxl:prefLabel, skosxl:literalForm) is a sub-property of skos:prefLabel.
  • S56: The property chain (skosxl:altLabel, skosxl:literalForm) is a sub-property of skos:altLabel.
  • S57: The property chain (skosxl:hiddenLabel, skosxl:literalForm) is a sub-property of skos:hiddenLabel.
  • S58: skosxl:prefLabel, skosxl:altLabel and skosxl:hiddenLabel are pairwise disjoint properties .
Hence the question if these could be expressed in OWL2 as defined by W3C.

I tried to use OWL2 for cases
In these 4 cases my conclusion was very hard: that OWL2 as defined by W3C was pretty useless for the case.
I tried to implement the same skos conditions using SPIN/SPARQL and that went fairly easy and painless.

This conclusion attracted some interest and motivated Holger Knublauch of TopQuadrant to write a blog entry with the title "WHERE OWL fails".

His main points were:
  • OWL is hard-coded against specific design patterns, and anything that goes beyond those patterns cannot be expressed.
  • The choice of supported design patterns is heavily influenced by the theory of Description Logics being theoretically sound but the 'usefulness in practice' questionable.
This triggered a response of Kendall Clark of C&P heavily disagreeing.

Since I'm a happy user of both TopBraid Composer of TopQuadrant and Pellet of C&P, I would like to add my point(s) of view.

Before we continue I must make clear that in this discussion we are talking about 3 different things:
  • SPIN, the constraint and construct language developed by Holger Knublauch and implemented in the TBC suite of tools, but also available in open source
  • OWL2 with an open world assumption as described by W3C and criticized by Holger
  • OWL2 with a closed world assumption as implemented in Pellet ICV made by Clark & Parsia, from now on referred to as OWL2IC.

Do they disagree?

Let's start with constraint checking.

From a distance I think they both more agree than Kendall is willing to admit.

They both agree that:
  • in a lot of use cases the Open World Assumption of OWL2 is counter-intuitive and counter-productive (Why integrity constraints?)
  • checking closed world constraints is best being done using SPARQL
They only differ in opinion on how the constraint checking SPARQL queries need to be generated.
  • In the case of SPIN, you need to write the SPARQL yourself.
  • In the case of OWL2IC, you write OWL axioms which are transformed then in the background to SPARQL queries.
I do not have a firm opinion on this one.
Jeni Tennison reacted on Twitter that you have a similar situation in the XML world:
XML Schema/RELAX NG vs Schematron: declarative versus rule-based constraints and both are considered useful.
Although there is a difference with the SPIN - OWL2IC divide: XML SChema and RelaxingNG do not generate Schematron in the background.
For people that want to do that you can use the XSD2Schematron converter from Rick Jelliffe, but I digress.

Some additional points to take into consideration:
  • The writing of SPARQL queries is not that obvious. This is also one of the rationales behind the development of the Linked Data API. cf. slide
    So indeed, if well done, a declarative approach can make writing constraints easier for certain types of users.
    On the other hand is my experience and on the XML and RDF side that some constraints can only be expressed using rules; so I would say that this approach is more powerful, as being proved also in the context of S14.
    Easier versus powerful or maybe when we grow up, we get a combined solution such as in the upcoming XSD 1.1. (see also the suggestion of Evren Sirin in the context of S14.)
  • SPIN is more than a constraint checking language, as being proved by the solution for the property chain inference which could not be expressed by OWL2.
But I would say: let the market decide which approach is preferred. There is surely a need to have something to validate RDF. Time for the W3C to step in?

Do they disagree?

Of course, they disagree on the importance of OWL2.

For TopQuadrant OWL2 is just one and optional piece within SW applications.
"But this makes OWL just one out of a catalog of vocabularies, on the same level as SKOS or FOAF or SIOC or GoodRelations. "
The flagship product of Clark&Parsia is Pellet, the leading OWL2 DL reasoner; so it's obvious where they stand.
And I can imagine one gets nervous when OWL2 is not accompanied by drumrolls.
However Holger's opinion is according to me well balanced.
I agree on Holger's point 1: OWL 2 (DL) implies indeed some constraints on what you can model, which doesn't always fit what you need and want. This was the whole point of my series.
Concerning point 2: I also experienced myself more than once that OWL DL reasoning can take some time, but I hope and expect that clever engineering will make things better in the future.

But if you need and want OWL2, you need and want Pellet.
One main and sufficient reason: the explain feature which helps me solve the bugs in my head.

Let the software speak

The good point of this whole discussion was that this triggered Clark & Parsia to ameliorate their OWLIC implementation in Pellet ICV of which a new version 0.4 was released yesterday.
An overview of my test results is given in the table below.
Details can be found in updated versions of the respective blog entries S14, S13, S27, S55.
SKOS Constraint SPIN OWL2 OWL2IC
S14 Y + - -
S13 Y + - +
S27 Y + - +
S55 N + - -

OWL-API and SKOS

I take the opportunity to discuss some SKOS related issues I encounter with every software that's built upon the OWL API, being the Protégé's 4, the Neon Toolkit.

Importing the skos-xl ontology at http://www.w3.org/2008/05/skos-xl in your own ontology.
This skos-xl ontology contains itself another owl:imports statement of the core skos ontology:
<owl:imports rdf:resource="http://www.w3.org/2004/02/skos/core"/>
This indirect import gets lost during import.
The result of this loss is that due to some OWL2 magic the property skos:definition becomes an Object Property while it has been defined originally as an Annotation Property. ???
You can correct this loss by doing a direct import of the skos core ontology . This direct import works, but doesn't correct the issue mentioned above. Furthermore this import cannot be saved. ???

Also all annotation properties get doubled as datatype properties. The explanation given today on the Protégé list:
"Actually this happens in part because it appears that the skos ontology is inconsistent with the OWL 2 specifications. There it says that
If an ontology has an ontology IRI but no version IRI, then a different ontology with the same ontology IRI but no version IRI should not exist.
However skos has two distinct ontologies with the same name."

Conclusion
I'm afraid that one of the more popular SW vocabularies being SKOS and OWL2 do live in separate worlds and that hence you better don't use tools that are too hardwired to OWL2.






Comments