While the datatype of "abc"^^xsd:integer and "xyz"^^xsd:integer is set to "xsd:integer", the fact that the values are not in the domain of those types should make the types "RDF terms" instead of "numeric". In that case, the appropriate operations are not op:numeric-equal(), but RDFterm-equal and fn:not(RDFterm-equal).
The definition of RDFterm-equal says that it returns true only if the compared terms are the same term. If both terms are literals but not the same term, then they produce a type error. This is consistent with the cases you show in the first example (unbound), since the compared values are different terms. The second example compares values that are literal and are the same term. This means that RDFterm-equals returns "true", and fn:not(RDFterm-equal) returns false. Paul On Thu, Jan 24, 2013 at 1:57 PM, Rob Vesse <[email protected]> wrote: > 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 > >
