- 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