W3C home > Mailing lists > Public > public-swbp-wg@w3.org > October 2005

Re: XML Schema Datatypes in RDF and OWL

From: Jeff Z. Pan <jpan@csd.abdn.ac.uk>
Date: Mon, 17 Oct 2005 17:53:08 +0100
Message-ID: <00c301c5d33b$439c5fe0$d3d7858b@Newton>
To: "Dave Reynolds" <der@hplb.hpl.hp.com>, <public-swbp-wg@w3.org>
Cc: "Jeremy Carroll" <jjc@hplb.hpl.hp.com>

Hi Dave,

Many thanks for the comments. I understand that, for both points, it is not easy decision at all. As for the "pointer of user defined datatypes", although the DAML+OIL solution is a non-standard approach, it is an easier (if not the easiest) approach. Regarding the "comparison of values", I appreciate that the "eq" approach could cause performance. However, I think the implementation problems might be resolvable. For example, implementations can customise the mapsTo relations and only support the needed approximation mappings.

Kind regards,

Dr. Jeff Z. Pan (http://www.csd.abdn.ac.uk/~jpan/)
Department of Computing Science, The University of Aberdeen

----- Original Message ----- 
From: "Dave Reynolds" <der@hplb.hpl.hp.com>
To: <public-swbp-wg@w3.org>
Sent: Monday, July 18, 2005 10:29 AM
Subject: Re: XML Schema Datatypes in RDF and OWL

> 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, 17 October 2005 16:57:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:31:13 UTC