Re: EBV of invalid numeric literals

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