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

At 21:21 06/05/2003 +0100, Graham Klyne wrote:
>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.

Hmmm, guesswork not good.  Different people might guess differently.

Can I ask you about the reverse transform.  Given some incoming RDF, could 
you transform it to the Owl AS?  Could you tell if it was legal Owl 
DL/Lite?  If you were to write an Owl DL/Lite ontology by hand in RDF, 
could you do it?

We need to decide what, if any, comment RDFCore wishes to make about this 
aspect of the OWL draft.

Graham, what is your recommendation?



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

RHS?  Which was is north?  Doesn't this depend on which way round you write 
the production rule?


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

Received on Wednesday, 7 May 2003 05:48:32 UTC