Review of new HTTPbis text for 303 See Other

[Pat Hayes]

On Jul 9, 2009, at 11:21 AM, Xiaoshu Wang wrote:

> Pat Hayes wrote:
>>
>> On Jul 9, 2009, at 5:03 AM, Jonathan Rees wrote:
>>
>>> On Wed, Jul 8, 2009 at 6:03 PM, Roy T. Fielding<fielding@...>  
>>> 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 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?
> Why puzzled? It makes perfect sense.  A transportation protocol  
> express the semantics of a server but not that of its resource.

That part I understand (and agree that the wording change is an  
improvement.) The part I am still worried about is the claim that a  
303 redirect necessarily means that the server *does not have* a  
representation. I think this is (a) wrong, in that such a  
representation may exist, but the server may choose not to deliver it  
for some reason on this occasion, and (b) needlessly strong, since  
nothing hinges on the existence or otherwise of this representation.  
The http-range-14 decision does not depend on this being the intended  
meaning of a 303 redirect: it requires only that a 200-level  
representation for the requesting URI is *not* delivered, even  
indirectly (as would be the case with a 301 or 307, for example). And  
since this is all that is required, it seems like good practice to not  
say anything more, on the grounds that whatever else is said will  
likely come back to bite you later.

For example, here is a possible scenario. I have an OWL ontology all  
about breeding horses, and it uses hash-coded URIrefs throughout to  
denote breeds of horse, like http://ex.thehorseplace.com/foo#arabian.  
I also want to use the bare URI http://ex.thehorseplace.com/baz to  
denote my company (not my website), so I need to do a 303 redirect  
when this URI comes along. All this is done by my one web server,  
however. So this entity which handles all this has access to a  
representation of itself, which it will 200-deliver when given the URI http://ex.thehorseplace.com/foo 
, but when given the URI http://ex.thehorseplace.com/baz it will  
ignore this representation and perform a 303 redirect to a document  
about my company. Now, I could say that there are two resources here,  
each with its own URI, but that wouldnt in fact reflect the reality of  
how my website is constructed. What there is, is one entity which has  
two URIs and which responds differently to them. In one case, it  
**has** a representation but **chooses** not to deliver it, in order  
to comply with http-range-14.

So, I would suggest changing the wording to something like:

A 303 response to a GET request indicates that the server will not  
deliver a transferable representation of ...

>  At most, it express what the URI owner thinks about the resource  
> denoted by the URI, but it is neither what the resource owner thinks  
> nor what the resource is.
>
> httpRange-14 is a bad design by forcing the latter semantics upon  
> the URI owner.

(Just to clarify for the record, I am not intending here to quarrel  
with http-range-14, only with the wording being used to express it.)

Pat

> Xiaoshu
>
>

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[Xiaoshu Wang-3]

Pat Hayes wrote:

>
> On Jul 9, 2009, at 11:21 AM, Xiaoshu Wang wrote:
>
>> Pat Hayes wrote:
>>>
>>> On Jul 9, 2009, at 5:03 AM, Jonathan Rees wrote:
>>>
>>>> On Wed, Jul 8, 2009 at 6:03 PM, Roy T. Fielding<fielding@...>
>>>> 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 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?
>> Why puzzled? It makes perfect sense.  A transportation protocol
>> express the semantics of a server but not that of its resource.
>
> That part I understand (and agree that the wording change is an
> improvement.) The part I am still worried about is the claim that a
> 303 redirect necessarily means that the server *does not have* a
> representation. I think this is (a) wrong, in that such a
> representation may exist, but the server may choose not to deliver it
> for some reason on this occasion, and (b) needlessly strong, since
> nothing hinges on the existence or otherwise of this representation.
> The http-range-14 decision does not depend on this being the intended
> meaning of a 303 redirect: it requires only that a 200-level
> representation for the requesting URI is *not* delivered, even
> indirectly (as would be the case with a 301 or 307, for example). And
> since this is all that is required, it seems like good practice to not
> say anything more, on the grounds that whatever else is said will
> likely come back to bite you later.
>
> For example, here is a possible scenario. I have an OWL ontology all
> about breeding horses, and it uses hash-coded URIrefs throughout to
> denote breeds of horse, like http://ex.thehorseplace.com/foo#arabian.
> I also want to use the bare URI http://ex.thehorseplace.com/baz to
> denote my company (not my website), so I need to do a 303 redirect
> when this URI comes along. All this is done by my one web server,
> however. So this entity which handles all this has access to a
> representation of itself, which it will 200-deliver when given the URI
> http://ex.thehorseplace.com/foo, but when given the URI
> http://ex.thehorseplace.com/baz it will ignore this representation and
> perform a 303 redirect to a document about my company. Now, I could
> say that there are two resources here, each with its own URI, but that
> wouldnt in fact reflect the reality of how my website is constructed.
> What there is, is one entity which has two URIs and which responds
> differently to them. In one case, it **has** a representation but
> **chooses** not to deliver it, in order to comply with http-range-14.
>
> So, I would suggest changing the wording to something like:
>
> A 303 response to a GET request indicates that the server will not
> deliver a transferable representation of ...

Yes, I think this wording is good.

Xiaoshu

[Pat Hayes]

On Jul 9, 2009, at 12:01 PM, Roy T. Fielding wrote:

> On Jul 9, 2009, at 9:04 AM, Pat Hayes wrote:
>> 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?
>
> No, at least not for GET requests.  303 (See Other) was originally
> defined as "redirect with a different method" and not fully specified.
> When HTTP was standardized, 303 became "see other" for the specific
> purpose of redirecting a non-GET request to a GET of another resource.
> Defining a specific purpose for 303 in response to a GET is what we
> are doing right now.  There was no pre-existing usage of 303 in  
> response
> to a GET prior to the HTTPrange issue being decided.

OK, thanks for the explanation. I had not realized that previous uses  
of 303 were restricted to non-GET requests. I guess this narrows the  
'meaning' of a 303 response even more tightly than I thought.

Pat

>
> ....Roy
>
>
>
>

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[Roy T. Fielding]

On Jul 9, 2009, at 6:17 AM, J Ross Nicoll wrote:

> Roy T. Fielding wrote:
>
>>> That just seems plain false. A 303 does not indicate that something
>>> does not exist. It simply indicates that the server, for reasons  
>>> which
>>> may be entirely opaque and nobody is under any obligation to  
>>> explain,
>>> has decided to redirect the query elsewhere.
>>
>> No, we have other redirect codes for that.
>
> As I understand it, 301 (moved permanently), 302 (found) and 307 (not
> modified) all indicate a different location for the resource, never  
> for
> an alternative to it. 304 is "Not modified", and 305/6 are
> deprecated/reserved respectively. So, I don't think there is any other
> redirect code for "Instead of the resource you requested, please see
> this resource instead"...

The only reason for a server to say "see this other resource
instead" to a GET request is that the person who configured
the server knows that this other resource is not the same as
the requested resource (i.e., not a 301/302/307) and yet wants
the client directed to that resource because it is more responsive
to the client's request than responding with a 404 or 410.

The only way a server can be responsive to the client's original
GET request (i.e., not broken or lying) is if the 303 response
points to a resource that describes the originally requested
resource.  Any other result would be pointlessly random, which
would be silly because 302 is already provided for pointlessly
random redirects.

....Roy

[Roy T. Fielding]

On Jul 9, 2009, at 9:04 AM, Pat Hayes wrote:
> Hmm, then I am puzzled. Does 303 redirection really imply that
> the server **does not have** a transferable representation?

If the server has a transferable representation, it would
respond to the GET with the appropriate status code (200 or 304).

....Roy

[Pat Hayes]

On Jul 9, 2009, at 6:22 PM, Roy T. Fielding wrote:

> On Jul 9, 2009, at 9:04 AM, Pat Hayes wrote:
>> Hmm, then I am puzzled. Does 303 redirection really imply that
>> the server **does not have** a transferable representation?
>
> If the server has a transferable representation, it would
> respond to the GET with the appropriate status code (200 or 304).
>

Well, yes, IF it were driven solely by what one might call rational  
HTTP architectural principles. BUt surely the whole issue about  
httprange14 is that it introduces new principles which on their face  
have nothing to do with http architecture as such, but to do with  
denotation and naming. If the URI in the GET request is not intended  
to denote the resource to which the GET is directed, then that  
resource must issue a 303 redirection, and must not return a  
representation using a 200 status code. That has nothing to do with  
the existence or not of such a representation. Even if the  
representation exists and the server has access to it, it cannot  
return it with a 200 code when the URI is intended to denote some  
other thing, in particular a non-information resource of some kind.

If we follow your rule, above, and also httprange14, then a server can  
be placed in an impossible position. If it has a representation of  
itself which  could be put into a 200-code response, and it receives a  
GET request with a URI which it knows (somehow, perhaps by some  
externally agreed convention) is being used to denote a non-
information resource; what should it do? HTTPrange14 requires it to  
not deliver a 200-coded reply, but your criterion requires that it  
must. This is why I think the wording should make absilutely minimal  
assumptions about what exactly the 303 means.

Pat

> ....Roy
>
>
>

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[Richard Cyganiak-2]

Pat,

On 10 Jul 2009, at 01:32, Pat Hayes wrote:
>> If the server has a transferable representation, it would
>> respond to the GET with the appropriate status code (200 or 304).
>
> Well, yes, IF it were driven solely by what one might call rational  
> HTTP architectural principles. BUt surely the whole issue about  
> httprange14 is that it introduces new principles which on their face  
> have nothing to do with http architecture as such, but to do with  
> denotation and naming.

Not as far as HTTP is concerned. HTTP is just a transfer protocol. The  
HTTP world is really simple:

1. There are URIs. URIs are thought to identify things called  
resources. As far as HTTP is concerned, it does not matter much what  
the resource actually is -- a document, a file on a server, a person,  
whatever.

2. Resources (whatever they are) are thought to have things called  
representations. As far as HTTP is concerned, it is totally up to the  
server owner to decide what's a representation of what. After the  
server owner has made their decision, a resource either has a  
representation or not.

3. If a resource has a representation, then a GET to its URI should be  
answered by 200. If not, then 303, 404 or 410 would be fine choices.

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.

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.

Now, different subcommunities have different opinions on how to model  
resources and representations. That's not a good thing, and it would  
be good for interoperability if everyone agreed. However, this is  
pretty much orthogonal to any discussion of the HTTP protocol. As long  
as the subcommunities subscribe to the basic "URI-identifies-resource-
which-can-have-representations" model, HTTP can accomodate them.

Now let me take off my RDF hat for a bit.

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; but if we can make them happy with a minimal tweak to the  
language of an existing status code, then why not. HTTP is for everyone.

> If the URI in the GET request is not intended to denote the resource  
> to which the GET is directed, then that resource must issue a 303  
> redirection, and must not return a representation using a 200 status  
> code.

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.

> That has nothing to do with the existence or not of such a  
> representation. Even if the representation exists and the server has  
> access to it, it cannot return it with a 200 code when the URI is  
> intended to denote some other thing, in particular a non-information  
> resource of some kind.

Wether a representation exists or not for a particular kind of  
resource is entirely up to the server owner, as far as HTTP is  
concerned. If you subscribe to a religion that says, "Thou shall not  
make a representation of me, for I am not an information resource",  
then that's great, and let me shake your hand brother, but this has no  
effect on HTTP.

> If we follow your rule, above, and also httprange14, then a server  
> can be placed in an impossible position. If it has a representation  
> of itself which  could be put into a 200-code response, and it  
> receives a GET request with a URI which it knows (somehow, perhaps  
> by some externally agreed convention) is being used to denote a non-
> information resource; what should it do? HTTPrange14 requires it to  
> not deliver a 200-coded reply, but your criterion requires that it  
> must. This is why I think the wording should make absilutely minimal  
> assumptions about what exactly the 303 means.

(RDF hat back on) Any sensible definition of "non-information  
resource" obviously MUST entail "does not have representations in the  
HTTP sense". In fact, that IS the definition of "non-information  
resource", in my book.

Wrapping up:

For the function of the HTTP transfer protocol, it does not matter  
what exactly the nature of the things identified by URIs is.

For the function of the HTTP transfer protocol, it does not matter  
wether the things you serve as representations on your server make  
particularly good representations of the resources.

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. But the HTTP protocol itself is  
and should be agnostic with regard to your position in these debates.  
That's layering.

Best,
Richard

>
> Pat
>
>> ....Roy
>>
>>
>>
>
> ------------------------------------------------------------
> IHMC                                     [phone] or (650)494  
> 3973
> 40 South Alcaniz St.           [phone]   office
> Pensacola                            [phone]   fax
> FL 32502                              [phone]   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>
>

[Chimezie Ogbuji]

> 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

[Alan Ruttenberg-2]

On Thu, Jul 9, 2009 at 12:04 PM, Pat Hayes<phayes@...> wrote:

>
> On Jul 9, 2009, at 5:03 AM, Jonathan Rees wrote:
>
>> On Wed, Jul 8, 2009 at 6:03 PM, Roy T. Fielding<fielding@...> 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                                     [phone] or [phone]
> 40 South Alcaniz St.           [phone]   office
> Pensacola                            [phone]   fax
> FL 32502                              [phone]   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>
>
>

[Alan Ruttenberg-2]

On Sat, Jul 11, 2009 at 6:27 AM, Richard Cyganiak<richard@...> wrote:
> 3. If a resource has a representation, then a GET to its URI should be
> answered by 200. If not, then 303, 404 or 410 would be fine choices.

This *should* is not warranted. As there is often no way to include
structured information *about* a resource in-band of the
representation (sense http/awww), or to include it in a way that is
predictable by the requester, is a perfectly reasonable choice to use
303 to interpose and therefore provide a way of supplying this "about"
information. In those cases where someone is confident enough that a
200 response would have been appropriate, that one can supply
information *about* the resource (in RDF, for instance) means that
there is an opportunity to indicate (with the potential for being much
more precise than http) where that "representation" can be fetched
from.

-Alan

[Alan Ruttenberg-2]

On Thu, Jul 9, 2009 at 7:16 PM, Roy T. Fielding<fielding@...> wrote:

> On Jul 9, 2009, at 6:17 AM, J Ross Nicoll wrote:
>
>> Roy T. Fielding wrote:
>>
>>>> That just seems plain false. A 303 does not indicate that something
>>>> does not exist. It simply indicates that the server, for reasons which
>>>> may be entirely opaque and nobody is under any obligation to explain,
>>>> has decided to redirect the query elsewhere.
>>>
>>> No, we have other redirect codes for that.
>>
>> As I understand it, 301 (moved permanently), 302 (found) and 307 (not
>> modified) all indicate a different location for the resource, never for
>> an alternative to it. 304 is "Not modified", and 305/6 are
>> deprecated/reserved respectively. So, I don't think there is any other
>> redirect code for "Instead of the resource you requested, please see
>> this resource instead"...
>
> The only reason for a server to say "see this other resource
> instead" to a GET request is that the person who configured
> the server knows that this other resource is not the same as
> the requested resource (i.e., not a 301/302/307) and yet wants
> the client directed to that resource because it is more responsive
> to the client's request than responding with a 404 or 410.

> The only way a server can be responsive to the client's original
> GET request (i.e., not broken or lying) is if the 303 response
> points to a resource that describes the originally requested
> resource.  Any other result would be pointlessly random, which
> would be silly because 302 is already provided for pointlessly
> random redirects.

"describes", "is about", "has topic" - there are a number of names for
the relation of the 303 response to the originally requested resource.
I agree with your assessment here and would welcome stronger language
in the specifications that make clear this expectation about 303
responses.

-Alan
>
> ....Roy
>
>

[Pat Hayes]

On Jul 11, 2009, at 5:27 AM, Richard Cyganiak wrote:

> Pat,
>
> On 10 Jul 2009, at 01:32, Pat Hayes wrote:
>>> If the server has a transferable representation, it would
>>> respond to the GET with the appropriate status code (200 or 304).
>>
>> Well, yes, IF it were driven solely by what one might call rational  
>> HTTP architectural principles. BUt surely the whole issue about  
>> httprange14 is that it introduces new principles which on their  
>> face have nothing to do with http architecture as such, but to do  
>> with denotation and naming.
>
> Not as far as HTTP is concerned. HTTP is just a transfer protocol.  
> The HTTP world is really simple:
>
> 1. There are URIs. URIs are thought to identify things called  
> resources.

OK, stop there and tell me what you mean here by "identifies".  
Because...

> As far as HTTP is concerned, it does not matter much what the  
> resource actually is -- a document, a file on a server, a person,  
> whatever.

... in the usual sense of 'identifies' that one might expect to be use  
in the context of a network transfer protocol, which is similar to the  
use one might expect when talking about programming language  
identifiers and what they identify, it most certainly does matter. In  
particular, it simply does not make sense to speak, using that normal  
terminology, of 'identifying' a person (or a galaxy or a sodium atom,  
etc.); in fact, it does not make sense to talk of identifying anything  
much beyond some kind of data structure or data object. So if HTML  
claims to be able to make sense of talking of 'identifying' people  
(for example), it must be in a wholly different space than all  
previous computationally based notational systems, and be using the  
word "identify" in a wholly different sense. And, to repeat, can you  
tell me what that sense is?

>
> 2. Resources (whatever they are) are thought to have things called  
> representations. As far as HTTP is concerned, it is totally up to  
> the server owner to decide what's a representation of what. After  
> the server owner has made their decision, a resource either has a  
> representation or not.

Really? OK, I will take you at your word. I am a server owner, and I  
will decide that a certain resource, to wit, me, has a thing called a  
representation of me. This representation of me is in fact a portrait,  
painted using acrylic paints on a piece of masonite approximately 30  
cm square almost exactly a month ago: but let us not go into details,  
as you tell me that such details are none of HTTP's business. Still,  
the representation exists, and the resource has it. OK, let us proceed.

>
> 3. If a resource has a representation, then a GET to its URI should  
> be answered by 200. If not, then 303, 404 or 410 would be fine  
> choices.

So, HTTP must reply to a GET on my URI with a 200. OK, what should it  
put as the payload of this 200 response, attached to the code  
information? HOw do I get acrylic-coated masonite into an http  
response? There is no representation which can be transmitted in bits.  
You did not mention this aspect in your above summary: was that an  
omission?

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

As you can see, I took advantage of this freedom in my example.

> All these matters of denotation, information resources and so on are  
> introduced by higher layers of the architecture.

Wrong. Denotation is not introduced by a higher level, and even if it  
were, it would not be higher in an architectural sense. You, in this  
very message, in fact brought denotation into the picture, by telling  
me that a URI can "identify" a person. URIs are symbols strings, and  
the ONLY POSSIBLE SEMANTIC RELATIONSHIP between ANY symbol and a  
physical object, is denotation. Sorry to shout there a little, but the  
point needs to be made strongly. That is what "denotation" means: it  
is all that is left of "identifying" when you take away the actual  
network machinery, the computational byte-transferring. And you have  
to take this away when you start claiming to talk of relationships  
between names (of any kind) and non-computational entities such as  
people (or indeed of any kind), simply because computational byte-
transfer talk is COMPLETELY IRRELEVANT to semantic relationships (such  
as "identification") between symbols (of any kind) and non-
computational entities. The fact, if it is a fact, that this word is  
not in your technical vocabulary is entirely irrelevant. By claiming  
that your symbols "identify" non-computational entities such as people  
or books (or the weather in Oaxacala, to take another random  
example) , you are no longer playing in the network-architectural  
sandbox, precisely because these kind of things simply are not  
connected to networks in the same functional sense that things like  
web servers are. Either HTTP is a computational notion or it isn't. If  
it is, then it is indeed quite simple. And I would be delighted if the  
HTTP literature simply restricted itself to the computational world.  
But it does not, and never has: HTTP has ALWAYS had these claims to  
semantic grandeur: it has ALWAYS claimed to be not just about web  
sites and web servers and files and documents, but about the whole  
grand span of symbol usage to refer to absolutely anything in any  
possible universe. And if indeed that is what HTTP is claiming to be  
able to talk about, then it is about denotation, right out of the box.

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

See above. If indeed it is out of scope, so is any talk of URIs  
"identifying" people. You can't have it both ways. Either you are  
doing real semantics or you aren't. If you aren't, then don't make  
ridiculous claims about "identifying" things that have no possible  
connection to any physical network, or of "representations" that  
cannot be sent in a byte stream.

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

OK, please tell me how to use HTTP to send my piece of masonite  
attached to a 200 code. I've made up MY mind: over to you.

>
> Now, different subcommunities have different opinions on how to  
> model resources and representations. That's not a good thing, and it  
> would be good for interoperability if everyone agreed. However, this  
> is pretty much orthogonal to any discussion of the HTTP protocol. As  
> long as the subcommunities subscribe to the basic "URI-identifies-
> resource-which-can-have-representations" model, HTTP can accomodate  
> them.
>
> Now let me take off my RDF hat for a bit.
>
> 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.

No, that is not the primary reason. Http-range-14 is not about  
resources, it is about URIs and what they denote. The dilemma is that  
people want 'normal' URIs to denote what it that HTTP thinks of them  
as identifying, the "information resource" (not that that matters).  
Which would be fine, except that there are some URIs which people want  
to denote something else. And still, actually for different ('linked  
data', Timblish) reasons, people want a GET on those URIs to finish  
up, one way or another, with useful information being returned. This  
is a problem. It would be ugly to have two 'kinds' of URI, and  
impossible to change the millions of 'normal' URIs in any way at all.  
The decision allows the few non-normal URIs to take part in a slightly  
irrational HTTP dance which allows everyone to say: look, since it  
didn't return a 200 code, its not 'normal', and HTTP says it doesn't  
identify anything at all; so the 'normal' assumptions about what it  
denotes are cancelled. And that cancellation is the entire content of  
the decision: it has no other purpose. The nature of the entity which  
handles the GET, and the presence or absence of 'representations' of  
it, are irrelevant.

> It beats me why anyone would want to do that

The reason is that there are, believe it or not, entities in the  
universe other than web servers; and people want to refer to them  
using URIs.

> ; but if we can make them happy with a minimal tweak to the language  
> of an existing status code, then why not. HTTP is for everyone.
>
>> If the URI in the GET request is not intended to denote the  
>> resource to which the GET is directed, then that resource must  
>> issue a 303 redirection, and must not return a representation using  
>> a 200 status code.
>
> There is no such thing as denotation in HTTP. The only relation  
> between URIs and resources in HTTP is "identifies".

Which, if i means anything at all when used between a symbol and a non-
computational entity, means 'denote' (or, if you prefer, 'refers to'  
or 'is a name for'; they are all equivalent usages.) And again, I  
challenge you (or anyone else) to tall me what "identifies" can  
possibly mean, in thee circumstances, other than this.

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

That model is either (1) already about denotation, or (2) utterly  
broken, or (3) meaningless as stated.

>
>> That has nothing to do with the existence or not of such a  
>> representation. Even if the representation exists and the server  
>> has access to it, it cannot return it with a 200 code when the URI  
>> is intended to denote some other thing, in particular a non-
>> information resource of some kind.
>
> Wether a representation exists or not for a particular kind of  
> resource is entirely up to the server owner, as far as HTTP is  
> concerned. If you subscribe to a religion that says, "Thou shall not  
> make a representation of me, for I am not an information resource",  
> then that's great, and let me shake your hand brother, but this has  
> no effect on HTTP.

But thats the easy case. The hard case, for you, is when I use that  
very handy English word "representation" is one of its normal senses,  
not when I refuse to use it at all. There are many,  many kinds of  
representations of things, and only a miniscule proportion of them  
have anything even remotely to do with computers or network transfer  
protocols.

>
>> If we follow your rule, above, and also httprange14, then a server  
>> can be placed in an impossible position. If it has a representation  
>> of itself which  could be put into a 200-code response, and it  
>> receives a GET request with a URI which it knows (somehow, perhaps  
>> by some externally agreed convention) is being used to denote a non-
>> information resource; what should it do? HTTPrange14 requires it to  
>> not deliver a 200-coded reply, but your criterion requires that it  
>> must. This is why I think the wording should make absilutely  
>> minimal assumptions about what exactly the 303 means.
>
> (RDF hat back on) Any sensible definition of "non-information  
> resource" obviously MUST entail "does not have representations in  
> the HTTP sense". In fact, that IS the definition of "non-information  
> resource", in my book.
>

Of course, but that is completely irrelevant to my point. The server,  
in my example, is not the non-information resource that the URI refers  
to; that is precisely why httprange14 requires it, the server, to emit  
a 303 code rather than a 200 code. It is merely the servant whose job  
it is to emit the appropriate code to make everything work properly.  
But it is AN information resource, and it may well have a  
representation (in the http sense) of itself. Its just a different  
resource than the one the URI denotes/refers to.

> Wrapping up:
>
> For the function of the HTTP transfer protocol, it does not matter  
> what exactly the nature of the things identified by URIs is.

Oh, but it does. Because HTTP talks about information transfer between  
entities which can transfer information, but it talks of  
'identification' of ANY THINGS WHATSOEVER, whether they can or even  
possibly could transfer information. For example, a numeral identifies  
a number, and also is a representation of it. So HTTP should apply to  
this case as well, according to what you say here. I should be able to  
send a GET request to the number seventeen and expect to get sent back  
a 200-coded response with a suitable numeral in its body, say "17". I  
know that is ridiculous: but it FOLLOWS FROM WHAT YOU ARE SAYING;  
ergo, what you are saying is ridiculous.  So you ought to modify what  
you are saying, so that it makes more sense.

>
> For the function of the HTTP transfer protocol, it does not matter  
> wether the things you serve as representations on your server make  
> particularly good representations of the resources.
>
> 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. But the HTTP  
> protocol itself is and should be agnostic with regard to your  
> position in these debates. That's layering.

No, it is a poisonous combination of semantic (or maybe philosophical  
or semiotic) ignorance, and hubris. You want http to be universal, but  
you are claiming a kind of universality which goes way beyond anything  
to do with network architecture, and so you can't escape the  
consequences by appealing to network design principles.  Maybe you  
don't intend to be doing this, but it is being done by what you (and I  
should cast this in a kind of anonymous plural, as the excellent  
southern phrase y'all, as I don't intend this rant to be directed at  
you in particular) are actually saying.

Best wishes

Pat

>
> Best,
> Richard
>
>
>
>>
>> Pat
>>
>>> ....Roy
>>>
>>>
>>>
>>
>> ------------------------------------------------------------
>> IHMC                                     [phone] or (650)494  
>> 3973
>> 40 South Alcaniz St.           [phone]   office
>> Pensacola                            [phone]   fax
>> FL 32502                              [phone]   mobile
>> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>>
>>
>>
>>
>>
>>
>
>
>

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[Xiaoshu Wang-3]

Pat Hayes wrote:

>
> On Jul 11, 2009, at 5:27 AM, Richard Cyganiak wrote:
>
>> Pat,
>>
>> On 10 Jul 2009, at 01:32, Pat Hayes wrote:
>>>> If the server has a transferable representation, it would
>>>> respond to the GET with the appropriate status code (200 or 304).
>>>
>>> Well, yes, IF it were driven solely by what one might call rational
>>> HTTP architectural principles. BUt surely the whole issue about
>>> httprange14 is that it introduces new principles which on their face
>>> have nothing to do with http architecture as such, but to do with
>>> denotation and naming.
>>
>> Not as far as HTTP is concerned. HTTP is just a transfer protocol.
>> The HTTP world is really simple:
>>
>> 1. There are URIs. URIs are thought to identify things called resources.
>
> OK, stop there and tell me what you mean here by "identifies". Because...
>
>> As far as HTTP is concerned, it does not matter much what the
>> resource actually is -- a document, a file on a server, a person,
>> whatever.
>
> ... in the usual sense of 'identifies' that one might expect to be use
> in the context of a network transfer protocol, which is similar to the
> use one might expect when talking about programming language
> identifiers and what they identify, it most certainly does matter. In
> particular, it simply does not make sense to speak, using that normal
> terminology, of 'identifying' a person (or a galaxy or a sodium atom,
> etc.); in fact, it does not make sense to talk of identifying anything
> much beyond some kind of data structure or data object. So if HTML
> claims to be able to make sense of talking of 'identifying' people
> (for example), it must be in a wholly different space than all
> previous computationally based notational systems, and be using the
> word "identify" in a wholly different sense. And, to repeat, can you
> tell me what that sense is?
>
>>
>> 2. Resources (whatever they are) are thought to have things called
>> representations. As far as HTTP is concerned, it is totally up to the
>> server owner to decide what's a representation of what. After the
>> server owner has made their decision, a resource either has a
>> representation or not.
>
> Really? OK, I will take you at your word. I am a server owner, and I
> will decide that a certain resource, to wit, me, has a thing called a
> representation of me. This representation of me is in fact a portrait,
> painted using acrylic paints on a piece of masonite approximately 30
> cm square almost exactly a month ago: but let us not go into details,
> as you tell me that such details are none of HTTP's business. Still,
> the representation exists, and the resource has it. OK, let us proceed.
>
>>
>> 3. If a resource has a representation, then a GET to its URI should
>> be answered by 200. If not, then 303, 404 or 410 would be fine choices.
>
> So, HTTP must reply to a GET on my URI with a 200. OK, what should it
> put as the payload of this 200 response, attached to the code
> information? HOw do I get acrylic-coated masonite into an http
> response? There is no representation which can be transmitted in bits.
> You did not mention this aspect in your above summary: was that an
> omission?
>
>>
>> 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.
>
> As you can see, I took advantage of this freedom in my example.
>
>> All these matters of denotation, information resources and so on are
>> introduced by higher layers of the architecture.
>
> Wrong. Denotation is not introduced by a higher level, and even if it
> were, it would not be higher in an architectural sense. You, in this
> very message, in fact brought denotation into the picture, by telling
> me that a URI can "identify" a person. URIs are symbols strings, and
> the ONLY POSSIBLE SEMANTIC RELATIONSHIP between ANY symbol and a
> physical object, is denotation. Sorry to shout there a little, but the
> point needs to be made strongly. That is what "denotation" means: it
> is all that is left of "identifying" when you take away the actual
> network machinery, the computational byte-transferring. And you have
> to take this away when you start claiming to talk of relationships
> between names (of any kind) and non-computational entities such as
> people (or indeed of any kind), simply because computational
> byte-transfer talk is COMPLETELY IRRELEVANT to semantic relationships
> (such as "identification") between symbols (of any kind) and
> non-computational entities. The fact, if it is a fact, that this word
> is not in your technical vocabulary is entirely irrelevant. By
> claiming that your symbols "identify" non-computational entities such
> as people or books (or the weather in Oaxacala, to take another random
> example) , you are no longer playing in the network-architectural
> sandbox, precisely because these kind of things simply are not
> connected to networks in the same functional sense that things like
> web servers are. Either HTTP is a computational notion or it isn't. If
> it is, then it is indeed quite simple. And I would be delighted if the
> HTTP literature simply restricted itself to the computational world.
> But it does not, and never has: HTTP has ALWAYS had these claims to
> semantic grandeur: it has ALWAYS claimed to be not just about web
> sites and web servers and files and documents, but about the whole
> grand span of symbol usage to refer to absolutely anything in any
> possible universe. And if indeed that is what HTTP is claiming to be
> able to talk about, then it is about denotation, right out of the box.
>
>>
>> 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.
>
> See above. If indeed it is out of scope, so is any talk of URIs
> "identifying" people. You can't have it both ways. Either you are
> doing real semantics or you aren't. If you aren't, then don't make
> ridiculous claims about "identifying" things that have no possible
> connection to any physical network, or of "representations" that
> cannot be sent in a byte stream.
>
>> 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.
>
> OK, please tell me how to use HTTP to send my piece of masonite
> attached to a 200 code. I've made up MY mind: over to you.
>
>>
>> Now, different subcommunities have different opinions on how to model
>> resources and representations. That's not a good thing, and it would
>> be good for interoperability if everyone agreed. However, this is
>> pretty much orthogonal to any discussion of the HTTP protocol. As
>> long as the subcommunities subscribe to the basic
>> "URI-identifies-resource-which-can-have-representations" model, HTTP
>> can accomodate them.
>>
>> Now let me take off my RDF hat for a bit.
>>
>> 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.
>
> No, that is not the primary reason. Http-range-14 is not about
> resources, it is about URIs and what they denote. The dilemma is that
> people want 'normal' URIs to denote what it that HTTP thinks of them
> as identifying, the "information resource" (not that that matters).
> Which would be fine, except that there are some URIs which people want
> to denote something else. And still, actually for different ('linked
> data', Timblish) reasons, people want a GET on those URIs to finish
> up, one way or another, with useful information being returned. This
> is a problem. It would be ugly to have two 'kinds' of URI, and
> impossible to change the millions of 'normal' URIs in any way at all.
> The decision allows the few non-normal URIs to take part in a slightly
> irrational HTTP dance which allows everyone to say: look, since it
> didn't return a 200 code, its not 'normal', and HTTP says it doesn't
> identify anything at all; so the 'normal' assumptions about what it
> denotes are cancelled. And that cancellation is the entire content of
> the decision: it has no other purpose. The nature of the entity which
> handles the GET, and the presence or absence of 'representations' of
> it, are irrelevant.
>
>> It beats me why anyone would want to do that
>
> The reason is that there are, believe it or not, entities in the
> universe other than web servers; and people want to refer to them
> using URIs.
>
>> ; but if we can make them happy with a minimal tweak to the language
>> of an existing status code, then why not. HTTP is for everyone.
>>
>>> If the URI in the GET request is not intended to denote the resource
>>> to which the GET is directed, then that resource must issue a 303
>>> redirection, and must not return a representation using a 200 status
>>> code.
>>
>> There is no such thing as denotation in HTTP. The only relation
>> between URIs and resources in HTTP is "identifies".
>
> Which, if i means anything at all when used between a symbol and a
> non-computational entity, means 'denote' (or, if you prefer, 'refers
> to' or 'is a name for'; they are all equivalent usages.) And again, I
> challenge you (or anyone else) to tall me what "identifies" can
> possibly mean, in thee circumstances, other than this.
>
>> 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.
>
> That model is either (1) already about denotation, or (2) utterly
> broken, or (3) meaningless as stated.
>
>>
>>> That has nothing to do with the existence or not of such a
>>> representation. Even if the representation exists and the server has
>>> access to it, it cannot return it with a 200 code when the URI is
>>> intended to denote some other thing, in particular a non-information
>>> resource of some kind.
>>
>> Wether a representation exists or not for a particular kind of
>> resource is entirely up to the server owner, as far as HTTP is
>> concerned. If you subscribe to a religion that says, "Thou shall not
>> make a representation of me, for I am not an information resource",
>> then that's great, and let me shake your hand brother, but this has
>> no effect on HTTP.
>
> But thats the easy case. The hard case, for you, is when I use that
> very handy English word "representation" is one of its normal senses,
> not when I refuse to use it at all. There are many,  many kinds of
> representations of things, and only a miniscule proportion of them
> have anything even remotely to do with computers or network transfer
> protocols.
>
>>
>>> If we follow your rule, above, and also httprange14, then a server
>>> can be placed in an impossible position. If it has a representation
>>> of itself which  could be put into a 200-code response, and it
>>> receives a GET request with a URI which it knows (somehow, perhaps
>>> by some externally agreed convention) is being used to denote a
>>> non-information resource; what should it do? HTTPrange14 requires it
>>> to not deliver a 200-coded reply, but your criterion requires that
>>> it must. This is why I think the wording should make absilutely
>>> minimal assumptions about what exactly the 303 means.
>>
>> (RDF hat back on) Any sensible definition of "non-information
>> resource" obviously MUST entail "does not have representations in the
>> HTTP sense". In fact, that IS the definition of "non-information
>> resource", in my book.
>>
>
> Of course, but that is completely irrelevant to my point. The server,
> in my example, is not the non-information resource that the URI refers
> to; that is precisely why httprange14 requires it, the server, to emit
> a 303 code rather than a 200 code. It is merely the servant whose job
> it is to emit the appropriate code to make everything work properly.
> But it is AN information resource, and it may well have a
> representation (in the http sense) of itself. Its just a different
> resource than the one the URI denotes/refers to.
>
>> Wrapping up:
>>
>> For the function of the HTTP transfer protocol, it does not matter
>> what exactly the nature of the things identified by URIs is.
>
> Oh, but it does. Because HTTP talks about information transfer between
> entities which can transfer information, but it talks of
> 'identification' of ANY THINGS WHATSOEVER, whether they can or even
> possibly could transfer information. For example, a numeral identifies
> a number, and also is a representation of it. So HTTP should apply to
> this case as well, according to what you say here. I should be able to
> send a GET request to the number seventeen and expect to get sent back
> a 200-coded response with a suitable numeral in its body, say "17". I
> know that is ridiculous: but it FOLLOWS FROM WHAT YOU ARE SAYING;
> ergo, what you are saying is ridiculous.  So you ought to modify what
> you are saying, so that it makes more sense.
>
>>
>> For the function of the HTTP transfer protocol, it does not matter
>> wether the things you serve as representations on your server make
>> particularly good representations of the resources.
>>
>> 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. But the HTTP protocol
>> itself is and should be agnostic with regard to your position in
>> these debates. That's layering.
>
> No, it is a poisonous combination of semantic (or maybe philosophical
> or semiotic) ignorance, and hubris. You want http to be universal, but
> you are claiming a kind of universality which goes way beyond anything
> to do with network architecture, and so you can't escape the
> consequences by appealing to network design principles.  Maybe you
> don't intend to be doing this, but it is being done by what you (and I
> should cast this in a kind of anonymous plural, as the excellent
> southern phrase y'all, as I don't intend this rant to be directed at
> you in particular) are actually saying.

I like this -- "it is a poisonous combination of *philosophical*
ignorance with hubris".  I have had this sentiment for quite a while.

But between Alan and Pat, I actually think that you two agree, as oppose
to disagree.  The problem is, however, the dual sense of an HTTP-URI,
which is used both as a name, (which is all about denotation) and a
locator, (which is all about transportation).  I believe if you two
reword your arguments by clarifying the exact use, you will find that
there is not much that you two disagree philosophically.

TAG, take my suggestion -- make *one* pure URN for the Web. It doesn't
have to be in the shape of the schemeless-one as I have proposed.  As
long it is a pure name, in the sense that there is no predefined binding
of a transportation protocol, it will do the job.

Let's not use the cost-excuse.  I just don't buy it.  First, I don't
believe the cost is high because how can adding a new URI scheme any
existing schemes.  Second, even if it is high, it will be worth it. So,
we will not spend those endless discussion all caused by an ambiguous
wording.

Xiaoshu

[Richard Cyganiak-2]

Pat,

1. You are on the web architecture mailing list. It should have  
occurred to you that I use the word "representation" in the web  
architecture sense: a stream of bytes with a content type (and maybe  
additional metadata). Your examples about your painted self-portrait  
and the number 17 miss the point. It's like insisting on discussing  
human anatomy in a thread about object-oriented programming languages  
because not all "members" are instance-scoped variables.

2. I said: "As far as HTTP is concerned, it does not matter much what  
the resource actually is -- a document, a file on a server, a person,  
whatever." You heard: "A URI can identify a person." What I meant was:  
"For HTTP, it REALLY DOES NOT MATTER what the resource actually is."  
It is simply the thing that is thought to sit behind the HTTP  
interface and that the HTTP conversation is about. You can implement  
the HTTP protocol, both on the server and client side, while being  
totally agnostic about what can and cannot be identified by HTTP. All  
you need to know is that URIs identify something that can have  
publisher-chosen representations. Wether that something actually is a  
document, file on a server, or a person, is IRRELEVANT to discussions  
of the HTTP protocol.

Because you misunderstood my point on these two counts, you end up  
ranting against a POV that I do not hold.

I especially continue to maintain that any talk about denotation is  
out of place on the HTTP protocol level. There is no such thing as  
denotation in the universe of the Hypertext Transfer Protocol. Yes,  
people obviously use HTTP URIs to denote all sorts of things, and a  
lot can be said about how one should model resources and  
representations based on the things one wants to denote, and what one  
can or cannot infer about the denotation of a URI based on HTTP  
interactions, but none of this matters one bit for the actual  
operations of the protocol. The protocol is just about pushing  
representations around.

Best,
Richard



On 13 Jul 2009, at 01:31, Pat Hayes wrote:

> On Jul 11, 2009, at 5:27 AM, Richard Cyganiak wrote:
>
>> Pat,
>>
>> On 10 Jul 2009, at 01:32, Pat Hayes wrote:
>>>> If the server has a transferable representation, it would
>>>> respond to the GET with the appropriate status code (200 or 304).
>>>
>>> Well, yes, IF it were driven solely by what one might call  
>>> rational HTTP architectural principles. BUt surely the whole issue  
>>> about httprange14 is that it introduces new principles which on  
>>> their face have nothing to do with http architecture as such, but  
>>> to do with denotation and naming.
>>
>> Not as far as HTTP is concerned. HTTP is just a transfer protocol.  
>> The HTTP world is really simple:
>>
>> 1. There are URIs. URIs are thought to identify things called  
>> resources.
>
> OK, stop there and tell me what you mean here by "identifies".  
> Because...
>
>> As far as HTTP is concerned, it does not matter much what the  
>> resource actually is -- a document, a file on a server, a person,  
>> whatever.
>
> ... in the usual sense of 'identifies' that one might expect to be  
> use in the context of a network transfer protocol, which is similar  
> to the use one might expect when talking about programming language  
> identifiers and what they identify, it most certainly does matter.  
> In particular, it simply does not make sense to speak, using that  
> normal terminology, of 'identifying' a person (or a galaxy or a  
> sodium atom, etc.); in fact, it does not make sense to talk of  
> identifying anything much beyond some kind of data structure or data  
> object. So if HTML claims to be able to make sense of talking of  
> 'identifying' people (for example), it must be in a wholly different  
> space than all previous computationally based notational systems,  
> and be using the word "identify" in a wholly different sense. And,  
> to repeat, can you tell me what that sense is?
>
>>
>> 2. Resources (whatever they are) are thought to have things called  
>> representations. As far as HTTP is concerned, it is totally up to  
>> the server owner to decide what's a representation of what. After  
>> the server owner has made their decision, a resource either has a  
>> representation or not.
>
> Really? OK, I will take you at your word. I am a server owner, and I  
> will decide that a certain resource, to wit, me, has a thing called  
> a representation of me. This representation of me is in fact a  
> portrait, painted using acrylic paints on a piece of masonite  
> approximately 30 cm square almost exactly a month ago: but let us  
> not go into details, as you tell me that such details are none of  
> HTTP's business. Still, the representation exists, and the resource  
> has it. OK, let us proceed.
>
>>
>> 3. If a resource has a representation, then a GET to its URI should  
>> be answered by 200. If not, then 303, 404 or 410 would be fine  
>> choices.
>
> So, HTTP must reply to a GET on my URI with a 200. OK, what should  
> it put as the payload of this 200 response, attached to the code  
> information? HOw do I get acrylic-coated masonite into an http  
> response? There is no representation which can be transmitted in  
> bits. You did not mention this aspect in your above summary: was  
> that an omission?
>
>>
>> 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.
>
> As you can see, I took advantage of this freedom in my example.
>
>> All these matters of denotation, information resources and so on  
>> are introduced by higher layers of the architecture.
>
> Wrong. Denotation is not introduced by a higher level, and even if  
> it were, it would not be higher in an architectural sense. You, in  
> this very message, in fact brought denotation into the picture, by  
> telling me that a URI can "identify" a person. URIs are symbols  
> strings, and the ONLY POSSIBLE SEMANTIC RELATIONSHIP between ANY  
> symbol and a physical object, is denotation. Sorry to shout there a  
> little, but the point needs to be made strongly. That is what  
> "denotation" means: it is all that is left of "identifying" when you  
> take away the actual network machinery, the computational byte-
> transferring. And you have to take this away when you start claiming  
> to talk of relationships between names (of any kind) and non-
> computational entities such as people (or indeed of any kind),  
> simply because computational byte-transfer talk is COMPLETELY  
> IRRELEVANT to semantic relationships (such as "identification")  
> between symbols (of any kind) and non-computational entities. The  
> fact, if it is a fact, that this word is not in your technical  
> vocabulary is entirely irrelevant. By claiming that your symbols  
> "identify" non-computational entities such as people or books (or  
> the weather in Oaxacala, to take another random example) , you are  
> no longer playing in the network-architectural sandbox, precisely  
> because these kind of things simply are not connected to networks in  
> the same functional sense that things like web servers are. Either  
> HTTP is a computational notion or it isn't. If it is, then it is  
> indeed quite simple. And I would be delighted if the HTTP literature  
> simply restricted itself to the computational world. But it does  
> not, and never has: HTTP has ALWAYS had these claims to semantic  
> grandeur: it has ALWAYS claimed to be not just about web sites and  
> web servers and files and documents, but about the whole grand span  
> of symbol usage to refer to absolutely anything in any possible  
> universe. And if indeed that is what HTTP is claiming to be able to  
> talk about, then it is about denotation, right out of the box.
>
>>
>> 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.
>
> See above. If indeed it is out of scope, so is any talk of URIs  
> "identifying" people. You can't have it both ways. Either you are  
> doing real semantics or you aren't. If you aren't, then don't make  
> ridiculous claims about "identifying" things that have no possible  
> connection to any physical network, or of "representations" that  
> cannot be sent in a byte stream.
>
>> 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.
>
> OK, please tell me how to use HTTP to send my piece of masonite  
> attached to a 200 code. I've made up MY mind: over to you.
>
>>
>> Now, different subcommunities have different opinions on how to  
>> model resources and representations. That's not a good thing, and  
>> it would be good for interoperability if everyone agreed. However,  
>> this is pretty much orthogonal to any discussion of the HTTP  
>> protocol. As long as the subcommunities subscribe to the basic "URI-
>> identifies-resource-which-can-have-representations" model, HTTP can  
>> accomodate them.
>>
>> Now let me take off my RDF hat for a bit.
>>
>> 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.
>
> No, that is not the primary reason. Http-range-14 is not about  
> resources, it is about URIs and what they denote. The dilemma is  
> that people want 'normal' URIs to denote what it that HTTP thinks of  
> them as identifying, the "information resource" (not that that  
> matters). Which would be fine, except that there are some URIs which  
> people want to denote something else. And still, actually for  
> different ('linked data', Timblish) reasons, people want a GET on  
> those URIs to finish up, one way or another, with useful information  
> being returned. This is a problem. It would be ugly to have two  
> 'kinds' of URI, and impossible to change the millions of 'normal'  
> URIs in any way at all. The decision allows the few non-normal URIs  
> to take part in a slightly irrational HTTP dance which allows  
> everyone to say: look, since it didn't return a 200 code, its not  
> 'normal', and HTTP says it doesn't identify anything at all; so the  
> 'normal' assumptions about what it denotes are cancelled. And that  
> cancellation is the entire content of the decision: it has no other  
> purpose. The nature of the entity which handles the GET, and the  
> presence or absence of 'representations' of it, are irrelevant.
>
>> It beats me why anyone would want to do that
>
> The reason is that there are, believe it or not, entities in the  
> universe other than web servers; and people want to refer to them  
> using URIs.
>
>> ; but if we can make them happy with a minimal tweak to the  
>> language of an existing status code, then why not. HTTP is for  
>> everyone.
>>
>>> If the URI in the GET request is not intended to denote the  
>>> resource to which the GET is directed, then that resource must  
>>> issue a 303 redirection, and must not return a representation  
>>> using a 200 status code.
>>
>> There is no such thing as denotation in HTTP. The only relation  
>> between URIs and resources in HTTP is "identifies".
>
> Which, if i means anything at all when used between a symbol and a  
> non-computational entity, means 'denote' (or, if you prefer, 'refers  
> to' or 'is a name for'; they are all equivalent usages.) And again,  
> I challenge you (or anyone else) to tall me what "identifies" can  
> possibly mean, in thee circumstances, other than this.
>
>> 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.
>
> That model is either (1) already about denotation, or (2) utterly  
> broken, or (3) meaningless as stated.
>
>>
>>> That has nothing to do with the existence or not of such a  
>>> representation. Even if the representation exists and the server  
>>> has access to it, it cannot return it with a 200 code when the URI  
>>> is intended to denote some other thing, in particular a non-
>>> information resource of some kind.
>>
>> Wether a representation exists or not for a particular kind of  
>> resource is entirely up to the server owner, as far as HTTP is  
>> concerned. If you subscribe to a religion that says, "Thou shall  
>> not make a representation of me, for I am not an information  
>> resource", then that's great, and let me shake your hand brother,  
>> but this has no effect on HTTP.
>
> But thats the easy case. The hard case, for you, is when I use that  
> very handy English word "representation" is one of its normal  
> senses, not when I refuse to use it at all. There are many,  many  
> kinds of representations of things, and only a miniscule proportion  
> of them have anything even remotely to do with computers or network  
> transfer protocols.
>
>>
>>> If we follow your rule, above, and also httprange14, then a server  
>>> can be placed in an impossible position. If it has a  
>>> representation of itself which  could be put into a 200-code  
>>> response, and it receives a GET request with a URI which it knows  
>>> (somehow, perhaps by some externally agreed convention) is being  
>>> used to denote a non-information resource; what should it do?  
>>> HTTPrange14 requires it to not deliver a 200-coded reply, but your  
>>> criterion requires that it must. This is why I think the wording  
>>> should make absilutely minimal assumptions about what exactly the  
>>> 303 means.
>>
>> (RDF hat back on) Any sensible definition of "non-information  
>> resource" obviously MUST entail "does not have representations in  
>> the HTTP sense". In fact, that IS the definition of "non-
>> information resource", in my book.
>>
>
> Of course, but that is completely irrelevant to my point. The  
> server, in my example, is not the non-information resource that the  
> URI refers to; that is precisely why httprange14 requires it, the  
> server, to emit a 303 code rather than a 200 code. It is merely the  
> servant whose job it is to emit the appropriate code to make  
> everything work properly. But it is AN information resource, and it  
> may well have a representation (in the http sense) of itself. Its  
> just a different resource than the one the URI denotes/refers to.
>
>> Wrapping up:
>>
>> For the function of the HTTP transfer protocol, it does not matter  
>> what exactly the nature of the things identified by URIs is.
>
> Oh, but it does. Because HTTP talks about information transfer  
> between entities which can transfer information, but it talks of  
> 'identification' of ANY THINGS WHATSOEVER, whether they can or even  
> possibly could transfer information. For example, a numeral  
> identifies a number, and also is a representation of it. So HTTP  
> should apply to this case as well, according to what you say here. I  
> should be able to send a GET request to the number seventeen and  
> expect to get sent back a 200-coded response with a suitable numeral  
> in its body, say "17". I know that is ridiculous: but it FOLLOWS  
> FROM WHAT YOU ARE SAYING; ergo, what you are saying is ridiculous.  
> So you ought to modify what you are saying, so that it makes more  
> sense.
>
>>
>> For the function of the HTTP transfer protocol, it does not matter  
>> wether the things you serve as representations on your server make  
>> particularly good representations of the resources.
>>
>> 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. But the HTTP  
>> protocol itself is and should be agnostic with regard to your  
>> position in these debates. That's layering.
>
> No, it is a poisonous combination of semantic (or maybe  
> philosophical or semiotic) ignorance, and hubris. You want http to  
> be universal, but you are claiming a kind of universality which goes  
> way beyond anything to do with network architecture, and so you  
> can't escape the consequences by appealing to network design  
> principles.  Maybe you don't intend to be doing this, but it is  
> being done by what you (and I should cast this in a kind of  
> anonymous plural, as the excellent southern phrase y'all, as I don't  
> intend this rant to be directed at you in particular) are actually  
> saying.
>
> Best wishes
>
> Pat
>
>>
>> Best,
>> Richard
>>
>>
>>
>>>
>>> Pat
>>>
>>>> ....Roy
>>>>
>>>>
>>>>
>>>
>>> ------------------------------------------------------------
>>> IHMC                                     [phone] or (650)494  
>>> 3973
>>> 40 South Alcaniz St.           [phone]   office
>>> Pensacola                            [phone]   fax
>>> FL 32502                              [phone]   mobile
>>> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
> ------------------------------------------------------------
> IHMC                                     [phone] or (650)494  
> 3973
> 40 South Alcaniz St.           [phone]   office
> Pensacola                            [phone]   fax
> FL 32502                              [phone]   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>

[Richard Cyganiak-2]

On 12 Jul 2009, at 00:47, Alan Ruttenberg wrote:
>>>>  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?

I think the word "transferable" just adds a bit of wiggle room that  
allows the server not to send the representation even if it has one.  
An example might be a client that is not authorized to view the  
resource, and the server 303-redirects it to a preview of the  
resource. Another example might be a representation that is too large  
for a mobile client on a slow connection. There might be many reasons  
why a server, even though it technically speaking has a  
representation, would prefer to redirect a client to some other  
resource instead.

(I didn't write Roy's text and am obviously just guessing.)

Richard

> 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                                     [phone] or (650)494  
>> 3973
>> 40 South Alcaniz St.           [phone]   office
>> Pensacola                            [phone]   fax
>> FL 32502                              [phone]   mobile
>> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>>
>>
>>
>>
>>
>>
>>
>

[Pat Hayes]

On Jul 13, 2009, at 10:24 AM, Richard Cyganiak wrote:

> Pat,
>
> 1. You are on the web architecture mailing list. It should have  
> occurred to you that I use the word "representation" in the web  
> architecture sense: a stream of bytes with a content type (and maybe  
> additional metadata). Your examples about your painted self-portrait  
> and the number 17 miss the point. It's like insisting on discussing  
> human anatomy in a thread about object-oriented programming  
> languages because not all "members" are instance-scoped variables.

That would be a fine response if you had not, in the same email,  
spoken of URI "identifying" people, and told me in block capitals that  
the nature of the resources and what counts as a representation, is  
entirely irrelevant to HTTP. To repeat: you can't have it both ways.  
If you are talking solely about architecture, then don't stray into  
non-architectural semantic issues. People (and books and Mexican  
weather) are not computational/architectural entities: they play no  
role whatever in network architecture.

>
> 2. I said: "As far as HTTP is concerned, it does not matter much  
> what the resource actually is -- a document, a file on a server, a  
> person, whatever." You heard: "A URI can identify a person." What I  
> meant was: "For HTTP, it REALLY DOES NOT MATTER what the resource  
> actually is." It is simply the thing that is thought to sit behind  
> the HTTP interface and that the HTTP conversation is about. You can  
> implement the HTTP protocol, both on the server and client side,  
> while being totally agnostic about what can and cannot be identified  
> by HTTP. All you need to know is that URIs identify something that  
> can have publisher-chosen representations. Wether that something  
> actually is a document, file on a server, or a person, is IRRELEVANT  
> to discussions of the HTTP protocol.

I'm sorry, I DO NOT ACCEPT THIS. I believe that YOU ARE WRONG. And  
here is why. This thing, that is thought to sit behind the HTTP  
interface, cannot be absolutely anything. It does have to have certain  
properties simply by virtue of BEING THE KIND OF THING THAT CAN SIT  
BEHIND ANY SUCH INTERFACE. That is, it has to be a computational or  
maybe network engine of some kind. It has to be capable of accepting  
and emitting byte streams, and so forth. People are not such entities,  
neither are books or galaxies or numbers or imaginary aardvarks. But  
you claim that HTTP can deal with URIs "identifying" such things.  
Which is nonsense; or at any rate, it is nonsense if "identifies" is  
understood in terms appropriate to network architecture. If, on the  
other hand, "identifies" is understood as  including the relationship  
between a symbolic name and a thing, which is often called denotation  
or reference or naming, then it certainly makes sense to say that a  
URI can "identify" a person or a book. But then, HTTP is already a  
semantic specification as well as an architectural one. It is about  
meaning and reference, not solely about network transfer. I really  
don't care which path you take at this fork in the road, but you can't  
go both ways. If HTTP is semantic, then it is about denotation right  
down to the metal. If it's not, then URI's can't "identify" people and  
books and galaxies in the same sense (presumably a sense related to  
network architecture in some way) that they "identify" web sites and  
digital documents. PLEASE get your story straight, one way or the  
other. (Again, that is a y'all.)

>
> Because you misunderstood my point

I do not think I did misunderstand it. Your POV has a background  
assumption which you seem to be (from these emails) unaware of, and  
which is false; indeed, ridiculous: to wit, that all things that can  
be referred to are things that can be thought of in terms appropriate  
to a computer network architecture. For example, the very idea of  
"layering" is a computational notion. There is no layering in the  
world outside computer science.

> on these two counts, you end up ranting against a POV that I do not  
> hold.
>
> I especially continue to maintain that any talk about denotation is  
> out of place on the HTTP protocol level. There is no such thing as  
> denotation in the universe of the Hypertext Transfer Protocol. Yes,  
> people obviously use HTTP URIs to denote all sorts of things, and a  
> lot can be said about how one should model resources and  
> representations based on the things one wants to denote, and what  
> one can or cannot infer about the denotation of a URI based on HTTP  
> interactions, but none of this matters one bit for the actual  
> operations of the protocol.

Seems to me that this may have been true before http-range-14, but it  
is not a stance that can possibly be maintained in the face of that  
decision. And your final sentence above is, surely you can yourself  
see, tendentious. If the HTTP 'layer' really were completely  
unconcerned with denotation, how could one *possibly* infer anything  
about what a URI denotes from *anything* about HTTP interactions?

> The protocol is just about pushing representations around.

Well, I would be delighted if this were true. But then the HTTP specs  
should not claim or even hint at the idea that URIs can "identify" non-
computational things, or that such things can have "representations"  
in its specialized sense. (It would be very good manners, in fact, to  
clarify just what that highly specialized sense of "representation"  
is, and state explicitly that it is not intended to cover any wider  
sense of representation, for example the sense in which it it used in  
such phrases as "knowledge representation".) And you should be quite  
open and clear about the fact that this view of HTTP is not compatible  
with the http-range-14 decision.

Pat

PS. You never did tell me what you think "identifies" means, by the  
way. Apparently it means something, since you dismissed my  
interpretation of it as inappropriate. So there are some restrictions  
on the meaning of "identifies". Can you even sketch what they might be?

>
> Best,
> Richard
>
>
>
> On 13 Jul 2009, at 01:31, Pat Hayes wrote:
>> On Jul 11, 2009, at 5:27 AM, Richard Cyganiak wrote:
>>
>>> Pat,
>>>
>>> On 10 Jul 2009, at 01:32, Pat Hayes wrote:
>>>>> If the server has a transferable representation, it would
>>>>> respond to the GET with the appropriate status code (200 or 304).
>>>>
>>>> Well, yes, IF it were driven solely by what one might call  
>>>> rational HTTP architectural principles. BUt surely the whole  
>>>> issue about httprange14 is that it introduces new principles  
>>>> which on their face have nothing to do with http architecture as  
>>>> such, but to do with denotation and naming.
>>>
>>> Not as far as HTTP is concerned. HTTP is just a transfer protocol.  
>>> The HTTP world is really simple:
>>>
>>> 1. There are URIs. URIs are thought to identify things called  
>>> resources.
>>
>> OK, stop there and tell me what you mean here by "identifies".  
>> Because...
>>
>>> As far as HTTP is concerned, it does not matter much what the  
>>> resource actually is -- a document, a file on a server, a person,  
>>> whatever.
>>
>> ... in the usual sense of 'identifies' that one might expect to be  
>> use in the context of a network transfer protocol, which is similar  
>> to the use one might expect when talking about programming language  
>> identifiers and what they identify, it most certainly does matter.  
>> In particular, it simply does not make sense to speak, using that  
>> normal terminology, of 'identifying' a person (or a galaxy or a  
>> sodium atom, etc.); in fact, it does not make sense to talk of  
>> identifying anything much beyond some kind of data structure or  
>> data object. So if HTML claims to be able to make sense of talking  
>> of 'identifying' people (for example), it must be in a wholly  
>> different space than all previous computationally based notational  
>> systems, and be using the word "identify" in a wholly different  
>> sense. And, to repeat, can you tell me what that sense is?
>>
>>>
>>> 2. Resources (whatever they are) are thought to have things called  
>>> representations. As far as HTTP is concerned, it is totally up to  
>>> the server owner to decide what's a representation of what. After  
>>> the server owner has made their decision, a resource either has a  
>>> representation or not.
>>
>> Really? OK, I will take you at your word. I am a server owner, and  
>> I will decide that a certain resource, to wit, me, has a thing  
>> called a representation of me. This representation of me is in fact  
>> a portrait, painted using acrylic paints on a piece of masonite  
>> approximately 30 cm square almost exactly a month ago: but let us  
>> not go into details, as you tell me that such details are none of  
>> HTTP's business. Still, the representation exists, and the resource  
>> has it. OK, let us proceed.
>>
>>>
>>> 3. If a resource has a representation, then a GET to its URI  
>>> should be answered by 200. If not, then 303, 404 or 410 would be  
>>> fine choices.
>>
>> So, HTTP must reply to a GET on my URI with a 200. OK, what should  
>> it put as the payload of this 200 response, attached to the code  
>> information? HOw do I get acrylic-coated masonite into an http  
>> response? There is no representation which can be transmitted in  
>> bits. You did not mention this aspect in your above summary: was  
>> that an omission?
>>
>>>
>>> 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.
>>
>> As you can see, I took advantage of this freedom in my example.
>>
>>> All these matters of denotation, information resources and so on  
>>> are introduced by higher layers of the architecture.
>>
>> Wrong. Denotation is not introduced by a higher level, and even if  
>> it were, it would not be higher in an architectural sense. You, in  
>> this very message, in fact brought denotation into the picture, by  
>> telling me that a URI can "identify" a person. URIs are symbols  
>> strings, and the ONLY POSSIBLE SEMANTIC RELATIONSHIP between ANY  
>> symbol and a physical object, is denotation. Sorry to shout there a  
>> little, but the point needs to be made strongly. That is what  
>> "denotation" means: it is all that is left of "identifying" when  
>> you take away the actual network machinery, the computational byte-
>> transferring. And you have to take this away when you start  
>> claiming to talk of relationships between names (of any kind) and  
>> non-computational entities such as people (or indeed of any kind),  
>> simply because computational byte-transfer talk is COMPLETELY  
>> IRRELEVANT to semantic relationships (such as "identification")  
>> between symbols (of any kind) and non-computational entities. The  
>> fact, if it is a fact, that this word is not in your technical  
>> vocabulary is entirely irrelevant. By claiming that your symbols  
>> "identify" non-computational entities such as people or books (or  
>> the weather in Oaxacala, to take another random example) , you are  
>> no longer playing in the network-architectural sandbox, precisely  
>> because these kind of things simply are not connected to networks  
>> in the same functional sense that things like web servers are.  
>> Either HTTP is a computational notion or it isn't. If it is, then  
>> it is indeed quite simple. And I would be delighted if the HTTP  
>> literature simply restricted itself to the computational world. But  
>> it does not, and never has: HTTP has ALWAYS had these claims to  
>> semantic grandeur: it has ALWAYS claimed to be not just about web  
>> sites and web servers and files and documents, but about the whole  
>> grand span of symbol usage to refer to absolutely anything in any  
>> possible universe. And if indeed that is what HTTP is claiming to  
>> be able to talk about, then it is about denotation, right out of  
>> the box.
>>
>>>
>>> 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.
>>
>> See above. If indeed it is out of scope, so is any talk of URIs  
>> "identifying" people. You can't have it both ways. Either you are  
>> doing real semantics or you aren't. If you aren't, then don't make  
>> ridiculous claims about "identifying" things that have no possible  
>> connection to any physical network, or of "representations" that  
>> cannot be sent in a byte stream.
>>
>>> 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.
>>
>> OK, please tell me how to use HTTP to send my piece of masonite  
>> attached to a 200 code. I've made up MY mind: over to you.
>>
>>>
>>> Now, different subcommunities have different opinions on how to  
>>> model resources and representations. That's not a good thing, and  
>>> it would be good for interoperability if everyone agreed. However,  
>>> this is pretty much orthogonal to any discussion of the HTTP  
>>> protocol. As long as the subcommunities subscribe to the basic  
>>> "URI-identifies-resource-which-can-have-representations" model,  
>>> HTTP can accomodate them.
>>>
>>> Now let me take off my RDF hat for a bit.
>>>
>>> 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.
>>
>> No, that is not the primary reason. Http-range-14 is not about  
>> resources, it is about URIs and what they denote. The dilemma is  
>> that people want 'normal' URIs to denote what it that HTTP thinks  
>> of them as identifying, the "information resource" (not that that  
>> matters). Which would be fine, except that there are some URIs  
>> which people want to denote something else. And still, actually for  
>> different ('linked data', Timblish) reasons, people want a GET on  
>> those URIs to finish up, one way or another, with useful  
>> information being returned. This is a problem. It would be ugly to  
>> have two 'kinds' of URI, and impossible to change the millions of  
>> 'normal' URIs in any way at all. The decision allows the few non-
>> normal URIs to take part in a slightly irrational HTTP dance which  
>> allows everyone to say: look, since it didn't return a 200 code,  
>> its not 'normal', and HTTP says it doesn't identify anything at  
>> all; so the 'normal' assumptions about what it denotes are  
>> cancelled. And that cancellation is the entire content of the  
>> decision: it has no other purpose. The nature of the entity which  
>> handles the GET, and the presence or absence of 'representations'  
>> of it, are irrelevant.
>>
>>> It beats me why anyone would want to do that
>>
>> The reason is that there are, believe it or not, entities in the  
>> universe other than web servers; and people want to refer to them  
>> using URIs.
>>
>>> ; but if we can make them happy with a minimal tweak to the  
>>> language of an existing status code, then why not. HTTP is for  
>>> everyone.
>>>
>>>> If the URI in the GET request is not intended to denote the  
>>>> resource to which the GET is directed, then that resource must  
>>>> issue a 303 redirection, and must not return a representation  
>>>> using a 200 status code.
>>>
>>> There is no such thing as denotation in HTTP. The only relation  
>>> between URIs and resources in HTTP is "identifies".
>>
>> Which, if i means anything at all when used between a symbol and a  
>> non-computational entity, means 'denote' (or, if you prefer,  
>> 'refers to' or 'is a name for'; they are all equivalent usages.)  
>> And again, I challenge you (or anyone else) to tall me what  
>> "identifies" can possibly mean, in thee circumstances, other than  
>> this.
>>
>>> 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.
>>
>> That model is either (1) already about denotation, or (2) utterly  
>> broken, or (3) meaningless as stated.
>>
>>>
>>>> That has nothing to do with the existence or not of such a  
>>>> representation. Even if the representation exists and the server  
>>>> has access to it, it cannot return it with a 200 code when the  
>>>> URI is intended to denote some other thing, in particular a non-
>>>> information resource of some kind.
>>>
>>> Wether a representation exists or not for a particular kind of  
>>> resource is entirely up to the server owner, as far as HTTP is  
>>> concerned. If you subscribe to a religion that says, "Thou shall  
>>> not make a representation of me, for I am not an information  
>>> resource", then that's great, and let me shake your hand brother,  
>>> but this has no effect on HTTP.
>>
>> But thats the easy case. The hard case, for you, is when I use that  
>> very handy English word "representation" is one of its normal  
>> senses, not when I refuse to use it at all. There are many,  many  
>> kinds of representations of things, and only a miniscule proportion  
>> of them have anything even remotely to do with computers or network  
>> transfer protocols.
>>
>>>
>>>> If we follow your rule, above, and also httprange14, then a  
>>>> server can be placed in an impossible position. If it has a  
>>>> representation of itself which  could be put into a 200-code  
>>>> response, and it receives a GET request with a URI which it knows  
>>>> (somehow, perhaps by some externally agreed convention) is being  
>>>> used to denote a non-information resource; what should it do?  
>>>> HTTPrange14 requires it to not deliver a 200-coded reply, but  
>>>> your criterion requires that it must. This is why I think the  
>>>> wording should make absilutely minimal assumptions about what  
>>>> exactly the 303 means.
>>>
>>> (RDF hat back on) Any sensible definition of "non-information  
>>> resource" obviously MUST entail "does not have representations in  
>>> the HTTP sense". In fact, that IS the definition of "non-
>>> information resource", in my book.
>>>
>>
>> Of course, but that is completely irrelevant to my point. The  
>> server, in my example, is not the non-information resource that the  
>> URI refers to; that is precisely why httprange14 requires it, the  
>> server, to emit a 303 code rather than a 200 code. It is merely the  
>> servant whose job it is to emit the appropriate code to make  
>> everything work properly. But it is AN information resource, and it  
>> may well have a representation (in the http sense) of itself. Its  
>> just a different resource than the one the URI denotes/refers to.
>>
>>> Wrapping up:
>>>
>>> For the function of the HTTP transfer protocol, it does not matter  
>>> what exactly the nature of the things identified by URIs is.
>>
>> Oh, but it does. Because HTTP talks about information transfer  
>> between entities which can transfer information, but it talks of  
>> 'identification' of ANY THINGS WHATSOEVER, whether they can or even  
>> possibly could transfer information. For example, a numeral  
>> identifies a number, and also is a representation of it. So HTTP  
>> should apply to this case as well, according to what you say here.  
>> I should be able to send a GET request to the number seventeen and  
>> expect to get sent back a 200-coded response with a suitable  
>> numeral in its body, say "17". I know that is ridiculous: but it  
>> FOLLOWS FROM WHAT YOU ARE SAYING; ergo, what you are saying is  
>> ridiculous.  So you ought to modify what you are saying, so that it  
>> makes more sense.
>>
>>>
>>> For the function of the HTTP transfer protocol, it does not matter  
>>> wether the things you serve as representations on your server make  
>>> particularly good representations of the resources.
>>>
>>> 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. But the HTTP  
>>> protocol itself is and should be agnostic with regard to your  
>>> position in these debates. That's layering.
>>
>> No, it is a poisonous combination of semantic (or maybe  
>> philosophical or semiotic) ignorance, and hubris. You want http to  
>> be universal, but you are claiming a kind of universality which  
>> goes way beyond anything to do with network architecture, and so  
>> you can't escape the consequences by appealing to network design  
>> principles.  Maybe you don't intend to be doing this, but it is  
>> being done by what you (and I should cast this in a kind of  
>> anonymous plural, as the excellent southern phrase y'all, as I  
>> don't intend this rant to be directed at you in particular) are  
>> actually saying.
>>
>> Best wishes
>>
>> Pat
>>
>>>
>>> Best,
>>> Richard
>>>
>>>
>>>
>>>>
>>>> Pat
>>>>
>>>>> ....Roy
>>>>>
>>>>>
>>>>>
>>>>
>>>> ------------------------------------------------------------
>>>> IHMC                                     [phone] or  
>>>> [phone]
>>>> 40 South Alcaniz St.           [phone]   office
>>>> Pensacola                            [phone]   fax
>>>> FL 32502                              [phone]   mobile
>>>> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>> ------------------------------------------------------------
>> IHMC                                     [phone] or (650)494  
>> 3973
>> 40 South Alcaniz St.           [phone]   office
>> Pensacola                            [phone]   fax
>> FL 32502                              [phone]   mobile
>> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>>
>>
>>
>>
>>
>
>
>

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[Pat Hayes]

On Jul 13, 2009, at 10:32 AM, Richard Cyganiak wrote:

>
> On 12 Jul 2009, at 00:47, Alan Ruttenberg wrote:
>>>>> 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?
>
> I think the word "transferable" just adds a bit of wiggle room that  
> allows the server not to send the representation even if it has one.  
> An example might be a client that is not authorized to view the  
> resource, and the server 303-redirects it to a preview of the  
> resource. Another example might be a representation that is too  
> large for a mobile client on a slow connection. There might be many  
> reasons why a server, even though it technically speaking has a  
> representation, would prefer to redirect a client to some other  
> resource instead.

Ah, that would indeed be just the wiggle room I would need to make  
sense of this, since it allows for the possibility of there being a  
200-appropriate representation even when a 303 is emitted. But the  
text really should make this intention clearer than it does, if indeed  
this is what it means to be saying. I took Roy's reply to my suggested  
rewording to be a firm rejection of this interpretation, but maybe I  
missed the wiggle.

Pat

>
> (I didn't write Roy's text and am obviously just guessing.)
>
> Richard
>
>
>
>
>
>
>> 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                                     [phone] or (650)494  
>>> 3973
>>> 40 South Alcaniz St.           [phone]   office
>>> Pensacola                            [phone]   fax
>>> FL 32502                              [phone]   mobile
>>> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
>

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[Richard Cyganiak-2]

Pat,

You still didn't get my point. You ask:

"In the context of the HTTP protocol, what can be a resource? What can  
be the thing sitting behind the HTTP interface?"

I take YOUR preferred answer to be: "It can only be a computational  
resource."

It appears that you THINK that my answer is: "It can be anything."

But that is NOT my answer. My answer is: "I don't know, I don't care,  
and it's the wrong question to ask. It's just a resource, something  
that has representations. If you wish to discuss such matters, then  
this automatically moves you outside of the scope of the HTTP protocol."

Can HTTP URIs identify people? As far as the operation of HTTP  
protocol is concerned, I'm 100% agnostic. It is simply unnecessary to  
answer that question in order to reason about, implement, or specify  
the HTTP protocol.

More below.

On 13 Jul 2009, at 19:33, Pat Hayes wrote:

>> 1. You are on the web architecture mailing list. It should have  
>> occurred to you that I use the word "representation" in the web  
>> architecture sense: a stream of bytes with a content type (and  
>> maybe additional metadata). Your examples about your painted self-
>> portrait and the number 17 miss the point. It's like insisting on  
>> discussing human anatomy in a thread about object-oriented  
>> programming languages because not all "members" are instance-scoped  
>> variables.
>
> That would be a fine response if you had not, in the same email,  
> spoken of URI "identifying" people,

I did not say that.

> and told me in block capitals that the nature of the resources and  
> what counts as a representation, is entirely irrelevant to HTTP. To  
> repeat: you can't have it both ways. If you are talking solely about  
> architecture, then don't stray into non-architectural semantic issues.

I'm talking solely about a transfer protocol.

> People (and books and Mexican weather) are not computational/
> architectural entities: they play no role whatever in network  
> architecture.

Right, and I did not claim otherwise.

>> 2. I said: "As far as HTTP is concerned, it does not matter much  
>> what the resource actually is -- a document, a file on a server, a  
>> person, whatever." You heard: "A URI can identify a person." What I  
>> meant was: "For HTTP, it REALLY DOES NOT MATTER what the resource  
>> actually is."

Here, read this again. Look, I have no opinion on the question wether  
a HTTP URI can identify a person!

>> It is simply the thing that is thought to sit behind the HTTP  
>> interface and that the HTTP conversation is about. You can  
>> implement the HTTP protocol, both on the server and client side,  
>> while being totally agnostic about what can and cannot be  
>> identified by HTTP. All you need to know is that URIs identify  
>> something that can have publisher-chosen representations. Wether  
>> that something actually is a document, file on a server, or a  
>> person, is IRRELEVANT to discussions of the HTTP protocol.
>
> I'm sorry, I DO NOT ACCEPT THIS. I believe that YOU ARE WRONG. And  
> here is why. This thing, that is thought to sit behind the HTTP  
> interface, cannot be absolutely anything. It does have to have  
> certain properties simply by virtue of BEING THE KIND OF THING THAT  
> CAN SIT BEHIND ANY SUCH INTERFACE. That is, it has to be a  
> computational or maybe network engine of some kind.

That's not a necessary assumption. From prodding the interface, I  
cannot tell what's sitting behind it. I can just get representations  
of the thing, I cannot learn its nature. Hence why should I make  
assumptions about its nature?

> It has to be capable of accepting and emitting byte streams, and so  
> forth.

No. The byte streams are accepted/emitted by the web server, which is  
a separate component. The URI http://example.com:8080/foo.html tells  
me that there might be a server at example.com and I can maybe connect  
to port 8080 and make an HTTP request to hopefully get a  
representation of the thing identified by the URI, whatever it is. The  
web server is not the resource. The resource does not have to be a web  
server.

> People are not such entities, neither are books or galaxies or  
> numbers or imaginary aardvarks. But you claim that HTTP can deal  
> with URIs "identifying" such things.

No, I did not say that.

Although I'm sure that we can dream up contraptions that causally  
connect any of the above to a web server.

You want to legislate what kind of contraption is allowed behind the  
HTTP interface. I say: For specifying the HTTP protocol, let's not  
care, as long as a URI goes in and a representation comes out. We can  
gloss over the question what the resource actually *is*.

> Which is nonsense; or at any rate, it is nonsense if "identifies" is  
> understood in terms appropriate to network architecture. If, on the  
> other hand, "identifies" is understood as  including the  
> relationship between a symbolic name and a thing, which is often  
> called denotation or reference or naming, then it certainly makes  
> sense to say that a URI can "identify" a person or a book. But then,  
> HTTP is already a semantic specification as well as an architectural  
> one. It is about meaning and reference, not solely about network  
> transfer.

HTTP is NOT a semantic system. HTTP is NOT about denotation. In the  
context of HTTP, "identifies" simply means "names something that has  
representations." In the context of HTTP, "identifies" does not  
include denotation.

> I really don't care which path you take at this fork in the road,  
> but you can't go both ways. If HTTP is semantic, then it is about  
> denotation right down to the metal.

HTTP is not semantic.

> If it's not, then URI's can't "identify" people and books and  
> galaxies in the same sense (presumably a sense related to network  
> architecture in some way) that they "identify" web sites and digital  
> documents.

In the context of HTTP, URIs identify things that have representations.

> PLEASE get your story straight, one way or the other. (Again, that  
> is a y'all.)
>
>>
>> Because you misunderstood my point
>
> I do not think I did misunderstand it.

Your writing suggests otherwise.

> Your POV has a background assumption which you seem to be (from  
> these emails) unaware of, and which is false; indeed, ridiculous: to  
> wit, that all things that can be referred to are things that can be  
> thought of in terms appropriate to a computer network architecture.

I do not hold that assumption. I hold the following assumptions:

1. The purpose of the Hypertext Transfer Protocol is to exchange  
representations over networks.

2. The Hypertext Transfer Protocol spec should treat HTTP URIs simply  
as identifiers inside a transfer protocol.

3. If people want to do weird shit with HTTP URIs, beyond exchanging  
representations over networks, that's great and more power to them.

4. The HTTP spec does not need to worry about regulating such weird  
shit.

5. Someone should clearly worry about such weird shit, but not in the  
HTTP spec.

> For example, the very idea of "layering" is a computational notion.  
> There is no layering in the world outside computer science.

Not getting your point. I'm talking about transfer protocols and  
knowledge representation. What does the world outside of computer  
science have to do with that?

>> on these two counts, you end up ranting against a POV that I do not  
>> hold.
>>
>> I especially continue to maintain that any talk about denotation is  
>> out of place on the HTTP protocol level. There is no such thing as  
>> denotation in the universe of the Hypertext Transfer Protocol. Yes,  
>> people obviously use HTTP URIs to denote all sorts of things, and a  
>> lot can be said about how one should model resources and  
>> representations based on the things one wants to denote, and what  
>> one can or cannot infer about the denotation of a URI based on HTTP  
>> interactions, but none of this matters one bit for the actual  
>> operations of the protocol.
>
> Seems to me that this may have been true before http-range-14, but  
> it is not a stance that can possibly be maintained in the face of  
> that decision.

I think you're insisting on an unhelpful reading of httpRange-14.  
Again, try wrapping your head around that layering idea:

There is one layer that tells you how you can push representations  
around the network. That's HTTP.

There is another layer that tells you how to best model the world as  
resources and representations. That's where RDF, denotation, Linked  
Data, information resources etc live. AWWW and other best practices  
documents say a lot about this layer.

httpRange-14 is about the second layer, not about the first. So I  
don't see how httpRange-14 has any effect on anything that concerns  
the first layer.

> And your final sentence above is, surely you can yourself see,  
> tendentious. If the HTTP 'layer' really were completely unconcerned  
> with denotation, how could one *possibly* infer anything about what  
> a URI denotes from *anything* about HTTP interactions?

The HTTP protocol allows you to infer things about the  
*representations* that a resource has. That's all, you cannot learn  
anything else about the resource just through HTTP. However, by  
inspecting those representations, you might learn something about the  
intended denotation of the URI. But that, again, is outside the scope  
of the HTTP protocol.

>> The protocol is just about pushing representations around.
>
> Well, I would be delighted if this were true. But then the HTTP  
> specs should not claim or even hint at the idea that URIs can  
> "identify" non-computational things, or that such things can have  
> "representations" in its specialized sense.

I'm delighted to inform you that I'm pretty sure that the HTTP spec  
doesn't hint at the idea of URIs identifying non-computational things,  
anywhere.

> (It would be very good manners, in fact, to clarify just what that  
> highly specialized sense of "representation" is, and state  
> explicitly that it is not intended to cover any wider sense of  
> representation, for example the sense in which it it used in such  
> phrases as "knowledge representation".)

I think that AWWW, RFC 2616, and Roy's Chapter 5 are all very clear  
about this. I don't understand how you can read any of those and walk  
away thinking that an acrylic painting might be a representation.

> And you should be quite open and clear about the fact that this view  
> of HTTP is not compatible with the http-range-14 decision.

I don't see that incompatibility.

> Pat
>
> PS. You never did tell me what you think "identifies" means, by the  
> way.
> Apparently it means something, since you dismissed my interpretation  
> of it as inappropriate. So there are some restrictions on the  
> meaning of "identifies". Can you even sketch what they might be?

As far as HTTP is concerned, "identifies" is the relationship between  
a URI and the resource whose representation you receive when you  
perform a GET on the URI. That's all.

(I'm just talking about HTTP here; RDF people often use "identifies"  
synonymous with "denotes", but such talk goes beyond and outside the  
scope of the HTTP protocol.)

Let's please try to somehow wrap up this discussion. Can you somehow  
live with the POV that one can specify and implement HTTP while  
avoiding the question what resources actually are? And that questions  
such as "What does a given URI denote? What is a valid representation  
of a given resource? Are there things that ought not to be denoted by  
URIs?" can be answered elsewhere than the HTTP spec?

Best,
Richard

>
>
>
>>
>> Best,
>> Richard
>>
>>
>>
>> On 13 Jul 2009, at 01:31, Pat Hayes wrote:
>>> On Jul 11, 2009, at 5:27 AM, Richard Cyganiak wrote:
>>>
>>>> Pat,
>>>>
>>>> On 10 Jul 2009, at 01:32, Pat Hayes wrote:
>>>>>> If the server has a transferable representation, it would
>>>>>> respond to the GET with the appropriate status code (200 or 304).
>>>>>
>>>>> Well, yes, IF it were driven solely by what one might call  
>>>>> rational HTTP architectural principles. BUt surely the whole  
>>>>> issue about httprange14 is that it introduces new principles  
>>>>> which on their face have nothing to do with http architecture as  
>>>>> such, but to do with denotation and naming.
>>>>
>>>> Not as far as HTTP is concerned. HTTP is just a transfer  
>>>> protocol. The HTTP world is really simple:
>>>>
>>>> 1. There are URIs. URIs are thought to identify things called  
>>>> resources.
>>>
>>> OK, stop there and tell me what you mean here by "identifies".  
>>> Because...
>>>
>>>> As far as HTTP is concerned, it does not matter much what the  
>>>> resource actually is -- a document, a file on a server, a person,  
>>>> whatever.
>>>
>>> ... in the usual sense of 'identifies' that one might expect to be  
>>> use in the context of a network transfer protocol, which is  
>>> similar to the use one might expect when talking about programming  
>>> language identifiers and what they identify, it most certainly  
>>> does matter. In particular, it simply does not make sense to  
>>> speak, using that normal terminology, of 'identifying' a person  
>>> (or a galaxy or a sodium atom, etc.); in fact, it does not make  
>>> sense to talk of identifying anything much beyond some kind of  
>>> data structure or data object. So if HTML claims to be able to  
>>> make sense of talking of 'identifying' people (for example), it  
>>> must be in a wholly different space than all previous  
>>> computationally based notational systems, and be using the word  
>>> "identify" in a wholly different sense. And, to repeat, can you  
>>> tell me what that sense is?
>>>
>>>>
>>>> 2. Resources (whatever they are) are thought to have things  
>>>> called representations. As far as HTTP is concerned, it is  
>>>> totally up to the server owner to decide what's a representation  
>>>> of what. After the server owner has made their decision, a  
>>>> resource either has a representation or not.
>>>
>>> Really? OK, I will take you at your word. I am a server owner, and  
>>> I will decide that a certain resource, to wit, me, has a thing  
>>> called a representation of me. This representation of me is in  
>>> fact a portrait, painted using acrylic paints on a piece of  
>>> masonite approximately 30 cm square almost exactly a month ago:  
>>> but let us not go into details, as you tell me that such details  
>>> are none of HTTP's business. Still, the representation exists, and  
>>> the resource has it. OK, let us proceed.
>>>
>>>>
>>>> 3. If a resource has a representation, then a GET to its URI  
>>>> should be answered by 200. If not, then 303, 404 or 410 would be  
>>>> fine choices.
>>>
>>> So, HTTP must reply to a GET on my URI with a 200. OK, what should  
>>> it put as the payload of this 200 response, attached to the code  
>>> information? HOw do I get acrylic-coated masonite into an http  
>>> response? There is no representation which can be transmitted in  
>>> bits. You did not mention this aspect in your above summary: was  
>>> that an omission?
>>>
>>>>
>>>> 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.
>>>
>>> As you can see, I took advantage of this freedom in my example.
>>>
>>>> All these matters of denotation, information resources and so on  
>>>> are introduced by higher layers of the architecture.
>>>
>>> Wrong. Denotation is not introduced by a higher level, and even if  
>>> it were, it would not be higher in an architectural sense. You, in  
>>> this very message, in fact brought denotation into the picture, by  
>>> telling me that a URI can "identify" a person. URIs are symbols  
>>> strings, and the ONLY POSSIBLE SEMANTIC RELATIONSHIP between ANY  
>>> symbol and a physical object, is denotation. Sorry to shout there  
>>> a little, but the point needs to be made strongly. That is what  
>>> "denotation" means: it is all that is left of "identifying" when  
>>> you take away the actual network machinery, the computational byte-
>>> transferring. And you have to take this away when you start  
>>> claiming to talk of relationships between names (of any kind) and  
>>> non-computational entities such as people (or indeed of any kind),  
>>> simply because computational byte-transfer talk is COMPLETELY  
>>> IRRELEVANT to semantic relationships (such as "identification")  
>>> between symbols (of any kind) and non-computational entities. The  
>>> fact, if it is a fact, that this word is not in your technical  
>>> vocabulary is entirely irrelevant. By claiming that your symbols  
>>> "identify" non-computational entities such as people or books (or  
>>> the weather in Oaxacala, to take another random example) , you are  
>>> no longer playing in the network-architectural sandbox, precisely  
>>> because these kind of things simply are not connected to networks  
>>> in the same functional sense that things like web servers are.  
>>> Either HTTP is a computational notion or it isn't. If it is, then  
>>> it is indeed quite simple. And I would be delighted if the HTTP  
>>> literature simply restricted itself to the computational world.  
>>> But it does not, and never has: HTTP has ALWAYS had these claims  
>>> to semantic grandeur: it has ALWAYS claimed to be not just about  
>>> web sites and web servers and files and documents, but about the  
>>> whole grand span of symbol usage to refer to absolutely anything  
>>> in any possible universe. And if indeed that is what HTTP is  
>>> claiming to be able to talk about, then it is about denotation,  
>>> right out of the box.
>>>
>>>>
>>>> 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.
>>>
>>> See above. If indeed it is out of scope, so is any talk of URIs  
>>> "identifying" people. You can't have it both ways. Either you are  
>>> doing real semantics or you aren't. If you aren't, then don't make  
>>> ridiculous claims about "identifying" things that have no possible  
>>> connection to any physical network, or of "representations" that  
>>> cannot be sent in a byte stream.
>>>
>>>> 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.
>>>
>>> OK, please tell me how to use HTTP to send my piece of masonite  
>>> attached to a 200 code. I've made up MY mind: over to you.
>>>
>>>>
>>>> Now, different subcommunities have different opinions on how to  
>>>> model resources and representations. That's not a good thing, and  
>>>> it would be good for interoperability if everyone agreed.  
>>>> However, this is pretty much orthogonal to any discussion of the  
>>>> HTTP protocol. As long as the subcommunities subscribe to the  
>>>> basic "URI-identifies-resource-which-can-have-representations"  
>>>> model, HTTP can accomodate them.
>>>>
>>>> Now let me take off my RDF hat for a bit.
>>>>
>>>> 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.
>>>
>>> No, that is not the primary reason. Http-range-14 is not about  
>>> resources, it is about URIs and what they denote. The dilemma is  
>>> that people want 'normal' URIs to denote what it that HTTP thinks  
>>> of them as identifying, the "information resource" (not that that  
>>> matters). Which would be fine, except that there are some URIs  
>>> which people want to denote something else. And still, actually  
>>> for different ('linked data', Timblish) reasons, people want a GET  
>>> on those URIs to finish up, one way or another, with useful  
>>> information being returned. This is a problem. It would be ugly to  
>>> have two 'kinds' of URI, and impossible to change the millions of  
>>> 'normal' URIs in any way at all. The decision allows the few non-
>>> normal URIs to take part in a slightly irrational HTTP dance which  
>>> allows everyone to say: look, since it didn't return a 200 code,  
>>> its not 'normal', and HTTP says it doesn't identify anything at  
>>> all; so the 'normal' assumptions about what it denotes are  
>>> cancelled. And that cancellation is the entire content of the  
>>> decision: it has no other purpose. The nature of the entity which  
>>> handles the GET, and the presence or absence of 'representations'  
>>> of it, are irrelevant.
>>>
>>>> It beats me why anyone would want to do that
>>>
>>> The reason is that there are, believe it or not, entities in the  
>>> universe other than web servers; and people want to refer to them  
>>> using URIs.
>>>
>>>> ; but if we can make them happy with a minimal tweak to the  
>>>> language of an existing status code, then why not. HTTP is for  
>>>> everyone.
>>>>
>>>>> If the URI in the GET request is not intended to denote the  
>>>>> resource to which the GET is directed, then that resource must  
>>>>> issue a 303 redirection, and must not return a representation  
>>>>> using a 200 status code.
>>>>
>>>> There is no such thing as denotation in HTTP. The only relation  
>>>> between URIs and resources in HTTP is "identifies".
>>>
>>> Which, if i means anything at all when used between a symbol and a  
>>> non-computational entity, means 'denote' (or, if you prefer,  
>>> 'refers to' or 'is a name for'; they are all equivalent usages.)  
>>> And again, I challenge you (or anyone else) to tall me what  
>>> "identifies" can possibly mean, in thee circumstances, other than  
>>> this.
>>>
>>>> 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.
>>>
>>> That model is either (1) already about denotation, or (2) utterly  
>>> broken, or (3) meaningless as stated.
>>>
>>>>
>>>>> That has nothing to do with the existence or not of such a  
>>>>> representation. Even if the representation exists and the server  
>>>>> has access to it, it cannot return it with a 200 code when the  
>>>>> URI is intended to denote some other thing, in particular a non-
>>>>> information resource of some kind.
>>>>
>>>> Wether a representation exists or not for a particular kind of  
>>>> resource is entirely up to the server owner, as far as HTTP is  
>>>> concerned. If you subscribe to a religion that says, "Thou shall  
>>>> not make a representation of me, for I am not an information  
>>>> resource", then that's great, and let me shake your hand brother,  
>>>> but this has no effect on HTTP.
>>>
>>> But thats the easy case. The hard case, for you, is when I use  
>>> that very handy English word "representation" is one of its normal  
>>> senses, not when I refuse to use it at all. There are many,  many  
>>> kinds of representations of things, and only a miniscule  
>>> proportion of them have anything even remotely to do with  
>>> computers or network transfer protocols.
>>>
>>>>
>>>>> If we follow your rule, above, and also httprange14, then a  
>>>>> server can be placed in an impossible position. If it has a  
>>>>> representation of itself which  could be put into a 200-code  
>>>>> response, and it receives a GET request with a URI which it  
>>>>> knows (somehow, perhaps by some externally agreed convention) is  
>>>>> being used to denote a non-information resource; what should it  
>>>>> do? HTTPrange14 requires it to not deliver a 200-coded reply,  
>>>>> but your criterion requires that it must. This is why I think  
>>>>> the wording should make absilutely minimal assumptions about  
>>>>> what exactly the 303 means.
>>>>
>>>> (RDF hat back on) Any sensible definition of "non-information  
>>>> resource" obviously MUST entail "does not have representations in  
>>>> the HTTP sense". In fact, that IS the definition of "non-
>>>> information resource", in my book.
>>>>
>>>
>>> Of course, but that is completely irrelevant to my point. The  
>>> server, in my example, is not the non-information resource that  
>>> the URI refers to; that is precisely why httprange14 requires it,  
>>> the server, to emit a 303 code rather than a 200 code. It is  
>>> merely the servant whose job it is to emit the appropriate code to  
>>> make everything work properly. But it is AN information resource,  
>>> and it may well have a representation (in the http sense) of  
>>> itself. Its just a different resource than the one the URI denotes/
>>> refers to.
>>>
>>>> Wrapping up:
>>>>
>>>> For the function of the HTTP transfer protocol, it does not  
>>>> matter what exactly the nature of the things identified by URIs is.
>>>
>>> Oh, but it does. Because HTTP talks about information transfer  
>>> between entities which can transfer information, but it talks of  
>>> 'identification' of ANY THINGS WHATSOEVER, whether they can or  
>>> even possibly could transfer information. For example, a numeral  
>>> identifies a number, and also is a representation of it. So HTTP  
>>> should apply to this case as well, according to what you say here.  
>>> I should be able to send a GET request to the number seventeen and  
>>> expect to get sent back a 200-coded response with a suitable  
>>> numeral in its body, say "17". I know that is ridiculous: but it  
>>> FOLLOWS FROM WHAT YOU ARE SAYING; ergo, what you are saying is  
>>> ridiculous.  So you ought to modify what you are saying, so that  
>>> it makes more sense.
>>>
>>>>
>>>> For the function of the HTTP transfer protocol, it does not  
>>>> matter wether the things you serve as representations on your  
>>>> server make particularly good representations of the resources.
>>>>
>>>> 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. But the HTTP protocol itself is and should be agnostic with  
>>>> regard to your position in these debates. That's layering.
>>>
>>> No, it is a poisonous combination of semantic (or maybe  
>>> philosophical or semiotic) ignorance, and hubris. You want http to  
>>> be universal, but you are claiming a kind of universality which  
>>> goes way beyond anything to do with network architecture, and so  
>>> you can't escape the consequences by appealing to network design  
>>> principles.  Maybe you don't intend to be doing this, but it is  
>>> being done by what you (and I should cast this in a kind of  
>>> anonymous plural, as the excellent southern phrase y'all, as I  
>>> don't intend this rant to be directed at you in particular) are  
>>> actually saying.
>>>
>>> Best wishes
>>>
>>> Pat
>>>
>>>>
>>>> Best,
>>>> Richard
>>>>
>>>>
>>>>
>>>>>
>>>>> Pat
>>>>>
>>>>>> ....Roy
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------
>>>>> IHMC                                     [phone] or  
>>>>> [phone]
>>>>> 40 South Alcaniz St.           [phone]   office
>>>>> Pensacola                            [phone]   fax
>>>>> FL 32502                              [phone]   mobile
>>>>> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>> ------------------------------------------------------------
>>> IHMC                                     [phone] or (650)494  
>>> 3973
>>> 40 South Alcaniz St.           [phone]   office
>>> Pensacola                            [phone]   fax
>>> FL 32502                              [phone]   mobile
>>> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
> ------------------------------------------------------------
> IHMC                                     [phone] or (650)494  
> 3973
> 40 South Alcaniz St.           [phone]   office
> Pensacola                            [phone]   fax
> FL 32502                              [phone]   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>

[Alan Ruttenberg-2]

On Sat, Jul 11, 2009 at 6:27 AM, Richard Cyganiak<richard@...> wrote:

> Not as far as HTTP is concerned. HTTP is just a transfer protocol. The HTTP
> world is really simple:
>
> 1. There are URIs. URIs are thought to identify things called resources. As
> far as HTTP is concerned, it does not matter much what the resource actually
> is -- a document, a file on a server, a person, whatever.
>
> 2. Resources (whatever they are) are thought to have things called
> representations. As far as HTTP is concerned, it is totally up to the server
> owner to decide what's a representation of what. After the server owner has
> made their decision, a resource either has a representation or not.
>
> 3. If a resource has a representation, then a GET to its URI should be
> answered by 200. If not, then 303, 404 or 410 would be fine choices.
>
> 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.

This is a nice simple story, but as far as I can tell it just isn't
correct. There are many places in HTTP which address issues of
semantics or otherwise go beyond transport.

e.g Content negotiation:

Most HTTP responses include an entity which contains information for
   interpretation by a human user. Naturally, it is desirable to supply
   the user with the "best available" entity corresponding to the
   request. Unfortunately for servers and caches, not all users have the
   same preferences for what is "best," and not all user agents are
   equally capable of rendering all entity types. For that reason, HTTP
   has provisions for several mechanisms for "content negotiation" --
   the process of selecting the best representation for a given response
   when there are multiple representations available.

      Note: This is not called "format negotiation" because the
      alternate representations may be of the same media type, but use
      different capabilities of that type, be in different languages,
      etc.

or:

 10.2.4   203 Non-Authoritative Information ........................59

or:

 10.4.3    402 Payment Required ....................................66

or:

14.11   Content-Encoding .........................................118
14.12   Content-Language .........................................118

or any of the caching stuff.

---

TCP is a transport protocol. HTTP is concerned with more than just
transport of opaque bit strings. In my view, your presentation of
HTTP's view of resources and representations as a kind of mathematical
abstraction doesn't do justice to the intellectual work that preceded
and led to the development of HTTP (H = Hypertext, for example).

It is certainly true that there are additional layerings that are
added by, e.g. AWWW and RDF, but to suggest that HTTP did not  bring
to the table anything more than shipping certain kinds of packets
called representations which are in grouped in buckets called
resources doesn't seem accurate.

It may very well be the case that whatever HTTP brings to the table in
these areas is underspecified, ambiguous, inconsistent,  and
unhelpful, and that a retrenchment to a view of HTTP along the lines
you suggest might be a useful advance towards a more coherent overall
infrastructure for a Semantic Web. Let's have that discussion, then,
rather than one over who's account of history is right. (my suspicion
is that the older folks will win that one ;-)

-Alan

[Xiaoshu Wang-3]

Pat Hayes wrote:

<snip>

>> on these two counts, you end up ranting against a POV that I do not
>> hold.
>>
>> I especially continue to maintain that any talk about denotation is
>> out of place on the HTTP protocol level. There is no such thing as
>> denotation in the universe of the Hypertext Transfer Protocol. Yes,
>> people obviously use HTTP URIs to denote all sorts of things, and a
>> lot can be said about how one should model resources and
>> representations based on the things one wants to denote, and what one
>> can or cannot infer about the denotation of a URI based on HTTP
>> interactions, but none of this matters one bit for the actual
>> operations of the protocol.
>
> Seems to me that this may have been true before http-range-14, but it
> is not a stance that can possibly be maintained in the face of that
> decision. And your final sentence above is, surely you can yourself
> see, tendentious. If the HTTP 'layer' really were completely
> unconcerned with denotation, how could one *possibly* infer anything
> about what a URI denotes from *anything* about HTTP interactions?

The assumption here is that httpRange-14 is the right direction.  But
that is a big *if*. If anything, this debate only shows how *bad* that
this whole idea of httpRange-14 and information resource thing is.
 

>> The protocol is just about pushing representations around.
>
> Well, I would be delighted if this were true. But then the HTTP specs
> should not claim or even hint at the idea that URIs can "identify"
> non-computational things, or that such things can have
> "representations" in its specialized sense. (It would be very good
> manners, in fact, to clarify just what that highly specialized sense
> of "representation" is, and state explicitly that it is not intended
> to cover any wider sense of representation, for example the sense in
> which it it used in such phrases as "knowledge representation".) And
> you should be quite open and clear about the fact that this view of
> HTTP is not compatible with the http-range-14 decision.

The HTTP protocol should be about pushing representation around.  And it
shouldn't careless about if its URI denotes or identifies anything.  The
latter is up to the one who implements that particular URI.   Let's not
ignore the existence of such entities because it is those who expressed
their denotation semantics.

Also, let's us not play linguistic tricks.  If the owner of
"http://example.com/a.hamburger" makes it to denote a hamburger. Then
HTTP-GET "http://example.com/a.hamburger" means "get me an
awww:representation" of the hamburger. But it does NOT mean the "get"
like in "get me that hamburger" as what we would say in front of a
grill.  To think otherwise is to hallucinate.

httpRange-14 was at first designed to prevent people from episodes of
this kind of hallucination.  But at the end, it ends up with its own one
-- the hallucination of the information resource.

But let's get real.  Let's not temper the HTTP semantics with our own
view on what the world or the Web ought to be.  Sure, you (or y'all) can
have your wonderful world of "information resources".  It is none of my
business.  But -- PLEASE, don't push it upon me. I am just not
sophisticated enough to appreciate that delicate wonder. And most of
all, I don't care.

Xiaoshu