Re: RDF's curious literals

Story Henry wrote:
> Now if we look here at the eg:uspresidents then I think it would be 
> impossible to build such a
> function in code that would only require the input from the string to 
> get its value. Well the code
> would have to have a database of all the name of presidents for it to 
> work. And what if we have two presidents with the same name?

I think this discussion is getting confusing because of a few too many 
philosophical terms, but that could be just because I don't fully (yet) 
understand those terms. ;)

The name of the president and whether it is unique is a red herring. The 
main question is whether a US president could be a literal in the RDF 
abstract syntax. The answer is yes; use the president's social security 
number or some other identifying number, if names confuse the issue: 
"123-45-6789"^^eg:uspresident.

In fact, any resource could be an instance of rdfs:Literal in the RDF 
abstract syntax, if you decide to give it an identifying string. Those 
same resource would not be literals if you used URIs to identify them 
rather than strings. Having a concept of rdfs:Literal bring no 
additional value to the RDF abstract syntax.

Another way of summarizing things: the string "10" only relates to the 
value 10 in the context of datatype xsd:integer (which is a subclass of 
xsd:decimal). The string "10" would relate to the value 2 in the context 
of the datatype eg:binary. The string "10" doesn't relate to any number 
by itself---only in the context of some datatype. That means you cannot 
talk about an RDF integer literal using only the string "10"; you must 
use "10"^^<|http://www.w3.org/2001/XMLSchema#integer>.

Some people are telling me that there is some huge, unbridgeable divide 
between the following two representations:

|"10"^^<|http://www.w3.org/2001/XMLSchema#integer>|
<|http://www.w3.org/2001/XMLSchema#integer:|10|>|

They look pretty similar to me, except that the latter allows me to 
treat so-called "literals" just like any other resource.

Garret

Received on Thursday, 2 August 2007 19:25:15 UTC