RE: Cutting the Patrician datatype knot

From: Peter F. Patel-Schneider (
Date: 11/28/01

Subject: RE: Cutting the Patrician datatype knot
Date: Wed, 28 Nov 2001 18:18:21 +0200

> > -----Original Message-----
> > From: ext Peter F. Patel-Schneider 
> > []
> > Sent: 24 November, 2001 09:16
> > To: Stickler Patrick (NRC/Tampere)
> > Subject: RE: Cutting the Patrician datatype knot
> > 
> > 
> > From:
> > Subject: RE: Cutting the Patrician datatype knot
> > Date: Fri, 23 Nov 2001 20:57:49 +0200
> > 
> > [...]
> > > 
> > > If the data type does not define a lexical space, then
> > > no mechanism is going to work. Either there's a defined
> > > mapping from lexical form to value or there isn't. It
> > > is therefore enough to identify that pairing of lexical
> > > form (literal) to data type (URI) in order to denote the
> > > value.
> > 
> > The problem is not that the datatypes don't meet your 
> > conditions above, the
> > problem occurs when two datatypes share some data values, but 
> > disagree on
> > how to do the lexical-to-value mapping.  If the typing comes 
> > from RDF(S),
> > then it may be the case that a literal gets these two 
> > datatypes.  Then the
> > value for that literal is ambiguous.
> The value*S* are not ambigous. In the case where there are
> multiple pairs of lexical forms and data types, each pair
> denotes a value in the value space of the data type. If those
> values are not the "same" then we have a contradiction.
> Contradictions are part of general life in the semantic web,
> no? 

The whole point, and the problem with Pat Hayes's solution, is that you
don't get a contradition.  A contradition might be much better than what
you actually get, which is a model that has an unintended lexical-to-value
mapping.  However, if you switch Pat's model theory around to remove the
ambiguities, then there are datatyping schemes, such as XML Schema, where
most literals have no coherent value.

For example, if you allow union XML Schema datatypes there is a model of 

	<rdfs:range foo xsd:[integer union string]>
	<John foo 7>

where the value of John's foo is the string "7", which is not the intended
value.  This is because you can datatype the literal as a string and use
string's lexical-to-value map.  If you instead require that the
lexical-to-value map be consistent with all the types of the value, then
you get too many contractions.  For example, the integer 7 belongs to the
datatype integer, which is fine, but it also belongs to the datatype
[string union integer].  Therefore you can't get from the literal 7 to the
integer 7, because that would violate the lexical-to-value map for [string
union integer].

> By basing the data typing solution on the *pairing* of lexical
> form to data type, where the data type defines both lexical
> and value space, then we are free to employ whatever idioms
> we choose to define such pairings and interpretation is reliable,
> even when we have contradictory assertions. E.g.
>    x eg:property [ rdf:value "10"; rdf:type xsd:gDay ] .
>    eg:property rdfs:range xsd:gMonth .
> resulting in the contradiction that "10" is a lexical form
> denoting a day value *and* a month value. In both cases,
> the pairing is crystal clear
>    ("10",xsd:gDay)
>    ("10",xsd:gMonth)
> Whether the values denoted by those pairings are the same, and
> whether there is a contradiction is a matter for the application.
> RDF has done its part by making the pairings clear and available
> for such interpretation.

I don't see how this does anything to help the situation, at least in the
RDF model theory.  If you do the obvious translation of the above into the
RDF model theory you get the same ambiguities as before.  If you make a
small change, which you seem to be expecting, you get contradictions where
you expect none.

To show that you indeed have a solution you will have to present a full
description of what exactly is the meaning here.  This doesn't have to be a
model theory, but it does have to be much more than is presented above.
For example, what is the theory of rdf:type on datatype classes?

> Cheers,
> Patrick

Peter F. Patel-Schneider
Bell Labs Research

This archive was generated by hypermail 2.1.4 : 04/02/02 EST