Re: Proposed response to Graham Klyne

A modified response taking into account Jim and Sean's comments is
appended. If this is now OK then I will send it.

Ian

------------------------------------------------------
Thank you for your comments.

On May 9, Graham Klyne writes:
> These are some personal comments that arise out of a review I was asked to 
> do for the RDFcore working group.   I must emphasize that they are offered 
> as personal comments, as they do not cover any official RDFcore WG concerns.
> 
> -----
> 
> I looked briefly at the abstract syntax section [1] (it actually looks like 
> a quite concrete serialization to me), which does appear to be very well 
> presented, then at section 4.1 [2] of the OWL abstract syntax and semantics 
> document, with a particular view to seeing if I could understand how to do 
> the mapping.
> 
> 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 [3] 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 some guesswork.
> 
> 2.  I think the presentation of the mapping leaves something 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.
> 
> There was some discussion about the purpose of these transformation 
> rules.  From the description given, I think it is to translate OWL AS to an 
> RDF graph, but others have
> also suggested that they might be used for defining inverse transformation.
> I don't think the mapping table is well-suited to that purpose.

Please see [1] for a detailed discussion of this issue.

> 
> More detailed comments are below.
> 
> [1]  http://www.w3.org/TR/2003/WD-owl-semantics-20030331/syntax.html
> 
> [2]  http://www.w3.org/TR/2003/WD-owl-semantics-20030331/mapping.html#4.1
> 
> [3]  http://www.haskell.org/
> 
> -----
> 
> Concerning section 4: 
> http://www.w3.org/TR/2003/WD-owl-semantics-20030331/mapping.html
> 
> [[
> 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?
> 
> 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.

Again, please see [1] for a detailed discussion of these issues.

> 
> ----
> 
> Concerning: 
> http://www.w3.org/TR/2003/WD-owl-semantics-20030331/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
> might at least be used consistently.)

In section 2.1 of S&AS [2] we now have:

ontology ::= 'Ontology(' [ ontologyID ] { directive } ')'
directive ::= 'Annotation(' ontologyPropertyID ontologyID ')'
	 | 'Annotation(' annotationPropertyID URIreference ')'
         | 'Annotation(' annotationPropertyID dataLiteral ')'
         | 'Annotation(' annotationPropertyID individual ')'
         | axiom
         | fact


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

Terminals are indicated by italics.

> 
> ----
> 
> 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:
> 
> 1.
>    gives a piece of abstract syntax corresponding to an abstract syntax
>    production rule (with further nonterminal symbols in an italic font)
> 
> 2.
>    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, expressed as T(...), may be used to
>    represent RDF triples, and also to represent individual nodes within
>    such triples.
> 
> 3.
>    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.)

This bit has been changed to 

The left column of the <a href="#transformation">table</a> gives a
piece of <span class="change">abstract</span> syntax (S);
the center column gives its transformation 
<span class="change">into triples</span> (T(S)); 
and the right column gives an identifier for the main
node of the transformation (M(T(S))), for syntactic
constructs that can occur as pieces of directives.  

The new version is available at
http://www.bell-labs.com/user/pfps/owl/semantics/ 

The information about how the triples are represented is contained in a
paragraph shortly after.


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

There is no strict correspondence between the syntax production and the
mappings so this labelling would not work out.

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

This is handled by 

Bnode identifiers here must be taken as local to each transformation, 
i.e., different identifiers should be used for each invocation of a
transformation rule.     
Ontologies without a name are given a bnode as their main node;
ontologies with a name use that name as their main node;
in both cases this node is referred to as O below.

from just before the translation table.


> -----
> 
> Concerning: 
> http://www.w3.org/TR/2003/WD-owl-semantics-20030331/mapping.html#4.2
> 
> This gives some rules to determine whether some RDF graph is an Owl-lite or 
> Owl-DL ontology.  Presumably anything that doesn't satisfy either of these 
> criteria is Owl-full.  But the rules are stated in terms of an AS->Graph 
> transformation, so I'm not sure they constitute an effective procedure for 
> making such a determination.

This document only provides definitions of various parts of OWL.  Turning
these definitions into effective procedures is a task for
implementors (c.f.the OWL Species Validator, available from the WG
web page or at [5]).

> There's a point that isn't entirely clear to me:
>    "the ontologies in O taken together provide a type for every individual ID"
> What about mixtures of arbitrary RDF and OWL ontology statements?
> Does this mean that every individual must have an explicit type statement?
> Exactly what counts as an individual for the purposes of this assertion?

The ontologies in O are in abstract syntax, so there is a clear definition
of what counts as an individual ID.

> It has been my assumption that the various flavours of OWL can be used as a 
> "logical layer" to perform some reasoning about things described by 
> common-or-garden RDF.  I've since been told this may not be so.  If it is 
> true that Owl DL and Owl-lite are not suitable for doing any reasoning 
> about things described by ordinary "in the wild" RDF, I think this needs to 
> be clearly stated.

This is addressed by the introduction to the OWL Web Ontology
LanguageOverview [3]. Test also discusses document conformance in some
detail [4].

> -----
> 
> For interest, the attachment to this message is the start of a sketch for 
> implementing the (section 4.1) 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.
> 
> #g
> 
> 
> -------------------
> Graham Klyne
> <GK@NineByNine.org>
> PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E


Please reply to this message as to whether this response is satisfactory,
copying public-webont-wg@w3.org. Again, thank you for your comments.

Ian Horrocks and Peter Patel-Schneider

[1] http://lists.w3.org/Archives/Public/public-webont-comments/2003Jun/0025.html
[2] http://www.w3.org/TR/2003/WD-owl-semantics-20030331/syntax.html
[3] http://www.w3.org/TR/owl-features/#s1.3
[4] http://www.w3.org/2002/03owlt/editors-draft/draft/#conformance
[5] http://phoebus.cs.man.ac.uk:9999/OWL/Validator

Received on Saturday, 21 June 2003 08:22:07 UTC