W3C home > Mailing lists > Public > public-awwsw@w3.org > January 2008

RE: Example for consideration: Resource versus Representation

From: Williams, Stuart (HP Labs, Bristol) <skw@hp.com>
Date: Wed, 23 Jan 2008 14:07:47 +0000
To: Alan Ruttenberg <alanruttenberg@gmail.com>, "public-awwsw@w3.org" <public-awwsw@w3.org>
Message-ID: <9674EA156DA93A4F855379AABDA4A5C61194EE3463@G5W0277.americas.hpqcorp.net>

> -----Original Message-----
> From: public-awwsw-request@w3.org
> [mailto:public-awwsw-request@w3.org] On Behalf Of Alan Ruttenberg
> Sent: 23 January 2008 04:34
> To: public-awwsw@w3.org
> Subject: Example for consideration: Resource versus Representation
>
>
> Are representations resources?

Grudgingly... they can be... but (see below) they are generally not the things that are identified (denoted) by the URI used in a retrieval operations that give rise to them. On the whole I don't think it is helpful to think of representations as resources - but you can do it if you must.

[ASIDE: I think there is an interesting duality between the illusion of a direct resource manipulation (eg. the web) created on top of a message passing system; and the illusion of a message passing system created by direct resource manipulation (eg memory based linked list message queues). Ironically you can go further by considering computer bus cycles as message exchanges...]

Roy Fielding's model of a resource which is the basis used in AWWW is probably most succintly expressed in [1]

        "The key abstraction of information in REST is a resource.
        ...

        More precisely, a resource R is a temporally varying
        membership function MR(t), which for time t maps to a set of
        entities, or values, which are equivalent. The values in the set
        may be resource representations and/or resource identifiers.
        A resource can map to the empty set, which allows
        references to be made to a concept before any realization of
        that concept exists - a notion that was foreign to most
        hypertext systems prior to the Web [14]. Some resources are
        static in the sense that, when examined at any time after their
        creation, they always correspond to the same value set.
        Others have a high degree of variance in their value over
        time. The only thing that is required to be static for a
        resource is the semantics of the mapping, since the semantics
        is what distinguishes one resource from another."

[1] http://www.ics.uci.edu/~fielding/pubs/webarch_icse2000.pdf

Roy's point is that the resource is this membership function over all time. I'd also note (which I have previously missed or lost sight of at times) that URIs are not a parameter of that function. ie. in this formulation there is a mapping (dereference) from URI to resource (membership function) and thence from membership function and time to a set of equivalent entities or values. The implication here is that the resource associate with a URI can change without changing the resource - infact given that the defn of resource is scope over all future time it's simply not possible for a resource to change (hmmm... predetermination or self will!)

My reading is that the "set of entities, or values which are equivalent"  at an instant is a set available resource representations (values) or variant resources (entities) which may be content-negotiated between - but are equivalent wrt to the creator/author/deployers notion of the particular resource is.

> I have heard the argument that they are not. In this
> morning's call I agreed to send an example I've been thinking about.
>
> Consider some Information Resource that responds to a request
> with a Representation of type application/pdf. I save the
> response on my hard disk.

> Is the thing I have (henceforth known as the file) on my hard disk an Information Resource?

Yes... though that of course is an abstraction induced by software working on an arrangement of polarised magnetic domains on a spinning ferro-magnetic platter.

> If it is, when and how did it become one, having been only a
> Representation until recently?

So this representation word here is tricky. You could be referring to a bitsequence which is characteristic of all messages that convey the same bit sequence - in which case it is (perhaps) a 'type' or you could be referring in a particular, ephemeral message, exchanged between an origin server and your web client - ie. (perhaps) a 'token'.

I think that you could, and probably, would argue that instances of both of these are 'things' and hence eligible to be thought of as resources. The point that I'm trying make is that either way, neither is of them is the resource originally referred to.

Anyway... taking representation as message (token) then the message was used to create a new resource on your local file system - you did that when you saved it - and it is a different resource because properties like when it was created, last accessed, last access by etc. will be independent of the original resource.

Taking representation as a characteristic bit sequence (type) - well I'd say that was something abstract of which you could have exemplars - the exchanged (response) message being one and the original resource being a factory of such exemplars (at least for a period of time). The exemplar is then again used as a means to create a resource when it is saved.

> If not, what happens when I move the file to a directory (actually, I don't move the
> file, I make changes to directory structures) that my Apache
> server can serve from?

Well I answered yes on the first clause... nevertheless you appear to have moved a resource within an information space of some kind (your filing system) and intentionally or otherwise made it visible on the web (or possibly if you copied rather than moved... then created yet another 'similar' resource).

> Can my server respond to requests for Representations?
> If not, how should it avoid serving this file?

There's no techincal reason why it couldn't.

> If the server answers requests only about Resources and
> is willing to serve the file then the file must be a
> Resource.

s/serve the file/serve representations of the file/

but we're not arguing over whether the file is a resource.

> If it is, same question: When and how did it become a Resource, having only
> recently been a Representation?

Same answer... when you saved it...

> It was suggested that perhaps Resources were only Resources
> if they were identified by a URI.

FWIW I was probably the one that came closest to saying that on the call.

My take is that the URI of the original reference identifies the file 'thing' (on the origin server) (which absent other knowledge could change state in the future, and may have had different state in the past) and *not* either the bit-sequence (type) of the response or the particular (http response) message instance (token) transferred on the wire.

Those things, type or token, can be resources. You could choose to assign them a URI; having done so, you could choose, to deploy them on the web such that representations of their state are available.

In the case of representation as type, then for such a resource (ie. a type) then I might concede that any representation retrieved from it must be typed by the resource itself - which I think would necessarily make the resource invariant over time. But... if there is a possibility of future change - or the experience of historic change the resource cannot possibly be the given bitsequence (type).  Alternatively, you might choose to think of any single representation, time invariant resource, as such a type and of there being an identity relation between resource and representation in the case of such types.

Larry Masinter's "TDB and DURI" URN namespace internet draft [1] is interesting and relevant in that it proposed a way to refer to the state of a resource (DURI) or thing described by a resource (TDB) at the first instant of some epoch - regardless of subsequent change in resource state - albeit with no-guarantees of a retrievable representation.

[1] http://larry.masinter.net/duri.html

> However this statement
> generated some controversy, so at least this is a point we
> should resolve.
>
> -Alan

Regards,

Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England
Received on Wednesday, 23 January 2008 14:10:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 July 2008 07:55:27 GMT