- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Thu, 16 May 2002 15:48:34 -0400
- To: Dan Connolly <connolly@w3.org>, Graham Klyne <Graham.Klyne@mimesweeper.com>
- CC: Jeremy Carroll <jjc@hplb.hpl.hp.com>, RDF Core <w3c-rdfcore-wg@w3.org>
On 2002-05-16 14:51, "ext Dan Connolly" <connolly@w3.org> wrote: > But keep in mind there are at least a few implementations > that we break if we go the other way: > > # how does existing RDF software handle this datatypes test? > http://lists.w3.org/Archives/Public/www-rdf-interest/2002Jan/thread.html#199 > > > Responses indicate RDQL, rdfql, Squish, and Euler think literals > are tidy. The general impression that I got from all the responses to the query tests were that, with rare and limited exceptions, query engines simply weren't doing datatyping at all, insofar as any global range or other typing knowledge is concerned. I.e., in the absence of any actual datatyping mechanisms that would e.g. associate a datatype with the inline idiom, one can do nothing but treat literals as tidy, as there's no further information in the graph by which you could make any comparisons, and since folks generally want to achieve useful comparisons, they resort to string comparison. That doesn't though mean that it is really valid or reliable to presume that the meaning of those literals which are string-equal is actual globally consistent -- and the title="10"/age="10" example bears that out, I think. In addition, it is important to point out that applications which associate datatyping semantics with specific properties (e.g. CC/PP, etc.) all have untidy literals. So I don't find the present treatment afforded to literals by the current RDF query engines to be very strong motivation for adopting tidy literals, but is just an artifact of the lack of any standardized datatyping mechanism that such engines could utilize. Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com
Received on Thursday, 16 May 2002 15:45:04 UTC