Re: [XSCH/ALL] straw poll options

----- Original Message -----
From: "Jeremy Carroll" <jjc@hpl.hp.com>
To: "Jeff Z. Pan" <jpan@csd.abdn.ac.uk>
Cc: <Jacco.van.Ossenbruggen@cwi.nl>; <public-swbp-wg@w3.org>
Sent: Wednesday, December 07, 2005 3:23 PM
Subject: Re: [XSCH/ALL] straw poll options


>
> Jeremy:
> >> I haven't understood how (2) differs from (1) then.
>
> Jeff Z. Pan wrote:
> > As we mentioned in our draft [1], 2) supports the eq operator, while
> 1) does
> > **not**. More specifically, 1) is descibed in Section 3.4, while an early
> > version of 2) is described in Section 3.5.
> >
>
> I disagree. Yes 1) is described in 3.4, and 2) derives from 3.5. But no
> 1) supports the eq operator, not natively in the semantics, but in
> SPARQL or XPath eq is a function that takes two operands and returns a
> boolean. The two operands can, for example, be a decimal and a float,
> and an appropriate boolean is returned. Option (1) does not rule out
> such a function,

This is not what we agreed in our draft

http://www.w3.org/TR/swbp-xsch-datatypes/.

At the end of Section 3, we wrote (endorsed by **both** of us):

"EDITORS' OPINION: Our preference is to use XPath eq despite it not being an
equivalence relation (the difference between the two relations can be captured
by the approximation mapping mapsTo). The advantage of this choice is the
compatibility with XPath and SPARQL. We hope that the implementation problems
are resolvable. Jeremy Carroll, Jeff Pan"

This says the advantage of the approach presented in Section 3.5, i.e., 2), is
the compatibility with XPath and SPARQL, while the other aprroaches, including
1) presented in Section 3.4, are not compatible with XPath and SPARQL.

Jeff



>but makes it clear that it is an application decision
> whether to call that function and what to do with its return value,
> rather than it being an inherent part of the meaning of some Semantic
> Web data.
>
>
>
>
>
>
>> Jacco,
>>
>>> Jeff, we discussed this during the teleconf, but were not sufficiently
>>> clear on how your mappings will look like and how an we could guarantee
>>> interoperable behavior (for example in terms of the behavior of the
>>> SPARQL example posted by Jeremy).
>>>
>>> Could you be more precise and give an example of the proposed mappings?
>>
>> An exmaple approaximate mapping can be
>>
>> (*) "1.3"^^xsd:decimal owlx:mapsTo "1.3"^^xsd:float .
>>
>> Given the following data
>>
>> eg:car1 eg:engineSizeInLitres "1.3"^^xsd:decimal .
>> eg:car2 eg:engineSizeInLitres "1.2999999523"^^xsd:float .
>> eg:car2 eg:engineSizeInLitres "1.299999999999999822"^^xsd:decimal .
>>
>> now we consider two SPARQL queries A and B.
>>
>> 1) Query A:
>>  SELECT  ?x ?size
>>  WHERE   { ?x eg:engineSizeInLitres ?size .
>>            FILTER (?size = "1.3"^^xsd:decimal) . }
>>
>> where the "=" operation supports the type promotion/approximate mapping (*).
>
> "=" is currently defined on the XML Schema datatypes where the values
> are explicitly typed values rather than pure numbers. An "=" that has a
> built-in relationship to a user defined mapsTo operation would be a more
> powerful beast, but would be a change to SPARQL and maybe to XPath2 or
> XPath Functions & Operators.
>
>
>>
>> Query result:
>> eg:car1 "1.3"^^xsd:decimal
>> eg:car2 "1.2999999523"^^xsd:float
>>
>> Note that "1.3"^^xsd:decimal can be promoted/mapped to "1.3"^^xsd:float, and
>> that "1.3"^^xsd:float and "1.2999999523"^^xsd:float represent the same value.
>> Note that if we use the "primitive equality" approach,
>>
>> eg:car2 "1.2999999523"^^xsd:float
>>
>> would not in the result because "1.3"^^xsd:decimal and
"1.2999999523"^^xsd:float
>> represent different values.
>>
>
> Incorrect:
> Both triples would be returned in this case too.
> The triple:
> eg:car2 eg:engineSizeInLitres "1.2999999523"^^xsd:float .
>
> matches the pattern:
>
> ?x eg:engineSizeInLitres ?size .
>
> binding ?size to "1.2999999523"^^xsd:float
>
> The filter
> ?size = "1.3"^^xsd:decimal
>
> use the XPath F&0 op:numeric-equals (see Table 11.1 in the SPARQL defn
> http://www.w3.org/TR/2005/WD-rdf-sparql-query-20051123/#FuncAndOp
> )
>
> http://www.w3.org/TR/xpath-functions/#func-numeric-equal
>
> This uses promotion:
> [[
>  If the arguments are of different types, one argument is promoted to
> the type of the other
> ]]
> see para above definition
> and see also
> http://www.w3.org/TR/xpath-functions/#op.numeric
>
> linking to
> http://www.w3.org/TR/xpath20/#promotion
> [[
> A value of type xs:decimal (or any type derived by restriction from
> xs:decimal) can be promoted to either of the types xs:float or xs:double.
> ]]
>
> i.e. the 1.3^^decimal is cast to float, and then the comparison returns
> true.
>
>
>
>
>> 2) Query B:
>>  SELECT  ?x ?size
>>  WHERE   {?x eg:engineSizeInLitres "1.3"^^xsd:float .}
>>
>> Query result:
>> eg:car2 "1.2999999523"^^xsd:float.
>>
>> Note that in this query we only consider equality and no type
>> promotions/approximate mappings are allowed. If we use the "primitive
equality"
>> approach for this query, the result would be the same.
>
> which is why I don't see how the two approaches differ, except that in
> one the user defines a mapsTo relationship that seems unnecessary and
> requires changes in other documents.
>
> Jeremy
>
>
>

Received on Sunday, 11 December 2005 17:44:08 UTC