Re: yet another resource/representation diagram

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. You can omit 'has part', since there is a reasonably
standard definition for this.

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.

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?

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.

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

-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 15:19:26 UTC