- From: David Booth <david@dbooth.org>
- Date: Mon, 29 Jun 2009 21:21:21 -0400
- To: Jonathan Rees <jar@creativecommons.org>
- Cc: AWWSW TF <public-awwsw@w3.org>
On Mon, 2009-06-29 at 17:22 -0400, Jonathan Rees wrote: > My presentation at the TAG F2F went pretty well, as far as I could > tell from where I stood. > Among other things I showed my latest diagram: > http://www.w3.org/2001/tag/awwsw/jar-diagram-7.pdf (includes post-TAG changes) > which happens to correspond pretty well (not completely) with the OWL > file I checked in today > http://www.w3.org/2001/tag/awwsw/http.owl The explanation at the bottom of the diagram includes: [[ The server knows somehow about a current correspondence between the "requested resource" and some entity, so it reports on this correspondence by placing that entity (including perhaps last-modified and expires times) in the response it sends back to the client. (If it knows several correspondences it chooses one somehow - CN, User-agent, cookies, whim, etc.) Other servers may know different correspondences for the same resource. The correspondence reflects (is a quality of?) of some situation (process?) involving the resource and possibly other factors (we can't rule those out). Those factors might include the server, as when the resource "resides on" the server, or some independent resource involved in encoding and/or decoding correspondences. ]] Abstracting the above, it sure sounds to me like the server is implementing a function from time and requests to representations, but maybe I'm just a broken record. > > These are kitchen-sink ontologies for the purpose of discussion only; > I would expect a published ontology to contain only a few of these > classes. > > Several TAG members requested that the ontology be applied in > explaining current puzzles and debates around HTTP. One of these is > the content sniffing debate. (This gets us in the direction of > language versioning and drift, which would be either terrifying or > cool, depending on your optimism level.) Another is the question of > javascript application state encoded in fragment ids that Raman has > been looking into. This idea of real-world application dovetails > nicely with Alan's persistent suggestion that we go out on the web and > find interesting kinds of objects, named by http: URIs, to model, and > my idea that the "true" definition of good-200-responder will be found > not by starting from first principles, but rather by looking to see > how 200-response-evoking http: URIs *in the wild* (meaning outside the > semweb) would most naturally refer, in the most naive possible view. > > I've discovered one little puzzle: There are entity-headers that do > not seem to me to belong to what we call the 'representation'. That > is, they are not really inherent in the representation or the > resource, but rather reflect information that is known by the > particular server that is responding to requests but is not specific > to the representation or resource. (Remember than one resource may be > served by multiple servers.) These headers include Expires, > Last-modified, and Content-location. I would propose that we say that > these do not belong to the 'wa-representation'. Why not? Are you saying that these are just artifacts of the HTTP protocol? I agree that these things are not usually germane to what we usually care about when we talk about wa-representations, and I would expect every protocol to have artifacts that would be abstracted away when viewed from the Webarch perspective, but I'm wondering what is your motivation. > This contradicts our > earlier consensus that every HTTP entity is a wa-representation. I > would instead invent a new class HttpRepresentation which are simply > HTTP entities stripped of these rogue headers. (They would still > include obviously identity-bearing information such as content-type.) > I think this improves the treatment of the identity of http > representations. > > For example, this lets you say that the http-representation of a > "fixed resource" is one of the http-representations of a "generic > resource" without having to lie just because the Expires: of the first > is not consistent with the Expires: of the second. > > If I hear no objections I'll just make this change. > > Open to suggestions for what to talk about. > > Jonathan > > > -- David Booth, Ph.D. Cleveland Clinic (contractor) Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.
Received on Tuesday, 30 June 2009 01:21:57 UTC