Re: OWL Syntax

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

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

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

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.

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.


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.


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

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.

The second is semantic:

Ontology( Individual( type( restriction( dp ) ) )

entails

Ontology( DataValuedProperty( dp ) )

according to the direct semantics,

but not when mapped to triples.

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

Ontology( DisjointClasses( classID )  )

entails

Ontology( Class( classID ) )

but not when mapped to triples. (this bug appears a number of times).

All the Class and Property axioms fail to allow for owl:DeprecatedClass and 
owl:DeprecatedProperty.

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

The abstract syntax undermines the I18N requirements agreed by the WG.

Jeremy

Received on Wednesday, 12 February 2003 16:53:51 UTC