Re: [XSCH/ALL] straw poll options

Benjamin,

>> Let me clarify the two proposals.
>>
>> 1) Primitive equallity: all XML Schema datatypes have disjoint value spaces.
>>
>> 2) Primitive equality extended with approximate mappings (easlier known as
"leave it to the application"): it is more general than 1). Now all XML Schema
datatypes have disjoint value spaces, plus applications can specify some
approximate mappings, such as mapping "1.3"^^xsd:float to "1.3"^^xsd:double.

>Surely a best practice would be to ask applications **not** to map
xsd:float to xsd:double, but allow xsd:double to xsd:float, or any type
promotion legal wrt XPath, or at least suggest something, such as
returning the fact the result was calculated using an approximate mapping.

In fact, XPath2.0 does promote xsd:float to xsd:double; see

http://www.w3.org/TR/xpath20/#promotion.

Anyway, the 2) approach is to include a general framework for approximate
mappings, so that applications and even standards (such as XPath) can specify
the mappings they prefer and/or recommend. Yes, we should also suggest best
practice too.


>> Note that in this case, the values of "1.3"^^xsd:float and "1.3"^^xsd:double
are different, but the approximate mapping **enables** the use of the XPATH eq
operator, such as in the following SPARQL query:
>
> > SELECT  ?size
> > WHERE   { eg:car eg:engineSizeInLitres ?size .
> >           FILTER (?size = xsd:decimal("1.3") ) . }
>
>> Using 2), "1.3"^^xsd:float and "1.3"^^xsd:double could be  results of the
above query with the >help of approximate mappings.
>
>> Another benefit of 2) is interoperability. Consider the scenario where one
map ontology use xsd:float as the range of milage while the other use
xsd:double. Using 1), milages in all different. While using 2), approximate
mappings allows applications to do some useful things.

>Fully agree with benefits.

:-)

>
>> We have briefly addressed how to formalise the approximate mappings in our
draft, see:
>
>> http://www.w3.org/TR/swbp-xsch-datatypes/#sec-values-eq

>See my previous comments (and Jeremy's comments ) at :

>http://lists.w3.org/Archives/Public/public-swbp-wg/2005Nov/0055.html

The eq operator is not transitive because if the two values are of the same type
(e.g., xsd:decimal), no type promotions are applied. This is fine with the 2)
approach, in which approximate mappings can be used to specify type promotions.


>> Finally, the 2) approach is not non-monotonic. Even if we map"1.3"^^xsd:float
to "1.3"^^xsd:double, their interpretations are still different. It would be
non-monotonic if their interpretations became equal to each other after the
mapping.

>Unsure here, will detail later.

OK.

Jeff

--
Dr. Jeff Z. Pan (http://www.csd.abdn.ac.uk/~jpan/)
Department of Computing Science, The University of Aberdeen

Received on Sunday, 4 December 2005 23:48:59 UTC