- From: Michael Kifer <kifer@cs.sunysb.edu>
- Date: Thu, 26 Mar 2009 14:31:27 -0400
- To: Chris Welty <cawelty@gmail.com>
- Cc: RIF WG <public-rif-wg@w3.org>
On Thu, 26 Mar 2009 06:29:24 -0400 Chris Welty <cawelty@gmail.com> 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? I think I am ok with it, but to be sure it would be useful if the proposal were spelled out explicitly, without pointers to other emails. michael > 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? > > 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 18:32:08 UTC