AS&S more comments

I thought I should try and list other thoughts on AS&S that I have had but
not yet sent to the list.

I have labelled each point from A to Q (omitting I and O) but they are not
in that order.


2 Abstract Syntax
=================
A:
No ability to annotate annotations
(see
http://lists.w3.org/Archives/Public/www-webont-wg/2003Jan/0411.html
)

B:
A plausible change would be to permit (unnamed) descriptions as part of the
ontology i.e.

directive ::= 'Annotation(' URIreference URIreference ')'
            | 'Annotation(' URIreference dataLiteral ')'
	    | 'Imports(' URI ')'
	    | axiom
	    | fact
          | description

this would make the articulation of what are legal RDF graphs more
attractive in that the current restriction that all unnamed descriptions
must be used somewhere would go.
This makes it more conformant with the constraints on unnamed individuals
which is that they can be used once only.

C:

suggest replace
axiom ::= 'DisjointClasses(' description { description } ')'

with

axiom ::= 'DisjointClasses(' description description  ')'

this does not impact expressive power of language, but means that the
mapping rules can be set up to respect a no bnode is the object of more than
triple rule, that is easy to articulate.

P:
suggest drop the concept of imports closure from the abstract syntax
completely
(see N below). I think only the RDFS version works.

3 Direct Semantics
==================
D:
I think the annotation entailment problem could be attacked by having
separate concepts of consistency and entailment in the direct semanitcs and
for the exchange syntax.
This could fix the problem by defining the exchange syntax entailment as:
  RDF/XML-doc-A OWL DL-entails RDF/XML-doc-B
if
  abstract-doc-A entails abstract-doc-B
and
  RDF/XML-doc-A RDFS-entails annotations-in-RDF/XML-doc-B

where abstract-doc-A is an arbitrary abstract syntax version of the imports
closure of RDF/XML-doc-A.

4 Mapping
=========
E:
I am revising my acceptance of the description of OWL DL in RDF graphs being
informative.
Certain classes of developer will use this description more than the very
difficult to use mapping rules. I believe that should divergences emerge
that we should no prejudge whether the correct erratum is a change in the
description of the RDF graphs, or a change in the mapping rules, or a change
in the abstract syntax.

F:
The mapping rules require that XML schema datatypes be declared as
rdfs:Datatype iff they are used in some part of the graph other than in a
cardinality constraint. I suggest this be relaxed by:
-  making the mapping rule
datatypeID => datatypeID rdf:type rdfs:Datatype .
  optional for the built-in XML Schema Datatypes
- making a new mapping rule
*nothing* => datatypeID rdf:type rdfs:Datatype .
  that can be applied any number of times

This would allow the ommission of declarations for the built-in types, and
not require deletion of declaration that were no longer used, or imported
from a set of user defined datatypes.

G:
Suggest
EquivalentClasses(description1 … descriptionn)
=>
T(description<sub>i</sub>) owl:sameClassAs T(description<sub>i+1</sub>) .
1?i<n

This allows blank nodes to conform with the no bnode is the object of more
than one triple rule.

Q: on EquivalentClasses and unmodified DisjointClasses
Also unclear as to whether a blank node resulting as the main node of
T(descriptioni) for one instance is the same or not as the blank node
resulting for another instance. e.g.
Equivalen(<a>,unionOf(<a>,<b>),<b>)
could transform unionOf(<a>,<b>) into triples once (my understanding) or
twice (once to say its the sameAs <a>, the second time to be the sameAs
<b>).

L: introduction
I think this could be improved with additional text along the lines of:
[[
OWL DL has semantics defined over the abstract syntax
and a concrete syntax consisting of a subset of RDF graphs.
Hence it is necessary to relate specific abstract syntax ontologies
with specific RDF/XML documents and their corresponding graphs.
This section defines a many-to-many relationship between
abstract syntax ontologies and RDF graphs. This is done
using a set of nondeterministic mapping rules.
Thus to apply the semantics to a particular RDF graph it is necessary
to find one of the abstract syntax ontologies that correspond with that
graph under the mapping rules and to apply the semantics to that
abstract ontology.
The mapping is designed so that any of the RDF/XML graphs
that correspond to a particular abstarct ontology have the same meaning,
as do any of the abstract ontologies that correspond to a
particular RDF/XML graph.
Moreover, since this process cannot be applied to RDF graphs
that do not have corresponding abstract syntax forms, the mapping
rules implicitly define a set of graphs, which syntactically
characterise OWL DL in RDF/XML.
Since running the mapping rules backwards is difficult
an alternative syntactic characterization of OWL DL in RDF graphs
is also given.
]]


M: rule for imports
The rule
Imports(URI) => U owl:imports URI .
should be replaced with
Imports(URI) => U* owl:imports URI .
where U* is any URI

This is because the subject of an imports triple:
- may be any of the documents in the imports closure
- may be subject to an xml:base directive
- is completely ignored in OWL Full imports closure rules

This probably holds with the Annotations too - that some care needs to be
taken over not constraining U very much at all. This needs more thought.

N: 4.2
In the first Definition:  there is a sequencing problem with imports
closure.
How can we apply the direct imports closure to an RDF graph, without first
finding its abstract form.
Suggest change the hyperlink to be to the rdfs version of the concept rather
than the direct version. I suspect this makes the concept of imports closure
redundant in the abstract syntax (see P).




(note I am suggesting the wholesale replacement of your descriptive text,
and making it to be on the same normative status as the mapping rules
definition of OWL DL and OWL Lite)

5: RDFS compatible
==================
(I have still not properly reviewed this part)
H:
owl:Property is not part of the language
(IOP can be part of the model theory)

J:
Suggest that it would be clearer, and more correct, if
the following were specified as subclasses of owl:ObjectProperty
  owl:InverseFunctionalProperty
  owl:TranstiveProperty
  owl:SymmetricProperty

I believe the current (nearly DL)-entailments hold in the RDFS version of
the DL semantics unnecessarily:

<owl:DatatypeProperty rdf:ID="p">
   <rdfs:comment>An empty property</rdfs:comment>
   <rdfs:range rdf:resource="&xsd;negativeInteger"/>
   <rdfs:range rdf:resource="&xsd;nonNegativeInteger"/>
</owl:DatatypeProperty>

misentails

<owl:TranstiveProperty rdf:ID="p"/>

K:
suggest that the third condition on OWL Full
IOP = CEXTI(SI(rdf:Property))
be strengthened to
IOOP = CEXTI(SI(rdf:Property))

Received on Thursday, 23 January 2003 06:01:06 UTC