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