Re: proposed reply to Re: OWL S&AS: Translation to RDF Graphs

Jeremy Carroll wrote:
> I had some doubt about this response
> >A normative definition of this is very likely to be no more intelligible
> >than the current sitation.  A non-normative and incomplete, but more
> >comprehensible discussion would be useful.  The Guide
> >( serves as at least a partial vehicle for
> >this purpose

I agree with Jeremy here. I do not believe the response is satisfactory.
I only know of a few people who have ever tried to use S&AS to find out
information about the syntax of OWL, and every time it seems that they
have a similar reaction to Dave Beckett. I believe Jeremy pointed some
of this out when he first reviewed S&AS, and I more recently encountered
this difficulty when trying to understand the syntax of restrictions. I
quote from my message of April 23 [1]:

  Second, although the AS&S makes it easy to transform from the abstract
  syntax to RDF, I think it is much harder to do the reverse
  transformation (which actually seems like a more common one). I think
  would be nice to have a table that presents this transformation. This
  may also be useful in placating people who ask "where's the official

This seems like an issue we can't just sweep under the rug. I think we
need to provide a table that translates from RDF to the abstract syntax
(if it has to be non-normative then so be it). There may be some
complexity in describing the fact that some RDF graphs are disallowed,
but I believe it can be managed. For example, we could do an
allValuesFrom restriction as follows:

_:x rdf:type owl:Restriction . 	| restriction(T(ID)
_:x rdf:type owl:Class . [opt]  |
_:x rdf:type rdfs:Class . [opt] |
_:x owl:onProperty ID . 	|
_:x owl:allValuesFrom range . 	|
* no others with subject _:x *  |

Note, the "no others" part is needed to indicate the OWL-Lite/DL
restriction that a Restriction is limited in what properties it may
have. In particular, you can't have allValuesFrom with someValuesFrom,
hasValue, cardinality, etc.

Note, I do not believe that such a table would be design change, so it
wouldn't force us to go through another last call.

I request that we discuss this at the telecon today during the time
alloted to discuss public comments.



> and later
> >Agreed, but the Guide serves this purpose.
> Two problems with these references to the Guide:
> 1: I think Peter is talking about things that might have been included in the
> Guide rather than things that actually are in the Guide.
> (or maybe it's only the second point)
> 2: I don't think of Dave Beckett as a Guide reader.
>    He's happy reading fairly turgid technical material for developers, and he
> seems to be saying that this section looked too difficult, and seems to be
> asking the fairly open-ended question of can we make it easier?
>   The answer might be no we can't, but I don't think the answer Dave is after
> is found in the Guide.
> Jeremy

Received on Thursday, 15 May 2003 10:56:27 UTC