Here is a testcase for optional triples:
Data:
:x :p :a .
:x :q :b .
Query: (Using [] to indicate an optional match)
Q1: two separate optional parts:
[(:x :p ?v)]
[(:x :q ?v)]
Possible results:
R1: ?v = :a
which matches the first part but then the second can't match.
R2: ?v = :b
which matches the second part but not the first.
If executed in order, this would only happen is the first part included the
"no match" case or if the second triple were matched first.
R3: ?v = null is the trivial case of no match from either part and is
unlikely to be what the application writer expects. If the query is:
[(:x :p ?v)]
a result of:
?v = null // Choosing not to match ?v
?v = :a // mathcing ?v
seems unhelpful
Q2:
[(:x :p ?v) (:x :q ?v)]
has no match because ?v can't be both :a and :b
The key point here is that ?v occurs in both parts: in Q1, the optional
parts are independent, in Q2 there is one optional part of two triple
patterns. I think we will need to either define what happens or have some
execution model that does not let the case of binding in different optional
parts arise.
Andy