[Fwd: Coments on first working draft of SPARQL]

Comments from Peter Patel-Schneider: discussion for the WG of the issues 
he raises inline.

	Andy

> I took a quick look at 
> 
>     SPARQL RDF query language
>     http://www.w3.org/TR/rdf-sparql-query/
> 
> For a first working draft it is quite good.
> 
> Nevertheless, I have a number of things that I think need bringing up.
> 
> 
> First, a few nits:
> 
> - Are query variables disjoint from RDF Terms?  It looks as if they should
>   be.

Yes - the defintion of Query Variable states this but it could be made
clearer.

> 
> - The use of "bound" in the discussion of Optional Values is rather
>   jarring.  You probably don't mean bound, but instead mean something like
>   mentioned.

Agreed - the "bound" language is a bit procedural.

> 
> - Why is there an AND keyword?  Wouldn't it just be possible to intersperse
>   triple patterns and constraints?  If the AND keyword is needed, how
>   tightly does it bind to the rest of the query.  For example, does a
>   constraint in an OPTIONAL portion constrain all results?

AND is not necessary syntactically and its operator binding is the same
as conjunction in patterns elsewhere.

There is a potential issue about && being within constraints.  This was
raised in Graham's email and needs to be explored.

>   
> - What happens if an OPTIONAL block has multiple matches?  I assume that
>   multiple bindings will result.

Yes - will make clearer.

> 
> 
> Now for some more substantive issues:
> 
> 
> SPARQL allows bnodes in triple patterns and in constraints.  This leads to
> a number of thorny issues.  

bNodes can be in triple patterns and in constraints only if they have got
there from the graph being queried.  The query syntax does not allow
bNodes (although I'm sure implementations will do something ad hoc here
for the local case).

> 
> How are blank nodes handled in constraints?  For example, what does
> 	_:a < 30  (where _:a is a blank node)
> evaluate to?

Sections 3 and 12 had better discuss this.  It should be "error" leading
to a false constraint. That is, "! (_:a < 30)" is also going to cause the
match to be rejected.

> 
> How are blank nodes handled in triple patterns?  For example, does the
> triple pattern
> 	( ?x ex:r _:v )
> match the RDF graph
> 	ex:a ex:r _:a .
> 	ex:a ex:r _:b .
> 
> In general, what is the status of blank nodes in SPARQL?  For example,
> which definition of subgraph does SPARQL use - the standard one from graph
> theory or the expansive one used in RDF semantics in the presence of bnode
> relabelling?

That pattern would not match - can't have a bNode in the query like that. 
  bNodes can not be put in query requests and that needs to be explained 
somewhere.

Could someone more versed in the details of RDF semantics help here.

> 
> Even if bnodes do not appear in a query, how are multiple matches that
> differ only with respect to bnodes handled?
> 
> 
> Theses issues are all a consequence of the following issue:
> 
> 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?

Its not supposed to say that.  bNodes do not leave the graph if I
understand the meaning of "leaving" correctly.

In the local case (no serialization of results), 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.

In the case where results are serialized, XML or RDF/XML forms, there are
merely labels (c.f. like bNodes ids in RDF/XML) that are document scoped. 
  They only enable one bNode in the document to be distinguished from 
another.  They can not be used to get back to the original bNode in the 
graph - that would have to be done by reusing a graph pattern that found it.

> 
> Peter F. Patel-Schneider
> Bell Labs Research

These useful points on bNodes suggest we have a special section to 
explciitly say what happens.

Received on Sunday, 17 October 2004 17:37:39 UTC