- From: Dave Reynolds <der@hplb.hpl.hp.com>
- Date: Mon, 18 Jul 2005 10:29:16 +0100
- To: public-swbp-wg@w3.org
On behalf of the HP Jena team we would like to comment on working draft 27/4/05 of this document. This document is very useful and we thank the Editors for laying out the options so clearly and comprehensively. 1. User defined datatypes Jena currently implements the DAML+OIL solution. We accept the argument in the WD that fragment identification is a syntactic reference in the sense of XPointer and thus that the Editor's opinion is the best route forward. Should this be the consensus opinion then we will consider migrating Jena to support it in the future but will maintain backward compatibility with existing DAML+OIL style usages where possible. 2. Comparison of values Jena currently implements option "Primitive". We regard this as the appropriate solution and, unlike the Editors, regard the "eq" alternative as the least satisfactory of the three. The theoretical problems of "eq" (it not being an equivalence relation due to context sensitive rounding) spill over into practical difficulties. We support the ability to retrieve semantically equivalent literal values in searches. If "eq" were used to define semantic equality then there would be significant performance implications since it would no longer to be possible to index a canonical form of the literal value. The least impractical solution would require storage of multiple pre-rounded forms for retrieval. Our opinion is that the space and complexity cost implications for implementers are too high. We don't regard the availability of the "eq" operator in SPARQL as a compelling argument. On the contrary it means that users who wish to compare across XSD type branches can do so using the *explicit* eq operator in SPARQL. Dave Reynolds, on behalf of the HP Jena team
Received on Monday, 18 July 2005 09:46:22 UTC