- From: Jim Hendler <hendler@cs.umd.edu>
- Date: Thu, 19 Jun 2003 19:38:41 -0400
- To: Ian Horrocks <horrocks@cs.man.ac.uk>, www-webont-wg@w3.org
- Message-Id: <p05200f2abb17f91f51cf@[10.0.1.2]>
I'm okay with this one except for one thing -- you have
At 5:57 PM +0100 6/19/03, Ian Horrocks wrote:
>This document only provides definitions of various parts of OWL. Turning
>these definitions into effective procedures is a task for implementors.
which is begging for someone to say "you need a long CR for this" --
however, our web page has a pointer to Sean's validator which proves
this can be implemented - so why don't we say
"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]), which is such an implementation).
[5] http://phoebus.cs.man.ac.uk:9999/OWL/Validator"
---
Make that change and it is okay to send it.
-JH
t 5:57 PM +0100 6/19/03, Ian Horrocks wrote:
>Here is a proposed response from Peter and me to:
>
>http://lists.w3.org/Archives/Public/public-webont-comments/2003May/0055.html
>
>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.
>
>> 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
--
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 Thursday, 19 June 2003 19:39:16 UTC