Re: XML Schema Datatypes in RDF and OWL

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,
Jeff

--
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