- From: Booth, David (HP Software - Boston) <dbooth@hp.com>
- Date: Sat, 22 Nov 2008 01:27:14 +0000
- To: "noah_mendelsohn@us.ibm.com" <noah_mendelsohn@us.ibm.com>, Pat Hayes <phayes@ihmc.us>
- CC: Alan Ruttenberg <alanruttenberg@gmail.com>, Harry Halpin <hhalpin@ibiblio.org>, Jonathan Rees <jar@creativecommons.org>, "public-awwsw@w3.org" <public-awwsw@w3.org>
Noah, If one accepts the idea that an InformationResource is essentially a function from (Time x Request) to Representation, then I think the distinction that you are making is very clear and simple: it is the difference between x as a Representation and y as a <Time, Request, Representation> tuple. David Booth, Ph.D. HP Software +1 617 629 8881 office | dbooth@hp.com http://www.hp.com/go/software Statements made herein represent the views of the author and do not necessarily represent the official views of HP unless explicitly so stated. > -----Original Message----- > From: public-awwsw-request@w3.org > [mailto:public-awwsw-request@w3.org] On Behalf Of > noah_mendelsohn@us.ibm.com > Sent: Friday, November 21, 2008 8:07 PM > To: Pat Hayes > Cc: Alan Ruttenberg; Harry Halpin; Jonathan Rees; public-awwsw@w3.org > Subject: Re: statements about resources vs. representations > > > Reflecting on the note I sent below, I realize that there's a > subtlety I > didn't deal with. There are at least two abstractions we > might want to > identify: > > 1) A representation in the sense of a particular set of bits sent at a > particular time from an HTTP resource to a client or proxy, > or conversely, > such a representation sent upstream with PUT or POST. By > this definition, > any representation involved in a subsequent interaction would > necssarily > be a different one. > > 2) A representation defined to be the information sent with a > GET, PUT, > POST, etc. By this definition, it's at least possible that > the same URI > would be used to identify the representation that resulted > from, say, two > or more GETs. I believe the natural way to go down this path > is to allow > the same URI to be used to identify representations with the > same content, > even if provided as representations from very different > resources. For > example, the representation that is Content-type: text/plain > with entity > body "hello world" could have the same URI even if returned on GETs to > many different resources. > > When I claimed that I wanted to indicate that a given > representation was > poorly formed, I could have meant in the sense of (1) or (2). > If I want > to make a statement that a particular representation was > received at 4PM, > I probably mean in sense (2). Or maybe for that case I need > a URI for the > HTTP response, which contains a representation but > potentially contains > additional information as well. > > Anyway, I realized that there is potentially such an ambiguity, and I > think we should be very clear which of the possible > abstractions we refer > to when we decide to identify a "representation" with a URI. > > Noah > > -------------------------------------- > Noah Mendelsohn > IBM Corporation > One Rogers Street > Cambridge, MA 02142 > 1-617-693-4036 > -------------------------------------- > > > > > > > > > Noah Mendelsohn > 11/21/2008 06:22 PM > > To: Pat Hayes <phayes@ihmc.us> > cc: Alan Ruttenberg <alanruttenberg@gmail.com>, > Harry Halpin > <hhalpin@ibiblio.org>, Jonathan Rees <jar@creativecommons.org>, > "public-awwsw@w3.org" <public-awwsw@w3.org> > Subject: Re: statements about resources vs. > representations > > > Pat Hayes writes: > > > I think what Harry should have said is that they are too > > ephemeral for someone to want to give them an enduring name or > > identifier. But there are other ways to refer to things than > > baptizing them with a URI for all time. > > On this I don't think I agree. We're talking about the Web here, and > what's more, I think a representation is an information > resource. I mean, > > not only can the thing be represented as a computer message, the whole > point of it is to be sent in a computer message! The key > architectural > imperative for the Web is "Identify with URIs." I see no > reason why, in > cases where you do want some means of identifying a particular > representation, a URI wouldn't be the way to do it. When I make that > choice, I get a variety of advantages: I can make Semantic > Web statements > > about the representation (it was buggy, it took a long time > to arrive, it > was cached at proxy p1, etc.) in the natural way without resorting to > indirection; I think I could even choose to run a server that would > respond to GETs with representations of, well, the representation. I > think the usual rules of the Web apply well here: when you need to > identify something, do it with URIs. > > Noah > > [1] http://www.w3.org/TR/webarch/#pr-use-uris > > -------------------------------------- > Noah Mendelsohn > IBM Corporation > One Rogers Street > Cambridge, MA 02142 > 1-617-693-4036 > -------------------------------------- > > > > > > > >
Received on Saturday, 22 November 2008 01:29:30 UTC