The default behavior of the GraphDB query optimiser is to try and reposition BIND clauses so that all the variables within its EXPR part (on the left side of 'AS') are bound to have valid bindings for all of the variables referred within it.
If we look at following data:
and try to evaluate a SPARQL query such as the one below (without any rearrangement of the statement patterns):
the 'correct' result would be:
because the expression that sums several variables will not produce any valid bindings for ?R.
But if we rearrange the statement patterns in the same query so that we have bindings for all of the variables used within the sum expression of the BIND clause:
the query would return a single result and now the value bound to ?r will be "6":
By default, the GraphDB query optimiser will try to move the BIND after the last statement pattern, so that all the variables referred internally have a binding. However, that behavior can be modified by using a special 'system' graph within the dataset section of the query (e.g. as 'FROM' clause) that has the following IRI:
In this case, the optimiser will retain the relative position of the BIND operator within the group in which it appears, so that if we evaluate the following query against the GraphDB repository:
we will get the following result:
Still, the default evaluation without the special 'system' graph will provide a more useful result:
Skip to end of metadata Go to start of metadata