Order of triples in SPARQL

[Aqualung]

I used to know that the order of triples in a SPARQL query should not matter, but I've come across cases where it does. I did come across such cases a long time ago, but I somehow became convinced in the meantime that it must have been a bad dream, or that I must have been doing something wrong. Or somethin'. Nevertheless, yesterday I got smacked in the face with the same behavior while running some code in TBCME. And by "should not matter" I do not mean that the code might run faster or slower depending on the order of triples, but that it gives patently different results(!).

Can anyone explain this? Can I get a definite answer as to whether the order of triples matter or not?

[Andy Seaborne]

Do you have an example of where it making a difference in one of your queries?

The order in a basic graph pattern (adjacent triple patterns) does not affect the results but if various other forms are mixed in, it can correctly, make a difference. e.g. BIND.

    Andy

[Aqualung]

SELECT ?ubo ?p

WHERE {

{SELECT ?ubo (SUM(?p4) AS ?perc)

WHERE { ... whatever ...

} GROUP BY ?ubo}

OPTIONAL{?ubo ubo:hasPerc ?x} .

BIND(?perc + IF(BOUND(?x), ?x, 0) AS ?p)

}

versus:

SELECT ?ubo ?p

WHERE {

OPTIONAL{?ubo ubo:hasPerc ?x} .

BIND(?perc + IF(BOUND(?x), ?x, 0) AS ?p)

{SELECT ?ubo (SUM(?p4) AS ?perc)

WHERE { ... whatever ...

} GROUP BY ?ubo}

}

The funny thing is that, as far as I know, the embedded query should be executed first no matter what.

Thanks for replying.

[Andy Seaborne]

These are two very different queries. OPTIONAL is order-dependent. (SQL leftjoin is order dependent.)

Triple order where triples are adjacent does not matter:

{ ?s :predicate1 ?v1 . ?s :predicate2 ?v2 . }

{ ?s :predicate2 ?v2 . ?s :predicate1 ?v1 . }


But
{ ?s :predicate1 ?v1 .
  OPTIONAL { ?s :predciate2 ?v2 }
}
does not have adjacent triples and it is different to
{
  OPTIONAL { ?s :predciate2 ?v2 }
  ?s :predicate1 ?v1 .
}

The first is, in SPARQL algebra terms is:

   (leftjoin
      (bgp (triple ?s :predicate1 ?v1))
      (bgp (triple ?s :predicate2 ?v2))) )

the second is

    (join
      (leftjoin
        (table unit)
        (bgp (triple ?s :predicate2 ?v2)))
      (bgp (triple ?s :predicate1 ?v1))))

because OPTIONAL is really a binary operator - it "optionals" to add matches to what went before.

In the second case, nothing goes before; in the first it's the sub-SELECT

You can experiment with the SPARQL algebra at http://sparql.org/validate/query

Yes - the inner select is evaluated before combining with the rest of the patterns. But in the first it is left-hand side of the OPTIONAL and in the second it is joined tot he results of OPTIONAL then BIND being evaluated.

    Andy