W3C home > Mailing lists > Public > www-rdf-interest@w3.org > April 2004

Re: What if two resources are the same subject?

From: Jon Hanna <jon@hackcraft.net>
Date: Wed, 14 Apr 2004 10:01:34 +0100
Message-ID: <1081933294.407cfdeee3f49@>
To: "www-rdf-interest@w3.org" <www-rdf-interest@w3.org>

Quoting "Thomas B. Passin" <tpassin@comcast.net>:

> Jan Algermissen wrote:
> >>Well there is only one resource, but multiple URIs, 
> > 
> > 
> > Ah, that I did not know. So resources may 'span across authorities', yes?
> > A single resource can live on different hosts controlled by different
> > authorities, yes?
> > 
> > (I expect the REST camp to scream but if they agree, too, so much the
> better) 
> > 

Consider that a resource can be anything, including physical objects like
people. I know this isn't an entirely contention-free point, but while I
can't speak for the entire REST camp Fielding's dissertation states:

"Any information that can be named can be a resource: a document or image, a
temporal service (e.g. “today’s weather in Los Angeles”), a collection of other
resources, a non-virtual object (e.g. a person), and so on."

So this would seem to be the REST position, or at least the orthodox REST
position. With RDF it's hard to justify any other position if you are using
URIs for things like predicates which are clearly abstract and don't "belong"
to anyone).

Now, it simply isn't possible to have a single naming authority for every
and concept in existence (or not in existence, since fictional things can be
identified) and it isn't practical to have a single naming authority for every
object and concept of interest to everyone on the web. Even splitting the
authority would require a centralised governing authority. Hence anyone who can
coin URIs (uneasily governed by being in charge of a domain name) can coin a
URI to identify anything.

That two or more URIs will identify the same resource is inevitable, and
potentially fruitful (determining whether or not two URIs are identifying one
or two resources may be very useful indeed, but two URIs are needed to allow
for the possibility that they are two resources until that is determined).

> You want to remember that the URI as used in an RDF statement is NOT 
> being used as a REST-like GET-able representation.  It is purely an 
> identifier.  What does it identify?  Ah, there's the rub.  IF it 
> resolves to a retrievable resource, you could apply the convention that 
> the resource "should" say cogent things about the thing identified by 
> the URI.  In that case, the retrievable URL would be acting like a PSI. 

I have to disagree.
In RDF a URI is used to identify a resource (a thing).
In REST a URI is used to identify a resource (a thing) and additionally if
it in a GET operation is successful then a representation of that resource will
be returned.

Since RDF has nothing to say about derefencing URIs once you dereference it
you're in REST's territory, not RDF's so a successful derefence should indeed
provide say things about the thing identified by the URI (whether it's cogent
or not depends on who or what is dereferencing, and why, so that can't be

In using URIs RDF is buying into REST to some extent, otherwise it would be
better for it to use some other identifier system. Without the advantages of
being able to buy into REST and inherit its goodness RDF would indeed be better
off inventing a new identifier (domain names are a reasonable if imperfect way
to partition authority within the namespace, but RDF has no direct use for
schemes, and didn't need to inherit the growing pains URIs are having with
non-ASCII characters).

>   However, this is only a convention.

URIs, RDF, XML, RDF/XML, HTTP and other web technologies are all conventions, I
can send whatever I want to port 80 of a web server, it's by following the
conventions that I might achieve something useful. It's all "only a

Jon Hanna
"…it has been truly said that hackers have even more words for
equipment failures than Yiddish has for obnoxious people." - jargon.txt
Received on Wednesday, 14 April 2004 05:02:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:50 UTC