W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2006

Re: 7 tests to induct xsd:boolean into SPARQL

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Thu, 19 Jan 2006 15:19:22 +0000
Message-ID: <43CFADFA.1090706@hp.com>
To: "Seaborne, Andy" <andy.seaborne@hp.com>
CC: "Eric Prud'hommeaux" <eric@w3.org>, public-rdf-dawg@w3.org



Seaborne, Andy wrote:
> 
> 
> Eric Prud'hommeaux wrote:
>> On Fri, Jan 13, 2006 at 11:45:29AM +0000, Seaborne, Andy wrote:
>>>
>>> Eric Prud'hommeaux wrote:
>>>> A while ago, it became clear that, since we were talking about
>>>> xsd:boolean in the spec, the type should probably be recognized by
>>>> SPARQL. To that end, I've created these tests:
>>>>
>>>> EBV result is the same as xsd:boolean
>>>> -> http://www.w3.org/2001/sw/DataAccess/tests/#boolean-logical-or
>>>>
>>>> "false"^^xsd:boolean = "0"^^xsd:boolean
>>>> -> http://www.w3.org/2001/sw/DataAccess/tests/#boolean-equiv-false
>>>>
>>>> "true"^^xsd:boolean = "1"^^xsd:boolean
>>>> -> http://www.w3.org/2001/sw/DataAccess/tests/#boolean-equiv-true
>>>>
>>>> T=T T=1 1=T 1=1 F=F F=0 0=F 0=0
>>>> -> http://www.w3.org/2001/sw/DataAccess/tests/#boolean-equiv-xsdtype
>>>>
>>>> graph match canonical lexical form of "false"
>>>> -> http://www.w3.org/2001/sw/DataAccess/tests/#boolean-false-canonical
>>>>
>>>> graph match on the canonical lexical form of "true"
>>>> -> http://www.w3.org/2001/sw/DataAccess/tests/#boolean-true-canonical
>>>>
>>>> = match on the canonical lexical result of an EBV
>>>> -> http://www.w3.org/2001/sw/DataAccess/tests/#boolean-ebv-canonical
>>>>
>>>>
>>> I ran the tests in tests/data/ValueTesting:
>>> Tests = 14 : Successes = 11 : Errors = 0 : Failures = 3
>>>
>>> ==== "typePromotion-decimal-decimal-pass"
>>> typePromotion-decimal-decimal-pass.rq
>>>
>>> Test fails:
>>> http://lists.w3.org/Archives/Public/public-rdf-dawg/2005OctDec/0339.html
>> agreed -- due to the first line in the second table that says that the
>> result of two integer operations is an interger (which is a little odd
>> because integer is the only derived type with that behavoior, but i
>> expect they have their reasons).
>>
>>> ==== "boolean-false-canonical"
>>>
>>> Should be two results if graph matching is done by value.
>>> #ftext and #fdigit both match the value false.
>>>
>>> Uses rdfs:value.
>>>
>>> ==== "boolean-true-canonical"
>>>
>>> As "boolean-false-canonical", there are 2 matches if the graph matching 
>>> done by value on the objects.
>>>
>>> #ttext and #tdigit both match the value true.
>> These two both depend on whether we require D-entailment (two
>> answers), avoid D-entailment (one answer), or limit ourselves to tests
>> that are agnostic about D-entailment (strike the test).
> 
> And furthermore they depend on whether the D-entailment is done in the graph 
> or in the query engine.  I [*] was doing some D-entailment in the query engine 
> because that way the input graph syntax is maintained - users like reading in 
> and writing out to look the "same".
> 
> For me, the tests explain and illustrate the language but furthermore I'd like 
> it if systems would use them as part of their test suites.
> 
> I flipped to the plainest of plain graph implementations and it passes those 
> two tests.

More ...

(DanC: please note)

Somewhile ago I added tests at Dan's request to show the relationship between 
filters and graphs.

I reran tests with the plainest of plain graph implementations and some of 
these now do not pass.

http://www.w3.org/2001/sw/DataAccess/tests/data/ExprEquals/

Equality 1-1 -- graph
http://www.w3.org/2001/sw/DataAccess/tests/data/ExprEquals/query-eq-graph-1.rq

Equality 1-2 -- graph
http://www.w3.org/2001/sw/DataAccess/tests/data/ExprEquals/query-eq-graph-2.rq

Equality - 2 var - test equals -- graph
http://www.w3.org/2001/sw/DataAccess/tests/data/ExprEquals/query-eq2-graph-1.rq


To take one of them:
    { ?x :p ?v . FILTER ( ?v = 1 ) . }
and
     { ?x :p 1 }
are not the same any more because the 1 does not graph-match "1"^^xsd:double.

I have commented out these tests for now because they are not approved and 
seem to be wrong.  There's a brief note in the manifest.

	Andy

> 
>> Some argument could be made for the latter, though I would expect some
>> text in rq23 to tell the world that they can't count on the presence
>> or absense of D-entailment.
> 
> It's described in the test suite README.
> 
> And also there is sec 3.4
> http://www.w3.org/2001/sw/DataAccess/rq23/#matchDEntail
> 
> Is that OK?
> 
>> We can't make allowances like this for all
>> concievable entailments, but we can for D-entailment, RDFS and OWL-* .
> 
> 	Andy
> 
> [*] It wasn't me personally.  Chris, Jeremy and Dave did all that work to 
> cover XSD datatypes.
> 
Received on Thursday, 19 January 2006 15:25:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:25 GMT