Re: Re: EBV of invalid numeric literals

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

-- 
-eric

office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
mobile: +1.617.599.3509

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.