On 26/03/13 04:10, Holger Knublauch wrote:
I have always wondered why the SPARQL 1.1 WG did not decide to allow
variables in OFFSET and LIMIT - both are common patterns in interactive
UIs where users page through a result set. I believe it would be great
if this was supported in ARQ Syntax, and maybe SPARQL 1.2 will align
with ARQ Syntax just like it did in previous iterations.
I would personally prefer to go with established techniques such as
pre-binding before inventing another query preprocessor syntax that
cannot be parsed by SPARQL parsers and that opens the door to other
problems.
SPIN already has a syntax for templates and a mechanism to declare
arguments. It has been used for quite some time now and seems to work well.
Holger
Useful if the variables can get bound externally - prepared queries was
considered too much additional work. They cover various issues so
adding a work item like that was significant.
If it can be broken down into specific items, deployed in multiple
systems, we can make some progress.
Using templates is an established techniques from SQL prepared queries
where they use the positional "?" rather than named slots. Originally
for performance reasons, nowadays they are important e.g. "INSERT ..
VALUES ..." for applications.
It's the security and application API featues I'm looking at. The
precompiled queries apsect is rather system specific (it can make a
differece see some of the small queries in BSBM - but I don't see it as
a major problem in the semantic web).
Having looked at usage patterns and all the SPARQL 1.1 work, I'm not
currently convinced prepared queries need stanardizing - adding
complexity comes at a cost. The impact on the protocol is substantial
and the statefulness at odds with HTTP if precomplied queries were done.
A useful part of prepared queries is parameters+templates.
Treating this as an API issue seems a viable way to go. Then maybe add
to Fuseki as a protocol extension (need query references as well to be
useful, which incidental is part of the needed precompiled optimizations
without getting into spec'ing server query management which is woolly at
best and a spec-nightmare).
This would replace pre-binding -- it addresses some of the problems of
that mechanism where they are (1) somewhat at odds with SPARQL Update,
(2) don't work for the INSERT DATA case, (3) are dangerous if you forget
to bind a variable and get a very expensive query and (4) ad hoc.
Andy
If we're tweaking the syntax anyway, we might as well have template
variable syntax.
The reason for some checking is so you can't do "SELECT * { ?s ?p ?o
}" forgetting to replace ?s with a URI, for example.
== Query
LIMIT and OFFSET take fixed integers by syntax and ideally they would
parameters.
== Update
INSERT DATA / DELETE DATA restrict
It would be good to have template data updates. But the data part of
INSERT DATA explicitly forbids variables.
To this end, I have got the machinery for transforms of Element
objects (c.f. transforms on Ops) working. By working on the AST,
injection is harder because the template parameter must be a Node to
go in the right place in the AST.
Comments and thoughts?
Rob - does this relate to jena-jdbc in some way?
Andy
[1]
public static void injection() {
String str =
"PREFIX : <http://example/>\nINSERT DATA { <s> <p> ?var2 . }" ;
ParameterizedSparqlString pss = new ParameterizedSparqlString(str) ;
pss.setIri("var2",
"hello> } ; DROP ALL ; INSERT DATA { <s> <p> <goodbye"
) ;
String x = pss.toString() ;
System.out.println(x) ;
}
