# Retain BIND position special graph¶

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 you look at the following data:

INSERT DATA {
<urn:q> <urn:pp1> 1 .
<urn:q> <urn:pp2> 2 .
<urn:q> <urn:pp3> 3 .
}


and try to evaluate a SPARQL query such as the one below (without any rearrangement of the statement patterns):

SELECT ?r {
?q <urn:pp1> ?x .
?q <urn:pp2> ?y .
BIND (?x + ?y + ?z AS ?r) .
?q <urn:pp3> ?z .
}


the ‘correct’ result would be:

1 result: r=UNDEF


because the expression that sums several variables will not produce any valid bindings for ?r.

But if you rearrange the statement patterns in the same query so that you have bindings for all of the variables used within the sum expression of the BIND clause:

SELECT ?r {
?q <urn:pp1> ?x .
?q <urn:pp2> ?y .
?q <urn:pp3> ?z .
BIND (?x + ?y + ?z AS ?r) .
}


the query would return a single result and now the value bound to ?r will be 6:

1 result: r=6


By default, the GraphDB query optimiser tries 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 URI:

<http://www.ontotext.com/retain-bind-position>.


In this case, the optimiser retains the relative position of the BIND operator within the group in which it appears, so that if you evaluate the following query against the GraphDB repository:

SELECT ?r
FROM <http://www.ontotext.com/retain-bind-position> {
?q <urn:pp1> ?x .
?q <urn:pp2> ?y .
BIND (?x + ?y + ?z AS ?r) .
?q <urn:pp3> ?z .
}


you will get the following result:

1 result: r=UNDEF


Still, the default evaluation without the special ‘system’ graph provides a more useful result:

1 result: r="6"