W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > October 2002

Re: details of rdf:datatype?

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Wed, 16 Oct 2002 08:35:23 +0300
Message-ID: <004d01c274d5$d30bb0d0$544516ac@NOE.Nokia.com>
To: "Graham Klyne <Graham.Klyne" <Graham.Klyne@MIMEsweeper.com>, "ext Jos De_Roo" <jos.deroo.jd@belgium.agfa.com>
Cc: "Dan Connolly" <connolly@w3.org>, <w3c-rdfcore-wg@w3.org>, <w3c-rdfcore-wg-request@w3.org>

[Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com]

----- Original Message -----
From: "ext Jos De_Roo" <jos.deroo.jd@belgium.agfa.com>
To: "Graham Klyne <Graham.Klyne" <Graham.Klyne@MIMEsweeper.com>
Cc: "Dan Connolly" <connolly@w3.org>; "Patrick Stickler" <patrick.stickler@nokia.com>; <w3c-rdfcore-wg@w3.org>;
Sent: 15 October, 2002 18:49
Subject: Re: details of rdf:datatype?

> >> > My take is that only the first case is RDF-entailed:  if the datatype
> and
> >> > text are the same for two literals then they must denote the same
> value.
> >>
> >>But they are not the same datatype. They are different URIs, and RDF
> >>cannot know that there is any intersection of the value spaces of
> >>xsd:integer and xsd:decimal. Thus the first case is not RDF-entailed.
> >
> >Oops, I missed that.  Yes, if the datatype URIs are different then IMHO
> >(alone) cannot infer an equivalence.
> not with following (as part of rdfs)
> xsd:decimal a rdfs:Class .
> xsd:integer rdfs:subClassOf xsd:decimal .
> xsd:nonPositiveInteger rdfs:subClassOf xsd:integer .
> xsd:long rdfs:subClassOf xsd:integer .
> xsd:nonNegativeInteger rdfs:subClassOf xsd:integer .
> xsd:negativeInteger rdfs:subClassOf xsd:nonPositiveInteger .
> xsd:int rdfs:subClassOf xsd:long .
> xsd:unsignedLong rdfs:subClassOf xsd:nonNegativeInteger .
> xsd:positiveInteger rdfs:subClassOf xsd:nonNegativeInteger .
> xsd:short rdfs:subClassOf xsd:int .
> xsd:unsignedInt rdfs:subClassOf xsd:unsignedLong .
> xsd:byte rdfs:subClassOf xsd:short .
> xsd:unsignedShort rdfs:subClassOf xsd:unsignedInt .
> xsd:unsignedByte rdfs:subClassOf xsd:unsignedShort .
> -- ,
> Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/

Subclass relations are not sufficient to determine equality
of values. The class extension of a datatype is its value
space. And if one datatype is a subclass of another, all that
means is that its value space is a subset of the superordinate
datatype's value space. Thus, an integer *value* is always
a decimal value, etc.

However, (and this is what seems to be missed here), there is
no requirement that a subordinate datatype's lexical space be
a subset of the superordinate datatype's lexical space or that
the lexical to value mapping of the subordinate datatype be
compatable with that of the superordinate datatype. How each
datatype serializes its values and the mappings from lexical
forms to values is entirely the domain of the datatype alone,
disjunct from any subclass relations with any other datatypes.

This is what allows us to, e.g. say that a Schema integer is
a subclass of XSD Integer and visa versa, as they have perfectly
intersecting value spaces, yet have incompatable lexical spaces.
It is a critical feature of the extensible nature of RDF datatyping
which allows us to relate datatypes by their value spaces
irrespective of their lexical representations, which is the key
to interoperability between disparate datatype frameworks.

So, just because xsd:integer is a subclass of xsd:decimal, and
the lexical form is the same for both typed literals, that does
not mean that both typed literals (absolutely) map to the same
value. They might (and in this case they do) but they might
not, and RDF does not know this, even with the above subClassOf

E.g., one could just as well have:

   foo:binaryInteger rdfs:subClassOf xsd:integer .
   Jenny age xsd:integer"10" .
   Bob age foo:binaryInteger"10" .

where in actuality, even though the lexical forms are identical
and foo:binaryInteger is a subclass of xsd:integer, Jenny's
and Bob's ages are in fact not the same.

Received on Wednesday, 16 October 2002 01:35:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:16 UTC