draft formal objection Issue 5.26 OWL DL Syntax

This is a draft formal objection that I will either withdraw or confirm at 
tomorrows telecon, depending on the outcome of my proposal [1] and feedback 
from HP colleagues.

0. Summary
==========
The resolution of this issue results in:
- a recommendation that does not adequately inform implementors what they 
need to do
- is unnecessarily difficult to implement correctly
- will often be implemented incorrectly (in fact might never be implemented 
correctly)
- will result in interoperability failures between implementations
- causes document authors unnecessary difficulty in creating syntactically 
correct documents

In short, the resolution imposes an unnecessary cost on the OWL community.

1. Background
=============
I raised the OWL DL Syntax issue [2] with the goal of making it possible to 
both articulate and implement systems that can recognise which RDF graphs 
correspond to OWL DL abstract ontologies.
This ability is fundamental to the operation of OWL DL, since it is part of 
the link between Web documents in OWL and their meaning as specified in 
section 3 of the Semantics and Abstract Syntax WD [3].
Graphs which do not correspond to OWL DL abstract ontologies are in OWL 
Full - the semantics of these graphs can be related to OWL DL counterparts 
by using the OWL Full semantics found in [7].
The resolution [4] of the issue without B.1 and B.2, is a significant 
improvement on the earlier WDs (such as [5]).
However, the omission of parts B.1 and B.2 leaves a significant hole 
concerning the abstract syntax constructs DisjointClasses and 
EquivalentClasses and their RDF/XML equivalents: triples with predicate 
owl:disjointWith and owl:equivalentClass.

2. Example of problem
=====================

2.1 EquivalentClasses
=====================
Given an OWL DL document (namespaces omitted) such as:

<rdf:RDF>

<!-- definitions of descriptions and/or restrictions -->
   <owl:Class rdf:nodeID="a">
     <owl:unionOf rdf:parseType="Collection">
        <owl:Class rdf:ID="A"/>
     </owl:unionOf>
   </owl:Class>

   <owl:Class rdf:nodeID="b">
     <owl:unionOf rdf:parseType="Collection">
        <owl:Class rdf:ID="B"/>
     </owl:unionOf>
   </owl:Class>

   <owl:Class rdf:nodeID="c">
     <owl:unionOf rdf:parseType="Collection">
        <owl:Class rdf:ID="C"/>
     </owl:unionOf>
   </owl:Class>

<!-- equivalent and disjoint classes -->
   <owl:Class rdf:nodeID="a">
     <owl:equivalentClass rdf:nodeID="b"/>
   </owl:Class>

   <owl:Class rdf:nodeID="b">
     <owl:equivalentClass rdf:nodeID="c"/>
   </owl:Class>

</rdf:RDF>

An implementation has to run the mapping rules [6] in reverse to find the 
abstract form:

EquivalentClasses( unionOf( <A> )
                    unionOf( <B> )
                    unionOf( <C> ) )

This is made decidedly difficult when subtly different variants of the 
RDF/XML cannot be subject to such a reverse mapping.
For example the following is not in OWL DL, according to the last call 
candidate, but is, in fact, in OWL Full:

<rdf:RDF>

<!-- definitions of descriptions and/or restrictions -->
as above
<!-- equivalent and disjoint classes -->
   <owl:Class rdf:nodeID="a">
     <owl:equivalentClass rdf:nodeID="b"/>
   </owl:Class>

   <owl:Class rdf:nodeID="a">
     <owl:equivalentClass rdf:nodeID="c"/>
   </owl:Class>

</rdf:RDF>

However, in OWL Full it has exactly the same meaning as the original document.

2.2 DisjointClasses
===================

Correct treatment of the DisjointClasses construct involves checking that 
the owl:disjointWith triples form non-overlapping cliques with sufficient 
crosslinks between them. e.g.


<rdf:RDF>

<!-- definitions of descriptions and/or restrictions -->
as above
<!-- equivalent and disjoint classes -->
   <owl:Class rdf:nodeID="a">
     <owl:disjointWith rdf:nodeID="b"/>
   </owl:Class>

   <owl:Class rdf:nodeID="a">
     <owl:disjointWith rdf:nodeID="c"/>
   </owl:Class>

   <owl:Class rdf:nodeID="b">
     <owl:disjointWith rdf:nodeID="c"/>
   </owl:Class>

</rdf:RDF>

Can be mapped in reverse to

DisjointClasses( unionOf( <A> )
                    unionOf( <B> )
                    unionOf( <C> ) )

Because the last three parts of the RDF/XML form a complete (undirected) 
graph K3 over the nodes _:a, _:b and _:c.

The related


<rdf:RDF>

<!-- definitions of descriptions and/or restrictions -->
as above
<!-- equivalent and disjoint classes -->
   <owl:Class rdf:nodeID="a">
     <owl:disjointWith rdf:nodeID="b"/>
   </owl:Class>

   <owl:Class rdf:nodeID="a">
     <owl:disjointWith rdf:nodeID="c"/>
   </owl:Class>

</rdf:RDF>

Does not have any such inverse mapping, and is hence not in OWL DL, but in 
OWL Full - however, it's meaning in OWL Full is the same as documents 
corresponding to the abstract syntax form:

DisjointClasses( unionOf( <A> )
                    unionOf( <B> ) )
DisjointClasses( unionOf( <A> )
                    unionOf( <C> ) )

More complicated examples involving say two cliques of four and three 
description nodes could be formed - if there are seven distinct nodes then 
the example is in OWL DL, if any of the nodes is shared between the two 
cliques then the example is in OWL Full, but its meaning is unchanged.


3. Articulation of the RDF graphs in OWL DL
===========================================

Earlier working drafts had text [8] trying to articulate which RDF graphs 
are in OWL DL, in a fashion that did not rely on running the mapping rules 
backwards. This text did not attempt to articulate the constraints on 
owl:disjointWith and owl:equivalentClass (was known as owl:sameClassAs).
Without such text, with a correct articulation of these triples, 
implementors are left with a problem that has defeated the working group.

A specific issue is the constraints on blank nodes within the graph.
Excluding triples with predicate owl:disjointWith and owl:equivalentClass, 
these constraints are easy to articulate and implement: the blank nodes 
must form a tree. With the current approach to these two constructs this 
constraint is not true, and worse, it is hard to say precisely what is and 
what is not allowed in terms of the blank node structure involving such 
triples.

4 Implementation Issues
=======================
Different implementors will respond to this in different ways. A brave few, 
may correctly implement the spec - managing to charectrize the set of RDF 
graphs that are in OWL DL as defined by the mapping rules.
Others will take short cuts, and accept as OWL DL documents that are, 
according to the spec, actually OWL Full. These will probably be mapped 
into abstract syntax forms that do have the same meaning (in OWL Full) as 
input. However, different implementors will choose different short cuts, 
and accept and reject different subsets of OWL Full as close enough to OWL DL.

5. Proposed solutions
=====================

5.1 Solution initially proposed by Patel-Schneider
==================================================

This is articulated in [4] parts B.1 and B.2 and was made at the technical 
plenary in Cambridge in March 2003.
This removes the irregularities by allowing fairly arbitrary sharing of the 
bnodes involved.
The constraints on bnode structures are then:
[[
A blank node which occurs as the object of more than one triple must 
correspond to a restriction or description.
Directed cycles of blank nodes may not occur in OWL Lite and in OWL DL must 
contain at least one triple with property owl:disjointWith or 
owl:equivalentClass.
]]
All the examples in this message are then in OWL DL.

5.2 Structure copying proposal
==============================

This is fully articulated in, for instance, the appendix at the end of [1].
The EquivalentClasses and DisjointClasses axioms get mapped, effectively, 
as sets of axioms between only pairs of descriptions. This results in the 
blank node structures in OWL DL being strictly tree like, and hence both 
easy to articulate and implement.
None of the examples in this message would then be in OWL DL.

6. Pros and Cons of Proposed Solutions
======================================
The group has rejected the first solution apparently because of potential 
technical difficulties with an important proof [9]. While the desire for 
proven correctness is important, my judgement is that, in the absence of 
such a proof, the clear risk of lack of interoperability (with the WG's 
resolution) should be given priority over the slight risk that there is a 
technical error making the proposed solution unsound.

The group is unconfortable with the second proposal apparently because: it 
results in unnecessary bloat in the RDF graphs when mapping from the 
abstract syntax, and because it may prove difficult when doing the reverse 
mapping to reconstruct EquivalentClasses and DisjointClasses axioms with 
more than two components. Neither of these concerns seems as compelling to 
me as the risk of interoperability failure. (In fairness, this proposal has 
not been discussed at great length, since the Patel-Schneider proposal is 
clearly better).

7. Conclusion
=============

(a reiteration of the summary)

The resolution of this issue results in:
- a recommendation that does not adequately inform implementors what they 
need to do (see part 3 above)
- is unnecessarily difficult to implement correctly (see parts 4 and 5 above)
- will often be implemented incorrectly (in fact might never be implemented 
correctly) (see part 4 above)
- will result in interoperability failures between implementations (see 
part 4 above)
- causes document authors unnecessary difficulty in creating syntactically 
correct documents (see examples above)


References
==========

[1]
http://lists.w3.org/Archives/Public/www-webont-wg/2003Mar/0191.html
[2]
http://lists.w3.org/Archives/Public/www-webont-wg/2003Jan/0489.html
[3]
http://www.w3.org/TR/owl-semantics/direct.html
[4]
http://lists.w3.org/Archives/Public/www-webont-wg/2003Mar/0066.html
[5]
http://www.w3.org/TR/2003/WD-owl-semantics-20030203/
[6]
http://www.w3.org/TR/owl-semantics/mapping.html#4.1
[7]
http://www.w3.org/TR/owl-semantics/rdfs.html#5
[8]
http://www.w3.org/TR/2003/WD-owl-semantics-20030203/mapping.html#4.2
[9]
http://www.w3.org/TR/owl-semantics/proofs.html#A.1

Received on Wednesday, 26 March 2003 06:13:04 UTC