Re: [XSCH/ALL] straw poll options

Jeff Z. Pan wrote:
>> jacco:
>> [[
>> I was not happy about the third option in Saterday's straw poll.
>> I felt I was forced to vote on "leave it to the application", while I was
>> under the impression that Jeff's proposal was something along the lines of:
>>
>> "no owl entailment, but provide a well-defined a way that applications
>> can use to 'map' 1.3 floats on 1.3 doubles etc".
>>
>> In my opinion, this approach solves the formal owl problems, the
>> non-monotonic problem and
>> the interoperability problems.
>> ]]
>>
>> While I think that Jeff will need to clarify the proposal, here is my
>> analysis.
> 
> 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.
> 
> 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.
> 
> 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
> 
> 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.
> 
> Jeff


I haven't understood how (2) differs from (1) then.

Whatever we do SPARQL, and other application layer tools, can make of 
any data whatever they like. SPARQL in particular has support for type 
conversion of the sort needed for doing the application level reasoning 
that we agree is needed in some cases.

If we are agreed that the semantics of typed literals is as under (1), 
then it is merely an editorial matter as to how to best present how an 
application may make allowances for float/decimal confusion etc.

If:
   we agree on the core semantics (1)
   we agree that the key use cases for applications to deviate from this 
semantics (at the application level) are addressed by type conversion
   and  we agree that SPARQL has adequate type conversion mechanisms

then
   we should indicate the core semantics
   we should  use SPARQL to illustrate application level deviation from 
the core semantics
   and we should not discuss some other mechanism that has no standards 
support

If we can identify limitations with using SPARQL, then documenting those 
may be appropriate; and note that there is no standard way to overcome 
those limitations at present.

Jeremy

Received on Wednesday, 30 November 2005 12:00:36 UTC