Sunday, October 15, 2006

Precedence in SPARQL

A recent, "bug report" on the Jena mailing list was sent to me. Basically, it's saying that ARQ doesn't execute SPARQL the way that was expected and JRDF was being held up as correct.

This has to do with the "Nested OPTIONALs" problem, as described by Richard Cyganiak. It basically boils down to the fact that ARQ interprets queries in a left to right, top to bottom fashion; which is the way the SPARQL standard defines it. For example, { <pattern 1> opt { <pattern 2> opt { <pattern 3> } } } should be executed as: take the results of <pattern 1> opt <pattern 2> and then take the results and optionally match <pattern 3>.

This is contradictory to the expression: 6 / (3 - 2), where you perform what's most deeply nested first. To me SPARQL is saying the correct answer is 0 (2 - 2) rather than 6 (6 / 1).

For JRDF to meet SPARQL's requirements I'd either have to reorder the query or change to another compiler compiler, as SableCC is only an LALR parser. Again, not currently a problem for my current JRDF work but if I really want to stamp it SPARQL, when there are test cases that will fail, it will have to be fixed.

Update: This still seems an ongoing issue with the DAWG, "Issues with evaluating optional: Commutativity of AND".
Post a Comment