From SPARQL Working Group
Revision as of 22:23, 10 March 2009 by Imikhail (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Feature: Parameters

Queries can be parametrized in order to reduce redundand re-compilations of very similar queries.

Feature description

Experience demonstrates that producing an execution plan may take up to half of the processing time of many queries, specially if these queries select relatively little data. This is demonstrated for example by the Berlin SPARQL benchmark.

This may be easily remedied by supporting parametrized queries. Since the protocol is stateless, a ODBC/JDBC style notion of a prepared statement does not apply. However, it is simple to cache a number of recent parametrized execution plans on a server for eventual reuse.

In Virtuoso, if the name of a URL parameter in the SPARQL GET or POST request corresponds with a variable of the same name in the query, the value of this URL parameter is taken as as the initial binding of the variable, which is in effect for this execution of the query. This is an existing feature of Virtuoso. ARQ also offers parametrized queries, however not over the SPARQL protocol.

For better error checking, OpenLink proposes a special notation for parameter placeholders. In this manner, it is possible to signal an error if a parameter value is expected but is not present in the request. This could be ?:xx in the place ?xx. For similar purpose, an error should be reported if names of a variable and a parameter are the same (as ?sample and ?:sample). The web service enpoint MAY report an error if parameter name in the request matches variable name in the query but the query does not contain a parameter with that name. "MAY", not "MUST" is due to critical implementation problems for web service endpoints that use SPARQL preprocessors as "black boxes". While missed value of expected parameter is obviously an error, it is unclear whether we should support explicit passing of "unbound" as a parameter value. This might be useful for some tricks but it prevents the query optimizer from making some useful assumptions.

The special notation for parameter placesholders is strongly required if sub-selects are allowed. It is also very convenient if SPARQL queries are called via ODBC or JDBC like protocols that allow complete Prepare before Exec.

Parameters should be allowed in places where variables are allowed in SPARQL 1.0, there's no need to allow them in places where only constants are allowed (say, in FROM clause, as BASE or as function name). Parameters may appear in pragmas but it is pragma- and implementation-specific whether the name of parameter is replaced with its value.


For a query such as:

 PREFIX foaf: <http://xmlns.com/foaf/0.1/>
 SELECT ?name
  ?x foaf:name ?name .
  ?x foaf:weblog ?blog .

Leigh Dodds proposes protocol request of the form:


that would bind ?blog to the value in the URL parameter before it is matched against the dataset.

Virtuoso's implementation requires last triple in the query to be written as

  ?x foaf:weblog ?:blog .

and parameter name in the request starts with "?" to not conflict with any "plain" fields of the request and parameter values are serialized in TURTLE syntax, otherwise strings and IRIs are undistinguishable and it's impossible to pass typed literals or strings with language tags:


Existing Implementation(s)

  • Leigh Dodds: ARQ supports this usage in its core URL, and I have used this to implement the above style of parameter passing in several apps and endpoints whilst at my previous employer.
  • Sesame also implements this
  • Virtuoso uses the feature in "expreimental" status but for a long time, awaiting for the WG decision re. the exact syntax.

Existing Specification / Documentation

List any existing text that attempts a formal definition of this extension. This could be a draft specification, API or syntax documentation, etc.


If parameters begins with "?:" then the proposed feature introduces a new unambiguous syntax of both query language and HTTP request strings.

Links to postponed Issues

Has this extension/use case some history in the group already? I.e. are there posponed issues or archived mail-threads related to this originating from DAWG?

Related Features


Use cases

Enable support SQL style parameterised query directly from the SPARQL protocol. In conjunction with the proposed Query By Reference feature it enables the creation of simple "web APIs" using only the SPARQL protocol. E.g. I am able to publish a common SPARQL query that does some useful data extraction, and then reuse that query by altering the passed parameters.

Even without the Query By Reference feature it would simplify interaction with an endpoint (change url parameter(s) not query) and would allow the endpoint to cache and parse a query for repeated use, thereby removing any query parsing overheads.