On 05/09/12 01:45, Holger Knublauch wrote:
On 9/3/2012 19:33, Andy Seaborne wrote:
Holger,
You've used ?dummy inside the GRAPH (where it will be undef) which
blocks the optimizer from using (sequence)
Bottom-up evaluation: logically the inner part of the GRAPH is
calculated and then combined with the rest of the top-level pattern
group.
Would it make sense / be possible to check such things at query compile
time? I guess BIND of a variable makes no real sense if the same
variable is also used in an inner block, such as the GRAPH { ... }?
Possible - yes.
Sensible - a warning (static check of never can be bound) might be
useful but it is a legal query.
(sequence) exposes the left hand scope to the later clauses but here
that change the query by exposing the value from the BIND to the GRAPH
clause.
Try with FILTER (?anotherDummy > 0)
Yes this works, but what I don't understand is why the second BIND would
have an impact on the first one.
It doesn't. You can remove the
BIND (<http://topbraid.org/examples/kennedys> AS ?graph)
and the example still holds.
I can imagine that your code is
grouping the BINDS together in the Algebra,
Yes - it's more often easier to work with it as a set of expr/var pairs
than a nesting of expressions which can be in either order.
and that splitting them to
allow a smarter algorithm is too complicating.
The sequence vs join is not about BIND - it's purely that the query is
{
... ?dummy ...
GRAAPH { .... FILTER ?dummy.... }
}
It could be a bind or a triple pattern - anything that can set a
variable in which case it will be set in the intermdiate answers and
hence 'sequence' can't be used because sequence only works when the
bindings of the LHS can be validly used in the RHS - which they can't if
that FILTER is there.
On the downside this is
another case where things get very hard to understand and explain to end
users.
End users looking at the algebra? Excellent.
Andy
The problem is that execution order matters a lot here, because
people usually never want to iterate over all graphs in the dataset.
Regards
Holger
Andy
On 03/09/12 04:08, Holger Knublauch wrote:
Hi SPARQL gurus,
In ARQ 2.9.2 I have the following two queries
SELECT *
WHERE {
BIND (<http://topbraid.org/examples/kennedys> AS ?graph) .
BIND (42 AS ?dummy)
GRAPH ?graph {
?s rdfs:subClassOf ?o .
}
}
SELECT *
WHERE {
BIND (<http://topbraid.org/examples/kennedys> AS ?graph) .
BIND (42 AS ?dummy)
GRAPH ?graph {
?s rdfs:subClassOf ?o .
FILTER (?dummy > 0) # This is different
}
}
The seemingly trivial addition of the FILTER causes the lower one not to
work as expected. It will iterate over all graphs instead of using the
BIND. It's for some reason executing the BIND *after* the GRAPH. A look
at the debugger reveals the difference in algebra. The upper one is
(sequence
(extend ((?graph <http://topbraid.org/examples/kennedys>) (?dummy
42))
(table unit))
(graph ?graph
(bgp (triple ?s rdfs:subClassOf ?o))))
and the lower one becomes
(join
(extend ((?graph <http://topbraid.org/examples/kennedys>) (?dummy
42))
(table unit))
(graph ?graph
(filter (> ?dummy 0)
(bgp (triple ?s rdfs:subClassOf ?o)))))
What is causing this difference? It feels very inconsistent. How can I
safely execute the BIND before the GRAPH?
Thanks
Holger
