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

Re: datatypes [was Re: Argh!]

From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Date: Mon, 29 Oct 2001 21:58:27 +0000
Message-Id: <>
To: w3c-rdfcore-wg@w3.org
A useful exchange, indeed, between Sergey and Peter!  [Excerpt below.]

I was starting to think, in a kind of parallel to what Sergey seems to be 
suggesting, that the revised role of literal datatyping was somehow similar 
to the role of interpretation.  But I'm beginning to see how that isn't so.

In the beginning (of Pat's model theory for RDF), literals had a fixed 
denotation that was independent of any particular interpretation (which 
might or might not be a model of some set of statements).  This had the 
wonderful property (that Sergey seek to preserve) that the value of a 
literal could be determined without looking to any other part of the RDF 
graph, or the context in which it is used.

But we have seen many plausible use-cases where this isn't so:  integers 
and shoe sizes, integers and social security numbers, ambiguous labels, 
etc., etc.  I do believe that insisting on this restriction would make RDF 
less easy to use.  I think we need to recognize that the same syntactic 
literal, as it appears in (say) N-triples, can denote different values when 
used in different contexts.

But does this allow unfettered make-the-rules-as-you-go interpretation of 
literals?  I don't think so...

Pat (in 
http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Oct/0453.html) says:
Formally, a datatype scheme D is a set DT of things called types and two 
   DTS: DT-> (L ->LV) to datatypes
   DTC: DT-> powerset of LV
to the range of each datatype (integers, strings, etc.), and a datatyping 
of a set is a function from that set into DT, ie an assignment of a 
datatype to everything in the set. A typed interpretation <I,D> of a graph 
is an interpretation I of the vocabulary plus a datatyping D of the nodes 
which satisfies the following conditions. (The first condition isn't a 
mathematical condition on the structures involved, but it is required in 
order to make the datatype scheme useable in any web language.) :

1. If nnn is any uri of a datatype, then I(nnn) is in DT.
2. ICEXT(d) is a subset of DTC(d) for any d in (DT intersect IR)
3. LV(n)=DTS(D(n))(label(n))

... according to this a literal value may have several different 
denotations within a given interpretation of a given graph, which makes it 
seem more general than a URI which can have only one denotation under a 
given interpretation.  But the range of possible denotations is limited by 
the values called DT and the function DTS.   [I'm not sure that DTC adds 
value to all this.]

It seems to me that a given set DT and function DTS can be imposed on any 
interpretation, and may effect those interpretations considered to be 
models of some given statements.  But a datatyping scheme stands alone, is 
not "true" or "false", and its validity is not subject to any 
interpretation that might be used.  In this sense, the datatyping scheme is 
invariant with respect to the interpretation used, which I think makes it 
closer to the original idea of fixed interpretation of literals than to the 
variable nature of interpretation of URIs.


At 03:07 PM 10/29/01 -0500, Peter F. Patel-Schneider wrote:
>From: Sergey Melnik <melnik@db.stanford.edu>
>Subject: Re: Argh!
>Date: Mon, 29 Oct 2001 11:49:17 -0800


> > > > If literals may denote everything you like (and many things at once), I
> > > > don't see why we need resources/URIs any more. We could do just fine
> > > > with literals. For example, literal &quot;Peter&quot; could denote 
> a person,
> > > > sometimes Peter Pan, another time Peter The Great (even in the same
> > > > graph!). Literal &quot;2&quot; in the above example could well 
> denote Peter The
> > > > Great, too.
> > >

> > > This is soo wrong that I don't know how any reasonable person could even
> > > think of it.  Literals are constrained in their interpretation.
> > > Non-literals are less constrained than literals.  The only differences
> > > between literals and non-literals is that a literal has a 
> ``print-string''
> > > that is used to restrict what it can denote and a non-literal can have a
> > > label, which has no real import in a tidy RDF graph.

> > So? Literals are constrained by what? By properties defined in some
> > schemas? So why can't "Peter" denote Peter Pan (or Patel-Schneider,
> > given the context ;) ?

>[Warning:  In the following, I will be bit loose in terminology and
>syntax.  No ambiguities should result, however!]
>My model theory states that a literal Peter, as in
>         peter name "Peter".
>can only denote something that has an XML Schema datatype lexical
>representation that is the literal "Peter".
>If Peter Pan is not in the value space of any XML Schema datatype then it
>cannot be the denotation of a literal.  peter, of course, could denote
>Peter Pan.  Only if you were using a datatype scheme that had Peter Pan as
>one of its literal values, and a lexical representation of that literal
>value was "Peter", could you have "Peter" denote Peter Pan.
>Further, if you have
>         name rdfs:range xsd:string .
>         peter name "Peter" .
>then the name of peter has to be the string ``Peter''.
>More interesting is the following situation:
>         peter age "07" .
>         age rdfs:range xsd:integer .
>         susan shoe-size "07" .
>         shoe-size rdfs:range xsd:string .
>Then, indeed, the two occurences of "07" have different denotations, one
>being the integer 7 and the other being the string ``07''.  Similarly, if
>all you have is
>         mary phone "5824471" .
>then you don't know whether mary's phone is the decimal 5 824 471 or the
>string ``5824471'' or even the floating point number 5824471 (which is
>different, in XML schema, from the decimal 5 824 471).  There are even
>other interpretations for mary's phone (such as a URI, I think).

Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
Received on Monday, 29 October 2001 17:01:54 UTC

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