- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Thu, 19 Jan 2006 15:19:22 +0000
- 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 UTC