Re: Proposed response to Graham Klyne

At 1:25 PM +0100 6/21/03, Ian Horrocks wrote:
>A modified response taking into account Jim and Sean's comments is
>appended. If this is now OK then I will send it.
>
>Ian

send it.

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

-- 
Professor James Hendler				  hendler@cs.umd.edu
Director, Semantic Web and Agent Technologies	  301-405-2696
Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
Univ of Maryland, College Park, MD 20742	  *** 240-277-3388 (Cell)
http://www.cs.umd.edu/users/hendler      *** NOTE CHANGED CELL NUMBER ***

Received on Saturday, 21 June 2003 22:43:12 UTC