RE: On Parameters

-----Original Message-----
From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-request@w3.org]
On Behalf Of Simon Schenk
Sent: Wednesday, March 25, 2009 1:38 PM
To: public-rdf-dawg@w3.org
Cc: 'SPARQL Working Group'
Subject: Re: On Parameters


> In all SQL CLI's (call level interface) this is a given.   Also, most
> CLI's have array  parameters, i.e. passing  multiple sets of parameter
> bindings in a single client-server message.  The array parameter
> question can be addressed in the  conntext of the SPARQL protocol by
> the HTTP 1.1 pipelining

Apart from query optimization I see an interesting application for
arrays in federation. 

Eric proposed something similar for this purpose [1]. Without it,
distributed joins either need a large number of separate queries
(resulting in high latency), or you need to mimic [1] by rewriting the
query with lots of FILTERs or UNIONs as proposed in [2], which is a
rather hacky solution.

Cheers,
Simon

[1] http://www.w3.org/2007/05/SPARQLfed/
[2] Zemanek, Jan, Schenk, Simon, and Svatek, Vojtech. Optimizing SPARQL
Queries over Disparate RDF Data Sources through Distributed Semi-Joins.
ISWC 2008 Poster and Demo Session Proceedings. CEUR-WS. 2008.



Simon



Quite right.  I would propose to support a POST request with an XML body for
parameter rows and a corresponding 
wrapper format for keeping the result sets  separated.  Easy to specify and
easy to implement.
I am quite uncertain of the committee's adoption of such a thing, though, as
parameters themselves are not a given.  It is also true that a similar
effect to array parameters can be had with a pipelined HTTP request:  Write
all the request headers and then read all the responses.  If the query
itself is kept around for the next request, it can be reused from a cache of
recently compiled queries.

Putting or's into a query for federation is not really desirable, to be
sure.

Orri

Received on Wednesday, 25 March 2009 13:26:08 UTC