SPARQL defines evaluation bottom-up while bigdata performed vectored pipelined evaluation. In general, pipelined evaluation, which is close to top-down evaluation, does not conflict with bottom up evaluation. However, conflicts in the evaluation semantics can appear in cases where an intermediate join group does not provide a shared variable. A difference in semantics can also appear when a variable would not be visible in bottom up evaluation, but is already bound in pipelined evaluation. For queries where bottom-up and top-down evaluation differ, the query is often incorrect (it will not do what the user intends) and some platforms reject such queries out of hand.
Static analysis of join groups can determine when top-down evaluation would have different semantics. As indicated above, this breaks down into two cases:
(A) bottom up evaluation is required;
(B) bottom up evaluation can be mimicked by hiding variable bindings.
To address this issue:
1. Write a method which performs the static analysis and determines whether the two evaluation strategies would produce different results.
2. For cases which require bottom-up evaluation, perform bottom-up evaluation rather than pipelined evaluation.
3. As a special case, FILTERs may be unable to observe variables whose bindings are already known to a piplined evaluation strategy. This case can be handled by utilizing LET operators and anonymous variable names or "masking off" certain variables in order to "hide" the variable binding from the FILTER in a particular scope.
See "The Semantics and Complexity of SPARQL" by J Perez , Section 4.3 "Well-designed patterns and normalization"