the mistake I made! - was Re: proposed change to a spec

Jonathan Rees wrote:
> Nice try, Nathan, but I'm with David here. I think we have to assume
> that a large amount of metadata has been deployed in good faith that
> would only be true if representations were allowed to reflect
> *partial* state.

(any time I say resource here, i mean REST resource)

coming back to this, I can see a flaw in my thinking before, dawned on 
me last night.

I'd perceived a REST resource as mapping to a set of values over time, 
where the value at any given instant was the current state of the 
resource, and that state/value could be captured in a set of one or more 
representations, subject to negotiation.

I said, "REST maps a resource to a set of values over time, each single 
value has a 1:N relationship with representations." and "A resource 
representation is a realization (copy/instance) of the state of that 
resource".

To illustrate, in the case of RDF, I'd say that a REST resource mapped 
to a set of values over time, at any instant the value (state) is an 
abstract set of rdf triples, which has a 1:N relationship with a set of 
representations (realizations of that value, a chunk of turtle or 
rdf/xml etc).

See what I did there? the value/state of the resource at time t is some 
abstract value/state which you can get a representation of.

Now, here's what REST /actually/ says:

   REST Resource:
   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.

   (ignoring resource identifiers for the moment)

The values in the set are /the representations/ and not some abstract 
value or state.

Now here's what HTTP-bis say on resource representations:

    A "representation" is information in a format that can be readily
    communicated from one party to another.  A resource representation is
    information that reflects the state of that resource, as observed at
    some point in the past (e.g., in a response to GET) or to be desired
    at some point in the future (e.g., in a PUT request).

Why reflects? well it's reflects because in the case of GET 
representations can be conneg'd, subject to the capabilities of the 
agent, over language, auth*, or media type or suchlike - hence "which 
are equivalent" - and in the case of PUT, it's reflects because you may 
PUT a jpeg but the server will be able to send back the same image in 
gif or png or a different size.

So, I reiterate, for something GETtable the values in the set are the 
representations, it maps to a set of representations over time. The 
current state, or the value, of a REST resource is *the representation* 
which *you* GET.

This is a whole lot simpler then I'd thought for a long time, but it 
makes perfect sense, all you ever get back is a representation, the only 
thing the GETtable URI can possibly refer to (technically) is the set of 
representations.

When you look at a it over time, a resource is a conceptual mapping over 
time to the set of representations - conceptual because it depends on 
ones perspective, "/my-account refers to details of my account" for an 
account holder, and for the developer it refers to a process which shows 
users their account details, for one user it's an admin account, for 
another it's a restricted account, and so on.

Since a resource maps to a set of representations over time, and since a 
representation "is information in a format that can be readily 
communicate from one party to another", it can only ever refer to 
information over time.

"Information Resource" = that which remains consistent, or is reflected 
by, a resource's representations over time.

So I conclude, again, that a GETtable URI can only ever refer to 
information about a toucan, and not a toucan.

A representation is not a representation of X, it's a representation of 
  information (even useless information like a random bit), information 
in some format, where information is used loosely to mean potentially 
machine readable data in some format.

Step in RDF, it is critical then that RDF can describe the web, so that 
somebody can say "<u> refers to the weather forecast of Oaxaca", 
otherwise everybody has to guess, or repeatedly GET <u> to see what 
remains consistent over time.

Thankfully, it seems to me at least, that because GETtable URIs simply 
map to representations of information over time, then it is just 
naturally so that GETtable URIs refer to information resources and not cars.

*crosses fingers* - /please/ tell me the above just "is" the way things 
are and makes sense / is agreeable?

Cheers,

Nathan

Received on Tuesday, 1 March 2011 11:15:24 UTC