!=

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

Received on Sunday, 18 October 2009 03:02:29 UTC