Re: Template language for SPARQL?

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
implementations

Rob

[1] 
http://jena.apache.org/documentation/javadoc/arq/com/hp/hpl/jena/query/Para
meterizedSparqlString.html
[2] 
http://www.dotnetrdf.org/api/index.asp?Topic=VDS.RDF.Query.SparqlParameteri
zedString


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
>names,
>       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?
>
>David
>> 
>> 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.
>http://dbooth.org/
>
>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