Re: !=

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

Received on Sunday, 18 October 2009 14:04:19 UTC