Re: Template language for SPARQL?

Hey all,

please also take a look at QueryBuilder I've developed (uses SPIN API):
https://github.com/Graphity/graphity-browser/blob/master/src/main/java/org/graphity/util/QueryBuilder.java

What do you think about builder pattern approach?

Martynas
graphity.org

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
>>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 22:18:52 UTC