W3C home > Mailing lists > Public > www-rdf-interest@w3.org > September 2003

Re: relationship of rdfs:Literal to rdfs:Resource

From: Garret Wilson <garret@globalmentor.com>
Date: Sat, 27 Sep 2003 12:06:28 -0700
Message-ID: <3F75DFB4.5030403@globalmentor.com>
To: Graham Klyne <gk@ninebynine.org>
Cc: www-rdf-interest@w3.org

Graham Klyne wrote:
> At 08:27 14/09/03 -0700, Garret Wilson wrote:
>> 4. How can I assert properties of the resources indicated by the plain 
>> literal "10"? (If "10" really represents a resource, why can't that 
>> thing have properties, too?)
> Currently (in bare RDF) there's no way to do this -- not for any 
> fundamental reason but because this was one enhancement that the WG has 
> declined to define at this time.

Let me try to summarize what I've learned from this discussion. (Thanks, 
everyone, for the input.) Unfortunately, the answers are what I feared:

1. Everything to which we can refer is a resource.

2. We refer to some resources using URIs. We refer to other resources 
using literals.

3. Using only RDF capabilities (e.g. no OWL or custom ontologies), the 
set of resources referenced by URIs do not intersect with the set of 
resources we reference using literals.

I don't like this, and there seems to be no reason for it. Is a resource 
referenced by a literal somehow less of a resource that it can't be 
assigned a URI using the framework itself (i.e. RDF)? This makes 
implementation of ontologies that use literals cumbersome.

4. If we decide to refer to a resource using a URI (or, with blank 
nodes, no URI), we can make statements about the properties of the 
resource. If, on the other hand, we refer to a resource using a literal, 
we find we can't say anything at all about the resource's properties.

This conclusion (related to #3) doesn't set well with me, either. Why 
did RDF decide to allow properties to be assigned to certain resources 
and not others? Are URI-referenced resources somehow more 
"resource-like" than literal-referenced resources? Is there something 
fundamental about the resources in the world reference by URIs that make 
it more appropriate for them to have properties, and not those 
referenced by literals? It seems to me that a resource is a resource is 
a resource, however it's referenced, and all of should be able to have 

5. rdf:value doesn't express any semantics that would help us here.

It's tempting to want to use rdf:value to solve these problems by 
thinking that it has the same semantics as owl:sameAs. (Tempting enough 
that I've succumbed, in light of the above shortcomings #3 and #4, to 
abuse rdf:value in ontologies I create.) It doesn't. It doesn't have any 
semantics other than that imposed on it by the application that uses it.

In fact, it seems to have been created as a kludge to get around just 
those shortcomings that I've outlined above (i.e. #3 and #4). That is, 
to say "10" eg:isDivisibleBy "2", one would use:

<rdf:Description rdf:about"example:object">

If rdf:value had those sort of semantics, we could also write:

<rdf:Description rdf:about="example:object">

But as RDF does not endow rdf:kludge (sorry, rdf:value) with any such 
semantics, we're left wondering:

5(a) example:object has a property rdf:value, the value resource of 
which is represented by the lexical form "10" {example:object, 
rdf:value, "10"}. Since the property value is a resource, how can we 
express properties of that resource? Maybe we could use rdf:value, like 

<rdf:Description rdf:about="example:object">

rdf:value has no semantics unless I decide to use it as a substitute for 
owl:sameAs in my proprietary application. As the above example (5(a)) 
shows, this only works if I'm only using rdf:value this way in my own 
application, and not interacting with any other applications---defeating 
the whole purpose of RDF.

In short, (A) in RDF, URI-referenced resources and literal-referenced 
resources have arbitrary differences that shouldn't be, and (B) 
rdf:value doesn't help us out of this mess.


Received on Saturday, 27 September 2003 15:07:02 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 6 January 2021 22:03:27 UTC