W3C home > Mailing lists > Public > semantic-web@w3.org > July 2012

Re: Template language for SPARQL?

From: Rob Vesse <rav08r@ecs.soton.ac.uk>
Date: Fri, 27 Jul 2012 09:54:51 -0700
To: semantic-web <semantic-web@w3.org>
Message-ID: <EMEW3|757312abd058f91d87cfe3b4aa7e272bo6QHuK06rav08r|ecs.soton.ac.uk|CC380A60.1313B%rav08r@ecs.soton.ac.uk>
Just as an interesting aside on this some common frameworks have proper
built in support for templating queries/updates which are designed to deal
with the SPARQL injection issue and to ensure sensible insertion of values
avoiding the foaf:Bill thing seen below

For Jena see ParameterizedSparqlString [1] which just treats any SPARQL
variable as a placeholder that can be injected into

For dotNetRDF see SparqlParameterizedString [2] which allows any SPARQL
variable as a placeholder and ADO.Net style @param style parameters

NB - I'm a developer on both of these projects and wrote both the above



On 7/27/12 6:37 AM, "David Booth" <david@dbooth.org> wrote:

>Hi Austin,
>On Fri, 2012-07-27 at 05:11 -0700, Austin William Wright wrote:
>> On Thu, Jul 26, 2012 at 1:06 PM, David Booth <david@dbooth.org> wrote:
>>         There doesn't seem to be any sort of community consensus on
>>         preferred
>>         syntax for indicating parameters in a SPARQL template.
>>          Several syntaxes
>>         were mentioned:
>>           {?foo}  %{foo}  %2  $foo  ${foo}
>> I'll echo Steve Harris's concerns about security.
>Yes, in fact, now that you mention it I think I will make the warning in
>the man page about this a bit more prominent.
>> You shouldn't place variables inside string literals, that's asking
>> for trouble. 
>Yes it is, so anyone using this template processor must be aware that
>those dangers exist if they choose to use it that way.  I included one
>example of such dangers in the man page:
>       Also, although bare words (or numbers!) are allowed as variable
>       they are usually not a good idea, because it is too easy to make a
>       mistake like writing the following:
>         #inputs( givenName )
>         SELECT *
>         WHERE { ?name foaf:givenName "givenName" }
>       which, when givenName has the value "Bill", will silently become:
>         SELECT *
>         WHERE { ?name foaf:Bill "Bill" }
>       which is probably NOT what you intended.
>> Why invent a new variable/placeholder when one already exists? Almost
>> certainly you should be passing a raw query, and binding values onto
>> variables at query-time, or some equivalent if you can't do this on
>> the query engine level:
>> var query = SPARQLSubstitute( "SELECT * { ?president
>> foaf:givenName ?firstName;  foaf:familyName ?lastName. }" ,
>> {firstName: "Bill", lastName:"Clinton"} );
>Yes, if you can get by with merely binding values to variables, then
>existing SPARQL mechanisms are definitely preferable.  But this template
>processor was designed to be able to handle cases that cannot be done
>that way, such as changing graph names in graph operations, or filling
>in a WHERE clause with an entire path of predicates.
>> For instance, modify a SPARQL lexer/parser to parse the query string
>> for particular variables, and substitute them with the (properly
>> escaped) value. No new, special syntax is necessary. You can probably
>> get by implementing subset of the SPARQL syntax since if you assume a
>> well-formed query, you only need to parse for variables and string
>> literals (and maybe comments). Luckily the SPARQL standard publishes a
>> fairly readable grammar, I wrote a parser in Javascript for all of
>> SPARQL 1.1 in a fairly short amount of time. (I might try this out
>> tomorrow.)
>That sounds like it could be useful.  But would it give more
>functionality than using BINDINGS?
>> Like you point out, you can't pass variable values over the HTTP query
>> protocol, a standard to do this over HTTP is very much needed.
>David Booth, Ph.D.
>Opinions expressed herein are those of the author and do not necessarily
>reflect those of his employer.
Received on Friday, 27 July 2012 16:56:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:48:38 UTC