Re: OWL Syntax

From: Jeremy Carroll <jjc@hpl.hp.com>
Subject: Re: OWL Syntax
Date: Thu, 13 Feb 2003 08:30:53 +0100

[...]

> 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.

Agreed, there is no new semantics in this case, just a revision of
various bits and pieces of the rest of the document.  However, there are
changes required even for this case.

On the other hand, some other changes, such as allowing
sameClass/differentClass on descriptions that are embedded in other
descriptions, is new semantics.  This particular change means that things
like axioms can be embedded inside descriptions, requiring a treatment
different from anything currently in the direct semantics.

> >> 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.

Yes, this is a problem.

> 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.

I was hoping that this had been fixed, but I see now that the wording is
inadequate. 

> >> 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.

Yes, this is a bug.  

> >
> >> 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.

Actually, the abstract syntax and direct semantics themselves don't have a
problem with this pair of constructs.  The problem only arises on the RDF side.

> 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.

This way of doing things does make it clearer that the class and property
are different, which may indeed be better.

> >
> >> 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.

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.

> >> 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)

Actually the situation is more complex than this.  There is a mapping bug
lurking under here, which I had not appreciated.  In the current situation
the translation to triples would be non-deterministic in an unallowable
way, because a change to the mapping for property names requires that their
status as data or object properties be known.  This needs to be fixed.

One fix is to tag each use of a property, either by tagging the restriction
or tagging the property.  Once this is done, and the mapping rules changed
accordingly, the entailment follows on both sides.

> >
> >> 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.

Yes, I see that this is a good idea.  I had hoped otherwise.

> >> 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.

> >> 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.

How is this related to theory vs practice?

> 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.

Actually the issue here is different, and different from what I thought it
was.  I was working from my remembrance of an old version of the mapping
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.  

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.  

> 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.)

> 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.  

> 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.

> >> 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?

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.

peter

Received on Thursday, 13 February 2003 06:18:17 UTC