Re: !=

[Andy Seaborne]

Richard,

Test open-eq-10 is annotated with:
:open-eq-10 a mf:QueryEvaluationTest ;
    ...
    mf:notable mf:IllFormedLiteral ;
    mf:requires mf:KnownTypesDefault2Neq ;
    mf:requires mf:LangTagAwareness ;
    ...

test-manifest.n3 has:

:LangTagAwareness       rdf:type :Requirement ;
    rdfs:comment "Tests that require langauge tag handling in FILTERs" .

With lang tag awareness, the != operator can be overridden (because it's 
an error) and, with lang tags, it is definitely known that @en and and 
^^xsd:integer are different values.  I tend to think of each language 
tag inducing a independent value space.

I hope you will decide to provide support for language tags.

        Andy

Richard Newman wrote:
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