Suggestion: Parameterised Queries

[Leigh Dodds-3]

Hi,

I have the following featur esuggestion for the WG.

Feature: Parameterised Queries

Feature Description:

  Extend the SPARQL protocol such that additional URL parameters in
the query string (or a subset that match
  a specific naming convention) are reflected into the query as
initial variable bindings.

Example:

  E.g. for a query such as:

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

  A protocol request of the form:

  /sparql?query=...&blog=http://www.example.org/blog

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

Existing Implementations

 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.

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.

Cheers,

L.

--
Leigh Dodds
Programme Manager, Talis Platform
Talis
leigh.dodds@...
http://www.talis.com

[Arjohn Kampman-2]

Hi all,

Sesame also supports this in its HTTP protocol and we use it a lot. We
decided to use a '$' prefix for variable names though, to prevent
accidental name collisions with other URL-parameters (e.g. "query").

Regards,

Arjohn

Leigh Dodds wrote:

> Hi,
>
> I have the following featur esuggestion for the WG.
>
> Feature: Parameterised Queries
>
> Feature Description:
>
>   Extend the SPARQL protocol such that additional URL parameters in
> the query string (or a subset that match
>   a specific naming convention) are reflected into the query as
> initial variable bindings.
>
> Example:
>
>   E.g. for a query such as:
>
>   PREFIX foaf: <http://xmlns.com/foaf/0.1/>
>   SELECT ?name
>   WHERE {
>    ?x foaf:name ?name.
>    ?x foaf:weblog ?blog.
>   }
>
>   A protocol request of the form:
>
>   /sparql?query=...&blog=http://www.example.org/blog
>
>   Would bind ?blog to the value in the URL parameter before it is
> matched against the dataset.
>
> Existing Implementations
>
>  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.
>
> 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.
>
> Cheers,
>
> L.
>

--
Arjohn Kampman, Senior Software Engineer
Aduna - Semantic Power
www.aduna-software.com

[Benjamin Nowack-2]

Hi,

ARC uses "${var}" for parameters, a notation that's sometimes
used in template languages.

Downside:
   It requires a grammar tweak.

Upside:
   It separates vars from parameters so that a processor can
   detect missing input data, and it opens the door to things
   like ${var.stripTags()}, ${var.toLowerCase()}, or
   ${now().toXSD()}

Related implementation issue:
   How to detect/specify the type of an input parameter, i.e.
   should &var=foo be handled as <foo>, "foo", or _:foo, or
   whether there should also be a &var-type=uri|bnode|literal.


Benji

--
Benjamin Nowack
http://bnode.org/
http://semsol.com/

>Hi all,
>
>Sesame also supports this in its HTTP protocol and we use it a lot. We
>decided to use a '$' prefix for variable names though, to prevent
>accidental name collisions with other URL-parameters (e.g. "query").
>
>Regards,
>
>Arjohn
>
>Leigh Dodds wrote:
>> Hi,
>>
>> I have the following featur esuggestion for the WG.
>>
>> Feature: Parameterised Queries
>>
>> Feature Description:
>>
>>   Extend the SPARQL protocol such that additional URL parameters in
>> the query string (or a subset that match
>>   a specific naming convention) are reflected into the query as
>> initial variable bindings.
>>
>> Example:
>>
>>   E.g. for a query such as:
>>
>>   PREFIX foaf: <http://xmlns.com/foaf/0.1/>
>>   SELECT ?name
>>   WHERE {
>>    ?x foaf:name ?name.
>>    ?x foaf:weblog ?blog.
>>   }
>>
>>   A protocol request of the form:
>>
>>   /sparql?query=...&blog=http://www.example.org/blog
>>
>>   Would bind ?blog to the value in the URL parameter before it is
>> matched against the dataset.
>>
>> Existing Implementations
>>
>>  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.
>>
>> 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.
>>
>> Cheers,
>>
>> L.
>>
>
>
>--
>Arjohn Kampman, Senior Software Engineer
>Aduna - Semantic Power
>www.aduna-software.com

[Arjohn Kampman-2]

Benjamin Nowack wrote:

> Hi,
>
> ARC uses "${var}" for parameters, a notation that's sometimes
> used in template languages.
>
> Downside:
>    It requires a grammar tweak.
>
> Upside:
>    It separates vars from parameters so that a processor can
>    detect missing input data, and it opens the door to things
>    like ${var.stripTags()}, ${var.toLowerCase()}, or
>    ${now().toXSD()}
>
> Related implementation issue:
>    How to detect/specify the type of an input parameter, i.e.
>    should &var=foo be handled as <foo>, "foo", or _:foo, or
>    whether there should also be a &var-type=uri|bnode|literal.

Sesame encodes the values in their N-Triples notation, which has
two advantages:

- it seperates URI's, bnodes and literals; no need for something like
   a var-type parameter

- it encodes arbitrary unicode characters to ASCII characters,
   preventing any HTTP character encoding issues

--
Arjohn Kampman, Senior Software Engineer
Aduna - Semantic Power
www.aduna-software.com