ACTION 20030502#3 gk: review 4.1 of OWL AS&S

Re:  http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003May/0031.html

[[
ACTION 20030502#3 gk review 4.1 of AS&S especially the translation to 
triples table, with an eye on implementation.
]]

I've spent about half a day looking at the "abstract syntax" (it actually 
looks like a quite concrete serialization to me), and have started to 
sketch a Haskell implementation of the mapping [see attachment].  I come to 
the following conclusions:

1.  I do believe that I could implement a mapping to RDF based on this 
description, but with a fair amount of guesswork.

2.  I think the presentation of the mapping leaves much to be desired.  I 
could not have started to grasp what was going on without actually trying 
to think about the details of an implementation.

-----

Concerning: http://www.w3.org/TR/owl-semantics/mapping.html

More comments on section 4 (not exhaustive):

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

"Non-deterministic"?  Scary, if the goal is well-defined
semantics.

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

Good.  How confident can we be that this is so?

[Later]
Why complicate the transformation with options that are not needed?
I'd suggest simply deleting the optional elements of the
transformation rules, and picking just one of the possible
alternative transformations.  If there's anything else useful
to be said, indicate it separately as additional information,
with appropriate commentary.

----

Concerning: http://www.w3.org/TR/owl-semantics/mapping.html#4.1

Table row 3:

[[
Annotation(ontologyPropertyID URIreference)
]]

Doesn't obviously match an abstract syntax production.
I think the URIreference should be ontologyId.

(I recognize these resolve to the same thing, but if one is going
to go to the trouble of defining a heap of equivalent symbols, they
should at least be used consistently.)

----

In reading the transformation rules, it is not immediately obvious from
the table as presented what parts of the abstract syntax expression
are variables that are carried into the transformed expression, but when
getting down to the level of trying to code an implementation it seems
clear enough what goes where.  Some more explicit convention for naming
"variables" in the transformation rules might help.

----

I *think*, though it's not exactly clear, that the third column
indicates what part of the transformed expression to use for the
node when T(expr) appears as a node in a triple for a transformed
piece of syntax.

I think this piece of text:
[[
The left column of the table gives a piece of syntax (S), the center column
gives its transformation (T(S)), and the right column gives an identifier
for the main node of the transformation (M(T(S))), but only for syntactic
constructs that can occur as pieces of directives.
]]
could usefully be expanded.  I think something like this is intended:

The table has three columns:

left:
   gives a piece of abstract syntax corresponding to the RHS of an abstract
   syntax production rule (with nonterminal symbols in an italic font)

middle:
   gives a transformation of the abstract syntax into RDF triples, where
   the triples are presented as N-triples (with qnames for URIs).  Within
   these, further transformations are used to represent RDF triples, and
   also to represent individual nodes within such triples.

right:
   gives a node identifier to be used when a transformation of the
   corresponding abstract syntax is used as a node within a triple
   in some other (middle column) transformation expression.

The resulting RDF graph contains all of the triples generated by
the transformation of a given piece of abstract syntax.

(This may not be the best possible description, but I think something at
this level of detail would make the intent very much clearer.)

----

AFAICT, the mapping table is presented in the same order as the abstract
syntax production rules, with a 1:1 correspondence.  This is an important
clue, which I think would be better if made explicit by (a) labelling the
abstract syntax productions, and (b) using those labels to identify the
corresponding mapping rules.

----

I think the handling of the ontology node in the first two rows is not
entirely consistent with the treatment later given to other constructs
that result in the generation of new blank nodes.

(In my implementation sketch, I pass the explicit-or-generated
Ontology node as a parameter to the subsequent transformations.)

-----

The attachment to this message is the start of a sketch for implementing 
the transformation rules in Haskell.  The first part of the code is an 
encoding of the abstract syntax using Haskell data types.  The second part 
are some clauses of a Haskell function "transform" that implements the 
transformation T described by the mapping table, corresponding to the first 
6 rows of the table.

The code is far from complete, and hasn't been near a Haskell 
compiler.  But I now think I see enough to complete the implementation, but 
I'm not sure that it's really worth the effort at this time.

#g


-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E