- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Wed, 19 Jul 2006 11:44:27 +0100
- To: Lee Feigenbaum <feigenbl@us.ibm.com>
- CC: public-rdf-dawg@w3.org
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