That shouldn't happen for Blazegraph, especially as they even have a
blog entry for this topic, dubbed "order matters":
https://github.com/blazegraph/database/wiki/SPARQL_Order_Matters
You can check the Blazegraph query plan as well, just put
&explain=details to the request URL
You can also try to disable the query optimizer via
SELECT ... WHERE {
hint:Query hint:optimizer "None".
...
}
If this changes the result, then there is a bug in Blazegraph
On 03.08.21 19:44, Marco Neumann wrote:
OK yes, thank you for the algebra hint and implicit empty graph pattern
Andy. Blazegraph has thrown me off here since it seems to interpret the
query differently. without preserving the table unit on the left hand side
I presume.
On Tue, Aug 3, 2021 at 6:20 PM Andy Seaborne <[email protected]> wrote:
On 03/08/2021 17:38, Marco Neumann wrote:
I have just noticed that the following query pattern with optionals
yields
undesirable SPARQL query results if the variable (?xLabel) isn't bound.
Let the data be: :x :p :y
SELECT ?x
WHERE{
OPTIONAL{ ?x rdfs:label ?xLabel.}
?x :p ?y.
}
(join
(leftjoin
(table unit)
(bgp (triple ?x rdfs:label ?xLabel)))
(bgp (triple ?x :p ?y)))))
Note the (table unit) in the leftjoin
SELECT ?x
WHERE{
{}
OPTIONAL{ ?x rdfs:label ?xLabel.}
?x :p ?y.
}
while reversing the order in the query pattern yields a result as
expected:
:x
SELECT ?x
WHERE{
?x :p ?y.
OPTIONAL{ ?x rdfs:label ?xLabel.}
}
(project (?x)
(leftjoin
(bgp (triple ?x :p ?y))
(bgp (triple ?x rdfs:label ?xLabel)))))
Is this (the importance of order of optionals) a normal behavior during
query execution here?
Yes - it is correct. They are different queries with different results
(this is not an optimizer issue).
Andy
