approved DAWG test: extendedType-ne-fail

Hi DAWGs,

I'm trying to figure out how to derive the expected results of test 
extendedType-ne-fail based on the spec. text of rq23, and having 
difficulty. Would appreciate some pointers to what I'm missing or else 
some clarification in the spec. or test. 

The test is found at: 
http://www.w3.org/2001/sw/DataAccess/tests/#extendedtype-ne-fail

The test compares typed literals using != in a FILTER expression. In 
particular, it pairwise compares these literals:

"30.300000"^^loc:latitude
"-7420507.1"^^loc:ECEF_X

The test expects no results because, as the text that accompanies it says,

"""
Opaque types can not be tested for != .
"""

Now, what does the spec tell us?

In the operator mapping table (section 11.3, 
http://www.w3.org/2001/sw/DataAccess/rq23/#OperatorMapping ) we see that 
SPARQL defines A != B where A and B are both RDF Terms as 
fn:not(RDFTerm-equal(A,B)). So we check out RDFTerm-equal ( 
http://www.w3.org/2001/sw/DataAccess/rq23/#func-RDFterm-equal ) and learn 
that for literals, we need ot check out 6.5.1 Literal Equality of RDF 
Concepts. Heading over that way ( 
http://www.w3.org/2001/sw/DataAccess/rq23/#func-RDFterm-equal ) we see 
that:

"""
Two literals are equal if and only if all of the following hold:

    * The strings of the two lexical forms compare equal, character by 
character.
    * Either both or neither have language tags.
    * The language tags, if any, compare equal.
    * Either both or neither have datatype URIs.
    * The two datatype URIs, if any, compare equal, character by 
character.
"""

Clearly these conditions don't hold for the literals above and so by RDF 
Concepts they are not equivalent literals, and then by the definition of 
RDFTerm-equal the comparison is false. fn:not then performs logical 
negation and so the FILTER test comes out true, and the bindings should be 
included in the solution set. 

Nowhere in rq23 do I see any reference to opaque types or the open-world 
assumption or anything else that I thought to search for to find text that 
changes the interpretation of != in this case.

So either my understanding is wrong, the spec is wrong, or the test is 
wrong. Which is it? :-)

Lee

PS http://www.w3.org/2001/sw/DataAccess/tests/#extendedtype-ne-fail says 
that this test was approved in 
http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JulSep/0175 . 
Looking at those minutes, I see the approval of the companion test 
extendedType-eq-pass, but not of this particular test.  Searching the list 
archives for extendedtype-ne-fail doesn't turn anything up.

PPS SPARQLer (ARQ) agrees with the expected test results as in the 
approved test. My pre-pre-alpha implementation agrees with my reading of 
the spec, for obvious reasons. ;-) I haven't tested any other 
implementations.

Received on Wednesday, 19 July 2006 03:23:05 UTC