On 10 Jul 2013, at 12:36, Joshua TAYLOR <[email protected]> wrote:
> I know that when there are *sub*-queries in a query, they're evaluted
> from the inside out (i.e., innermost subqueries are evaluated first),
> but this doesn't make sense for OPTIONAL patterns, does it? The whole
> point of an optional pattern is to *extend* the solutions of the
> enclosing pattern if possible.
They are extended in the join. Evaluate one block, evaluate other block, join.
What order this happens in may vary, as you say, but the answers are supposed
to be equivalent.
I'm still fuzzy looking at the spec on the FILTER case, but on BIND here are a
couple of fun facts:
* 'Use of BIND ends the preceding basic graph pattern'
OPTIONAL {
BIND( ?index - 1 as ?index2 )
?element2 :atIndex ?index2 .
}
BIND here is doing nothing at all, since it closes the block and there's
nothing preceding it. If you look at the output of --explain you'll find
(extend ((?index2 (- ?index 1)))
(table unit))
i.e. it's acting on nothing.
If you add it after the ?element2 triple you'll get an error, since ?index2 is
already bound.
* You can rearrange your second query to get what you want:
OPTIONAL {
?element2 :atIndex ?index2 .
BIND( ?index2 + 1 as ?index)
}
---------------------------------------
| element | index | element2 | index2 |
=======================================
| :a | 0 | | |
| :b | 1 | :a | 0 |
| :c | 2 | :b | 1 |
| :d | 3 | :c | 2 |
---------------------------------------
Damian
