- From: Arjohn Kampman <arjohn.kampman@aduna-software.com>
- Date: Thu, 30 Aug 2007 13:27:49 +0200
- To: public-rdf-dawg-comments@w3.org
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