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

Re: literals must be self-evident

From: Bill de hOra <bdehora@interx.com>
Date: Thu, 18 Oct 2001 15:11:10 +0100
To: <w3c-rdfcore-wg@w3.org>
Message-ID: <002001c157de$c06671a0$01000001@MITCHUM>
Dan Connolly:
Then I haven't been clear.

I think graham stated it more precisely:
"the truth under any given 
interpretation of some RDF document is invariant;  consulting another 
document may restrict the interpretations that are considered to be
	-- GK, Wed, 17 Oct 2001 20:48:49 +0100

> Jeremy
> Documents are not self-contained.

In the way that I am suggesting, they are. In particular:
literals are self-contained.

Something Pat said to me on another thread said might be relevant:

"True, but what it can denote is severely restricted. The model theory 
at present assumes that literals have a *fixed value*. So whatever a 
literal denotes, it has to denote it once and for all, globally. It 
can't denote one thing in the Dublin core and something else 
somewhere else.

Now, that is a very simple and restrictive assumption, and Peter 
Patel-Schneider wants us to relax it to the extent of allowing 
datatype schemas for literals. The kind of examples he uses are where 
"070801" might mean either a date or a string or an integer, and one 
can determine from things like the rdfs:range information which 
datatype scheme is supposed to be applied to each literal occurrence. 
That is the scheme we have now worked out in full detail so that it 
COULD be incorporated into the MT for RDFS, if we want to do so, 
though right now its just kind of waiting to be put there. But even 
with this extension, the range of things that a literal can refer to 
is somewhat restricted to be the kinds of things that one finds in 
datatyping schemes. I'm not sure if having a literal like "creator" 
denote a particular human being would count as a datatyping scheme, 
but it sure doesn't sound like one to me."


bdehora at interx.com 

Received on Thursday, 18 October 2001 10:14:00 UTC

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