RE: homework assignment as interpreted by JAR

Hello Jonathan,
________________________________
From: Jonathan Rees [mailto:jar@creativecommons.org]
Sent: 16 April 2008 19:42
To: Williams, Stuart (HP Labs, Bristol)
Cc: public-awwsw@w3.org
Subject: Re: homework assignment as interpreted by JAR


On Apr 16, 2008, at 12:29 PM, Williams, Stuart (HP Labs, Bristol) wrote:
Hello Jonathan,

I think that what the URI dereferences is also the information resource ie. it dereferences what it denotes. Much as in C the dereference on a pointer, eg (*p) can appear either side of an assignment operation. Although GET is often spoken of as 'dereference' I would say that all of GET, PUT, POST, DELETE involve dereference which (though operationalised by the HTTP protocol in the case of HTTP) is conceptually moving to the other end of the pointer (finding the fielding/taylor mapping function that models the resource).
Opps... strike the 'also' from the first sentence.

I think you are pointing to a way in which my usage, which follows AWWW, is wrong. There are two operations here: you figure out what the URI denotes (the server "dereferences" or "dedenotes" the URI to obtain an IR), and then given the the IR, you select a representation of the IR's state to deliver to the client. It is the composition of denotes and is-representable-by that should label the arc from the URI to the Value. Something like "would have as a correct GET response" might be closer.
Broadly yes, though I would also try to avoid attributing particular action to a server. I'd just be a little less specific and speak of the web infrastructure. The 'you' that does the representation selection is also part of the infrastructure. Headers in a client's request will influence the selection - by the selection is made within the infrastructure. FWIW: part of my reticence to speak of servers and the like is simply that it lends a certain, often unnecessary definiteness, to stories we might tell of an access eg. on this occassion the response was provided by a cache - the resource or the server that animates it is completely unaware that the access has happened. 404s we don't have to be overly specific about in what way a resource was not found. Also, there is a bunch of local context such as proxy settings such that even if ones request URI is sat http://www.w3.org/ the TCP/IP connection from the client may terminate at http://web-proxy.hpl.hp.com:8088 which may connected onward through other layered proxies.

IMO... at least from a web client POV better just to think of web infrastructure starting at your local libwww or INET.DLL or whatever and attributing responses to the infrastructure as a whole.

[Oooppppsss climbed on that hobby horse again.]

AWWW says:
Dereference a URI<http://www.w3.org/TR/webarch/#uri-dereference>
Access a representation of the resource identified by the URI.
Ouch... yes it's a fair cop... though I will say that during my early life as a TAG member and relative W3C newcomer... I did try to get things expressed more precisely [1] though Tim didn't go for it [2]. I probably should have stuck more strongly to my guns. Nevertheless when I'm being more precise "dereference" <> "GET".

[1] http://lists.w3.org/Archives/Public/www-tag/2002Jul/0169
[2] http://lists.w3.org/Archives/Public/www-tag/2002Jul/0183
-- Perhaps I could say "awww:dereferences" instead of "dereferences"... (just kidding)
:-)
I think that's important because as it's currently drawn, what appears to be dereferenced is one of the representations available at the given instant that the HTTP operation occurs - which leads us back into "the URI identifies" the representation given the confusion around word senses of "identify".

Not what I meant - if you put the source of the arrow, the arrow label, and the label destination in a row then the diagram says that a URI dereferences (at time t) to a Value. If the diagram commutes then that Value will be a representation of the state of the IR denoted by the URI.
...at time 't'

Ok... I see what you meant. It's just that we (this community - self included) have a bad habit of hearing all of deference, denote and identify all as one.

As for "identify" I would say that a server can use a URI to identify which IR, among the ones it knows about, should be the one to have one of its current state's representations returned. The URI both denotes and identifies the IR. I agree with Pat, I think.
Me too... (though I'd leave the server out of the discussion...).
The taylor/fielding value cloud is just a way of modeling an information resource over all time - it's a way of flattening it into an invariant construct (it becomes meaningless to talk about the resource changing over time (though its state may) - if it changes then it is a different resource - because such change would entail a different future or a different past).

Wait, let's be careful. The value cloud is not a model of the IR, but rather a model of the way it's served.
Ok...
To call it a 'model' of the IR would be inaccurate in the mathematical sense since there will be true statements about the IR that can't be mapped to true statements about the value cloud.
Ok, I wasn't using model in the sense of 'model theory' or logic  A models B (which I have only a tenuous grasp on). More in the sense of a simulation model (eg. like in a model of a digital circuit)... though I suspect that you can show me a model theoretic basis for those as well.
The IR knows things that a faithful value cloud might not; for example, you could have an IR that's a 2000 dpi image (or perhaps even a continuous-space image), while all the values in the value cloud are only 400 dpi. Conversely, the IR doesn't specify the value cloud; there could be many value clouds faithful to the same IR (as we agreed on the call). So neither makes a good model of the other.

 Ok.... that's interesting (multiple value clouds)... I guess that I could also conceptualise in a way that allowed the value cloud to contain ALL possible representations over all time, and view the selective behaviour of the access protocol as eliminating most of them from view.
The Taylor/Fielding paper defines 'resource' in several different ways, and the definitions are mutually inconsistent. The formal definition coincides with what I've called the value cloud. The informal definitions (e.g. "Any information that can be named can be a resource") are closer to awww:information-resource.

It is not the intention to say that the information resource is actually organised that way as an implementation - just that it will be in states over time and that those states are projected of a moment as sets of awww:representations, one of which is provided in response to a GET operation using the relevant URI.

I agree. The paper is about a software architecture, and I think he's saying that if your systems are designed and implemented consistently with the formal model (as elaborated in the paper), you'll be RESTful and reap the benefits. To equate the formal model and the informal notion is just a bit of sloppiness that will not throw off people who are more clever than I am.

"I think that the 'Jonathan', he prostest too much" :-)

The value cloud, even though it's not an IR, is still a thing (as is the network endpoint) and we might want to write about it in RDF, e.g. if we were trying to reason about how well a system implements the REST model. All of these things, including IR, representation, information-resource, and network endpoint, are abstract models of various real world phenomena. To get clarity we have to figure out the relationships among these models and between the models and reality.

FWIW: I think that the value cloud is a useful why to capture variant representations (meaning roughly conneg) at a moment and change over time - sort of a continuous function of time whose range is sets of values (values being byte-sequences and media-types).

I think that there are some interesting conneg questions to do with the relationship between the value cloud presented by a variant resource and the value cloud of the generic resource which it is a variant of. Loosely it would seem to me that:

    g(t) = union(v_a(t), v_b(t),...,v_k(t),...v_n(t))

where g(t) is the value cloud for the generic and v_k(t) is the value cloud of variant k, allowing k to range over all variants. I also suspect that v_k(t) typically has only one value available at 't' - but thinking about this did cause me to think a bit about nested or multidimensional conneg - and surpisingly perhaps given your mention of dpi's above, I was thinking about say an image available in different dpi's and different formats. Not sure that I can encode dpi or #x,#y pixel constraints into an Accept header. Natural language and format would be more tractable as a 2 dimensional conneg... though the details may be that it may be able to all happens in one step.

The value-cloud is not an essential part of the picture. I only put it there because I wanted to understand Fielding & Taylor, to make sure my understanding of F&T matched that of others, and to articulate an example of something that IRs are *not*.

I think you're saying that a value cloud is *not* an IR in that it is an artifact of the F&T formulation of resource - I think I'd be inclined to regard there as being a 1:1 correspondence between VC and IR (at least when viewed through a web like lens) - nope that doesn't do it I suppose - i could have two identical 'document controlled' robot arms whose say joint articulations are encoded on a document - and they could happen to go through identical sequences of motion (over all time) - hence the VCs would in fact be identical, but they would each be traces of the movement of distinct robots that happen (coincidentally? or just pervesely for the sake of discussion) to have identical motion over time. Ok... so the VC could in sense type an IR, could it also be one as a type?

Just thinking aloud.

Jonathan


Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England