Re: OWL Syntax

Peter asked for some motivation for the proposed changes.

Off-list it also been suggested that I should give an example or summary for 
those who don't want to get into the detail.

The key goal is to replace the text of 4.2 of AS&S with something 
+ clearer, 
+ easier to implement, and 
+ more reliably correct.


There are other orthogonal goals to do with illustrating alternatives on the 
issues of RDF compatibility, xml:lang and rdf:XMLLiteral.


As an example we will consider the following DL ontology under AS&S.

Ontology(
  EquivalentClasses(
     restriction( dp1 cardinality(1) )
     restriction( dp2 allValuesFrom( xsd:byte ) )
     restriction( dp3 cardinality(1) )
  )
)

where dp1, dp2 and dp3 are datavaluedPropertyID's
and xsd:byte is a well-known datatype.

Later we will consider the corresponding Ontology under the revised syntax.

Mapping this to triples we use

EquivalentClasses(description1 … descriptionn) 
=>
T(descriptioni) owl:sameClassAs T(descriptionj) . 1=<i<j=<n 

which is read in conjunction with "When the transformation of a component is 
used as the subject or object of a triple, the transformation of the 
construct is part of the production (but only once per production)" (see 
section 4.1 of AS&S).

and we get the following triples

%  restriction( dp1 cardinality(1) )
_:a rdf:type owl:Restriction .
_:a owl:onProperty <dp1> .
_:a owl:cardinality "1"^^xsd:nonNegativeInteger .

% dp1
<dp1> rdf:type owl:DatatypeProperty .

% restriction( dp2 cardinality(1) allValuesFrom( xsd:byte ) )
_:b rdf:type owl:Restriction .
_:b owl:onProperty <dp2> .
_:b owl:allValuesFrom xsd:byte .


% dp2
<dp2> rdf:type owl:DatatypeProperty .

%  restriction( dp3 cardinality(1) )
_:c rdf:type owl:Restriction .
_:c owl:onProperty <dp3> .
_:c owl:cardinality "1"^^xsd:nonNegativeInteger .

% dp3
<dp3> rdf:type owl:DatatypeProperty .

% EquivalentClasses
_:a owl:sameClassAs _:b .
_:a owl:sameClassAs _:c .
_:b owl:sameClassAs _:c .

The difficulty here is that the bnode _:c is the object of two triples, one of 
the very few places where this is permitted in the mapping rules of AS&S; but 
it is only permitted when the owl:sameClassAs triples form a pattern that can 
be generated by this mapping rule (e.g. deleting one but not two of these 
triples moves the graph into OWL Full).

This example shows that with the current text the problem of identifying 
whether a graph is OWL DL or not, is difficult, and essentially involves 
running the mapping rules backwards.
It is hardly surprising that the English description misarticulates the 
condition when it says: "Therefore the definition triples of any description 
or datarange form a tree."

So the revised syntax was constructed by looking at both the abstract and the 
concrete syntax and trying to make the conditions on the concrete syntax both 
easy to articulate and correct, by, if necessary, making small changes to the 
abstract syntax, without impacting its expressive power.

However, given the number of problems and irregularities in the mapping rules, 
and the number of further bugs and omissions from the abstract syntax, the 
number of proposed changes is quite large.

To look at the same example in the revised syntax:
- the EquivalentClasses axiom has been dropped, and it is replaced by 
permitting  SameClassAs( ) decorations within any class, restriction or 
description.
Thus the equivalent abstract syntax form is:

Ontology(
    Restriction( 
        ComplexDataPropID( dp1 ) Cardinality(1)
        SameClassAs( 
          Restriction( 
              ComplexDataPropID( dp2 ) 
              AllValuesFrom( xsd:byte ) 
         )  )
        SameClassAs( 
          Restriction( 
              ComplexDataPropID( dp3 ) 
              Cardinality(1)
         )  )
    )
)

The difference to highlight is that the SameClassAs assertions are now 
syntactically part of the definition of one of the restrictions. Each one is 
mapped into one triple. The tree like structure of the abstract syntax form 
then ensures that the bnodes are also tree structured in the concrete form.

In triples this comes to

%  Restriction( 
%       ComplexDataPropID( dp1 ) Cardinality(1)
_:a rdf:type owl:Restriction .
_:a owl:onProperty <dp1> .
_:a owl:cardinality "1"^^xsd:nonNegativeInteger .

%  ComplexDataPropID( dp1 )
<dp1> rdf:type owl:DatatypeProperty .

% Restriction( 
%              ComplexDataPropID( dp2 ) 
%              AllValuesFrom( xsd:byte ) 
_:b rdf:type owl:Restriction .
_:b owl:onProperty <dp2> .
_:b owl:allValuesFrom xsd:byte .


%  ComplexDataPropID( dp2 )
<dp2> rdf:type owl:DatatypeProperty .

%  Restriction( 
%              ComplexDataPropID( dp3 ) 
%             Cardinality(1)
_:c rdf:type owl:Restriction .
_:c owl:onProperty <dp3> .
_:c owl:cardinality "1"^^xsd:nonNegativeInteger .

%  ComplexDataPropID( dp3 )
<dp3> rdf:type owl:DatatypeProperty .

% First   SameClassAs
_:a owl:sameClassAs _:b .

% second SameClassAs
_:a owl:sameClassAs _:c .
 
And the _:b owl:sameClassAs _:c triple is not produced nor allowed.

When coming at the triples, I have no idea how to use the description of the 
published document to show that the first set of triples is a legal OWL DL 
graph and the second isn't (according to the published doc). Nor do I know 
how to show it is not OWL Lite. It is theoretical possible to run the mapping 
rules backwards, and then judge whether the resulting Abstract Syntax form is 
OWL Lite or not - however you have to non-deterministically generate all 
possible solutions and show they are all OWL DL before determining that the 
graph is OWL DL.

When using the revised syntax one goes to the triple tables, we will start 
with the OWL Lite ones
http://sealpc09.cnuce.cnr.it/jeremy/owl-syntax/2003-12-Feb/lite-triples.html

Condtion 2 says "No blank node occurs as the object of more than one triple. "
Thus the first set of triples is not in OWL Lite (and similarly not in OWL 
DL).

Condition 7 says 
"Every blank node is assigned to one of the following categories:  ..."
and of those the only one that is allow to have an rdf:type of owl:Restriction 
is the category "restriction".

Thus we have seen that the blank nodes _:a, _:b and _:c are restricitions.

However no triple of the form

restriction owl:sameClassAs restriction 

appears in the triple tables; thus the document is not an OWL Lite document.

We now consider the OWL DL table,
http://sealpc09.cnuce.cnr.it/jeremy/owl-syntax/2003-12-Feb/dl-triples.html
 and we similarly conclude that _:a, _:b and _:c are restrictions 

In the paragraph at
http://sealpc09.cnuce.cnr.it/jeremy/owl-syntax/2003-12-Feb/dl-triples.html#blank-dl-restriction
we read "There may be additional triples in which such nodes are subjects as 
listed in the main triple table. " (The opposite sentence was present in the 
same position in the lite document).
The first triple in the main table matches the owl:sameClassAs triples, and so 
these are OK.

We also need to check the other conditions; the only tricky bit is whether the 
urirefs <dp1>, <dp2>, <dp3> are simpleDataPropIDs (for annotations) or 
complexDataPropIDs (for general use in an ontology).
Either category would match the rdf:type owl:DatatypeProperty triples.
But only the latter matches the owl:onProperty triples.
So for this graph we have to choose complexDataPropID for all three.

Jeremy

Received on Wednesday, 12 February 2003 16:18:36 UTC