- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Tue, 29 Mar 2011 05:17:00 -0400
- To: Jeen Broekstra <jeen.broekstra@gmail.com>
- Cc: Andy Seaborne <andy.seaborne@epimorphics.com>, public-rdf-dawg-comments@w3.org
* Jeen Broekstra <jeen.broekstra@gmail.com> [2011-03-29 10:13+1300] > On 27/03/2011 11:57, Eric Prud'hommeaux wrote: > >* Jeen Broekstra<jeen.broekstra@gmail.com> [2011-03-27 10:59+1300] > > [snip] > > >>Now, we apply RDFterm-equal to our comparison. Both operands are > >>literals. The definition says that two literals are RDF-term-equal > >>if they are "equivalent literals" according to def 6.5.1 in RDF > >>concepts. Since our operands have different lexical values as well > >>as different datatypes, literal equality fails. The definition of > >>RDFterm-equal then says: "[it] produces a type error when both > >>operands are literal but are not the same RDF term". Since in our > >>case both are literal but are not the same term, it results in a > >>type error. So RDFterm-equal results in a type error, and since > >>applying fn:not on a type error results in a type error, > >>"foo"^^xsd:string != "4"^^xsd:integer evaluates to a type error. > >>This is what I originally thought happened, and what I thought was > >>undesirable. > > > >Ahh, this is what I believe to have been the design goal. The problem > >is exemplified by > > "iiii"^^my:romanNumeral = "iv"^^my:romanNumeral > > Yes, quite, and I agree that this really the only way to handle > non-native datatypes. It's the fact that it also works this way for > native datatypes that annoys me. It leads to different SPARQL > implementations giving different results for very basic comparisons. > > >The answer there is probably a non-controversial "beats me". The > >answer to "foo"^^xsd:string != "4"^^xsd:integer in unextended > >implementations is also "beats me", but that doesn't keep you from > >adding operators for e.g. xsd:string and xsd:integer for which the > >answer to "=" is false. (You probably want a switch to enable you > >to run the unextended tests, which have no way of distinnguishing > >between sagely extension and wanton impudance.) > > True. In fact I have already implemented this in Sesame this way > (except for the switch bit). I am just of the opinion that it is > unwise to leave this decision up to indivual implementations, at > least for the native datatypes. > > I would be much happier if the datatypes that SPARQL claims to > support (that is, the ones mentioned in "Operand Data types") are > indeed fully supported, i.e. it is fixed in the spec that string and > int (and the other supported types) are pairwise distinct. > > >We could take the bold step of declaring the 19 native types pairwise > >distinct by either adding a bazillion rows to the operator mapping > > Surely it doesn't need that many? The numeric types are already > grouped under the nomer "numeric" (you could do the same for > dateTime, date, etc, by the way, e.g. "calendar"). I'd say this > would be enough: Per parenthetical proposal for "calendar" group, interesting tactic, but I think not yet necessary. SPARQL still appears to support only xsd:dateTime (apart from dayTimeDuration, which should never equal a dateTime). > Op type(A) type(B) maps to > ----------------------------------------------- > A != B string numeric TRUE > A != B string boolean TRUE > A != B string calendar TRUE > A != B numeric calendar TRUE > A != B numeric boolean TRUE > A != B calendar boolean TRUE > > Somewhat clunky, perhaps, but still managable I'd say. It is indeed; I hadn't bothered evaluating "bazillion". This could be tedious to evolve as SPARQL adopts more of the 17 xsd datatypes. > >or > >expanding the definition of RDFterm-equal like so: > >[[ > > Returns TRUE if term1 and term2 are the same RDF term as defined in > > Resource Description Framework (RDF): Concepts and Abstract Syntax > > [CONCEPTS]; > >+ returns FALSE if the arguments are different types but both are > >+ listed in ยง17.1 Operand Data Types; > > This is not quite enough as it does not check that the operands are > _valid_ typed literals. You'd still want "xyz"^^xsd:integer != > "foo"^^xsd:string to raise a type error, I think. * Jeen Broekstra <jeen.broekstra@gmail.com> [2011-03-29 11:09+1300] > On 29/03/2011 10:13, Jeen Broekstra wrote: > > [snip] > > >This is not quite enough as it does not check that the operands are > >_valid_ typed literals. You'd still want "xyz"^^xsd:integer != > >"foo"^^xsd:string to raise a type error, I think. > > Minor addendum: it took me five seconds after hitting 'send' (I really > hate it when that happens) to realize that this of course _also_ holds > for the operator mapping table. Simply mapping != to 'true' will not > quite be enough, it still needs the proviso that both operands have a > correct lexical-to-value mapping. > You could add that condition too I guess, but it all gets a bit > convoluted - perhaps adding some rows to the mapping table is easier > here? > > Cheers, > > Jeen -- -ericP
Received on Tuesday, 29 March 2011 09:17:36 UTC