Re: superimposing the Fielding and TBL architectures

On Tue, Sep 27, 2011 at 12:56 PM, David Booth <david@dbooth.org> 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".

What I mean is that you know its properties of interest, or at least
have ways to determine, judge, or assess them. "is determined" was a
loose manner of speaking, sorry, although in fact I don't know what
the difference is between knowing what something is, and knowing
properties adequate to distinguish it from other things.

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

I don't think so. I think the key is that Tim's view lets you look at
the representation cloud and determine properties of the referent, and
contrariwise infre properties of representation by inheritance from
the generic resource that is the referent. The "information resource"
distinction is as we have said (and I though agreed) over and over
again is totally a red herring. It has nothing to do with types, and
everything to do with which resource is meant.

I also think Tim's view is not captured by httpRange-14(a) since
httpRange-14(a) doesn't say *which* information resource the URI
refers to.

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

There is not enough information to determine this, but it is
consistent with saying that :y is a toucan, and :x is a document about
a toucan.

> And does there exist a :rfc3986-resource :z such that :z has a
> 3986-representation but :z is *not* a wa:GenericResource?

yes, the toucan

>  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?)

That's my whole point. 3986/Fielding supports the Ian Davis view - or
at least is not inconsistent with it.

> My own view is that the existence of an authorized wa:Representation
> implies that the resource is a wa:GenericResource (or IR).

Sure, that is just your view, and it is a consequence of
httpRange-14(a), and it is an outcome I would desire, but it does not
follow from the RFCs, is not consistent with Roy's REST writings, and
is not true given the way Ian and his customers use URIs.  If it did
follow from the RFCs there would have been no need for the
httpRange-14 resolution, and it would be easier to get consensus on
it.

Jonathan

> 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 Wednesday, 28 September 2011 12:54:51 UTC