W3C home > Mailing lists > Public > public-owl-wg@w3.org > July 2008

Re: A possible structure of the datatype system for OWL 2 (related to ISSUE-126)

From: Michael Smith <msmith@clarkparsia.com>
Date: Thu, 10 Jul 2008 12:53:32 -0400
To: Rob Shearer <rob.shearer@comlab.ox.ac.uk>
Cc: public-owl-wg@w3.org
Message-Id: <1215708812.27672.16.camel@msmith-laptop-wired.int.clarkparsia.com>

On Thu, 2008-07-10 at 15:31 +0100, Rob Shearer wrote:

> Two notes on this:
> 
> 1. You obviously need ambiguous values for this problem to arise, and  
> the IEEE spec only allows ambiguity for pretty wacky numbers. Anything  
> representable (not just represented, but representable) in decimal as  
> ±M × 10^{±N} for M < 10^9 and N < 14 is unambiguous (M < 10^17 and N <  
> 28 for double-precision), so users need to type a lot of digits before  
> they start experiencing the problem.

This information is very helpful.  The magnitude of the exponent here
makes me much more comfortable living with this problem.


> 2. A single ambiguous value does not in itself produce a problem.  
> Problems only arise in ontologies which use one ambiguous value, as  
> well as other values within the range of IEEE-754-legal  
> interpretations of that value. Given that the IEEE-754-legal range is  
> quite small (a limited error is allowed only in the least significant  
> digit of the destination type, which I read as the last bit of the  
> float), this issue is unlikely to arise very often.
> 
> I agree that this situation kind of sucks, but I don't see any viable  
> alternatives. The non-viable ones I can come up with are:
> 
> 1. Disallow floating-point numbers entirely. This seems like a non- 
> starter---the vast vast majority of scientific data makes use of such  
> numbers.
> 2. Only allow unambiguous floating-point representations. This seems a  
> clear violation of the XSchema semantics. What is more, the  
> implementation burden seems high; libraries usually don't have this  
> functionality. I wouldn't know how to implement this, and I strongly  
> suspect many implementors would either not implement it at all or get  
> it wrong.
> 3. Impose explicit rounding rules above and beyond IEEE-754. This  
> would break every floating point implementation in existence. I would  
> encourage Oxford to object to such a model, and I can't imagine such a  
> proposal passing a vote of the AC.

Would mandating the rounding algorithm remove the ambiguity?

> Other suggestions?

If we can define, as you have above, the circumstances in which problems
become visible, those circumstances should be documented in some user
facing document.

-- 
Mike Smith

Clark & Parsia
Received on Thursday, 10 July 2008 16:54:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:05 UTC