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

Re: Issue 80: terminology

From: Jos de Bruijn <debruijn@inf.unibz.it>
Date: Thu, 26 Mar 2009 10:59:27 +0100
Message-ID: <49CB51FF.1010400@inf.unibz.it>
To: Dave Reynolds <der@hplb.hpl.hp.com>
CC: RIF WG <public-rif-wg@w3.org>
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:00:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:03 GMT