From: Jos de Bruijn <debruijn@inf.unibz.it>

Date: Thu, 26 Mar 2009 12:08:58 +0100

Message-ID: <49CB624A.8060909@inf.unibz.it>

To: Dave Reynolds <der@hplb.hpl.hp.com>

CC: Chris Welty <cawelty@gmail.com>, RIF WG <public-rif-wg@w3.org>

Date: Thu, 26 Mar 2009 12:08:58 +0100

Message-ID: <49CB624A.8060909@inf.unibz.it>

To: Dave Reynolds <der@hplb.hpl.hp.com>

CC: Chris Welty <cawelty@gmail.com>, RIF WG <public-rif-wg@w3.org>

Dave Reynolds wrote: > Chris Welty wrote: >> >> Great- let's try to resolve this at the upcoming Telecon. Would anyone >> object to a resolution to add literal-not-identical to dtb? > > OK by me. It is already in there already so the resolution is retain it > but rename it (and remove literal-equal). > >> One point of ambiguity remains I think: is lni(?x,?y) true if ?x and?y >> are both literals but of different types, or do ?x and ?y have to be >> of the same type (but different values) for the pred to be true? > > lni(?x, ?y) should be true if ?x and ?y are literals and map to > different value spaces. That's the way DTB is currently written. Agreed. Jos > Some types are in a subtype hierarchy and share a value space and lni > should respect this. Thus: > > lni("1"^^xsd:int, "1"^^xsd:integer) false (same value space, same value) > lni("1"^^xsd:int, "2"^^xsd:integer) true (same value space, diff value) > lni("1"^^xsd:int, "1.0"^^xsd:float) true (different value spaces) > lni("1"^^xsd:int, "2.0"^^xsd:float) true (different value spaces) > > Dave > >> Truth table for Lni(?x,?y): >> ?x and?y are literals of the same type and the same value in the value >> space: FALSE >> ?x and ?Y are literals of the same type and different values in the >> vspace: TRUE >> ?x and ?y are literals of different types: >> ?x or ?y is a non-literal: FALSE >> >> >> -Chris (sent from my iPhone) >> >> On Mar 26, 2009, at 5:59 AM, Jos de Bruijn <debruijn@inf.unibz.it> wrote: >> >>> I guess many people do feel having literal-non-identity is important in >>> RIF. So, let's go for option (1) from [4], i.e., we have >>> literal-non-identity and we have the individual (in)equality operators >>> based on the XPath operators. >>> >>> >>> Jos >>> >>> Dave Reynolds wrote: >>>> We had a useful but not fully conclusive discussion on this at the last >>>> telecon and tried to clarify our terminology. I felt afterwards we >>>> didn't quite have it right so here's an attempt to articulate that. >>>> >>>> There are actually three notions of "equality" buried in here. >>>> >>>> (1) Identity. Two literals are identical if they correspond to the same >>>> value in the value space. >>>> >>>> (2) Equality. XSD defines algorithms for equality which mean that two >>>> non-identical points in a given value space can be equal. However, for >>>> XSD this equality is restricted to be within a datatype[1] and so >>>> doesn't include the "1"^^xsd:int = "1.0"^^xsd:float case. >>>> >>>> (3) Equivalence[3]. XPath F&0 defines equality operators (a different >>>> notion from the mathematical equality functions which characterize the >>>> XSD value spaces). These can span multiple datatypes, specifically >>>> numeric-equal does. This is the one that does type promotion and >>>> permits "1"^^xsd:int = "1.0"^^xsd:float. >>>> >>>> >>>> Now, in XML Schema 1.0, which is the version we current reference in >>>> DTB, equality and identity are the same[2]. So the issues we were >>>> worrying about in the telecon don't apply. >>>> >>>> In XML Schema 1.1 some datatypes have a non-identity equality. >>>> Specifically xsd:dateTime and float/double. Though with float/double >>>> the >>>> exceptions (-0 = +0, Nan != NaN) are perhaps not so interesting. >>>> >>>> For OWL then they define xsd:dateTimeStamp to have a value space >>>> corresponding to a timeline instead of following the XML Schema 1.1 >>>> structural model and so for OWL's definition identity and equality >>>> coincide again. >>>> >>>> So my contention is that the way literal-not-equal is defined in DTB at >>>> present (non-identity) corresponds to the equality notion in OWL for >>>> all >>>> the relevant datatypes and I keep my preference for options 2 or 1 [4]. >>>> >>>> This contention is trivially true if we stick to XML Schema 1.0 because >>>> there is no distinction between equality and identity there. If we move >>>> to XML Schema 1.1 (is there a proposal to do this? I assume so) there >>>> are differences but the main problematic datatype is not included in >>>> OWL[5]. >>>> >>>> Dave >>>> >>>> [1] http://www.w3.org/TR/xmlschema11-2/#value-space >>>> "For purposes of this specification, the value spaces of primitive >>>> datatypes are disjoint, even in cases where the abstractions they >>>> represent might be thought of as having values in common." >>>> >>>> [2] http://www.w3.org/TR/xmlschema11-2/#value-space >>>> "Note: In the prior version of this specification (1.0), equality was >>>> always identity. This has been changed to permit the datatypes defined >>>> herein to more closely match the "real world" datatypes for which they >>>> are intended to be used as transmission formats." >>>> >>>> [3] I don't know what a good name for this is so I'm using >>>> "equivalence" >>>> for now. You could call it "programmatic equality" or "pragmatic >>>> equality" or something. >>>> >>>> [4] http://lists.w3.org/Archives/Public/public-rif-wg/2009Mar/0076.html >>>> >>>> [5] OK, that does leave the corner cases of float/double (-0 = +0, Nan >>>> != NaN) I haven't checked how OWL handle these. If those are the only >>>> differences then I personally don't care either way. >>> >>> -- >>> +43 1 58801 18470 debruijn@inf.unibz.it >>> >>> Jos de Bruijn, http://www.debruijn.net/ >>> ---------------------------------------------- >>> Many would be cowards if they had courage >>> enough. >>> - Thomas Fuller >>> > > -- +43 1 58801 18470 debruijn@inf.unibz.it Jos de Bruijn, http://www.debruijn.net/ ---------------------------------------------- Many would be cowards if they had courage enough. - Thomas FullerReceived on Thursday, 26 March 2009 11:10:00 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:47:55 UTC
*