Re: EBV of invalid numeric literals

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

Received on Tuesday, 7 August 2007 09:28:30 UTC