Re: yet another resource/representation diagram

By the way - I forgot to credit Larry Masinter - he has also helped me  
with this puzzle.

On Mar 7, 2009, at 6:42 PM, Booth, David (HP Software - Boston) wrote:

>> From:  Jonathan Rees
>>
>> Inspired by some comments Henry made about conneg at the recent TAG
>> meeting I've made a third diagram to attempt to fit the conflicting
>> theories together; see [1].
>
> Thanks for doing this work and creating this diagram.  I'm trying to  
> digest it, but one thing I'm running into is that a couple of the  
> arrows are not labeled:
>
> - from 'Boothian "ftrr"' to 'Encoding of information thing';

This would be something like "has, in its image" (i.e. the encoding is  
in the image of the ftrr)

> - from 'network service (a la 2616)' to 'Response from service'

This would be a provenance relation like "generated" or "said" (i.e.  
relation between the response and the service is that the service  
generates the response; HTTP is just one possible transmission path).

Sorry, I thought these were obvious.
>
> What relationships were these intended to be?
>
> I liked the attempts in Michael Hausenblas's diagram[7] to indicate  
> subclass relationships between the classes, as I thought they added  
> a lot toward understanding the classes.  Might subclassing be added  
> to yours?

Yes, that's a good thing to do, and earlier I've done that with open- 
arrowhead arrows (a la UML). But a priori I see no need for any  
subclassing in this diagram. The only candidates I spot are "not time  
varying" a subclass of "[potentially] time varying" and "encoding" a  
subclass of "not time varying". I could go either way on this but  
would assume no subclassing until the need is demonstrated (e.g. via a  
need for common or generic properties).

("Time varying" really should be "potentially time varying", since  
there is in general no way to know whether something varies over time.  
Sometimes you know, and that's good, and sometimes you don't, and  
that's not terrible.)

The subclassing in Michael's diagram is either trivial (everything is  
a subclass of Resource) or not well supported (there's no consensus on  
what an "information resource" is).

If you added new boxes to my chart, e.g. if you placed your favorite  
"information resource" definition in it, you might find new subclass  
relationships.

>> This is a bit more focused than diagram #2 [2], and it no
>> longer talks
>> about URIs, just the things that might or might not be named.
>>
>> The boxes are classes and the arrows are properties that might hold
>> between members of the classes. 3D boxes are for things that have a
>> time dimension of any kind.
>>
>> The theories to be reconciled are:
>>   1. TimBL "generic resources" [3]
>>   2. REST [4]
>>   3. David Booth ftrr [5]
>>   4. HTTP [6]
>>
>> I think the overall diagram makes a plausible story.
>>   - a single GR doesn't "know" (commit to, model) what
>> representations are associated with its states
>
> One thing I notice about the GR description in [3] is that in  
> comparing GR to ftrr[5], GR does not seem to describe any way for  
> representations to depend on request inputs other than those that  
> might select different languages or content types.

I agree. Fielding&Taylor has the same property. This is why I didn't  
equate (or make isomorphic) ftrr and REST resource. There would be a  
projection from ftrr down to REST based on each fixed choice of  
headers not accounted for by REST.

>>   - REST is very similar to David's ftrr - difference lies in
>> treatment of request headers (e.g. User-agent)
>
> What difference do you mean?  AFAIK ftrr corresponds very closely to  
> REST.

I assume that user-agent is not a property of a REST (F&T)  
representation. Obviously it could be. Relative to the other issues we  
are dealing with this seems a minor modeling quibble.
>
>>   - a REST resource, or ftrr, commits at each time to some
>> particular set of representations
>
> Yes.  As I pointed out in [8]: 'If you take Roy's definition to be  
> essentially "a function from time to representation sets", then the  
> ftrr:IR definition is pretty much equivalent to Roy's definition.   
> The function in Roy's definition is pretty much a curried[9] version  
> of the function in the ftrr:IR definition.'

I'd have to look at the details. I thought the F&T membership function  
used the headers as a key to select among the set of available  
representations. If the representations cover all possible  
combinations of header values (an infinite set) then this works, but I  
doubt that this is the intent. The way I read it was that things like  
User-agent: and Link: would simply be unable to influence the choice  
of representation in F&T - that is, this aspect of real-world servers  
would go unmodeled in this model.

If we get to the point where we have to settle this kind of detail,  
we'll certainly have succeeded! Our important issues all lie at a much  
coarser level of analysis.
>
>>   - thus there many REST resources that are all "faithful" to a
>> single GR in the sense of delivering valid representations of
>> the GR's
>> states. Different granularity or identity criteria for the
>> two classes.
>
> Not sure what you mean here.  Are you pointing out that some REST  
> resources may be more coarse grained versions of a single GR?
No, the opposite
>  But that would also be said of GRs in relation to other GRs --  
> different granularity of "genericity" -- so I don't know what point  
> you're trying to convey here.

You know, I might be confusing "generic resource" with "abstract  
document". I'll have to reread Tim's document... although note that I  
say "akin to", not "same as". By "time invariant information thing"  
I'm thinking of something like a single resource "Moby Dick" for which  
there may be many ftrrs (or HTTP response sources), each one different  
from the other, distinguishable by which particular representations  
they encompass (or deliver). By "time varying information thing" I'm  
thinking of something like the Oaxaca weather report.

>>   - GRs and REST resources are not inherently physically embodied
>>   - REST and ftrr are Platonic ideals (models) of hypothetical or
>> real response sources
>>   - HTTP response sources are physically embodied, thus very
>> different from both GRs and REST
>>   - but an HTTP response source can be "faithful" to a GR or a REST
>> resource by implementing it correctly
>
> Hmm.  I see the difference between a hypothetical response source  
> and an actual response source -- essentially the difference between  
> saying "there *might* be one" and "there *is* one" -- but I'm not  
> entirely convinced that an HTTP response source should not also be  
> viewed as a Platonic ideal, since the protocol definition doesn't  
> care at all about real things, it describes a model also.  Even the  
> notion of "server" in RFC2616 seems to me like a Platonic ideal.

This is a modeling issue. I'm defining an HTTP response source to be  
something that's physically embodied. Otherwise is would be a source  
of responses. The diagram already has places for models  
(idealizations) of response sources - that's what ftrr, REST, GR, etc.  
are about. We know that web servers are real things - if I go to my  
basement and power mine off, it turns off, and so on. When I talk  
about it there is some amount of modeling going on in our heads, but  
that's just what happens in *any* communication and so doesn't deserve  
attention.
>
> Why do you see this notion of Platonic ideal as being an important  
> differentiator?

Three is different from three particular oranges. The distinction is  
just part of the way people think, talk, and reason. The things you  
say about physical things are different from the things you say about  
mathematical or "Platonic" things. Physical things are contingent -  
any statement you make about their future is hypothetical because you  
can't predict the future. But nothing can alter 5+3=8, or historical  
fact. Those things are not hypotheses. Yes, truth is unknowable,  
knowledge doesn't exist, etc. etc. You don't need to get into that  
quagmire in order to do logical models.

I don't want to get into the philosophy of language. I think it is  
probably not possible for us to agree on it. If you don't like what  
I've just said, then instead of getting philosophical we should take  
this to be *my* model of the system we're studying and then we can  
develop it together and ask whether it is a useful one (helpful for  
expressing what we know, teasing apart paradoxes, and making  
inferences that can be tested).

Clearly one may define one or more relations between response sources  
and ftrrs. Maybe you could think of an ftrr as being the "trace" of  
some particular response source, much as a recording hygrometer  
produces a record of what the humidity has been, or rather the way a  
climate modeler speaks of rainfall over time (both past and future).  
That would be an interesting exercise. (Clearly I am being vague about  
exactly how an "HTTP response source" should be modeled, but I want to  
stay away from pinning it down for now and look more generally at the  
rest of the diagram and how the "spokes" relate to one another.)
>
>>   - an HTTP response source can do all sorts of things that are not
>> modeled by GR or REST, such as deliver 3xx, 4xx, 5xx responses
>
> Yes, it clearly is a different beast.  It has broader functionality  
> than ftrr, GR or REST, and is used to *implement* them.

yes. as in the way a calculator implements addition. Or one might say  
that the calculator is a model of addition, or even that addition is a  
model of the calculator.
>
>>   - RFC 2616 permits resources that are "network services" - it is
>> not natural to talk about these having 'states' or
>> 'representations' -
>> not clear whether such services a REST resources at all - I don't
>> think they should be considered so (service: random number
>> generator,
>> webcam, database query?)
>
> I don't find the term "network services" when I search RFC2616.  To  
> what section are you referring?

1.3 "network data object or service" and 9.3 "data-producing process"

Received on Sunday, 8 March 2009 15:02:18 UTC