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
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
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.
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 .
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