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

At 10:49 07/05/2003 +0100, Brian McBride wrote:
>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.

Maybe.

I'll expand a little on that comment:  there were some steps that I did not 
find were clearly spelled out, but when I actually looked at the specific 
abstract syntax and transformation rules there didn't seem to me to be any 
likely alternative interpretations.

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

Hmmm... possibly tricky.

1. Based on the specific transformation rules I've looked at in detail, I 
think that some reverse transformations could reasonably be constructed.  I 
can't be confident about all the rules without attempting a full 
implementation.

2. My concern is that it is not obvious to me that the reverse 
transformation would be unique.   I'm (vaguely) concerned that different 
combinations of RDF triples might be usable to construct different abstract 
syntax.  The document itself says this is possible, but that any AS thus 
obtained would have the same meaning.  A related question might be:  how do 
I know I've done a complete reverse transformation?  That is not at all 
clear to me.

Is this really a requirement?  Why is it necessary to map RDF to abstract 
syntax?  I guess it's something to do with defining the semantics, but the 
OWL AS&S spec claims to contain a semantics based directly on the RDF 
triples.  I would assume the mapping (one way or the other) is needed as 
part of a proof of equivalence, but I don't see any operational need to map 
the RDF triples into OWL AS.

>We need to decide what, if any, comment RDFCore wishes to make about this 
>aspect of the OWL draft.
>
>Graham, what is your recommendation?

Regarding the OWL AS->RDF triples mapping, I would say:

(a) recommend slightly more explanation of the transformation table.  I 
think the table itself is probably OK, possibly modulo small 
adjustments.  I roughly sketched an example in my previous message, which 
could certainly be improved, but which I hope suggests a modest level of 
additional detail that would be helpful.

(b) that said, I think it's probably OK for proceeding to Proposed REC, but 
note that multiple interoperable implementations would be the appropriate 
proof-of-the-pudding for moving further along the REC track.

Regarding RDF->AS mapping, if this is really needed, I think more needs to 
be said about the selection of triples from an RDF graph.  Once triples are 
selected for a given transformation rule, I think applying the 
transformation in reverse should be relatively straightforward in most cases.

Since Jan has reviewed the entire document, I'd be interested to hear his 
comments on whether I'm looking at the right aspects of this.


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

Sure.  I expect LHS=nonterminal, RHS=expansion.  This was just a sketch -- 
actual wording details are not fully worked out.

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

Received on Wednesday, 7 May 2003 08:09:17 UTC