Subject: Re: Review of new HTTPbis text for 303 See Other

From: Chimezie Ogbuji <[email-masked]>
Date: Sat, 11 Jul 2009 10:56:00 -0400

> 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

---

From: Nick Gall <[email-masked]>
Date: Tue, 14 Jul 2009 19:25:25 -0400

A url referring to the entire digital contents of the library of congress?

-- Nick (sent from my mobile phone)

-----Original Message-----
From: "Alan Ruttenberg" <[email-masked]>
To: "Pat Hayes" <[email-masked]>
Cc: "Jonathan Rees" <[email-masked]>; "Roy T. Fielding" <[email-masked]>; "Julian Reschke" <[email-masked]>; "HTTP Working Group" <[email-masked]>; [email-masked]
Sent: 7/11/09 6:47 PM
Subject: Re: Review of new HTTPbis text for 303 See Other

On Thu, Jul 9, 2009 at 12:04 PM, Pat Hayes<[email-masked]> wrote:
>
> On Jul 9, 2009, at 5:03 AM, Jonathan Rees wrote:
>
>> On Wed, Jul 8, 2009 at 6:03 PM, Roy T. Fielding<[email-masked]> wrote:
>>
>>> That's because you happen to be reading it differently than
>>> what I was thinking when I wrote it.  The sentence is a bit
>>> ambiguous if you don't pay attention to what the second "that"
>>> means.  If it is reordered to say
>>>
>>>  A 303 response to a GET request indicates that the server does
>>>  not have a transferable representation

What does "transferable" add to representation?
Would it be possible for someone to give an example of an
*un*transferable representation?

Thanks,

-Alan

>>> of the requested resource
>>>  and is instead redirecting the client to some other resource
>>>  for further information.
>>>
>>> then I think the objection is handled without watering down
>>> the purpose of using the status code on a GET.
>>>
>>> ....Roy
>>
>> Excellent! The rewording you give above would be fine with me - I
>> would be satisfied if HTTPbis said this, or something equivalent.
>> (because then the choice to yield a 303 can be attributed to the
>> server, and would not necessarily reflect on the nature of the
>> resource - "the server does not have" vs. "the resource does not
>> have".)
>
> Hmm, then I am puzzled. Does 303 redirection really imply that the server
> **does not have** a transferable representation? Surely 303 redirection is
> used under other circumstances than this, circumstances which have nothing
> whatever to do with http-range-14 and were being used before the
> http-range-14 issue was even raised? No?
>
> Pat
>
>>
>> Best
>> Jonathan
>>
>>
>
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>
>
>