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

Re: Template language for SPARQL?

From: (wrong string) čius <martynas@graphity.org>
Date: Sat, 28 Jul 2012 01:18:24 +0300
Message-ID: <CAE35VmzeV11Oky8oCBV+ozMqjD-HF_8R8=YuHtPxLv+yWf1S5Q@mail.gmail.com>
To: Rob Vesse <rav08r@ecs.soton.ac.uk>
Cc: semantic-web <semantic-web@w3.org>
Hey all,

please also take a look at QueryBuilder I've developed (uses SPIN API):

What do you think about builder pattern approach?


On Fri, Jul 27, 2012 at 7:54 PM, Rob Vesse <rav08r@ecs.soton.ac.uk> wrote:
> 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
>>       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 22:18:52 UTC

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