Re: Review of XSD Datatypes 1.1 Changes

On Wed, Feb 8, 2012 at 8:43 AM, Sandro Hawke <sandro@w3.org> wrote:

> On Fri, 2012-02-03 at 23:49 -0800, Pat Hayes wrote:
> > On Feb 3, 2012, at 2:27 PM, Alex Hall wrote:
> >
> > > On Fri, Feb 3, 2012 at 3:49 PM, Pat Hayes <phayes@ihmc.us> wrote:
> > >
> > > On Feb 2, 2012, at 2:08 PM, Alex Hall wrote:
> > >
> > > > Per ACTION-136 - Review changes in W3C XML Schema Definition
> Language (XSD) --
> http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/#changes
> > > >
> > > > I've completed my review of the changes in XSD Datatypes 1.1. Rather
> than go through the exhaustive list of changes, I'll summarize the areas
> that I think are relevant to RDF:
> > > >
> > > > 1. Datatype definitions, including definitions of lexical spaces,
> value spaces, L2V mappings, and canonical mappings, underwent a thorough
> revision. This is a good thing, because the new definitions are much more
> precisely stated and leave less room for confusion. In general, RDF defers
> to XSD for datatype definitions so I don't think any action on our part is
> required here in terms of the RDF specs. However, implementors of XSD
> datatype processing in RDF will want to review these changes so we might
> want to call their attention to them. I did verify that the short-form
> literal definitions in Turtle for boolean, double, decimal, and integer are
> still valid subsets of the respective lexical spaces in XSD 1.1.
> > > >
> > > > 2. XSD 1.1 distinguishes between the identity of values and the
> (numeric) equality of values.
> >
> > ....
> >
> > > > To avoid confusion, it might be worth noting this distinction in the
> section on datatype entailment and explicitly stating that datatype
> entailment deals with identity and not equality, if that is indeed our
> position. [For SPARQL, pattern matching deals with identity and the '='
> operator deals with equality.
> > >
> > > Is that a previous decision, or do you just presume that it must work
> this way?
> > >
> > > This is based on RDF Semantics section 1.4 (
> http://www.w3.org/TR/rdf-mt/#gddenot):
> > >
> > > "In this table, and throughout this document, the equality sign =
> indicates identity"
> >
> > Sigh. That however was written using English as it was before XSD got to
> it, in the good old days when "identity" and "equality" were, um,
> identical. So while indeed it does mean to refer to identity, it did not
> mean to contrast this with equality. It uses the sign "=" to refer to
> identity, for example.
> >
> > So, after a brief period of mental anguish, I am inclined to say that
> our best response to this is to insert some explanatory prose into the
> semantics document which emphasises that RDF semantics recognizes, and is
> based upon, the notion of logical identity, and when XSD defines an
> 'equality' which differs from identity, that is not what we are talking
> about.
>
> I don't claim to understand all this, and that's probably okay.  The way
> I make sense of XSD, when I have to, is to translate what they are
> saying into programmer-speak (not math-speak).  The value spaces sound
> mathematical, but integer 3 and floating point 3 are not identical
> because (not surprisingly) they are implemented in all practical systems
> using different bit patterns.


Agreed. From a programming perspective, I can think of lots of parallel
examples that illustrate the distinction between identity and equality. The
most immediate one for me is Java's Object.equals() relation, which by
default evaluates as true if and only if the object being compared is the
same object as this one (so it's the identity relation). But it's common to
override this to evaluate as true if the object being compared represents
the same "value" (scare-quotes here because Java has no well-defined notion
of value for objects), i.e. the other object is of the same type and has
the same properties as this one.

The difficulty, of course, is that this example involves the comparison of
physical data structures in memory, not abstract mathematical values. Since
RDF Semantics deals with abstract mathematical values, I've attempted to
limit my discussion to that.


> I wish the XSD spec would stick to
> programmer-speak, but I guess that's seen as too constraining on
> implementations.
>

Yeah, they're very careful about this. Sometimes they venture more into
programmer-speak and give a reference implementation for a function, and
then say "any implementation is allowed as long as its visible results are
isomorphic with this one's."

-Alex



>
>  -- Sandro
>
> > Pat
> >
> >
> > ------------------------------------------------------------
> > IHMC                                     (850)434 8903 or (650)494 3973
> > 40 South Alcaniz St.           (850)202 4416   office
> > Pensacola                            (850)202 4440   fax
> > FL 32502                              (850)291 0667   mobile
> > phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
> >
> >
> >
> >
> >
> >
> >
>
>
>