W3C home > Mailing lists > Public > semantic-web@w3.org > August 2007

Re: RDF's curious literals

From: Garret Wilson <garret@globalmentor.com>
Date: Wed, 01 Aug 2007 08:06:04 -0700
Message-ID: <46B0A15C.2000105@globalmentor.com>
To: Richard Cyganiak <richard@cyganiak.de>
CC: Story Henry <henry.story@bblfish.net>, Tim Berners-Lee <timbl@w3.org>, Semantic Web <semantic-web@w3.org>

Richard Cyganiak wrote:
> On 1 Aug 2007, at 01:49, Garret Wilson wrote:
>> So let me state this another way: to say that non-literal resources 
>> use URIs as identifiers and literal resources use strings as 
>> identifiers is a false dichotomy. RDF uses strings for all its 
>> identifiers. It's just that for non-literals, these strings conform 
>> to a format called URI
> That's simply not true.
>     <http://dbpedia.org/wiki/George_W._Bush>
> and
>     "http://dbpedia.org/wiki/George_W._Bush"
> do not identify the same resource. The first identifies a person, the 
> 43rd president of the U.S.. The second identifies a string of Unicode 
> characters that happens to conform to the URI syntax.

Hi, Richard. You are *so* missing my point here.

I could say that #+1 555 1212# is a telephone number, but that "+1 555 
1212" is only a sequence of Unicode characters. I could say that 
%someone@example.com% is an email address, but that 
"someone@example.com" is only a string. But the point remains that these 
are all identifiers.

In RDF, if I use "someString" to identify something, it becomes a 
different type of something than if I use <someURI> to identify it, and 
I don't think that should be the case. If I call one identifier (that 
happens to have extra characters) a "URI" and the other a "string", how 
does that change the thing it identifies?

If <http://example.com/integers/123> and "123"^^xsd:integer both 
identify the same value (which, for the sake of argument, everyone 
agrees they do), why does the form of the identifier change the type of 
resource being identified?

Received on Wednesday, 1 August 2007 15:06:12 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:02 UTC