Re: RDF's curious literals

On 1 Aug 2007, at 19:53, Garret Wilson wrote:
> 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."

George Bush can not be a literal. I think that is clear. Even if he  
thinks literally, that is without looking at the world.

>>> 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.

It really is no problem. People have been telling you that you can go  
and create a bunch of URIs for
the numbers if you wish. You just need to get other people to follow  
your lead. If enough do, then that will be good. The following is  
completely legitimate RDF:

<http://numbers.eg/123>
    a xxx:Number;
    = 123;
    xsd:int "123" .

There is no problem. People chose to follow one way of doing things  
over the other. You can use URIs for numbers if you wish.

So you can fix the problem.

>> 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.

But who does that bother anyways?
In which model does it have to be presented that way? You mean in the  
spec right? But that is just a way to make sure we all agree on  
something. A bit like a Java reference implementation for say the  
Servlet API. Everyone can create more efficient ones later.

>
>>
>>> 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:

Did you go an read http://www.w3.org/TR/swbp-xsch-datatypes/
or any of the other pointers people have been giving you?

I know you have not because you are responding within minutes of the  
reply reaching you.

> "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."

this is not a problem.:
   - How each of them map to each other is well known.
   - How you store it is up to you, so the fact that you can name  
them differently is not a problem
   - you know all you need to know about them when you have their name.


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

it can't increase it. There are an infinite number of ways to refer  
to things.

> 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.

People would understand you less well at present, reasoners would not  
know certain things, and you would
not be making your life any easier.

The question can really be turned around: what are you gaining by  
just having URIs.

I think you are also confused because you think of the data type as  
typing the string, rather than a map to the string.


> 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.

Can you let us know how this is causing you any trouble?



> 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 18:20:40 UTC