better handling of FILTER in translation to algebra

[pfps]

Fixes #249

The current processing of FILTER expressions depends on an ill-defined "in" predicate and an unclear notion of what descendants of a groupgraphpattern are processed in its function.

---

Preview | Diff

[hartig]

I very much agree with the observation in #249 that the part about collecting the FILTER elements can be improved. Especially, the scope of this part, in combination with its integration into the overall translation algorithm should be made more explicit. In this sense, I generally like the direction of this PR.

However, simply moving the FILTER collection into the 'Translate Graph Patterns' section as done by this PR changes the outcome of the translation algorithm in terms of the basic graph patterns (BGPs) that are sub-expressions of the resulting algebraic expression. That is, originally (i.e., without this PR), FILTER elements are collected and removed before subsequent triple patterns are combined into BGPs (including also triple patterns created when rewriting property path patterns). Given the change in this PR, triple patterns are combined into BGPs already before removing the collected FILTER elements.

As a concrete example, consider the following group graph pattern.

{
  ?x :p ?y
  FILTER ( isIRI(?y) )
  ?y :q ?z
}

The original translation algorithm converts this into a Filter over a single BGP that consists of both triple patterns. In contrast, the translation algorithm in this PR converts this into a Filter over a Join of two BGPs, where each of these BGPs contains one of the two triple patterns, respectively.

Having said that, perhaps this change is not such a big deal because it doesn't have an impact on the query result (a join of two BGPs is semantically equivalent to a single BGP that is the union of the other two BGPs).

(Something else: this PR conflicts with PR #245, in the sense of one causing a merge conflict with the other.)

[afs]

The original translation algorithm converts this into a Filter over a single BGP that consists of both triple patterns. In contrast, the translation algorithm in this PR converts this into a Filter over a Join of two BGPs, where each of these BGPs contains one of the two triple patterns, respectively.

Having said that, perhaps this change is not such a big deal because it doesn't have an impact on the query result (a join of two BGPs is semantically equivalent to a single BGP that is the union of the other two BGPs).

It impacts SPARQL entailment regimes because they work on BGPs , not decomposes to triple patterns.

The filter be placed before its mentioned variables (unusual but possible) - putting at the end makes that work.

{
  FILTER ( isIRI(?y) )
  ?x :p ?y
  ?y :q ?z
}

[afs]

Placing gathered filters at the end needs to be retained.