Re: homework assignment as interpreted by JAR

On Apr 16, 2008, at 12:29 PM, Williams, Stuart (HP Labs, Bristol) wrote:

> Hello Jonathan,
>
> I think that what the URI dereferences is also the information  
> resource ie. it dereferences what it denotes. Much as in C the  
> dereference on a pointer, eg (*p) can appear either side of an  
> assignment operation. Although GET is often spoken of as  
> 'dereference' I would say that all of GET, PUT, POST, DELETE  
> involve dereference which (though operationalised by the HTTP  
> protocol in the case of HTTP) is conceptually moving to the other  
> end of the pointer (finding the fielding/taylor mapping function  
> that models the resource).

I think you are pointing to a way in which my usage, which follows  
AWWW, is wrong. There are two operations here: you figure out what  
the URI denotes (the server "dereferences" or "dedenotes" the URI to  
obtain an IR), and then given the the IR, you select a representation  
of the IR's state to deliver to the client. It is the composition of  
denotes and is-representable-by that should label the arc from the  
URI to the Value. Something like "would have as a correct GET  
response" might be closer.

AWWW says:
	Dereference a URI
	Access a representation of the resource identified by the URI.
-- Perhaps I could say "awww:dereferences" instead of  
"dereferences"... (just kidding)

> I think that's important because as it's currently drawn, what  
> appears to be dereferenced is one of the representations available  
> at the given instant that the HTTP operation occurs - which leads  
> us back into "the URI identifies" the representation given the  
> confusion around word senses of "identify".

Not what I meant - if you put the source of the arrow, the arrow  
label, and the label destination in a row then the diagram says that  
a URI dereferences (at time t) to a Value. If the diagram commutes  
then that Value will be a representation of the state of the IR  
denoted by the URI.

As for "identify" I would say that a server can use a URI to identify  
which IR, among the ones it knows about, should be the one to have  
one of its current state's representations returned. The URI both  
denotes and identifies the IR. I agree with Pat, I think.

> The taylor/fielding value cloud is just a way of modeling an  
> information resource over all time - it's a way of flattening it  
> into an invariant construct (it becomes meaningless to talk about  
> the resource changing over time (though its state may) - if it  
> changes then it is a different resource - because such change would  
> entail a different future or a different past).

Wait, let's be careful. The value cloud is not a model of the IR, but  
rather a model of the way it's served. To call it a 'model' of the IR  
would be inaccurate in the mathematical sense since there will be  
true statements about the IR that can't be mapped to true statements  
about the value cloud. The IR knows things that a faithful value  
cloud might not; for example, you could have an IR that's a 2000 dpi  
image (or perhaps even a continuous-space image), while all the  
values in the value cloud are only 400 dpi. Conversely, the IR  
doesn't specify the value cloud; there could be many value clouds  
faithful to the same IR (as we agreed on the call). So neither makes  
a good model of the other.

The Taylor/Fielding paper defines 'resource' in several different  
ways, and the definitions are mutually inconsistent. The formal  
definition coincides with what I've called the value cloud. The  
informal definitions (e.g. "Any information that can be named can be  
a resource") are closer to awww:information-resource.

> It is not the intention to say that the information resource is  
> actually organised that way as an implementation - just that it  
> will be in states over time and that those states are projected of  
> a moment as sets of awww:representations, one of which is provided  
> in response to a GET operation using the relevant URI.

I agree. The paper is about a software architecture, and I think he's  
saying that if your systems are designed and implemented consistently  
with the formal model (as elaborated in the paper), you'll be RESTful  
and reap the benefits. To equate the formal model and the informal  
notion is just a bit of sloppiness that will not throw off people who  
are more clever than I am.

The value cloud, even though it's not an IR, is still a thing (as is  
the network endpoint) and we might want to write about it in RDF,  
e.g. if we were trying to reason about how well a system implements  
the REST model. All of these things, including IR, representation,  
information-resource, and network endpoint, are abstract models of  
various real world phenomena. To get clarity we have to figure out  
the relationships among these models and between the models and reality.

The value-cloud is not an essential part of the picture. I only put  
it there because I wanted to understand Fielding & Taylor, to make  
sure my understanding of F&T matched that of others, and to  
articulate an example of something that IRs are *not*.

Jonathan