W3C home > Mailing lists > Public > www-archive@w3.org > August 2007

Re: RDF's curious literals (was: Re: RDFON: a new RDF serialization)

From: Tim Berners-Lee <timbl@w3.org>
Date: Wed, 1 Aug 2007 23:33:20 -0400
Message-Id: <4EB7B3DC-0B0D-4109-98C1-DD677E9C7D6E@w3.org>
Cc: Tim Berners-Lee <timbl@w3.org>
To: www-archive@w3.org

I totally agree, modulo a bunch of corrections.

On 2007-07 -31, at 18:43, Story Henry wrote:
> I think the point of Tim's post was that really he thinks that the  
> only things that are literals are strings.
>

Friendly correction:    I don't think the only literals *are*  
strings, but I point out that the existing
system can be defined (modeled?) using just strings and datatype  
properties.
The RDF system could have been just strings and properties.

This was in response to Garret's complaint that RDF datatypes had no  
rhyme nor reason.
I wanted to point out that one could look at them quite cleanly.


> [] xsd:integer "123" .
>
> can be written in shorthand as
>
> "123"^xsd:integer .
>
> (see the N3 tutorial)
>
> Because everybody in the xml world was going crazy about xsd  
> datatypes they wanted this more complex notion of literals. To  
> satisfy them the ^^ notation was added.
>
> 123 = "123"^^xsd:integer,
>       "123"^xsd:integer,
>       123 .
>
> is a nice shortcut in N3.

Yes. To be precise,

123 and  123"^^xsd:integer are alternative syntaxes for the same thing.
In my scheme when xsd:integer is an rdf property, then it also holds  
that

			"123"^integer   =   "123"^^xsd:integer

(or as a triple,  "123"^^xsd:integer xsd:integer "123".)



>> The RDFS definition at http://www.w3.org/TR/rdf-schema/#ch_literal  
>> is at first circular ("the class of literal values") and then  
>> nonexistent for some literals ("This specification does not define  
>> the class of plain literals."). The RDF Primer explanation at  
>> http://www.w3.org/TR/rdf-concepts/#section-Literals is more  
>> helpful: A literal is a resource identified by a lexical  
>> representation, which representation may be "more convenient or  
>> intuitive" to use instead of a URI.
>>
>> So at the end of the day, a literal is simply a resource that is  
>> easy to refer to using a string of characters. That's all well and  
>> good, but why should that affect my model? Why is a resource an  
>> instance of another class (rdfs:Literal) just because I like to  
>> identify it by a lexical representation?
>>
>
> You may have a good point there. There is a difference between a  
> string and a URI though that is worth keeping in mind. Namely you  
> have to look at the world to find out if the following is true or  
> false
>

Friendly correction:  There is a difference between a [string used as  
a] Symbol and a [string used as a] Literal in the language.

I understand that 'symbol'  is the right  term for the term <http//// 
whatever> and I understand 'litera' maybe weird but RDF for the term  
"http://whatever".   What we are distinguishing here is the role in  
the RDF (n3 or whatever) syntax.

> <uri1> = <uri2> .
>
> where uri1 and uri2 are two different strings.
>
> But you don't need to look at the world to tell that the following  
> is false
>
> "uri1" = "uri2" .
>
> you know they are different just by doing a character by character  
> comparison.
>

yes

> Now you may say that really that's just because they are a list of  
> characters, and you could refer to each character as a URI, and  
> then well your point would stand. So you could have something like
>
> ( <http://unicode.org/char/u> <http://unicode.org/char/r> <http:// 
> unicode.org/char/i> <http://unicode.org/char/1> ) = ( <http:// 
> unicode.org/char/u> <http://unicode.org/char/r> <http://unicode.org/ 
> char/i> <http://unicode.org/char/2> ) .
>
> There you would have to know something about the referents of each  
> of these characters to tell that it can't be true.
>
> Still it is convenient to have literals, you have to admit. Because  
> when you see one, you know how to deal with it immediately. And we  
> are engineers, so we do like to have some conveniences.
>
>> Take for example the resource identified by the URI <http:// 
>> example.org/presidents/GeorgeWBush>. This resource may have an  
>> rdf:type of foaf:Person. (I could assert all sorts of other RDF  
>> statements about this resource, but will decline to do so at this  
>> time.) Is this resource an instance of the class rdfs:Literal? No?  
>> Why not?
>>
>> But wait---if I decide that it's easier to represent this resource  
>> using a string, I could create the resource "George W.  
>> Bush"^^foaf:Person.
>
> Please have a closer look at N3, or else we will keep repeating the  
> same points. Tim BL would say that
> the above is more clearly stated as:
>
> "George W. Bush"^foaf:Person .
>
> which is
>
> [] foaf:Person "George W. Bush" .
>
> And as you can see that is not what you meant. foaf:Person is a  
> class and not a relation.
> (think of relations as arrows going between things as depicted here
> http://blogs.sun.com/bblfish/resource/Syntax-Semantics-Photo.jpg )
>
> Also to refer to people via a String is not helpful, because they  
> can have different names. Since the
> following is necessarily false
>
> "George W. Bush" = "George Bush" .
>
> you would not be able to make the assertions we all want to make.  
> In RDF we think of it this way:
>
> [] foaf:name "George W. Bush",
>              "George Bush" .
>
> That is ok. A person can have two name relations different  
> strings.  URIs are Universal Names.
> Strings are resources too, but they refer to themselves.
>
> That is an important and useful enough difference to make a special  
> case for the semantics.
>
>
> Henry
Received on Thursday, 2 August 2007 03:33:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:18:08 GMT