In our epic quest to explore SPARQL conformance, we found that the manifest.ttl entry for eq-2-2 was an identical copy of the entry for eq-2-1, and fixed it to use query-eq2-2.rq and result-eq2.2.ttl. They use the same data file as the other expr-equals tests; it inserts about ten triples with different arguments intended to test the equality operator.
SPARQL's equals is a bit picky; not only will it return true or false in the cases you might expect; it will also produce a type error in several cases. For example, the string "1" compared to the blank node _:b0 should not return false, but instead produce an error.
While the not-equal operator isn't explicitly defined in the spec, I imagine it's reasonable for it to return the negative of RDFterm-equal when it would return a boolean, and produce a type error when RDFterm-equal would produce a type error. But if this is so, then I don't understand why "zzz"^^myType should be returned as an answer to the eq-2-2 query, as the spec requires.
Here's the query, minus overhead:
Suffice to say, the possible values for ?v1 and ?v2 include things like "1", "zzz", "zzz"^^myType, 1^^integer, 1^^double. (I'm omitting namespaces and such here; hopefully the meaning is still clear.) The result ends up being every possible pair of these values where != resolves to true.
What I can't figure out is how numbers are supposed to be treated. My understanding is that numbers are just typed literals, e.g. "1.0"^^xsd:double. That should mean they should compare to any other literal, typed or plain, without throwing an error. Comparing "1" to "1"^^xsd:integer should work just like comparing "1" to "1"^^oogly:boogly; both should resolve to not equal, I thought.
But the suite doesn't like that. It expects 12 answers - all differing pairs chosen from a set of four values: "1", "zzz", :z, and "zzz"^^myType.
Not only that, but in the previous test, eq-2-1, it thinks things like "1"^^integer should equal "1"^^double and "1.0e0"^^double, even though the SPARQL 1.0 spec defining literal equality (section 11.4.10) says this shouldn't hold. (It defines in terms of RDF literal equality, which in turn demands char-by-char equality. I'm guessing it really wants to factor in value equality where values are described in section 5 of the RDF spec, but I never saw it explicitly refer to that.)
What's correct here? My intuition is shaken here, esp. since the manifest.ttl itself had an error.
asked 18 Dec '12, 21:55
Sorry about the manifest error.
!= is indeed defined in the SPARQL 1.0 spec. See the operator mapping in section 11.3. Your intuition about how != treats errors is correct (!= maps to fn:not being applied to an error, and section 11.2 specifies that this should result in an error).
Note that = and != are not just short-hand for RDFterm-equal. The operator table specifically defines how to do = and != on numerics, simple literals, strings, booleans, and dateTimes.
You are correct that numbers are typed literal. But your conclusion that they should therefore compare without error to any other literal is not backed by the spec. In fact, the spec says:
Therefore, the two examples you give are type errors which remain as type errors even when negated by fn:not.
Regarding equality, please refer to my earlier comment that numeric equality is defined in the operator mapping table not via RDFterm-equal, but via the XPath op:numeric-equal function.
hope this helps,
answered 18 Dec '12, 22:09