- From: Pat Hayes <phayes@ihmc.us>
- Date: Mon, 6 Aug 2007 13:45:06 -0500
- To: Eric Prud'hommeaux <eric@w3.org>
- Cc: public-rdf-dawg-comments@w3.org
>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