From: Alan Ruttenberg <alanruttenberg@gmail.com>

Date: Sat, 14 Feb 2009 13:33:07 -0500

Message-ID: <29af5e2d0902141033v1f4a4ce2x68258460a84396f1@mail.gmail.com>

To: public-rif-wg@w3.org, public-owl-wg@w3.org

Date: Sat, 14 Feb 2009 13:33:07 -0500

Message-ID: <29af5e2d0902141033v1f4a4ce2x68258460a84396f1@mail.gmail.com>

To: public-rif-wg@w3.org, public-owl-wg@w3.org

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

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