Re: Terminology Question concerning Web Architecture and Linked Data

On Jul 22, 2007, at 9:00 AM, Richard Cyganiak wrote:
> I think Roy's abstract model from REST goes something like this: A  
> resource (these days we should say: information resource) is a  
> function that maps a request Q received at time t to a  
> representation R. If this function is the same for two information  
> resources, then they are the same resource.

That last sentence isn't quite right.  If the function is the same then
they are the same resource from the point of view of all of the other
actors within the system.  The resource owner may have a different
opinion, but that opinion simply isn't observable to those accessing
the resource (and therefore irrelevant to the run-time architecture).

> So the function can return different representations at different  
> times, and it can return different representations at the same time  
> for different requests (content negotiation).
>
> And it's important to remember that this function is an  
> implementation detail of the server. We cannot determine the  
> function by inspecting the resource through its HTTP interface,  
> because for that we'd have to be able to travel through time.
>
> This means that only the resource owner can determine if two  
> information resources are the same.

The resource owner can publish assertions about resource equivalence,
though even resource owners can't really predict the future.  It isn't
intended to be a hard and fast rule.  The purpose of the definition of
resource is to help people understand the relationship between making
reference to a thing and later accesses to that thing.  Most people
just assume that all URIs identify a static file of bits, even when
they are doing something that obviously doesn't conform to that mental
model (like writing a script that handles an entire URIspace in
a programmatic way, or linking to a feed URI).  It was very hard to
explain to folks that what matters is what the link author intends
by the reference, not what the link resolves to at any given moment
in time.

REST is a model for network-based hypertext systems.  That was an
intentional limitation, since I couldn't possibly compare the
performance impact of the given constraints without a domain upon
which to base the comparison.  I honestly don't care whether people
think of that as the scope of information resource or some other
limitation.  I was certainly aware of resources that had no
representation -- Tim talked about it back in 1994.  Those resources
simply did not matter to the model since they did not contribute to
the Web as hypertext.

> I think Roy's work is by far the best and definitive account of the  
> things we now call information resources. But it does *not* account  
> for any of the new stuff we're doing with URIs these days. Web  
> architecture has evolved since Roy wrote his thesis. Unfortunately,  
> many REST proponents are still stuck in the pre-httpRange-14 past,  
> and are likely to remain there for a few more years.

Thanks, but what is this "stuff we're doing with URIs these days"
that is not accounted for within the REST model?  The httpRange-14
debate was intense because the original question was wrong -- that
HTTP should be limited to addressing documents.  We spent several
years butting our heads on what was essentially a poorly worded
question, and the answer was obvious once the goal of asking the
question was considered instead of the question itself.  I remember
suggesting redirects many times, but it wasn't until I explained
how the 303 (see other) code works [which I changed the definition
of back in 1995] that we finally had an answer that would satisfy
everyone's application.  303 is the RESTful answer -- a way of
indicating that the unrepresented resource exists while indirectly
continuing the conversation.

BTW, I would really appreciate it if people would stop defensively
lumping "REST proponents" into some category that assumes that a
bunch of individuals speak with one voice.  Most REST proponents
started out as critics, and each has their own perspective on why.

....Roy

Received on Monday, 23 July 2007 03:24:36 UTC