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