W3C home > Mailing lists > Public > public-awwsw@w3.org > June 2009

Re: Thinking ahead to next Tuesday's telecon...

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>
Message-Id: <1246324881.14395.990.camel@dbooth-laptop>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 30 June 2009 01:21:59 GMT