RE: OWL Syntax

Only techical discussion and clarifications ...
> > >
> > >> 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  }  )
> > >> ...


> > 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.
>
> I do not believe that the above is correct description of the OWL Lite
> triples.   In particular, I don't see how this construction can be carried
> out recursively in OWL Lite.
>

Consider

Ontology(Individual(
     type(restriction( op, cardinality(1) ))
          ) )

at some point we get to
T(restriction( op, cardinality(1) ))

non deterministically we match:


restriction(ID component1 . componentn)

=>

_:x owl:intersectionOf
  T(SEQ(restriction(ID component1).
   restriction(ID componentn))) .

So we generate

_:x owl:intersectionOf _:l .

and apply T(SEQ(restriction( op, cardinality(1) )))
this gives
_:x owl:intersectionOf _:l .
_:l rdf:type rdf:List .
_:l rdf:first T(restriction( op, cardinality(1) )) .
_:l rdf:rest rdf:nil .
and we get the recursive application of the sort
I described.

This could be blocked by requiring n>=2, but we still
end up with the ability to have complete classes in OWL
Lite mapping into named intersections with unnamed intersections
as components.

> > >> 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.
>
> But this is not an issue with the mapping rule, instead being at most an
> issue of characterising the result.

But the mapping rules need to be used backwards - if the result of
a rule is too difficult to characterise (or sufficiently difficult
that advanced users cannot do it) then people will never get
from the RDF/XML exchange syntax to the abstract syntax.

>
> > >> Ontology( DisjointClasses( classID )  )
> > >>
> > >> entails
> > >>
> > >> Ontology( Class( classID [partial] ) )
> > >>
> > >> but not when mapped to triples. (this bug appears a number of times).
[ .. snip ..]
> rules.  In the current mapping rules,
>
>  Ontology( DisjointClasses( classID )  )
>
> maps to the empty set of triples, and
>
>  Ontology( Class( classID [partial] ) )
>
> maps to
>
>   classID rdf:type owl:Class .
>
> or to
>
>   classID rdf:type owl:Class .
>   classID rdf:type rdfs:Class .
>
> There is no significant non-determinism here.

The non-determinism I had in mind was from the empty RDF/XML document to
  Ontology( DisjointClasses( classID )  ) for an arbitrary classID.

>
> There is, however, a bug with the treatment of DisjointClasses, which is
> probably best fixed by requiring at least two classes in a DisjointClasses
> (and in EquivalentClasses as well).
>
> > The correspondence theorem was meant to prevent that.
> > Since it doesn't it shows that the theorem statement
> > is flawed.
>
> The issue here is what happens if a name only occurs in the consequent.
> The correspondence theorem was written to prevent that, and it thus papers
> over the situation here.
>
Only if all the vocabulary used in the abstract form
is also used in the concrete form. Which means extra
care in the mapping rules.

> > 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.
>
> I agree that this is a good idea.  (I generally like syntax to be as
> liberal as possible, but there are extra considerations in OWL that place
> extra constraints on the syntax.)

The concrete syntax has aspects which are decidedly non-liberal, combined
with liberality in other places - a clearer set of design considerations
would make it more usable.


>
> > 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.
>
> I agree that there is a part of the specification here that will never be
> satisfied, and thus can be removed.  However, I don't see what force this
> motivation has.

To make the concrete syntax easier to understand it is helpful to reduce the
number of cases that need to be considered. Since we already need
potentially empty lists of individuals in owl:oneOf constructions, it is,
IMO, appropriate to allow potentially empty lists of individuals in the
owl:distinctMembers construction. Changing the abstract syntax to permit
that seems like lower cost than the introduction of a new syntactic category
(a list of one or more individualIDs) into the concrete syntax.

>
> > 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.
>
> If you delete it, then there is no way to have owl:differentFrom
> triples in
> an OWL DL triple ontology.  I'm not in favour of this change.   Requiring
> at n>=2 is a better solution, I think.

In my revision I replace that function with individualComparison constructs
on the individuals - this was motivated by wanting to permit unnamed
individuals in such constructs, yet not wanting the complex bnode patterns
already discussed for EquivalentClasses.


> > >> 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?
>
> No idea.
>
> > What's your take on the internationalization issues to do with URIrefs?
>
> No idea.
>
> > 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)?
>
> I don't even know what this is.

The point of the last three is that the abstract syntax can, and should,
piggy back off work already done in this area by RDF Core (I was the lead on
this work).
The suggested words are in
http://sealpc09.cnuce.cnr.it/jeremy/owl-syntax/2003-12-Feb/dl-syntax.html
and (without hyperlinks)
[[
A uriref is an RDF URI reference as defined in RDF Concepts.

A language is a language identifier as defined in RDF Concepts.

A lexicalForm is a lexical form as defined in RDF Concepts.
]]
assuming RDF Core don't get too much grief from the I18N people at Last
Call, this should cover OWL as well - except for the Ruby case, which also
requires the use of XMLLiteral.
I will ask Martin Durst to help with a Ruby test case.

Jeremy

Received on Thursday, 13 February 2003 07:14:03 UTC