I think the original issue raised by Ian was related to the concept of a "resource" in how it's defined in HTTP being an "abstract" thing, and inferring that being abstract is a bad thing.

However if you consider all the types of thing that can be referred to by a URI, then you quickly see it is indeed an abstract concept.  Given that we use the name URI, where R stands for "resource", therefore the resource must be the thing identified by a URI.  I don't see HTTP attempting to define the resource any further than this, and yes it is necessarily abstract, and that provides it scope to be anything you can think of.  So being abstract isn't a bad thing - it's the reason for HTTP's power.

As for the data you get back from a request, "resource representation" probably IMO reads a bit too much into it.  It may not necessarily represent any resource.  To me it's simply a result of the request.  It's just data.  It may (e.g. a GIF file) be the same binary data as the "resource" requested, or may not (e.g the result of script output, where the resource could be deemed to be the PHP file, or e.g. the coke machine itself vs the bytes coming back telling you how many cans are left).  You could consider on some level that the result of a request gives you something you can use, which could be deemed a resource in the broader sense.  But it's not *the* resource identified by the URI.  And since there must be a distinction between the thing identified by a URI, and the bytes (if any) you get back from a request, and since the label "resource" is already taken, we need another name for the result data.  We simply can't use the word "resource" there without creating confusion.

The concept of "resource representation" becomes perhaps more easily understood where there may be more than one result of a request which may be deemed on some meta-level to be equivalent (as defined by the content author) but which is different in terms of the bytes returned, such as different language versions of the same page.  It contains the same information, but in a different language so the site author deems it to be the same on some meta-level.

However, I'm happy with the concept of what "resource" and "resource representation" refer to.

My 2c



Ian Hickson wrote:
On Sun, 14 Jun 2009, Julian Reschke wrote:
HTTP URIs are URLs, and URLs simply are URIs that also double as 
locators (see RFC 3986). I don't see how this changes the definition of 
being an identifier at all.

I'm not arguing that they aren't identifiers, I'm arguing that when you 
dereference them you get an actual concrete resource, and that saying 
that you get a resource representation is pointless and confusing hair- 
splitting which doesn't actually help people understand the specs when 
they implement them, since the thoretical "resource" construct never 
actually needs to be dealt with in practice.

Whether HTTP URLs as identifiers for things like RDF properties or XML 
namespaces is a good idea is an entirely different discussion. Mixing 
those here isn't helpful.

I couldn't agree more.

Indeed, the spaces where URIs have been used as identifiers have shown 
why having dereferencable identifiers is a bad idea -- for instance 
they are unwieldy, leading to people using techniques like prefixes 
and prefix declarations to avoid the problem; and they invite 
dereferencing even when that isn't necessary, leading to high load for 
popular identifiers [1].

[1] http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic
Again, what does this have to do with the terminology discussion we 

By persuing a terminology that encourages people to think of URIs as 
something more than just a way to obtain a bag of bits, we have encouraged 
the kind of usage seen in RDF and Namespaces in XML.

If we just stuck to concrete terms and didn't go off on a theoretical 
tangent distinguishing "resource" and "resource representation", people 
would not be tempted to use that theoretical difference for actual 

It is the HTTP and URI specifications that are, IMHO, continuing 
to cause confusion by insisting on unfamiliar terminology.
Unfamiliar to whom?
The vast majority of engineers, including those implementing 
technologies such as HTTP and URIs. By using such confusing abstract 
terminology, these specs contribute to the less than perfect 
interoperability that has plagued the Web for the past two decades.
Let's agree to disagree on this. But it would be interesting if you 
could back up that claim. In particular, how does the terminology choice 
you are disagreeing with cause interoperability problems?

When implementors don't understand the terms used in a specification, they 
start assuming what it means. When faced with two terms that for all 
practical purposes mean the same thing as here, they start inventing 
differences to justify the spec text in their mind. I've seen this over 
and over again.


Adrien de Croy - WinGate Proxy Server - http://www.wingate.com