Re: Issue 80: terminology

> 
> 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.

Not entirely true.  We are concerned with the F&O definition of
dateTime-equals, and this definition relies on a particular algorithm
(section 3.2.7.4 of XSD datatypes 1.0) for calculating "equality".  This
algorithm can be seen as calculating the time on the timeline.

The definition of the value space itself is, unfortunately, ambiguous.
It states that "dateTime values may be viewed as objects with
integer-valued year, month, day, hour and minute properties, a
decimal-valued second property, and a boolean timezoned property".  I
personally interpret this as saying that what they meant to say is what
they said in XML schema 1.1, i.e., date time values are tuples (year,
month, day, hour, minute, second, TimeZone).  But, clearly, one can
interpret this specification in a number of different ways.
But it at least seems clear to me that two datetime values with
different time zones cannot be identical (even if they are
dateTime-equal according to the F&O definition).

> 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

right.

> 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. 

Like I argued, I believe this distinction is there, also in 1.0.

> If we move
> to XML Schema 1.1 (is there a proposal to do this? I assume so) there

Realizing more and more the high degree of ambiguity in the XML schema
1.0 specification, I would strongly supports moving to XML Schema 1.1.

Best, Jos

> 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 Tuesday, 31 March 2009 14:37:24 UTC