Re: Alan Ruttenberg: Re: notes from OWL and RIF datatype coordination meeting

Alan Ruttenberg via Sandro Hawke wrote:

> I would note that there are further issues that will complicate the
> RIF implementation that result from the way the functional calls on
> the numeric operators are defined in the xpath specification.
> 
> 1) http://www.w3.org/TR/xpath20/#mapping
> 
> A numeric operator may be validly applied to an operand of type AT if
> type AT can be converted to any of the four numeric types by a
> combination of type promotion and subtype substitution. If the result
> type of an operator is listed as numeric, it means "the first type in
> the ordered list (xs:integer, xs:decimal, xs:float, xs:double) into
> which all operands can be converted by subtype substitution and type
> promotion." As an example, suppose that the type hatsize is derived
> from xs:integer and the type shoesize is derived from xs:float. Then
> if the + operator is invoked with operands of type hatsize and
> shoesize, it returns a result of type xs:float. Similarly, if + is
> invoked with two operands of type hatsize it returns a result of type
> xs:integer.
> 
> By my read, this sanctions implementations to do any type promotion
> they wish to do in applying numeric operators, for example to coerce
> integer arguments to float arguments before doing computations. 

This does not follow. The type promotion rules are well defined and 
there is no implementation latitude that I can see - [1] defines the 
overloading of add, [2] defines the type promotions that are allowed to 
match the overloaded add signatures, the promotion operation themselves 
are defined in terms of cast and [3] defines that cast algorithm. This 
all adds up to predicable, well specified behaviour.

> Given
> examples such as above this means that if RIF relies on such
> operators, ontologies would be consistent in some implementations and
> inconsistent in others, independent of anything the OWL working group
> can do.

I don't believe this is correct. Is there a specific example which 
illustrates such an implementation dependence of the type promotion/casting?

> 2) http://www.w3.org/TR/xpath-functions/#op.numeric
> 
> For xs:decimal values the number of digits of precision returned by
> the numeric operators is ·implementation-defined·. If the number of
> digits in the result exceeds the number of digits that the
> implementation supports, the result is truncated or rounded in an
> ·implementation-defined· manner.
> 
> This also leads to the possibility of consistency of an ontology
> varying from implementation to implementation, should RIF extend OWL
> by using rule with operators such as addition.

Agreed and already raised by Jos.

However surely OWL already has xsd:decimal and xsd:integer and so 
already has this problem. This problem is not specific to the operators 
but is part of the definition of xsd:decimal. A "minimally conformant" 
implementation [4] is allowed to limit the precision of representation 
of decimals, so even reading in then writing out an OWL ontology which 
exceeds that limit will reveal implementation dependency.

> 3) http://www.w3.org/TR/xpath-functions/#func-numeric-add says:
> 
> op:numeric-add($arg1 as numeric, $arg2 as numeric) as numeric
> 
> Summary: Backs up the "+" operator and returns the arithmetic sum of
> its operands: ($arg1 + $arg2).
> 
> Of course this definition is incorrect. The results of numeric
> addition as applied to floats and decimals may only be an
> approximation of the arithmetic sum. I see no accurate definition of
> numeric-add.

Disagree for decimals. The operation is well defined for conformant, as 
opposed to minimally conformant, implementations of xsd:decimal.

For minimally conformant ones then agreed, the difference between 
truncation and rounding is underspecified. This seems eminently solvable 
to me (for example by requiring RIF conformant implementations to to be 
fully not minimally conformant XSD implementations).

For float/double agreed, but I don't see there is an alternative which 
meets our goal of low implementation barrier. For example, Java differs 
subtlety from IEEE 754 in not supporting all the traps and the 
associated default policy for those traps [*].

> My take on this: RIF justifies the choice of making xs:float and
> xs:decimal disjoint on the basis that this is needed in order for
> implementations of RIF to be based on existing implementation of xpath
> operators. The consequences of this choice for OWL go beyond simply
> making the types disjoint but bring addition constraints on types of
> facet values and additional complexity due to the possibility of
> implementation dependent results for the numeric operators. The
> adoption of xpath operators brings forward a number of issues that seem
> inadequately considered and this choice may turn out to be unworkable,
> in practice, even for RIF.
> 
> In order for OWL to be precisely defined we need to base our
> specification on the mathematical properties of numbers, not the
> properties of implementations.

If one excludes minimally conformant xsd:decimal implementations then 
the xsd:decimal hierarchy is well specified and corresponds to the 
mathematical definition for both RIF and OWL.

The issues only arise with floating point numbers and by definition 
those are about implementation issues and not mathematical abstractions. 
  I would have thought the right approach for OWL would be to eschew 
floating point altogether or to keep them at arms length by having them 
in disjoint value spaces in which case if RIF wants to also define 
operations over them then that's RIF's problem.

Dave

[1] http://www.w3.org/TR/xpath20/#mapping
[2] http://www.w3.org/TR/xpath20/#promotion
[3] http://www.w3.org/TR/xpath-functions/#casting-to-numerics
[4] http://www.w3.org/TR/xmlschema-2/#decimal
[*] This is not an area I've tracked so if Java has resolved the 
differences with IEEE 754 then this example might be false. My limited 
knowledge of these issues comes from skimming articles like: 
http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf :-)

Received on Sunday, 15 February 2009 10:27:38 UTC