W3C home > Mailing lists > Public > public-sparql-dev@w3.org > April to June 2012

Re: SPARQL 1.1. BINDINGS + FILTER

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Thu, 03 May 2012 22:03:41 +0100
Message-ID: <4FA2F2AD.9060408@epimorphics.com>
To: Benjamin Nowack <bn@talis.com>
CC: public-sparql-dev@w3.org


On 03/05/12 15:55, Benjamin Nowack wrote:
> Hi Andy,
>
> Thank you very much for the update.
>
> We are looking for something much more simple. All we would like to
> offer are basic SPARQL query templates, quite similar to how Prepared
> Statements work in SQL.
>
> Using BIND or VALUES seems to require query parsing and advanced
> knowledge of scoping in SPARQL 1.1, to avoid injecting the parameter
> values in the wrong place.
>
> Very late request, I know. It's just for the record, and maybe SPARQL
> 1.2 ;)
>
> Cheers,
> Benji

Benji,

Yes, it's quite late :-)

What had you in mind?

SQL prepared statements do several things - not just as query templates; 
for example, they allow query execution plan calculation ahead of time 
for reuse.  The latter is a stateful relationship of client and server 
(to allow for the server to be involved - not all implementations 
actually do this).

It would probably need a new class of variables which must be defined 
for a query to execute to distinguish "template variables" from regular 
query variables.

Injecting in the right place can be quite cheap - the query string upto 
that point, the syntax, and the query string after that point.  There is 
only one point to put variables in.

SELECT *
{
   VALUES (?x ?y) {}  ## Put your values here
   ?s ?x ?y .
}

and does not even have to be SPARQL syntax - string processing would 
work in practice with, say:

SELECT *
{
   VALUES (?x ?y) {$values$}
   ?s ?x ?y .
}

The BINDINGS feature, which was primarily driven by the needs of 
federated query only partly covers this usage.  This is a driver for the 
current VALUES proposal for data in the query pattern itself.

A change to the SPARQL protocol to allow template naming and 
substitution values would be the reason to standardise. It does not have 
to be a standard if the feature is added in the API.

ARQ also allows for rewrite of parsed queries: a query can be rewritten 
(either the abstract syntax tree or the SPARQL algebra) as replacing 
specific variables by values prior to execution (this is even in the 
public API).  Discuss with your implementation of choice.

	Andy
Received on Thursday, 3 May 2012 21:04:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 3 May 2012 21:04:12 GMT