Re: superimposing the Fielding and TBL architectures

Pat's comments about resource state reminded me that I meant to make
another comment about the diagram:

Regarding the "records the current state of" relation, are you
intentionally omitting the effects of the request inputs?  In general,
the result of an HTTP GET request (for example) depends both on the
resource state *and* on information in the request.  Most obviously this
would include things like language and media type preferences, but the
specs are clear that the response can actually depend on anything in the
request.

I suggest omitting the "records the current state of" relation.  You
already have the "has 3986-representation" relation going the other way.

David



On Tue, 2011-09-27 at 12:56 -0400, David Booth wrote:
> On Tue, 2011-09-27 at 12:01 -0400, Jonathan Rees wrote:
> > Mulling over designs for httpRange-14(a) opt-in, I made a picture
> > (attached), just for fun, that superimposes the Fielding/3986
> > architecture with the TimBL architecture.
> > 
> > What stands out is the common ground: There is general agreement on
> > what constitutes a correct retrieval operation using a URI. The
> > agreement derives from the RFCs and from server and client behavior.
> > This is invariant as we modulate theories of what the resource is and
> > what "is a representation of" means.
> > 
> > In the Fielding architecture the resource is unconstrained. I can give
> > you a bunch of different resources, and then when you challenge me to
> > prove that there is a resource with those Fielding-representations, I
> > can cook up any story I like, post hoc, and you'd have no way to prove
> > me wrong.
> > 
> > In Tim's architecture the resource is determined, modulo usually we
> > probably don't care about, by what the correct retrieval results would
> > be. Once those results are determined, there's no choice as to what
> > the resource is. Contrariwise, if the server side commits to what the
> > resource is, we can hold them to it by checking any
> > TBL-representations that they deliver.
> 
> I don't know what you mean by saying "the resource is determined".  It
> seems to me that the key difference (in this regard) between Tim's view
> and Roy's is that Tim's view attempts to distinguish "information
> resources" from other resources, and the "has TBL-representation"
> relation only holds with information resources, whereas Roy's view has
> no need for such a distinction: *any* resource can have a
> wa:Representation.
> 
> 
> > 
> > httpRange-14(a) opt-in would be a statement or protocol element that
> > says that the URI Fielding-identifies the generic resource (i.e. the
> > same thing that it TBL-identifies).
> 
> But then what would be the difference between a wa:GenericResource and
> an rfc3986-resource?  For example:
> 
>   :u a xsd:anyURI .
>   :x a wa:GenericResource .
>   :x :is-TBL-identified-by :u .
>   :y a :rfc3986-resource .
>   :y :is-rfc3986-identified-by :u .
> 
> What is the relationship between :x and :y ?  Are they the same thing?
> 
> And does there exist a :rfc3986-resource :z such that :z has a
> 3986-representation but :z is *not* a wa:GenericResource?  Or does the
> mere existence of a 3986-representation imply that :z is a
> wa:GenericResource?   (I.e., can there be a non-IR that has a
> wa:Representation?)
> 
> My own view is that the existence of an authorized wa:Representation
> implies that the resource is a wa:GenericResource (or IR).
> 
> David
> 
> > Nothing much new here, pretty much what Pat has said in different
> > words (although I put less stock in "access" and more in social
> > agreement over what would constitute correct access were it to occur).
> > Just noodling.
> > 
> > Jonathan
> 

-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Tuesday, 27 September 2011 22:36:48 UTC