Hey All
A colleague was perplexed by some of the behavior mandated in the DAWG tests
(for SPARQL 1.0) which appear to not entirely coincide with the spec. The
first example I think I can explain so can someone (Andy?) confirm my
understanding. The second example I am somewhat stumped on so I'll come to
that and my best guess of what is happening in question and hope someone else
can explain why this happens.
Example 1
Consider the malformed literals "abc"^^xsd:integer and "xyz"^^xsd:integer
If you do the following queries both will return false which would seem a
little counter-intuitive
ASK WHERE { FILTER("abc"^^xsd:integer = "xyz"^^xsd:integer) }
ASK WHERE { FILTER("abc"^^xsd:integer != "xyz"^^xsd:integer) }
While this is counter-intuitive (you usually expect = and != to be reflexive) I
understand why this happens. In both cases we are selecting which operator to
use from the operator mapping and we will be selecting op:numeric-equals() in
the first case and fn:not(op:numeric-equals()) in the second. In both cases we
try and do numeric equality on the arguments but they are not valid numbers so
this gives a type error. fn:not() of an error is still an error. Since FILTER
treats error as false both queries yield false.
This can perhaps be better demonstrated by the following query:
SELECT (?a = ?b AS ?equals) (?a != ?b AS ?notEquals)
{
BIND("abc"^^xsd:integer AS ?a)
BIND("xyz"^^xsd:integer AS ?b)
}
This gives the following:
----------------------
| equals | notEquals |
======================
| | |
----------------------
So we can see that both expressions evaluate to error and thus give unbound in
the result set. As far as I can tell I understand and explain things fine so
far.
Example 2
Now this is where I get stumped, now consider the case where the malformed
literal is just "abc"^^xsd:integer. Now if I run the equivalent ASK queries I
get different answers.
ASK WHERE { FILTER("abc"^^xsd:integer = "abc"^^xsd:integer) }
ASK WHERE { FILTER("abc"^^xsd:integer != "abc"^^xsd:integer) }
In this case the first query gives true and the second gives false, while this
makes sense from just looking at it this seems to be at odds with the spec.
Using the same arguments as before we are using op:numeric-equals() to do the
equality check which should give a type error and thus both filters should
receive an error and thus result in false for both queries.
What seems to be happening is that the engine is trying op:numeric-equals() and
if it gets a type error falling back to RDF term equality and if that gives
true returns true/false as appropriate, if it gives false then it passes the
type error upwards. This doesn't appear to be mandated by the SPARQL
specification but the tests certainly include this.
Again we can see this with the SELECT form:
SELECT (?a = ?b AS ?equals) (?a != ?b AS ?notEquals)
{
BIND("abc"^^xsd:integer AS ?a)
BIND("abc"^^xsd:integer AS ?b)
}
This time we get the following results:
----------------------
| equals | notEquals |
======================
| true | false |
----------------------
When if my understanding from Example 1 were to hold I would expect to see
unbound for both of these again.
Am I just missing something in my understanding of the operator mapping and
expression evaluation part of the SPARQL specification or is there something
else going on?
Thanks,
Rob
