On Tue, Jul 3, 2012 at 10:56 AM, Claude Warren <[email protected]> wrote:
> I was looking at a couple of queries and found that
>
> SELECT * WHERE {
> ?x a <foo> .
> OPTIONAL{ ?x <bar> ?bar } .
> OPTIONAL{ ?y <baz> ?baz }
> }
>
> becomes
> (leftjoin
> (leftjoin
> (bgp (triple ?x <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
> <file:///home/claude/workspace/RoadMap/foo>))
> (bgp (triple ?x <file:///home/claude/workspace/RoadMap/bar> ?bar)))
> (bgp (triple ?x <file:///home/claude/workspace/RoadMap/baz> ?baz)))
>
> BUT ....
>
> SELECT * WHERE {
> ?x a <foo> .
> OPTIONAL{ ?x <bar> ?bar .
> ?y <baz> ?baz }
> }
>
> becomes
>
> leftjoin
> (bgp (triple ?x <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
> <file:///home/claude/workspace/RoadMap/foo>))
> (bgp
> (triple ?x <file:///home/claude/workspace/RoadMap/bar> ?bar)
> (triple ?x <file:///home/claude/workspace/RoadMap/baz> ?baz)
> ))
>
>
> It seems to me that the 2nd form is much more efficient. (Am I wrong
> here?)
> That leads me to ask "Is there ever a time when 2 adjacent option
> statements can not be merged into a single statement?"
> And if not, should the parser be optimized to do the merging?
>
These are not the same query, so no, the first form should never be
rewritten by ARQ to match the second form.
The first form, with multiple optional clauses, will match each optional
part independently, and the result set that it produces may have either
?bar or ?baz unbound for any given solution.
The second form, with two triple patterns in a single optional clause, will
resolve the entire BGP at once, and will produce a result set where ?bar
and ?baz are either both bound or both unbound for every solution.
-Alex
