Thanks, Andy.
On 6/16/15 6:03 PM, Andy Seaborne wrote:
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?
http://w3c.github.io/data-shapes/shacl/
esp http://w3c.github.io/data-shapes/shacl/#sparql-constraints-prebound
http://www.w3.org/2014/data-shapes/track/issues/68
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.
Do you mean syntactic insertion like the ParameterizedQuery class? This
would not support bnodes, and the shapes and focus nodes of a SHACL
constraint will frequently be bnodes. It should also avoid repeated
query parsing, for performance reasons it would be better to operate on
Query objects and their general equivalents (Algebra objects).
2/ VALUES
There is a binding as a one row VALUES table and it's join'ed into the
query as usual.
I guess inserting a VALUES clause into the beginning would work, but
then again what about bnodes? I guess instead of the VALUES keyword (as
a string), it would need to rely on the equivalent algebra object?
Just to be clear, this only needs to work in local datasets, not
necessarily with SPARQL endpoints where all we have is a http string
interface. I am looking for a couple of sentences that would provide a
generic implementation strategy that most SPARQL engines either already
have, or could easily add to support SHACL.
Thanks
Holger
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
