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".

3 comments:

Paula said...

I had difficulty following Bijan's post on this. Maybe I'm too iTQL focussed, but this statements didn't make sense to me:
P1 = ((?X :name :paul) AND ((?Y :name :george) OPT (?X :email ?Z)))

Bijan knows what he's on about, but I just don't understand this at all. Do you get it?

Andrew said...

I'm not sure what doesn't make sense. :-)

The optional is going to optionally add any statements that match ?X :email ?Z (where ?X will be bound to the values in ?X :name :paul).

The way I read the is join of the matching of ?X :name :paul and ?Y :name :george.

The paper that explains some of the problems (and misunderstandings) possible with optional is:
http://arxiv.org/abs/cs.DB/0605124

Andrew said...

I should also say that I'm a bit worried about the fact that SPARQL won't have operations that are both associative and commutative.

A good overview:
http://www-db.stanford.edu/~widom/cs346/chaudhuri.pdf