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 <a...@apache.org> 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
>
--
---
Marco Neumann
KONA
