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

Hi Jonathan,

in-line and snipped as usual :)

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

Okay, I've held both positions and came to the same IRs exists we need 
httpRange-14 you can't name a toucan with a GETtable URI conclusion. 
It's nice that we can say both positions tersely now (or I can see them 
simply that is, and the difference between).

One good/key point, is that with both ways of looking at this, both mean 
that the toucan use case conflicts with "real" web arch - fair comment? 
and either one is just "the story", or perhaps we can have two stories, 
were both come to the same conclusion.. works for me.

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

yup, that's fine with me two - either one works and brings the same net 
result afaict - let's make sure the ir-axioms fits them both and we're 
sorted (?).

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

that's one view of conceptual :) the other one is the conceptual IR 
which has a state - both compliment / work imho, and a third weirdy one 
is the RWO which has a state which is reflected (the toucan view).

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

yes, I agree and acknowledge it too, the request goes to the server, 
only the server can ultimately choose - if it were the other way round 
the server would have to send several representations in one go, and let 
the client choose. Consider it acknowledged and agreed with, by me at least.

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

makes perfect sense to me, and matches certainly every I know of REST 
and HTTP.

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

That's what I thought too, until I looked hard and found that (imho) 
there's a contradiction in REST in 5.2.1.1 where ambiguity has crept in.

   The key abstraction of information in REST is a resource. Any
   information that can be named can be a resource: a document or image,
   a temporal service (e.g. "today's weather in Los Angeles"), a
   collection of other resources, a non-virtual object (e.g. a person),
   and so on. In other words, any concept that might be the target of an
   author's hypertext reference must fit within the definition of a
   resource. A resource is a conceptual mapping to a set of entities, not
   the entity that corresponds to the mapping at any particular point in
   time.

   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.

Note, "a resource is a conceptual mapping to a set of entities" .. "maps 
to a set of entities, or values, which are equivalent. The values in the 
set are resource representations and/or resource identifiers". That 
clearly conflicts with the earlier text "a non-virtual object (e.g. a 
person),".

This, I believe is the contradiction, and the one which makes no sense 
in HTTP or REST or Web Arch, and stems from "you can name anything with 
a URI, a resource is anything".

We can rewrite that key text to read:

   Any information that can be named can be a resource: a document or
   image, a temporal service (e.g. "today's weather in Los Angeles"), a
   collection of other resources, a non-virtual object (e.g. a person),
   and so on. In other words, any concept that might be the target of an
   author's hypertext reference must fit within the definition of a
   resource.

   The key abstraction of information in REST is a rest-resource.
   A rest-resource is a conceptual mapping to a set of entities, not the
   entity that corresponds to the mapping at any particular point in
   time.

   More precisely, a rest-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 rest-resource
   representations and/or resource identifiers.

and suddenly everything makes sense - over use of the word "resource" 
between HTTP, HTML and URI, when clearly there are two classes of 
"resource", "rest resources" (things you can GET a representation of, 
IRs) and "resources" (things you talk about, anything).

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

as above, mistakes are fine, everybody is human - but contradictions 
cause problems and need to be fixed one way or the other. I'm happy with 
my fix above, it makes the web work imho.

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

np, just took a while to make sense of it (as much as a few humans can 
anyway).

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

indeed, I don't think it matters what people say actually in this 
regard, if it's just naturally the way things are, then any words to try 
and prove, explain, or disprove don't really account to much. Tim's view 
makes sense to me, Roy's technical views that make the transfer 
protocols and network arch also make sense to me - it's a mess of words, 
not a mess of technical stuff, thank goodness. Roy is focused on making 
the web work / tick over between layers 1 and 2, Tim is focussed on 
making the semantic web work, between layers 2 and 3. Tim's view 
recognises the distinction between layer 2 and 3, and ensures that 
things in layers 2 and 3 are named unambiguously, Roy's view doesn't.

It's vital to anybody that wants to use layer 3, to have this 
distinction Tim promotes, the guys on layer 2 stuff, like Roy and Hixie 
don't hit that need, the guys on layer 3 like us and Tim, do hit 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.

Indeed, i think a simple clear story is very important, that people can 
understand, something like:

There are three layers of the web,
1: a web of machines
2: a web processes which we transfer data to/from and ask to do things
3: a web of things talked about or referenced in information, which 
includes things on layer 1, layer 2, and everything else one can conceive.

For the purpose of naming, we name things on layer 1 with domain names 
or ip addresses, and things on layer 2 with URLs. For anything else that 
doesn't exist on layer 1 or 2, we use a URI with a fragment.

> Good work... we're getting there.

agree - getting there, and likewise re good work of course.

Best,

Nathan

Received on Tuesday, 1 March 2011 13:42:43 UTC