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

On Tue, Mar 1, 2011 at 5:13 AM, Nathan <nathan@webr3.org> wrote:
> 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).

Yes, interesting that Roy is trying to inject more of REST into the
spec. I don't think anything like this is in 2616 (or in 2116 for that
matter :)).  Good luck to him.

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

yes

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

Um, no, I wouldn't say this.  I'd say that the resource has a state,
or is in a state. I also like to use the word "condition" (maybe like
a book whose pages become dog-eared). But the representations only
reflect or represent, or stand for, the state, they are not themselves
the state. Maybe if you had 'complete' representations you'd be able
to reconstruct the state.

My model of PUT is that it directs the server to force the resource
into a state that has the given representation as one of its
representations.

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

ah so *that's* what you mean by "conceptual".  This is what I've been
calling a "denotational model" - an interpretation where resources are
taken to be functions.  Sort of like David's request/response function
model.

FWIW I take the position (privately I suppose since I've never heard
anyone acknowledge me when I say it) that the choice between
simultaneous representations is made by the server, not by the
resource. This is my feeble attempt to reconcile sessions with Roy's
account. In REST there is a 'value' (representation) specific to each
session, but it's the server, not the resource, that is responsible
for routing the correct value to the correct session, based on
matching request properties (and context, maybe IP address) to
response characteristics (tags that say which session they belong to).

It's kind of a twisted theory I suppose so take it or leave it.

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

hmm, I don't see this.  Nothing in Roy's account would rule out the
resource being a mynah and the representation being a live audio feed
of it, as far as I know. This was one place where Roy and TimBL
disagreed.

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

Similar to my 'exchange invariants' and 'metadata properties' (which
is probably a bad name).

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

To repeat, this depends on a particular interpretation of 'reflects
the state of'. A thermometer display shows information that 'reflects
the state of' its ambient space, but is not an IR in the TimBL sense.

If you're looking for evidence in Roy's writings that TimBL is 'right'
I doubt you'll find it. And if you do, Roy will probably say he made a
mistake.

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

information is hard to define.  'copyable without loss of identity'
maybe figures in there somehow.

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

Right, this is what I mean by "making the world safe for metadata".
Thanks for listening!

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

Natural, yes, consistent with TimBL yes, but forced by anything Roy
says, I doubt it.

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

It's all just theories invented by people who are often pigheaded
and/or muddlebrained, so the test is whether it's predictive of
anything or good for any concrete purpose.

I've pondered the question "are IRs required, by any practical
concern, to be lacking momentum" and so far I've found nothing that
forces this. The audio channel to a mynah as partial 'representation'
of the bird's state seems unpleasant but I can't figure out why the
mynah being an information resource has to be ruled out. (Compare also
to FRBR 'expressions' such as dance performances.) (And note that the
audio information is not a *description* of the bird or its state!!
It's attributable to the bird, not to a describer. So I *do* rule out
the representation=description idea - it gets assignment of authority
and responsibility wrong.) In this way I'm less radical than TimBL.
His argument against momentum is based on mental hygiene, which is
good enough for me personally but I think it will be difficult for a
skeptic to swallow.

Good work... we're getting there.

Best
Jonathan

> Cheers,
>
> Nathan

Received on Tuesday, 1 March 2011 13:01:50 UTC