I have a question about the test 'open-eq-10', as found here:
http://www.w3.org/2001/sw/DataAccess/tests/data-r2/open-world/
This test demonstrates !=. If a pair of values appears in the output,
it means that the != comparison returned true.
Amongst these pairs are the following:
"xyz"@en "abc"^^<http://www.w3.org/2001/XMLSchema#integer>
"xyz"@en "abc"^^<http://example/unknown>
"xyz"@en "abc"^^<http://www.w3.org/2001/XMLSchema#integer>
"xyz"@en "abc"^^<http://example/unknown>
"xyz"^^<http://www.w3.org/2001/XMLSchema#integer> "abc"@en
"xyz"^^<http://www.w3.org/2001/XMLSchema#integer> "abc"@en
"xyz"^^<http://example/unknown> "abc"@en
"xyz"^^<http://example/unknown> "abc"@en
I don't agree with these with regards to the spec. Here is my analysis.
Comparing the first two, we find that one is a numeric literal, the
other a language-tagged literal.
There is no row in "SPARQL Binary Operators" for this pair, so we
deduce that the base case matches:
A != B RDF term RDF term fn:not(RDFterm-equal(A, B))
RDFterm-equal is defined as raising a type error if its arguments "are
both literal but are not the same RDF term".
This error is propagated by fn:not, because the type error is not
transformed by the EBV process in 11.2.2. Indeed, 11.3 states:
Note that per the XPath definitions, fn:not and op:numeric-equal
produce an error if their argument is an error.
and thus 11.2 applies directly:
• Any expression other than logical-or (||) or logical-and (&&) that
encounters an error will produce that error.
This whole comparison, then, returns a type error, which is
interpreted as a failure of the FILTER. This pair of values should not
appear in the results for this query.
The same reasoning applies for all 8 result rows above. *Intuitively*
these values are all !=, and that would be the case if the comparison
were fn:not(sameTerm(?v1, ?v2)), but according to the spec that's not
the case for !=.
So far as I can see, either:
* The spec meant to state that fn:not catches type errors (which,
admittedly, would be a very useful behavior).
* The tests assume an extended implementation that has a bunch of
"catch-all" rows.
Can anyone please enlighten me?
If a non-extended implementation is correct in not returning these
rows, I'll simply amend my local copy of the tests.
Thanks,
-R
