Re: notes from OWL and RIF datatype coordination meeting

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

1) Entailments that involve counting the number of distinct
literals. For example, consider a test for whether
OneOf("1.0"^^xsd:float, "1"^^xsd:integer) is equivalent to
OneOf("1"^^xsd:integer).

In the case that decimals and floats are disjoint these classes are
not equivalent. In the currently propose OWL 2 semantics these are
equivalent.

2) Suppose we have Domain(hasMeasurementInCentimeters xsd:float. In
the current OWL 2 semantics,
PropertyAssertion(hasMeasurementInCentimeters a:foot1 "26"^^xsd:integer)
is consistent. If decimals and floats are disjoint then this is inconsistent.

3) Facets. consider xsd:minInclusive.

DatatypeRestriction(xsd:float xsd:maxInclusive "1.00000001"^^xsd:decimal)
PropertyRange(a:fprop DatatypeRestriction(xsd:float xsd:minInclusive
"1.00000001"^^xsd:decimal))

a) PropertyAssertion(a:fprop a:h "1.0"^^xsd:decimal)
b) PropertyAssertion(a:fprop a:h "1.0"^^xsd:float)

In OWL both (a) and (b) are inconsistent.

However, RIF would need to use op:numeric-greater-than and
op:numeric-equal to detect this case.

The problem arises because the numeric operators behave differently
depending on their type.  According to http://www.w3.org/TR/xpath20/#mapping,
in case (a) the facet value and the property value would be compared
as xsd:decimal
and (a) would be determined to be inconsistent, in concordance with OWL 2.

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)

But in this case op:numeric-equal("1.0"^^xsd:float,"1.0"^^xsd:float) would yield
true, and (b) would be consistent, yielding a different result from OWL 2.

The incompatibility of the conclusions here is the first problem for OWL/RIF.

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.

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 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. 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.

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.

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.

The same applies to the other numeric operators.

---

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.

Received on Saturday, 14 February 2009 18:33:48 UTC