Re: approved DAWG test: extendedType-ne-fail

Lee Feigenbaum wrote:
> 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 != .
> """

Hmm ... not sure what an "opaque type" is because we have a requirement for 
extensibility.

> 
> 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. 

The text and the test are at odds.

> 
> 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? :-)

I believe the spec is not open world with respect to value testing and it 
should be.

Short reason: it does not permit operations on other types, xsd:date being a 
good example.  Seems quite reasonable for a processor to support xsd:date, 
ordering and all but as things stand, a processor that does so will violate 
the spec.

I wrote some open world valuetests

http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0104.html

!= on unknown types is not a very useful test.

	Andy
> 
> 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.

PPPS Yes - SPARQLer is running with the open world definition for !=   That's 
my understanding of the design intent as captured by the test.

Received on Wednesday, 19 July 2006 10:44:51 UTC