- From: Jeff Z. Pan <jpan@csd.abdn.ac.uk>
- Date: Mon, 05 Dec 2005 00:15:07 +0000
- To: jjc@hpl.hp.com
- Cc: public-swbp-wg@w3.org, Jacco.van.Ossenbruggen@cwi.nl
Jeremy, > I haven't understood how (2) differs from (1) then. As we mentioned in our draft [1], 2) supports the eq operator, while 1) does **not**. More specifically, 1) is descibed in Section 3.4, while an early version of 2) is described in Section 3.5. Jeff [1] http://www.w3.org/TR/swbp-xsch-datatypes/ -- Dr. Jeff Z. Pan (http://www.csd.abdn.ac.uk/~jpan/) Department of Computing Science, The University of Aberdeen > Whatever we do SPARQL, and other application layer tools, can make of > any data whatever they like. SPARQL in particular has support for type > conversion of the sort needed for doing the application level reasoning > that we agree is needed in some cases. > > If we are agreed that the semantics of typed literals is as under (1), > then it is merely an editorial matter as to how to best present how an > application may make allowances for float/decimal confusion etc. > > If: > we agree on the core semantics (1) > we agree that the key use cases for applications to deviate from this > semantics (at the application level) are addressed by type conversion > and we agree that SPARQL has adequate type conversion mechanisms > > then > we should indicate the core semantics > we should use SPARQL to illustrate application level deviation from > the core semantics > and we should not discuss some other mechanism that has no standards > support > > If we can identify limitations with using SPARQL, then documenting those > may be appropriate; and note that there is no standard way to overcome > those limitations at present. > > Jeremy > > > >
Received on Monday, 5 December 2005 00:30:30 UTC