On 16/06/15 04:20, Holger Knublauch wrote:
Hi,
(this question is motivated by the ongoing Data Shapes WG, but I don't
speak on their behalf).
Ptr?
Jena and other APIs such as Sesame support the concept of pre-binding
variables prior to SPARQL execution, using
QueryExecution.setInitialBinding(). This is convenient to reuse
parameterized queries, especially with blank nodes.
Question: is there any formal basis of this functionality, formulated so
that it can be implemented by other platforms too? I can see that it
populates the original bindings that are passed through the algebra
objects, but what would be the best way to explain this by means of
concepts from the SPARQL 1.1 spec?
Thanks
Holger
There are two possible explanations - they are not quite the same.
1/ It's a substitution of a variable for a value execution. This is
very like parameterized queries. It's a pre-execution step.
2/ VALUES
There is a binding as a one row VALUES table and it's join'ed into the
query as usual.
Differences in these viewpoints can occur in nested patetrns -
sub-queries (you can have different variables with the same name - a
textual substitution viewpoint breaks that) and OPTIONALs inside
OPTIONALs (bottom up execution is not the same as top down execution).
This has existed in ARQ for a very long time. ARQ actually takes the
initial binding and seeds the execution from there so it's like (2) but
not exactly; it does respect non-projected variables inside nested
SELECTS; it does not complete respect certain cases of
OPTIONAL-inside-OPTIONAL.
Andy
