Re: Review of new HTTPbis text for 303 See Other

> Not as far as HTTP is concerned. HTTP is just a transfer protocol. The
> HTTP world is really simple:
> I repeat: For the operation of the HTTP protocol, IT DOES NOT MATTER
> what exactly a resource is and what the exact relationship between
> resources and representations is. All these matters of denotation,
> information resources and so on are introduced by higher layers of the
> architecture.

Well said.  I myself don't understand the motivation for trying to
have the protocol dictate denotation (they have nothing to do with
each other)
and it seems more than a bit of stretch to suggest that interactions
in the protocol determine RDF denotation (or at least the class
of thing being denoted).  In fact, I don't even see the value in doing
so when there are other better-suited mechanisms for determining how
the RDF is interpreted (RDFS, OWL, OWL2, etc..)

> Yes, it would be useful to provide guidance to publishers about how
> best to model their information space as resources and
> representations. But this is out of scope for the HTTP protocol. The
> HTTP protocol kicks in AFTER the publisher has made up their mind
> about what resources they have and wether they have representations or
> not.

Id further add that if the RDF being consumed does not need (HTTP)
representations of its referents in order for
a machine to understand the intent of the publisher then the HTTP
protocol has nothing to
with any of this.

> As long  as the subcommunities subscribe to the basic
> "URI-identifies-resource-which-can-have-representations" model, HTTP can accomodate them.

I don't even think this subscription is necessary in all cases.
Sub-communities that deal with referents that do
not need representations do not need to care about this model or HTTP;
at least not beyond the publication and transport of
the representation of an RDF graph whose interpretation sufficiently
captures the meaning of the graph without requiring the
fetching of representations for the referents within.

> The suggested change for the 303 text came about because one
> subcommunity had the funny idea that some resources SHOULD have URIs
> but NO representations and it should STILL be possible to get
> information about them via HTTP. It beats me why anyone would want to
> do that;

+1

> There is no such thing as denotation in HTTP. The only relation
> between URIs and resources in HTTP is "identifies". If you care about
> other relations, you have to figure out how to translate them into the
> "URI-identifies-resource-which-can-have-representations" model of HTTP.

See above.  I typically care (in the domain I work in) more about
denotation and RDF interpretations
 than HTTP identification and resource-level representations and have
never had to *figure out* the translation to the
"URI-identifies-resource-which-can-have-representations" model in
order to solve legitimate problems.  It just didn't apply.

It seems to be only a problem that applies to applications in the
Linked Open Data scenario, which is
only *one* category of RDF applications where the requirement (from
the outset) is to ensure that
there is a strong correlation between denotation and the
representation of the corresponding resources (insofar
as all URIs are mandated to be resolvable).

> There are different schools of thought that try to clarify the nature
> of the "identifies" and "has representation" relationships, and this
> is critically important if we want to use HTTP URIs as identifiers for
> things that exist outside of the Web.

I wouldn't go as far as saying they are critically important for such
resources.
Again, if such URIs are being used in an RDF application that mostly
leverages OWL and RDFS
and other such languages to determine the 'meaning of the data', there
is little use in a role of the
web in machine consumption.

The only exception might be for linking logically separated parts
(such as the RDF graph and the governing OWL document), but
these can be easily handled by well-defined predicates such as
rdfs:isDefinedBy, owl:imports, etc..

-- Chimezie

Received on Saturday, 11 July 2009 14:56:43 UTC