[ALL, XSCH] Proposed WG Note

At the F2F meeting in Galway, both the editors and the WG were divided
as to which of the two proposed versions of the document should be moved
forward.

One party wanted the differences between float, double and decimal to be
reflected in the formal semantics; and application techniques such as
SPARQL be the preferred way to address possible mixed use.

The other party wanted a better formal foundation allowing applications
freedom to determine the appropriate relationships between the datatypes
for their context.

In our discussion, we have agreed that both of these approaches use the
XML Schema derivation tree as their basis, and that, to some extent,
users of datatypes in the Semantic Web need to know that whereas int
derives from integer which derives from decimal which is primitive,
float and double do not, and they are both primitive, and have no
inherent relationship with decimal or with each other.

However, we have also agreed that the semantic foundations for the
SPARQL approach are currently weak, and may remain so, even when SPARQL
reaches recommendation. Hence, we have gone with modified text from the
derive version of the f2f documents:

http://www.w3.org/2001/sw/BestPractices/XSCH/xsch-sw-20051027/derive

The two modification being:

1) adding a paragraph indicating semantic issues with SPARQL at the end
of section 3.5.

2) adding a new section 3.6, sketching how a mapsTo type solution can be
used to define an approximate equality which allows applications to use
a solution with better semantic foundations

The proposed text can be found at
http://www.w3.org/2001/sw/BestPractices/XSCH/xsch-sw/
(the additional text is pasted below for ease of reference)

archived at:

http://www.w3.org/2001/sw/BestPractices/XSCH/xsch-sw-20060127/

The new text of 3.6 does not suffer non-monotonicity problems
because the approximate equality it defines is explicitly not the same
as owl:sameAs.


The editors hence propose publishing:
http://www.w3.org/2001/sw/BestPractices/XSCH/xsch-sw-20060127/
as a WG Note.

Jeremy and Jeff

New text:

=======================

The following  [SPARQL] query will match all three.

SELECT  ?size
WHERE   { eg:car eg:engineSizeInLitres ?size .
           FILTER (?size = 1.3) . }

In the current [SPARQL] working draft, the mapping from the typed 
literal, as a syntactic object, to its corresponding value, is done as 
part of the operation of the = operator in the above query, rather than 
as part of say a D-interpretation from [RDF Semantics]. This mapping is 
specified in [Functions & Operators], and, being strongly typed, is not 
identical with that specified in [RDF Semantics]


3.6 Value Approximate Mapping

A difference approach, better embedded in [RDF Semantics] could enable 
meaningful mappings among values from different datatypes. This could 
give better foundations for operations such as the type promotion of the 
XML Path Language 2.0 [XPath 2.0] and the = operator in SPARQL mentioned 
in Section 3.5. A quick sketch is that we extend the RDF 
D-interpretation to support value approximate maps, as follows:

[Definition:] A value approximate map mapsTo is a partial mapping from 
typed literals to typed literals.
Example 3N

An example value approximate mapping is

"1.3"^^xsd:decimal owlx:mapsTo "1.3"^^xsd:float .

[Definition:] Given a datatype map D and a value approximate map mapsTo, 
the approximate equality aeq is defined as follows:

     * aeq("s1"^^u1, "s2"^^u2)=true if L2S(D(u1))(s1) = L2S(D(u2))(s2) 
or if mapsTo("s1"^^u1)="s3"^^u2 and L2S(D(u2))(s3) = L2S(D(u2))(s2),
     * aeq("s1"^^u1, "s2"^^u2)=false otherwise.

Note that, according to the above definition, aeq("s1"^^u1, 
"s2"^^u2)=true does not imply that "s1"^^u1 and "s2"^^u2 are interpreted 
as the same value (L2S(D(u1))(s1) = L2S(D(u2))(s2)).

To sum up, applications can specify a value approximate map mapsTo and 
make use of the approximate equality aeq for their purposes.


================================

Received on Friday, 27 January 2006 21:40:45 UTC