- From: Jeremy Carroll <jjc@hpl.hp.com>
- Date: Thu, 13 Feb 2003 08:30:53 +0100
- To: www-webont-wg@w3.org
Peter:
>> > This is a significant change to the abstract syntax, affecting just about
>> > every construction.
Jeremy:
>> That is because there are bugs or problems with just about every
>> construction changed.
>> See list below.
>>
>>
[...]
>> The changes are of three sorts:
>> - adding things agreed by the group but inexplicable left out of the WGs
>> document.
>> - adding things to enhance compatible with RDF and RDFS (explicitly listed)
>> - two specific changes called out as feature enhancements in the diffs list
>> * Named DataRanges (rather than having to use copy/paste)
>> * Individual Comparisons with Unnamed Individuals
>> which are permitted in the english description in section 4.2 of AS&S.
>>
>> There are no other feature changes.
>
>What about allowing descriptions as axioms? I do not believe that this
>significant change fits into any one of the three categories given above.
Minor syntactic variant on
EquivalentClasses(description)
already permitted in AS&S.
>
>> > It will require major changes to the semantics document,
>> > over and above any changes to the abstract syntax.
>>
>> Bluff. Give an example (other than the annotations stuff).
>
>There has to be an addition to the direct semantics to accommodate
>descriptions as top-level constructs.
Treat as
EquivalentClasses(description)
> There has to be an addition to the
>proof of the correspondence theorem to handle this construct. This is just
>for one of the many changes to the syntax.
The other *new* constructs are things like the classComparisons which
correspond directly to EquivalentClasses or DisjointClasses axioms
with two members.
Semantically all that is necessary is a minor transformation
from the revised syntax to the old form.
In terms of wordsmithing that might be an unsatisfactory
approach - but there is no new *semantics* here.
>> A far reaching bug is the transtive property side condition being
>> misarticulated. You have not proposed a fix. My proposed fix of treating
this
>> syntactic constraint in the syntax does involve changes to all rules
>> involving individual-valued properties.
>
>What is the misarticulation here?
In AS&S I read:
"Individual-valued properties that are transitive, or that
have transitive sub-properties, may not have cardinality
conditions expressed on them,"
as I have previously pointed out, all properties have the empty
property as a sub-property, and thus this condition prohibits
cardinality constraints in any ontology which includes the
empty property.
Moreover, I believe that the intended meaning of this
phrase includes consideration of owl:inverseOf, which
is not at all apparant, i.e. the following breaks the
intended side condition, but not the written words:
ObjectProperty( ivp1 inverseOf( ivp2 ) )
ObjectProperty( ivp3 super( ivp2 ) Transitive )
EquivalentClasses(
restriction( ivp1 cardinality(3) )
)
This construct is syntactically prohibited in my revision.
>> To list the bugs with the other productions:
>>
>> directive ::= 'Annotation(' URIreference URIreference ')'
>> | 'Annotation(' URIreference dataLiteral ')'
>> | 'Imports(' URI ')'
>>
>> do not allow annotations on or imports within imported ontologies, since
the
>> subject URI is fixed for all. Fixed using a repeating header constuction.
>
>Huh? Why cannot an imported ontology have annotations?
FileA:
<owl:Ontology rdf:about="">
<dc:creator>Smith</dc:creator>
</owl:Ontology>
FileB:
<owl:Ontology rdf:about="">
<owl:imports rdf:resource="FileA"/>
</owl:Ontology>
To tell whether FileB is in OWL Lite, OWL DL or OWL Full,
we take its import closure and get the following set
of triples
<FileA> rdf:type owl:Ontology .
<FileA> dc:creator "Smith" .
<FileB> rdf:type owl:Ontology .
<FileB> owl:imports <FileA> .
In the mapping rules in AS&S all four triples only match
productions that use the U symbol as the subject of a
triple
e.g.
Imports(URI)
=>
U owl:imports URI .
This symbol is defined by:
"the URI of this document is given as U. "
Hence, U must be <FileA> by considering the first
triple and be <FileB> by the third triple.
This gives a contradicition and the example is in OWL
Full.
One of the many minor bugs in the syntax in AS&S.
>
>> datatypeID ::= URIreference
>> classID ::= URIreference
>> individualID ::= URIreference
>> datavaluedPropertyID ::= URIreference
>> individualvaluedPropertyID ::= URIreference
>>
>> result in ambiguous constructs since the typing gets lost in the transition
>> from the lhs to the rhs. Fixed by replacing the RHS with terms.
>
>There is a source of ambiguity in the abstract syntax that was introduced
>in one of the changes to the abstract syntax. In my opinion a better way
>to remove this ambiguity would be to appropriately tag restrictions as
>datavalued restrictions or individualvalued restrictions.
I don't believe I have understood this -
it feels like cross-purposes.
If I see an abstract syntax construction
Class( <FileA#c> )
and another
ObjectProperty( <FileA#c> )
there is a problem - but to know that I need to know
the grammar in enough detail to know that the
parse tree for the class construction uses
the classID non-terminal, and the parse tree for
individualValuedProperty uses the individualValuedPropertyID
non-terminal.
I personally find it clearer if this is made
explicit in the abstract syntax construction vis:
Class( classId(<FileA#c>) )
and
ObjectProperty( individualValuedPropertyID(<FileA#c>) )
This is not a big deal, but then a lot of things that
make life a little harder do add up.
So this change should be seen as a suggested editorial
improvement - try listening to helpful suggestions.
>
>> individual ::= 'Individual(' [ individualID ] { annotation }
>> { 'type(' type ')' } { propertyValue } ')'
>> propertyValue ::= 'value(' individualvaluedPropertyID individualID ')'
>> | 'value(' individualvaluedPropertyID individual ')'
>> | 'value(' datavaluedPropertyID dataLiteral ')'
>>
>> accept for the oprthogonal annotations issue the proposed changes are
trivial
>> But I see it as an editorial improvement to uniformly use the nonterminal
>> symbol as the functor in the abstract syntax tree, avoiding any confusion
>> with the hasValue construct.
>
>Why should this be a problem?
When looking at the mapping rules the reader has to
take terms embedded within the T(_) construction in the
middle column, expand them with the grammar to some
new constructs and then match those new constructs against
some other row in the left hand column.
It appears that you have not done this as much as I have.
My user feedback to you is that it would be easier if
the words I have to search for are used as consistently
as possible.
A consistency suggestion is to "uniformly use the nonterminal
symbol as the functor in the abstract syntax tree".
So - it is a problem because the principal user of the
mapping rules to date has found it a source of unnecessary
mental effort.
Is it a great problem, no?
But since we are intending our documents to be read by
many thousands of people I suggest you save them that
small superfluous mental effort that you put me through
and accept this editorial suggestion.
>
>> restriction ::= 'restriction(' datavaluedPropertyID
>> { 'allValuesFrom(' dataRange ')'}
>> { 'someValuesFrom(' dataRange ')'}
>> { 'value(' dataLiteral ')' }
>> { cardinality } ')'
>>
>> changed to
>>
>> restriction [P1] ::= Restriction( complexDataPropID AllValuesFrom(
>> dataRange ) { restrictionComparison } )
>> [P2] | Restriction( complexDataPropID SomeValuesFrom(
>> dataRange ) { restrictionComparison } )
>> [P3] | Restriction( complexDataPropID Cardinality(
>> smallInt ) { restrictionComparison } )
>> [P4] | Restriction( complexDataPropID MinCardinality(
>> smallInt ) { restrictionComparison } )
>> [P5] | Restriction( complexDataPropID MaxCardinality(
>> smallInt ) { restrictionComparison } )
>> ...
>> as strict alternatives with one condition in each restriction (and fix to
>> EquivalentClasses problem in the { restrictionComparison } ).
>
>This change moves away from the frame syntax, which was one of the guiding
>sources for the abstract syntax.
Yes - this change is not intended as an improvement in the abstract syntax,
it is regretfully necessary to solve problems in the concrete syntax.
>
>> There are two problems with the published restriction syntax - the most
>> pressing for me is an aesthetic one - that the mapping rule for multipart
>> restrictions creates particularly strange constructs when combined with
>> complete class descriptions in OWL Lite. Trying to articulate those is a
>> mug's game.
>
>Perhaps.
Have a go - you have not tried to articulate OWL Lite triples
in English. That particular mapping rule can apply recursively
so an OWL Lite document can contain a named class
defined as an intersectionOf a list of [named classes]
or [unnamed restrictions] or [unnamed intersections of
unnamed restrictions or unnamed intersections of length 1
containing unnamed restrictions or further unnamed intersections
of length 1]
It is not acceptable to inflict such a disaster on our users.
>
>> The second is semantic:
>>
>> Ontology( Individual( type( restriction( dp ) ) )
>>
>> entails
>>
>> Ontology( DataValuedProperty( dp ) )
>>
>> according to the direct semantics,
>
>I don't believe that this is entailed in the direct semantics.
So
Ontology( Individual( type( datavalued-restriction( dp ) )
ObjectProperty(dp) )
is a legal and consistent ontology?
(using your notation from below)
>
>> but not when mapped to triples.
>
>There is an issue here, however. In response to requests, I tried to make
>the abstract syntax easier to use, which resulted in the antecedant
>ontology being ambiguous as to whether dp is an datatype property or an
>individualvalued property. My suggestion would be to change
>`restriction' to `datavalued-restriction' or something similar.
I think that only addresses a small part of the issue
I am not convinced that ease-of-use of the abstract syntax
should be the primary driver. Concrete syntaxes need to be
easy to use; the abstract syntax should be clear, which
is likely to lead to verbosity.
>
>> axiom ::= 'DisjointClasses(' description { description } ')'
>> | 'EquivalentClasses(' description { description } ')'
>>
>> as well as suffering from a very complex mapping rule, these constructions
>> also suffer from a similar semantic bug
>
>What complex mapping rule? It does result in O(n^2) triples, but so what?
See my recent post
http://lists.w3.org/Archives/Public/www-webont-wg/2003Feb/0156.html
which gives a worked example of this rule.
the problem is the impact on the bnode structures which
become distinctly non-tree like.
>
>> Ontology( DisjointClasses( classID ) )
>>
>> entails
>>
>> Ontology( Class( classID [partial] ) )
>>
>> but not when mapped to triples. (this bug appears a number of times).
>
>I don't see this as a bug. The correspondence theorem only works for
>separated vocabularies, and the vocabulary separation axiom will get this
>entailment back in the RDF-compatible semantics.
A repeated point-of-view difference is that you seem to worry
only about theoretical niceties rather than practical usability.
You seem to be technically correct about the correspondence
theorem.
The practical requirement is that given a first RDF/XML document
(say an empty one) and given a second RDF/XML document
say one with a single owl:Class element (corresponding
to the abstract syntax form above), does the first entail
the second?
The answer from AS&S is to map backwards from the
RDF as triples to an abstract syntax form, and then to
ask the question on the abstract syntax form.
That backward mapping is nondeterministic, and
the boolean yes/no is also nondeterministic with
both answers possible.
The correspondence theorem was meant to prevent that.
Since it doesn't it shows that the theorem statement
is flawed.
Fixing this problem is isolation is straight forward,
in my revised version I have applied the fix to
EquivalentProperties.
It requires at least two properties to be equivalent.
With DistinctIndividuals though the considerations
are different.
As in your english expression of the triple syntax I
would like:
[[
A node x in G is an all-different node if
...
and there is exactly one other triple
...
of one of the following forms, where l is a non-empty list
whose elements are individuals
x owl:distinctMembers owl:nil .
x owl:distinctMembers l .
]]
This is another mistake in AS&S since the abstract syntax rule
requires at least one individual so the first case cannot happen.
I think the correct fix to this one is to change the
abstract syntax rule to allow an empty list of
different individuals.
The motivation is that currently this is
the only place in the graph requiring a non-empty list of
individuals.
The other mapping rule for DifferentIndividuals (mapping to
O(n^2) owl:differentFrom triples) should be changed either
by deleting it (as in my revised version) or by requiring it
to have n >= 2.
>
>> All the Class and Property axioms fail to allow for owl:DeprecatedClass and
>> owl:DeprecatedProperty.
>
>Yeah, this late change didn't get into the abstract syntax.
It took me only a few minutes to add it to my rules ...
Also a few more would be needed for the semantics.
>
>> There is no provision in the abstract syntax for the ontology versioning
>> vocabulary agreed by the WG, which is in fact prohibited.
>
>Ditto.
This is more complicated syntactically since it only applies to
ontologies ...
>
>> The abstract syntax undermines the I18N requirements agreed by the WG.
>
>The abstract syntax does not currently allow for language tags. This
>should be changed.
Good.
How about Unicode Normal Form C?
What's your take on the internationalization issues to do with URIrefs?
Do you have any though as to how to permit Ruby annotation in
labels in OWL Lite (a feature available in both DAML+OIL and RDFS)?
>
>> Jeremy
>
>peter
>
Jeremy
Received on Thursday, 13 February 2003 02:30:33 UTC