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

Re: XML Schema Datatypes in RDF and OWL

From: Dave Reynolds <der@hplb.hpl.hp.com>
Date: Mon, 18 Jul 2005 10:29:16 +0100
Message-ID: <42DB766C.7000407@hplb.hpl.hp.com>
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

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