RE: ISSUE-126 (Revisit Datatypes): A proposal for resolution

On Tue, 2008-07-01 at 15:17 +0100, Boris Motik wrote:

> Given these definitions, the value spaces of all these datatypes are
> just numbers, not pairs of the form (number,type). Therefore,
> if we base the datatype system of OWL 2 on XML Schema, we have no
> other choice but to say that the value spaces are overlapping.


> - For xsd:float: The basic value space of double consists of the
> values m x 2^e, where m is an integer whose absolute value is less
> than 2^53, and e is an integer between -1075 and 970, inclusive.

You omitted the following, which complicates your interpretation.

        In addition to the basic ·value space· described above, the
        ·value space· of float also contains the following three special
        values: positive and negative infinity and not-a-number (NaN).

xsd:float and xsd:decimal overlap, but xsd:decimal does not contain all
of xsd:float.


> On the practical side, I can't see how overlapping value spaces would be more difficult to implement than if they were not
> overlapping. In my ISWC paper I've presented an algorithm that deals with this issue, and I really can't see a possible source of
> implementation difficulty. 

It might not be more difficult, and I don't think I've argued that nor
do I think anyone else has.

I have argued that implementations already exist based on the
disjointness of *primitive* datatypes and that such implementations
would be broken.  I have argued that users were given one set of advice
and that reversing that advice has some cost.  Further, re-using
xsd:float and xsd:double, but only with a subset of the values from XML
Schema seems inappropriate.


Finally, there is only one KR use case I've heard motivating the
inclusion of xsd:float and xsd:double, the ability to map data from an
ontology to a corresponding and widely implemented machine
representation.  This change would prevent that translation from being
accurate and would seem to undermine the argument for including the
machine datatypes at all.

-- 
Mike Smith

Clark & Parsia

Received on Tuesday, 1 July 2008 16:46:00 UTC