W3C home > Mailing lists > Public > public-rif-wg@w3.org > March 2009

Re: Issue 80: terminology

From: Dave Reynolds <der@hplb.hpl.hp.com>
Date: Thu, 26 Mar 2009 10:47:21 +0000
Message-ID: <49CB5D39.6030809@hplb.hpl.hp.com>
To: Chris Welty <cawelty@gmail.com>
CC: Jos de Bruijn <debruijn@inf.unibz.it>, RIF WG <public-rif-wg@w3.org>
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.
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)


> 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
Received on Thursday, 26 March 2009 10:48:18 UTC

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