Re: OWL Syntax

From: Jeremy Carroll <jjc@hpl.hp.com>
Subject: Re: OWL Syntax
Date: Wed, 12 Feb 2003 22:54:22 +0100

> > This is a significant change to the abstract syntax, affecting just about
> > every construction. 
> 
> That is because there are bugs or problems with just about every construction 
> changed.
> See list below.
> 
> Some of the changes are trivial, like I have used different case conventions. 
> I tried to keep those to a minimum, but a higher priority was to get as much 
> as possible to be machine processable as easily as I could.
> 
> >  It is also a significant change to the features of OWL
> > Lite and OWL DL. 
> 
> 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.

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

> > What are the benefits arising from this major change?  I don't see anything
> > that justifies even a moderate amount of effort.
> 
> You will need to work through the bugs with your document one way or another, 
> sooner or later.
> 
> 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?

> A further change that I plan to withdraw if there is agreement to move forward 
> on the basis of my revised syntax and your annotation semantics is the small 
> amount of interaction between properties used in annotations and other 
> properties. This has similar impact to fixing the transitive property side 
> condition bug.



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

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

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

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

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

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

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

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

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

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

> There is no provision in the abstract syntax for the ontology versioning 
> vocabulary agreed by the WG, which is in fact prohibited.

Ditto.

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

> Jeremy

peter

Received on Wednesday, 12 February 2003 17:53:56 UTC