- From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
- Date: Sat, 14 Feb 2009 16:39:20 -0500 (EST)
- To: alanruttenberg@gmail.com
- Cc: public-rif-wg@w3.org, public-owl-wg@w3.org
From: Alan Ruttenberg <alanruttenberg@gmail.com> Subject: Re: notes from OWL and RIF datatype coordination meeting Date: Sat, 14 Feb 2009 13:33:07 -0500 > On Mon, Feb 9, 2009 at 10:33 AM, Sandro Hawke <sandro@w3.org> wrote: > >> This was an informal meeting, to advance understanding of the issues, >> with no decisions, etc. So, these are more "notes" than "minutes". >> >> My sense of the outcomes: >> - Alan and Jos will talk more to get details on some real problems >> users will face if OWL follows the non-disjoint path > > I spoke to Jos de Bruijn about datatypes, as we discussed last > monday. Here is a summary of the potentially visible consequences of > differing semantics for datatypes. These differences stem from two > sources: 1) The choice of whether the float types are considered > disjoint from the decimals and descendants and 2) The consequences of > RIF relying on existing implementations of the xpath numeric > operators in the implementation of RIF. > > First, the situations where differences between OWL and RIF can show up [...] > in case (b) the facet value "1.00000001"^^xsd:decimal would first be > type promoted to float, > as http://www.w3.org/TR/xpath20/#promotion describes, so it becomes > "1.0"^^xsd:float > (because float loses precision in this case) [Aside: This is one of the great problems with the treatment of numbers in XPath. Why in the world is there a promotion from decimal to float / double, when decimal almost entirely encompasses float / double but not vice versa. I simply do not understand this design choice.] > The incompatibility of the conclusions here is the first problem for OWL/RIF. Well, it does point out a difference between the way that OWL works and the way that RIF works. Whether this is a problem or not, and for whom, is an entirely different matter. > The second problem is that RIF can't even make the determination of > which case to apply given the OWL 2 semantics as the interpretation > "loses" the type information. At the interpretation level, one doesn't > know whether 1.0 is float or decimal, and so the correct > op-numeric-equal can't be chosen. Perhaps, and only perhaps, this is a problem for RIF. A simple solution would be just to perform operations in the owl:realPlus space. > Because of this, the conclusion is that in order to be compatible with > RIF this case must not be allowed to arise, and so one would need to > only use float facet values where float values are to be compared, and > decimal facet values where decimals could be compared. I think that you should have said instead something like: The conclusion is that RIF does not correctly handle a pure numeric interpretation of numbers, instead being tied to an interpretation where a number data value consists of both a pure numeric value plus a tag indicating either integer, decimal, float, or double. (I'm not sure whether integer is strictly needed here.) [...] RIF could, if it wanted to, become compatible with the OWL semantics, while still using the XPath operators. All that it needs to do is to perform the appropriate coercions beforehand, mostly to decimal. Some coercions would need to have run-time tests applied, to check for the unusual values in float and double. [...] peter
Received on Saturday, 14 February 2009 21:39:40 UTC