ASS substantive: abstract and concrete syntax

This is a follow up message to my proposed change to AS&S:
http://lists.w3.org/Archives/Public/www-webont-wg/2003Jan/att-0356/01-jjc

Overall, I believe that having the abstract syntax does allow a clear 
semantics to be given to RDF graphs, but I am concerned that every draft to 
date of the AS&S has had a concrete syntax (RDF graph for OWL DL) that has 
either:
- only been described implicitly
- or described in convoluted and difficult to follow text

Moreover the concrete syntax for OWL Lite has never been articulated (except 
implciitly).

I believe that these facts would present  severe difficulties to both tool 
developers and OWL end users in actually using OWL Lite and OWL DL, since it 
is too difficultt:
- for tool developers to understand what is and what is not a legal OWL Lite 
or OWL DL document
- for document authors to understand the same
- and for tool developers to create error messages that communicate to 
document authors would they need to do to fix a document intended to be OWL 
Lite or OWL DL.

I believe that the approach at describing the concrete syntax developed in my 
message would better allow for all three of these.

==

This does involve two significant changes:
- first a change in mentality, away from the abstract syntax as driving the 
show (because of its connection with the semantics), and towards a more 
balanced approach in which concrete syntactical concerns influence the 
abstract syntax (sections 2 and 4 of AS&S should reflect a trade-off between 
the semantic needs and the concrete syntactic needs)

- second a few minor changes to the abstract syntax and mapping rules to make 
the proposed characterization correct. (a current list is detailed below)

I am not proposing that my characterization be normative, (although I do point 
out that it is currently the only correct characterization of the side 
condition on TransitiveProperties).

===

"Minor" changes, in order of magnitude:

- dataRange
     Under my proposal this either needs to be deleted entirely from the 
language (my preference) or assigned a type (e.g. owl:DataRange).

- annotations
    Under my proposal the properties in annotations are owl:ObjectProperty's 
and owl:DatatypeProperty's and can be used elsewhere in an ontology) However 
they may not be used in domain and range constraints, in any restrictions, or 
in transitive, symmetric, functional or inversefunctional properties
   It is open whether we would want to restrict relationships between 
ontologies as only being owl:imports, owl:backwardsCompatibleWith, 
owl:incompatibleWith, owl:priorVersion, or whether we allow this set to be 
user extensible. It is also open whether such relationships may be used 
elsewhere in the ontology (as owl:ObjectProperty's without further 
constraints).

- restrictions
   The abstarct syntax for restrictions needs to be changed to permit exacltly 
one restriction in each restriction construct. This makes no difference to 
the expressive power of language, since every use of the restriction 
construct can be repeated.

- Equivalent descriptions
   The mapping rules are changed slightly to provide n-1 sameClassAs for n 
equivalent classes instead of the current n(n-1)/2.

- DisjointClasses
   The abstract syntax is altered to express this pairwise, instead of 
permitting a list.
  (motivation this is the only place in the mapping rules in which a bnode 
becomes the object of more than triple - since this is an easy rule to 
articulate and understand, it is better to change the abstract syntax and not 
break the rule).
  drawback it is harder to express a list of disjointclasses (but then we 
decided to drop DisjointUnionOf from the concrete syntax - so I don't think 
we saw this as a big worry).
 
- types
   The mapping rules need changes to give every node a type


I think that's it - but I suspect there's a bit more.

==

I would be happy to work with Peter to integrate my text into the AS&S.

Jeremy

Received on Wednesday, 22 January 2003 03:30:17 UTC