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

On Mon, Jun 29, 2009 at 10:22 PM, Jonathan Rees<jar@creativecommons.org> 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

Gave it a quick look. First, note that "Some people (e.g. Harry) have
suggested that representations *cannot* be persistent (stored)" is
wrong, obviously representations can be cached and stored, as they are
just a bunch of digital bits. You can also obviously have a URI that
retrieves a fixed resource whose representation does not change.  I
did say  that there's a reason why representations are not assigned
URIs in-of-themselves and that URIs are assigned to "resources"
because representations, being bits on the wire that store the state
of a resource at a particular time, are in general (with the exception
of fixed resources, which are the minority of resources in the world I
think) more ephemeral than the resource itself.

Second, looking over the ontology, I think that it's obvious its too
large, and the focus of the group should be on finding use-cases for
each distinction that are plausible and ideally cover a use-case in
the wild. It should be not be necessary that a useful inference is
needed, but simply that someone would want to communicate "This URI X
is of resource-type Y" to solve a problem.

The reason I think the ontology is so big is that in general, the
issue with lots of these specs (URI specs, especially those mentioning
"conceptual mapping", even bits of Fielding's thesis, and even the
HTTP specs) is that modelling the entire spec is a bit difficult, as
the specs were written relatively informally. By cutting down on the
distinctions and zero-ing  in on useful ones (as we tried to do with
IRW), we can hopefully get something people will find useful.

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

Also, you could just consider these parts of the representation itself
that happen to be server specific. But if you wish to create a new
class, go for it. Pragmatically though, I feel the tendency should be
to go for less classes rather than more unless there's a good use-case
for a class or property existing.

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

Yes, that's a good use-case. Although you could just say, when
checking for equality of Web representations ignore these headers,
i.e. allow them to not have a restricted cardinality. Of course, then
you could state that a single Web representation returned by a single
server has two "expire times" which would be odd.

> If I hear no objections I'll just make this change.
>
> Open to suggestions for what to talk about.
>
> Jonathan
>
>

Received on Monday, 29 June 2009 21:53:32 UTC