Re: EBV of invalid numeric literals

So far, I haven't seen a conclusive answer to my question on the EBV of
malformed datatyped literals such as "aaa"^^xsd:int. Is this issue still
on the working group's radar?


Jeremy Carroll wrote:
> 
> 
> 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
>>
> 


-- 
Arjohn Kampman, Senior Software Engineer
Aduna - Guided Exploration
www.aduna-software.com

Received on Thursday, 30 August 2007 11:28:23 UTC