- From: Arjohn Kampman <arjohn.kampman@aduna-software.com>
- Date: Tue, 18 Sep 2007 20:03:44 +0200
- To: Eric Prud'hommeaux <eric@w3.org>
- CC: Jeremy Carroll <jjc@hpl.hp.com>, public-rdf-dawg-comments@w3.org
Thank you for clarifying this. Arjohn Eric Prud'hommeaux wrote: > In response to Arjohn's comment, the DAWG has added the top bullet > point in the resolution of effective boolean values: > [[ > The following rules reflect the rules for fn:boolean applied to the > argument types present in SPARQL Queries: > +------------------------------------------------------------------+ > | • The EBV of any literal whose type is xsd:boolean or numeric is | > | false if the lexical form is not valid for that datatype | > | (e.g. "abc"^^xsd:integer). | > +------------------------------------------------------------------+ > > • If the argument is a typed literal with a datatype of > xsd:boolean, the EBV is the value of that argument. > > • If the argument is a plain literal or a typed literal with a > datatype of xsd:string, the EBV is false if the operand value > has zero length; otherwise the EBV is true. > > • If the argument is a numeric type or a typed literal with a > datatype derived from a numeric type, the EBV is false if the > operand value is NaN or is numerically equal to zero; otherwise > the EBV is true. > > • All other arguments, including unbound arguments, produce a type > error. > > An EBV of true is represented as a typed literal with a datatype of > xsd:boolean and a lexical value of "true"; an EBV of false is > represented as a typed literal with a datatype of xsd:boolean and a > lexical value of "false". > ]] > > Many thanks to Arjohn and Jeremy. > > > * Jeremy Carroll <jjc@hpl.hp.com> [2007-08-07 10:28+0100] >> >> IMO the ebv of "aaa"^^xsd:int should be either false or an error (however >> you represent an error). >> >> I believe the quoted text says the EBV is true (see below). >> >> >> I suggest an additional introductory sentence concerning EBV along the >> lines of: >> >> >> "For typed literals that are not <a >> href="http://www.w3.org/TR/rdf-mt/#illformedliteral">ill-typed</a>:" >> >> scoping the quoted text, and any other text defining EBVs for typed >> literals. >> >> >> And an additional paragraph: >> >> "The EBV of any <a >> href="http://www.w3.org/TR/rdf-mt/#illformedliteral">ill-typed</a> >> literal is false." >> >> (or whatever). >> >> >> Note the link basically says RDF works OK with ill-typed literals, but they >> do not have a literal value. >> >> My reading of the quoted paragraph with "aaa"^^xsd:int is a s follows. >> >> >>>> "If the argument is a numeric type or a typed literal with a datatype >>>> derived from a numeric type, >> xsd:int is a datatype derived from a numeric type >> >>>> the EBV is false if the operand value is >>>> NaN or is numerically equal to zero; >> The operand is neither NaN or 0 >> >>>> otherwise the EBV is true." >> thus the EBV is true :( >> >> >> Jeremy >> >> PS I have not looked at the surrounding context for the quoted text, but >> believe that this is msg should be sufficiently helpful. If you need be to >> look at more text please send a link: but I'm only working a few hours this >> week. >> >> >> >> Eric Prud'hommeaux wrote: >>> Heya Jeremy, I thought I'd see if you knew the answer to this one off >>> the top of your head. I think the question is basically what is the >>> denotation (in mt tersm) of "bla"^^xsd:integer . >>> Thoughts so far: >>> - There is no <"bla", x> in xsd:integer. >>> - It would be impractical to demand that SPARQL work only on consistent >>> graphs (since it's a moving target). >>> - Even consistent wrt a subset of xsd-entailments ( >>> * xsd:integer >>> * xsd:decimal >>> * xsd:float >>> * xsd:double >>> * xsd:string >>> * xsd:boolean >>> * xsd:dateTime >>> ) would be impractical as the insertion of "bla"^^xsd:integer wold >>> make the whole graph disappear (or fall outside SPARQL). >>> - Maybe the triple {_:bob foaf:age "bla"^^xsd:integer} simply doesn't >>> exist, but then the graph-pattern-matching part of SPARQL has to do >>> expensive validity checking best left for FILTERs. >>> - EBVs and XPath invocation text could say that illegal lexical values >>> result in err:FOCA0002: Invalid lexical value. >>> -- http://www.w3.org/TR/xpath-functions/#ERRFOCA0002 >>> Arjohn's comment was about the boolean value of "bla"^^xsd:integer (say >>> FILTER ("bla"^^xsd:integer && TRUE)) but it also pertains to the rest >>> of the XPath-based operators ("bla"^^xsd:integer + 7). Their invocation >>> is defined in >>> http://www.w3.org/2001/sw/DataAccess/rq23/rq25#operandDataTypes >>> Is the answer already in there? Do I just need some explanatory text? >>> * Arjohn Kampman <arjohn.kampman@aduna-software.com> [2007-07-18 >>> 14:28+0200] >>>> Dear DAWG, >>>> >>>> It's not completely clear to me what the Effective Boolean Value of >>>> invalid numeric literals should be. I have been unable to find a >>>> decisive answer in the current SPARQL specification. >>>> >>>> The current definition of EBV states: >>>> >>>> "If the argument is a numeric type or a typed literal with a datatype >>>> derived from a numeric type, the EBV is false if the operand value is >>>> NaN or is numerically equal to zero; otherwise the EBV is true." >>>> >>>> With this definition, it's clear that the EBV of "0"^^xsd:integer should >>>> be <false> and the EBV of "12345"^^xsd:int should be <true>. However, it >>>> doesn't exactly cover the case of invalid numeric literals like >>>> "bla"^^xsd:integer. I assume that this would result in a type error, but >>>> with the definition quoted above it could just as well evaluate to >>>> <true>. >>>> >>>> The EBV definition for boolean literals is a little clearer, but it also >>>> leaves room for interpretation. >>>> >>>> I would appreciate it if someone could clarify what the expected >>>> behaviour should be. >>>> >>>> Thanks, >>>> >>>> Arjohn >>>> >>>> -- >>>> Arjohn Kampman, Senior Software Engineer >>>> Aduna - Guided Exploration >>>> www.aduna-software.com >> -- >> Hewlett-Packard Limited >> registered Office: Cain Road, Bracknell, Berks RG12 1HN >> Registered No: 690597 England > -- Arjohn Kampman, Senior Software Engineer Aduna - Guided Exploration www.aduna-software.com
Received on Tuesday, 18 September 2007 18:04:04 UTC