Re: comments on "SPARQL Query Language for RDF" (Non-respect for RDF Semantics)

From: Dan Connolly <connolly@w3.org>
Subject: Re: comments on "SPARQL Query Language for RDF" (Non-respect for RDF Semantics)
Date: Wed, 07 Sep 2005 22:26:54 -0500

> Thanks for the careful review... we have something of a back-log
> of comments, so it may be some weeks before we can respond to
> all of your points in substance.
> 
> Meanwhile, I'd like to know more about one of your points...
> 
> On Wed, 2005-09-07 at 21:26 -0400, Peter F. Patel-Schneider wrote:
> [...]
> > 
> > ISSUE 1 (show-stopper):  Non-respect for RDF Semantics
> [...]
> > For example, querying
> > 
> > G1	ex:a ex:b ex:c .
> > 	_:a ex:b ex:c .
> > 
> > with the triple pattern
> > 
> > 	?x ex:b ex:c .
> > 
> > will result in two matches, one for ex:a and one for _:a.
> > Querying 
> > 
> > G2	ex:a ex:b ex:c .
> > 
> > with the same triple pattern will result in only one match, for ex:a.  However,
> > G1 and G2 are equivalent with respect to simple interpretations (and thus also
> > for RDF interpretations, RDFS interpretations, and OWL interpretations).
> 
> The technical point you make is clear. If you can elaborate on what
> makes this a show-stopper, i.e. what one would want to do with SPARQL
> that one cannot do with the design as is, that would be even
> more helpful.
> 
> 
> -- 
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
> D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E


My view is that this turns interoperating RDF implementations into
non-interoperating implementations.  For example, an RDF implementation that
leans (RDF Semantics, Section 0.3) any graph it stores can interoperate with
one that doesn't, at least in my reading of the RDF Core WG documents.
Similarly, according to my reading of the RDF Core WG document, an RDF
implementation is free to rename blank nodes or even to not even internally
store any name with blank nodes and it can still interoperate with other RDF
implementations.  However, such interoperating RDF implementations cannot
become interoperating SPARQL implementations.  I view this sort of change as a
show-stopper.

This "opening up" of the internal storage of RDF-compatible implementations is
even more problematic for OWL.  My belief is that the OWL specifications have
been carefully written to allow for OWL implementations to use different
internal storage formats from RDF triples.  (For example, OWL implementations
might internally turn RDF triples that encode OWL descriptions into a
completely different form.)  However, even absent problems related to other
aspects of OWL entailment, SPARQL opens up this sort of machination and makes
precludes conforming OWL implementations from being conforming SPARQL
implementations.


I have made comments along this line for a previous draft of "SPARQL Query
Language for RDF".  I enclose excerpts of some of the relevant messages below.

http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2004Oct/0003.html

	SPARQL appears to depend on an unsanctioned extension of RDF, namely
	that bnodes in an RDF graph have identity that can be taken out of the
	graph and transmitted elsewhere.  Is this the case?  If so, how is this
	extension going to work?  If not, how can bnodes be handled reasonably
	in SPARQL?

http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2004Oct/0016.html

	> In the local case (no serialization of results, directly working with
	> the graph), the query processor can be working directly with the
	> graph and can return programming language objects that the graph
	> implementation uses for bNodes.  bNodes do not leave the graph; the
	> programming system has whatever mechanisms it uses to pass references
	> around just like literals and URIs in RDF APIs.

	Huh?  How does this work?  Is this really going to part of the SPARQL
	spec?  If so, it exposes a part of RDF that I had safely thought was
	hidden.

http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2004Nov/0009.html

	> I suspect we have different underlying views on how RDF applications
	> are going to be constructed.  My hope is that SPAQRL is neutral to
	> that - if you see some approaches being made impossible, or
	> difficult, then please let us know.

	Hmm.  Well if SPARQL does indeed not allow bnodes, then it may indeed
	be neutral.  However, the working draft is definitely not neutral - for
	repeatable results to queries using bnodes it requires RDF stores to
	maintain the identity of these bnodes, which I do not believe that an
	RDF store need do.


Peter F. Patel-Schneider
Bell Labs Research

Received on Thursday, 8 September 2005 10:38:14 UTC