- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Fri, 13 Jan 2006 22:01:16 +0000
- To: Eric Prud'hommeaux <eric@w3.org>
- Cc: public-rdf-dawg@w3.org
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. > 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 Friday, 13 January 2006 22:01:24 UTC