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 10:53:31 -0700
Message-ID: <46B0C89B.2030001@globalmentor.com>
To: Story Henry <henry.story@bblfish.net>
CC: Jeremy Carroll <jjc@hpl.hp.com>, Tim Berners-Lee <timbl@w3.org>, Semantic Web <semantic-web@w3.org>

Story Henry wrote:
>> Story Henry wrote:
>>> 1. you say why not "George Bush"^^xxx:president, and so why is not 
>>> everything a Literal?
>>>
>>>    there are in fact limitations on what can be a Literal.
>>
>> What limitations are those---I don't remember seeing this in the RDF 
>> specifications? Could "George  W. Bush"^^xxx:president be a literal, 
>> if I specify the range of allow lexical forms? What cannot be an 
>> instance of rdfs:Literal?
>
> The intuition I pointed out was that if you have things were the name 
> of the thing can tell you everything you need to know about it, then 
> you have something that is a candidate for being a Literal.

You still didn't give me an example of what could *not* be a literal, 
even though you stated that "there are in fact limitations on what can 
be a Literal."

>>
>> I'm sorry, but I still don't understand. You're saying that if I have 
>> the URIs <http://numbers.eg/123> and <http://numbers.eg/124> I don't 
>> know whether these are referring to the same resource or not, even 
>> though the URIs are distinct. But if I have literals, I know that the 
>> literal "123"^^xsd:integer is different from the literal 
>> "124"^^xsd:integer just because they are literals. Is that what 
>> you're saying?
>
> yes. Unless of course the RDF people had decided that numbers should 
> be uris starting with "http://numbers.eg/" which they could have done.

Which I'm saying they *should* have done.


> But people would not have found it natural and you have said - have 
> you not? - that it was good if languages felt natural. Why go against 
> the grain? Is that not one reason you were wanting to work on RDFON?

Again (and again and again), people keep mixing up the representation in 
the model and the representation in the serialization of N3, RDF/XML, 
and RDFON. Just minutes ago I begged TBL to believe me that I want to 
represent integers and strings as 123 and "123" in the serialization. I 
beg of you to believe me as well. No one seems to believe me.

This is is not a battle between presenting 123 as 
<http://numbers.eg/123> or 123. It is between presenting 123 in the RDF 
model as <http://numbers.eg/123> or "123"^^xsd:integer, neither of which 
is "natural", but neither of which people have to bother with because in 
N3 and RDFON they can just use 123. But one of these model 
representations (the former) is just like every other resource 
representation. The other is some strange thing called an rdfs:Literal.

>
>> So are you saying that I also know that the literal 
>> "+123"^^xsd:integer is different from the literal "123"^^xsd:integer 
>> because I can simply compare the strings and see that they are not 
>> equal?
>
> No look at
>
> http://www.w3.org/TR/swbp-xsch-datatypes/
>
> to find out how the definitions work.  What is sure is that you don't 
> need anything more than "+123"^^xsd:integer to know what you are 
> speaking of. The objects can be completely specified there in the 
> name. And there are an infinite number of such objects.

I'm willing to bet that you didn't read my sentence closely. Please read 
it again. Then let's look at what you stated:

"For example <http://presidents.com/Bush/George> referring to the same 
thing <http://presidents.com/Bush/George/W> is? Well you can't tell. You 
may assume they are different until told otherwise. ... Now for numbers 
we know that 123 is different from 1234 is different from 124 etc, etc. 
You can see how this could make for an absolutley humungous number of 
statements of differences in your database. Furthermore we *know* they 
are different without even looking at the world. There is no possible 
world in which they are the same. 123 is always different from 124. That 
can save a lot of calculations and storage. No need for the infinite 
number of statements <http://numbers.eg/123> owl:differentFrom 
<http://numbers.eg/124> . ..."

But I point out that you have exactly the same situation with 
literals---just because the lexical form is different doesn't mean that 
they refer to different resources. Let me quote from the same document 
http://www.w3.org/TR/swbp-xsch-datatypes/ you point to above:

"For example, "10"^^xsd:integer and "010"^^xsd:integer  both denote the 
integer ten."

But it gets even worse for your case. Quoting again:

"|"15"^^xsd:byte| and |"15.0"^^xsd:decimal| both denote the same value, 
fifteen.This follows because xsd:byte has primitive base datatype 
xsd:decimal."

So the RDF literal system actually increases the ways I can refer to the 
same resource, not decreases.

So all my questions remain. You have not told me what value rdfs:Literal 
brings me, or how I would miss it if I used <http://numbers.eg/123> 
instead of "123"^^xsd:integer and rdfs:Literal didn't exist.

You can refer to integers in the RDF model using URIs, like every other 
resource, or you can create some strange rdfs:Literal class and create 
strange representations in the RDF model for storing these strange 
rdfs:Literals. But the latter method buys you nothing that you wouldn't 
already have just by using URIs like you do with all other resources.

Garret

P.S. And please, please, please believe me that I want to use 123 and 
"123" in N3 and RDFON. Pretty please?
Received on Wednesday, 1 August 2007 17:53:44 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 21:45:17 GMT