Re: yet another resource/representation diagram

On Mar 9, 2009, at 11:18 AM, Alan Ruttenberg wrote:

> Some comments:
>
> 1) There are several relations used:
>
> has part
> has temporal part
> is encoded by
> carries
> responds with
> provided via
> stores/is faithful to
>
> It would help if there was some elaboration of what these mean.
> Domain/Range would help, and a definition, or at least gloss for each
> of these.

Agreed

> 2) "Concrete network data object" is not helpful, except perhaps as
> the target of some AKA. Unless it is completely defined in terms of
> the others. In which case it would helpful to know if so, and which
> other things are dependent in this way.

Examples: a file in a file system; a portion of the state of a router.

My "concrete"/"abstract" distinction is supposed to be based on physical
contingency: it is possible to destroy a concrete thing (e.g. by  
burning it),
but not an abstract thing. I'm probably using the wrong word here. We
could say generic/specific if we were in BFO land, but we're not.

> 3) The link between "response from service" and "network service"
> doesn't have a label. Also, what is the different between a solid line
> link and a dashed line link?

Dashed line is suggested by a convention in category theory, although  
I'm
not using it really in the same way... it's just meant to say that  
there's a theorem
to be proven, in the event this turned into a system that admits any  
theorems,
that the diagram commutes.
>
> 4) I'm a bit dubious about the time varying information thing. I think
> there are series of information things non-time-varying, and certain
> kinds of processes that group such together. These processes are
> different enough that I don't know how informative it is to talk about
> the time varying thing on its own.

It figures prominently in Tim's account, so I would like to keep it  
until
such time as Tim no longer feels he needs it.
>
> (there may be other issues, but these are the ones that come to mind
> immediately. FWIW, it does seem to be heading in the right direction)

Thanks
>
> -Alan
>
> On Sat, Mar 7, 2009 at 3:21 AM, Jonathan Rees  
> <jar@creativecommons.org> wrote:
>> 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].
>>
>> 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
>>  - REST is very similar to David's ftrr - difference lies in  
>> treatment of
>> request headers (e.g. User-agent)
>>  - a REST resource, or ftrr, commits at each time to some  
>> particular set of
>> representations
>>  - 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.
>>  - 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
>>  - 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
>>  - 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?)
>>  - not clear whether two distinct GRs can correspond to the same REST
>> resource. I think not since then they would have incommunicable  
>> 'essential
>> characteristics'
>>
>> Please don't jump on my terminology... it's easily changed. The  
>> main point
>> is that the four theories are about different kinds of things with  
>> different
>> identity criteria, but they can be related to one another in a  
>> sensible way.
>>
>> I think it's important to understand this story well before  
>> attempting to
>> answer any questions about "identification".
>>
>> Jonathan
>>
>> [1] http://www.w3.org/2001/tag/awwsw/jar-diagram-3.pdf
>> [2]
>> http://esw.w3.org/topic/AwwswHome?action=AttachFile&do=get&target=URI-representation-resource-unified.pdf
>> [3] http://www.w3.org/DesignIssues/Generic.html
>> [4] http://www.ics.uci.edu/~fielding/pubs/webarch_icse2000.pdf
>> [5]
>> http://www.w3.org/mid/184112FE564ADF4F8F9C3FA01AE50009FCF22AD676@G1W0486.americas.hpqcorp.net
>> [6] http://www.ietf.org/rfc/rfc2616.txt
>>
>>

Received on Monday, 9 March 2009 21:11:34 UTC