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

Re: RDF's curious literals

From: Story Henry <henry.story@bblfish.net>
Date: Thu, 2 Aug 2007 18:41:09 +0200
Message-Id: <413223F8-16DF-4C56-955E-223DEC6127E5@bblfish.net>
Cc: Lee Feigenbaum <lee@thefigtrees.net>, Richard Cyganiak <richard@cyganiak.de>, Garret Wilson <garret@globalmentor.com>, Tim Berners-Lee <timbl@w3.org>, Semantic Web <semantic-web@w3.org>
To: "Sandro Hawke" <sandro@w3.org>

On 2 Aug 2007, at 18:24, Sandro Hawke wrote:

>> http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section- 
>> Datatypes
>> [[
>> A datatype consists of a lexical space, a value space and a  
>> lexical-=20
>> to-value mapping.
>> The lexical space of a datatype is a set of Unicode [UNICODE]  
>> strings.
>> The lexical-to-value mapping of a datatype is a set of pairs whose  
>> =20
>> first element belongs to the lexical space of the datatype, and  
>> the =20
>> second element belongs to the value space of the datatype:
>> Each member of the lexical space is paired with (maps to) exactly  
>> one =20=
>> member of the value space.
>> Each member of the value space may be paired with any number =20
>> (including zero) of members of the lexical space (lexical =20
>> representations for that value).
>> A datatype is identified by one or more URI references.
>> RDF may be used with any datatype definition that conforms to this  
>> =20
>> abstraction, even if not defined in terms of XML Schema.
>> ]]
> Is there some other distinguishing criterion on datatypes?
> I can't think of one.
> Therefore, X is a datatype if and only if X is an  
> owl:FunctionalProperty
> and the rdfs:domain of X contains only Unicode strings.

well I was proposing in addition that it be a necessary truth, ie it  
necessarily identify the thing that way,  which will bring up some  
fun problems, but I think that the intuition behind datatypes is  
something along those lines.

> It's kind of a shame this logic isn't used more in the design of  
> RDF to
> simplify it.   There might be another re-articulation of the RDF  
> design
> which would use this fact.
> (Again, this is not a new idea [1]).
>> The important point there is that there has to be a lexical to value
>> mapping, and there has to be a one to one mapping.
> No, it's a one-to-many mapping.    For instance, the value one can be
> mapped to from "1", "01", "001", etc.

quite right, I wrote too fast.

>> This can only work
>> of course if all the information is contained in the String, ie,
>> there is not more information to be got from anywhere else, or else
>> there would be no way to create a decision procedure for it. So
>> "George Bush"^^xxx:presidents would not work. For one, George Bush
>> may never have been president.
> But it's easy for me to construct the mapping you quoted above.  So I
> can't understand what you mean.  A datatype like eg:uspresidents makes
> every bit as much sense as a datatype like xs:date.

That would not work with eg:uspresidents, because Bush could have had  
a different name, and  could also not have been president.

With numbers on the other hand it is different. Even though 10 could  
be written differently than "10"

10 xsd:int "10".

is necessarily true.

> This all brings me back to:
>    A simpler abstract syntax for RDF would be N-triples where you only
>    have unicode-string-literals (plainLiterals), b-nodes, and a "URI"
>    predicate. (You'd have to allow b-nodes in the predicate position.)
>    The current design of RDF is basically syntactic sugar on that
>    foundation.
>    [Personally, I'd probably use bit-strings or byte-strings  
> instead of
>    unicode-character-strings, too.    Tough design tradeoffs, there.]

Ok. I think what you are saying is that there is no need for the ^^  
symbol, in which case you are probably right. One can say the same  
using the ^ symbol.

1 xsd:int "1";
   = "1"^xsd:int;
   = "1"^^xsd:int .

On the other hand I think the class of rdfs:Datatypes remains a  
useful one.


>    -- Sandro
> [1] http://esw.w3.org/topic/InterpretationProperties
Received on Thursday, 2 August 2007 16:41:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:41:58 UTC