W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2011

Re: SPARQL Query 1.1 review

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Tue, 15 Feb 2011 13:39:03 +0000
Message-ID: <4D5A81F7.30904@epimorphics.com>
To: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
CC: Steve Harris <steve.harris@garlik.com>, SPARQL Working Group <public-rdf-dawg@w3.org>

On 15/02/11 11:24, Birte Glimm wrote:
> [snip]
>>> So far only the evaluation of BGPs (Bgp(...) in the
>>> algebra) is used to actually compute bindings. All other operations
>>> then work on solution sequences, which is really nice.
>> Not quite true - joins etc create new bindings from old.  I think you mean
>> that BGPs are the bottom of the binding creation tree.  That was true in
>> SPARQL 1.0, but we have with BINDINGS, we have another way to create
>> bindings at the bottom level.
> Well, joins compute bindings from bindings, whereas BGPs are used to
> generate bindings. Now BINDINGS also "generates" bindings, but in a
> very straightforward way; they are just "told" bindings.
>> By defining property paths as SPARQL expressions where possible, we have
>> reduced it to a few special operators.
>>> Some property
>>> path features require, however, an algebra extension that introduces
>>> other forms of computing solutions, e.g., the evaluation of
>>> :s :p+ ?o
>>> yields a solution sequence by an extended form of BGP matching, but
>>> this is not defined for entailment regimes and cannot be defined by
>>> means of entailment. Thus, queries with certain property paths cannot
>>> make use of the BGP matching extension point, which introduces in my
>>> opinion and unfortunate incompatibility, which is not mentioned or
>>> discussed in the document.
>>> I am not against property paths, but I think this incompatibility has
>>> to be mentioned and I would also like to see property path being an
>>> optional feature, i.e., a SPARQL 1.1 conformant system can but does
>>> not have to support property paths.
>> Good idea to have some text, but I think the entailment document is the
>> place to put it.  SPARQL, from rq25.xml, is a single unit of features over
>> simple entailment.
> That's my point, even simple entailment is about entailment between
> RDF graphs and
> es:s ex:p+ ex:o .
> is not an RDF graph and cannot be turned into one, so simple
> entailment is just not defined.
> Furthermore, 18.6 Extending SPARQL Basic Graph Matching says:
> The overall SPARQL design can be used for queries which assume a more
> elaborate form of entailment than simple entailment, by re-writing the
> matching conditions for basic graph patterns.
> This also no longer holds. What would be required is to handle also
> property path expressions and for those there is the problem that
> entailment is not even defined, so we would have to define new
> entailment relations for the property path expressions that cannot be
> rewritten into BGPs or the extension point is no longer an extension
> point IMO.

The property path forms for + and * are defined as operations over the 
data by breaking them down to a process that makes single steps of the 
property path.  That can be mapped onto BGPs.  In this way, it's just 
like UNION, BIND etc.  the algrebra translation tries to maximize the 
use of BGPs but there is no claim that one PathBlock is one entailment 

Maybe, some time, the theory of more expressive forms than just BGPs 
over various entailment regimes will be worked out and a consensus formed.

Received on Tuesday, 15 February 2011 13:39:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:03 UTC