Re: EBV of invalid numeric literals

>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 .

Well, the RDF MT says that it denotes something not in the class 
rdfs:Literal. That is, whatever it is, it isn't in the value space of 
any typed literal, so in particular this:

"bla"^^xsd:integer rdf:type xsd:integer .

is FALSE (or rather, it would be if it were legal RDF)

Similarly for any "ill-typed" typed literal.

Not sure if this helps with your problem here, though.

Pat

>
>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
>
>--
>-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.
>
>Content-Type: application/pgp-signature; name="signature.asc"
>Content-Description: Digital signature
>Content-Disposition: inline
>
>Attachment converted: betelguese2:signature 141.asc (    /    ) (0019C773)


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Monday, 6 August 2007 18:45:13 UTC