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, 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 Wednesday, 7 December 2005 15:27:06 UTC