Review of new HTTPbis text for 303 See Other

[Pat Hayes]

On Jul 14, 2009, at 9:01 AM, Xiaoshu Wang wrote:

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

As I said in another post, I think http-range-14 is terrible, but all  
the alternatives are worse.

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

Of course not. But it also does not mean, "get me an  
awww:representation" of the hamburger. Or at least, it had better not  
mean that, since hamburgers don't have awww:representations. Web pages  
about hamburgers can represent (not awww:represent) a hamburger, and  
they of course have awww:representations. But an awww:repreresentation  
of a representation of X is not an awww:representation of X.

> To think otherwise is to hallucinate.

Quite.

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

I don't like the terminology (and I don't think we need it, and  
especially do not need to be debating its exact meaning), but the  
general idea is clear enough: its the thing that HTTP returns the  
awww:representation of. That is certainly not a hallucination, because  
you just made HTTP contact with it.

Pat

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

------------------------------------------------------------
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 14, 2009, at 9:01 AM, Xiaoshu Wang wrote:
>
>> 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.
>
> As I said in another post, I think http-range-14 is terrible, but all
> the alternatives are worse.

Of course there is no better alternative because there is *not* a
problem at the first place. The problem is created by pushing IR into
the Web architecture.  But just like the web architecture should not
deal with hamburgers, it should not deal with IR as well.

>>>> 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.
>
> Of course not. But it also does not mean, "get me an
> awww:representation" of the hamburger. Or at least, it had better not
> mean that, since hamburgers don't have awww:representations. Web pages
> about hamburgers can represent (not awww:represent) a hamburger, and
> they of course have awww:representations. But an awww:repreresentation
> of a representation of X is not an awww:representation of X.

I mentioned that let us not ignore *the existence of an agent* -- the
one who implements the URI.  I do not know if a hamburger *can or
cannot* have an awww:representation because I am not a hamburger.  But I
do know that *I can* give a hamburger an awww:representation.  You don't
have to believe me, that is none of my business.  But to say that no one
should believe me, you cross the line for being either ignorant (of
being me) or arrogant (of being you).

>> To think otherwise is to hallucinate.
>
> Quite.
>
>>
>> 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.
>
> I don't like the terminology (and I don't think we need it, and
> especially do not need to be debating its exact meaning), but the
> general idea is clear enough: its the thing that HTTP returns the
> awww:representation of. That is certainly not a hallucination, because
> you just made HTTP contact with it.

Then, it is fine with me.  You can call an HTTP server, FTP server,
Mailto server or any kind of information server -- an "information
resource".  That is denotation semantics of that word's use.  It is fine
with me because we might just call it "xyz" -- for the sake of avoiding
confusion.  But this denotation semantics should not affect how *I*
implement *my* URI.  Most of all, it should not affect how *I* use the Web.

Xiaoshu

[Pat Hayes]

On Jul 13, 2009, at 7:29 PM, Richard Cyganiak wrote:

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

OK, then my response is, that is not an acceptable answer. It is  
either silly or tendentious. Because if this answer were true, then  
the HTTP protocol should apply to my picture-on-masonite example and a  
host of other examples to which it clearly does not and cannot apply.  
You rejected my example by an appeal to the fact that this was an  
architectural discussion. OK, then, http applies to computer  
architectural issues, but not to, say, newsprint or visual arts,  
right? So the nature of the "something" DOES matter.

<flame>
As for being the wrong question to ask, that really is bloody  
arrogance. We are discussing the wording of a technical specification.  
You want to use words in non-standard ways, ways which do not  
correspond to their normal English meanings, in the very heart of the  
spec, and when someone asks you want you intend them to mean, your  
answer is, that is the wrong question to ask?!!? Sorry, but screw you.  
That is EXACTLY the question to ask, and if can't answer it or refuse  
to answer it, you shouldn't be in the spec-writing business.
  </flame>

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

Absolute nonsense. If URIs can identify people, then your  
implementation strategy will involve surgery. You are trying to have  
things both ways, and I'm not going to let you get away with this,  
because it is intellectually irresponsible. On the one hand, you want  
to claim the implementer's prerogative of staying in your layer and  
not having to even think about what other layers' interpretations are.  
Which I understand and respect, by the way, but only within the  
overall framework of doing computer science (broadly conceived).  
Outside that intellectual discipline, this 'layering' notion simply  
does not apply in the same way. But, on the other hand, you also want  
to claim that HTTP applies not only within a computational framework,  
but to absolutely anything at all that can call itself a "resource"  
which has "representations". And others have already firmly, publicly  
and repeatedly insisted that the term "resource" is not a technical  
word within computer science, but a word which means "absolutely  
anything at all". So, either you are not safely inside the network  
world of computer science here, or else you should repudiate these  
more grandiose claims that are being made about URIs (maybe not by  
you, but they are being made.)

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

"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." "
That says, quite explicitly, that the HTTP protocol and the HTTP spec  
must apply to cases where the resource is a person. If it "does not  
matter" that the URI identifies a person, then the HTTP spec should  
apply to the case where the URI does in fact identify a person. If it  
"does not matter" what the nature of the representation is, then the  
spec should apply to the case where the representation is an acrylic  
painting on masonite. If, on the other hand, you want to rule out or  
not consider these cases, then it damn well DOES MATTER what the  
resource and the representation are. So please stop saying that it  
does not.

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

But you did, by saying that "it does not matter" what the  
representation is. That is why I have been hitting you over the head  
with these ridiculous examples, because what they clearly show is that  
it DOES MATTER.

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

That is not the issue. I am not wanting to rebuild your cognitive  
state. I am only concerned with the words used. To say that "it does  
not matter" what X is, when writing a spec about X, is to say "my spec  
applies to all X's, regardless of their nature."  That makes a VERY  
BIG CLAIM. It is not merely a statement of your unconcern, which BTW I  
understand perfectly, but with which I am not centrally concerned here.

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

Because it has to be the KIND of thing that can be attached to an  
interface at all. People and books and numbers and galaxies don't have  
interfaces in this sense. Of all the things that can be identified by  
a URI, the proportion of them that can possibly be given such an  
interface is vanishingly small.

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

True, and I realized when typing this that it wasnt strictly correct,  
but there are only so many minutes in the day. So let me just say, is  
interfaced to something capable, etc...

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

I think you did. Certainly others say this, loud and clear, and you  
say that it does not matter what the identified things are. To me, it  
follows immediately that you are saying that HTTP applies to these  
cases also.

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

Imaginary aardvarks? The number 17? How about Julius Caesar?

>
> You want to legislate what kind of contraption is allowed behind the  
> HTTP interface.

No. I just want to recognize the obvious fact that there are things  
that URIs are used to "identify" which aren't ever going to be  
interfaced to any server, in any possible world. The universe is way,  
way bigger than the Internet will ever be.

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

You can't gloss over the fact that many resources cannot possibly be  
involved in any way in any kind of network transaction. But they can  
still be referred to.

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

It does if URIs can "identify" people, etc.. Sorry, I don't care how  
big a font you use, you are just WRONG here. You can't have it both  
ways.

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

OK, fine. BUt then it DOES  matter what things the URIs "identify",  
since without semantics,  nothing outside of a computer network can be  
"identified". So please, please stop saying that it doesn't, as this  
means you are making a huge, unsustainable claim about the scope of  
the spec.

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

OK, though "representation" here has a narrow sense, but never mind.  
And...  um...  representations **of what**? Or put another way, what  
makes a byte stream into a "representation" (big word)? Or maybe, you  
don't care, right? So why not say, HTTP is to exchange **byte  
streams** over networks? That would cut out all lot of this  
philosophical chatter right at the root.

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

OK, but (no rhetoric, an honest appeal for help) can you or anyone  
explain, briefly, what you understand "identifier" to mean when used  
in this transfer-protocol context? Without using any semantic terms  
like "refer to" or "means", I presume.

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

Semantics isn't weird shit, but I take your point. You really do not  
want to be understood as saying anything at all about semantics. I  
don't think you have that option, however.

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

Whoa. YOu are NOT talking about knowledge representation here. Your  
sense of "representation" is much narrower than that.

> What does the world outside of computer science have to do with that?

Are you kidding? KR is almost entirely about knowledge of things  
outside computer science, and is centrally concerned with semantics.

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

Believe me, I know about layering. But I also know that it only  
applies in very special circumstances.

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

But is (httprange14) explicitly puts the two layers into close  
contact. It uses an HTTP code to send information about the SEMANTIC  
nature of the thing denoted by a URI. So these nice neat layers have  
gotten wholly jumbled here. I agree with you, having clean layering  
would be a great idea. But that was before http-range-14 came along.

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

HTTPrange14 explicitly denies this. You CAN learn about the resource  
from HTTP. A 200 code means that the resource is an 'information  
resource' identified by the  URI, in the same sense of 'identify' that  
HTTP uses. A 303 code cancels that inference. And this matters to HTTP  
because that is what the 303 code is FOR.

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

You did, in your email response. OK, I havnt checked the latest  
wording with a fine-tooth comb, my bad.

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

Actually no, I have read them all very carefully, several times. None  
of them define their terms or even discuss their own technical  
vocabulary, they just use it as though its meanings were obvious. None  
of them seem to be written by people who have the faintest idea what  
words like "represent" actually mean, even in KR work. They all seem  
to make ridiculous conceptual errors, which I diagnose as due to my  
not following what they are intending to say.  It took me months of  
heavy thinking before I was even able to reconstruct a guess about  
what they were intending to say, and Im still not sure I have it  
right. I still cannot find a trace of meaning in the phrasef "having  
an identity", for example.

> I don't understand how you can read any of those and walk away  
> thinking that an acrylic painting might be a representation.

You misunderstand. My acrylic painting IS a representation. That is  
just a fact, and no pissant W3C specs are going to make it false. So  
when I read that word, "representation" in the documents you cite, i  
have to keep thinking: they don't mean "representation" in any normal  
sense... they don't mean it in the KR sense, which is semantic (took  
me a while to work that one out)... I wonder what sense they actually  
have in mind... lets make a guess... Damn, no, that can't be right  
because then what Roy says here wouldn't be correct... And so on and on.

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

Well, if 303 meant "has no awww:representation" then that would be  
fine, but that's not what httprange14 says.

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

Excellent. Thank you. So, httprange14 is the decision that when GET  
returns a 200 coded response (but not when it returns a 303), then the  
URI is understood to denote whatever it identifies. That's it: no need  
to talk about 'information resources' or any of that guff. And the  
existence or not of an awww:representation of the identified resource  
is irrelevant. And it keeps the layers reasonably layered, as long as  
you are able to use the d-word just once . So can we just say this?

>
> (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?

Not really. Because the world of URI references and "resources" has  
become the entire universe of things that can be referred to. It is  
not the world of things that can be interfaced to computer networks  
any more. So this is not any longer a purely network-architectural  
issue.

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

Answered, yes, but not ignored by the HTTP spec. At the very least,  
the spec should explicitly wash its hands of questions like these,  
instead of saying "it doesn't matter because they are on a different  
layer".  Maybe they don't matter to HTTP, which is fine with me but  
drives a truck through httprange14;  but they are not in a different  
layer.

Best

Pat

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

[Larry Masinter]

This conversation is filling my mailbox. Some general
observations:

(Pat, your arguments are laced with ad hominem, which makes reading
the dialog unpleasant. I don't think Richard is being
silly, intellectually dishonest, bloody arrogant, or any of the
other terms you've used, please refrain.)

It's the nature of standards discussions that people speak
their point of view; doing so isn't arrogant.

It is the nature of technical specifications that it is frequently
necessary to take normal English words in particular technical
way; it is not intellectually dishonest to do so.

It is good practice for technical specifications in standards
groups to say as little as possible in order to meet the
needs of interoperability and the purpose for which the
specification is being written.

It is not necessary or even possible for a technical specification
to answer questions that may be fundamental for applications
that are outside of its scope. It is common, reasonable,
and traditional for standards specifications to "not answer"
questions because answering the question isn't necessary
for the purpose for which the standard was written.

It isn't necessary for the proper functioning of the web and
to accomplish interoperability of web clients and servers
to agree on how to use HTTP URIs and the HTTP protocol --
for that purpose, it isn't necessary to answer the question
of whether a HTTP URI can identify a person.

It may be necessary to answer the question in a technical
specification for the semantic web and in the RDF
specification  -- but the answer more likely
belong in those specifications and not in the
IETF HTTP specification.

It may be necessary for the IETF HTTP specification
be edited in a way that made it clear that it didn't
contain the answer to this question, but I'm not
sure where to draw the line of describing things
it doesn't answer.

It's easy to imagine a system in which a URI is used
to identify a person for the purpose of that system.
But I can't see how IETF, W3C, or continued discussion
on any of our mailing lists are going to converge
any time soon on answers to the philosophical questions
that have been with us for millennia. What is it
that "Pat Hayes" identifies, anyway? Can I use
mailto:phayes@... as a URI to identify you?
Well, that's a question outside of the "mailto:"
URI spec, I think.

Perhaps  there needs to be a better way of distinguishing
the statements "this specification does not limit the scope
of applicability" and "this specification applies in all
circumstances".

If you had some better way of phrasing it so that it would
be clear the former was meant rather than the latter, I
think that would be helpful.

The fact that something "does matter" -- to you, to the
RDF community, to the W3C, to the world at large --
does not mean that it is appropriate to "matter" in
the context of the HTTP spec.

It is an important design principle for developing
specifications to keep specifications orthogonal: for the purposes
of the HTTP protocol, it does not matter what resources
are exactly. For the purpose of resource identification, it should
not matter what the protocol is; tying semantic web
interpretation to a particular error code in the HTTP
protocol seems like bad design to me.

The idea that the HTTP working group should care about the
semantic web and change its specification to meet some
semantic web requirement for use of HTTP URIs in semantic
web applications  -- well, that raises several red flags
for me, that we're building specifications that are not
sufficiently orthogonal that things that *shouldn't* matter
are taken as important questions that *must* be answered.

The HTTP specification is *not* about what a "resource" is.
It *is* about how to use and implement the HTTP protocol.

There continues to be some confusion in the discussion between
"URI" and "HTTP URI" that I find disturbing and confusing, because
I think sometimes statements about one are attributed to the
other. Not all URIs are HTTP URIs. Please try to be more careful.  

Regards,

Larry
--
http://larry.masinter.net

[Nick Gall]

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

-- Nick (sent from my mobile phone)

-----Original Message-----
From: "Alan Ruttenberg" <alanruttenberg@...>
To: "Pat Hayes" <phayes@...>
Cc: "Jonathan Rees" <jar@...>; "Roy T. Fielding" <fielding@...>; "Julian Reschke" <julian.reschke@...>; "HTTP Working Group" <ietf-http-wg@...>; www-tag@...
Sent: 7/11/09 6:47 PM
Subject: Re: Review of new HTTPbis text for 303 See Other

On Thu, Jul 9, 2009 at 12:04 PM, Pat Hayes<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
>
>
>
>
>
>
>

[Richard Cyganiak-2]

Thanks Larry. I wish I could talk with such clarity.

I want to take the discussion with Pat a bit further, but will do so  
off-list. (Tomorrow, Pat -- I need to mull it over a bit.)

I initially joined the thread to say this: The HTTP spec, with Roy's  
proposed new 303 text, accommodates all Semantic Web use cases I can  
think of. Including using HTTP URIs to denote people. It's good to see  
httpRange-14 slowly "trickle down" into the specs.

Cheers,
Richard


On 14 Jul 2009, at 21:46, Larry Masinter wrote:

> This conversation is filling my mailbox. Some general
> observations:
>
> (Pat, your arguments are laced with ad hominem, which makes reading
> the dialog unpleasant. I don't think Richard is being
> silly, intellectually dishonest, bloody arrogant, or any of the
> other terms you've used, please refrain.)
>
> It's the nature of standards discussions that people speak
> their point of view; doing so isn't arrogant.
>
> It is the nature of technical specifications that it is frequently
> necessary to take normal English words in particular technical
> way; it is not intellectually dishonest to do so.
>
> It is good practice for technical specifications in standards
> groups to say as little as possible in order to meet the
> needs of interoperability and the purpose for which the
> specification is being written.
>
> It is not necessary or even possible for a technical specification
> to answer questions that may be fundamental for applications
> that are outside of its scope. It is common, reasonable,
> and traditional for standards specifications to "not answer"
> questions because answering the question isn't necessary
> for the purpose for which the standard was written.
>
> It isn't necessary for the proper functioning of the web and
> to accomplish interoperability of web clients and servers
> to agree on how to use HTTP URIs and the HTTP protocol --
> for that purpose, it isn't necessary to answer the question
> of whether a HTTP URI can identify a person.
>
> It may be necessary to answer the question in a technical
> specification for the semantic web and in the RDF
> specification  -- but the answer more likely
> belong in those specifications and not in the
> IETF HTTP specification.
>
> It may be necessary for the IETF HTTP specification
> be edited in a way that made it clear that it didn't
> contain the answer to this question, but I'm not
> sure where to draw the line of describing things
> it doesn't answer.
>
> It's easy to imagine a system in which a URI is used
> to identify a person for the purpose of that system.
> But I can't see how IETF, W3C, or continued discussion
> on any of our mailing lists are going to converge
> any time soon on answers to the philosophical questions
> that have been with us for millennia. What is it
> that "Pat Hayes" identifies, anyway? Can I use
> mailto:phayes@... as a URI to identify you?
> Well, that's a question outside of the "mailto:"
> URI spec, I think.
>
> Perhaps  there needs to be a better way of distinguishing
> the statements "this specification does not limit the scope
> of applicability" and "this specification applies in all
> circumstances".
>
> If you had some better way of phrasing it so that it would
> be clear the former was meant rather than the latter, I
> think that would be helpful.
>
> The fact that something "does matter" -- to you, to the
> RDF community, to the W3C, to the world at large --
> does not mean that it is appropriate to "matter" in
> the context of the HTTP spec.
>
> It is an important design principle for developing
> specifications to keep specifications orthogonal: for the purposes
> of the HTTP protocol, it does not matter what resources
> are exactly. For the purpose of resource identification, it should
> not matter what the protocol is; tying semantic web
> interpretation to a particular error code in the HTTP
> protocol seems like bad design to me.
>
> The idea that the HTTP working group should care about the
> semantic web and change its specification to meet some
> semantic web requirement for use of HTTP URIs in semantic
> web applications  -- well, that raises several red flags
> for me, that we're building specifications that are not
> sufficiently orthogonal that things that *shouldn't* matter
> are taken as important questions that *must* be answered.
>
> The HTTP specification is *not* about what a "resource" is.
> It *is* about how to use and implement the HTTP protocol.
>
> There continues to be some confusion in the discussion between
> "URI" and "HTTP URI" that I find disturbing and confusing, because
> I think sometimes statements about one are attributed to the
> other. Not all URIs are HTTP URIs. Please try to be more careful.
>
> Regards,
>
> Larry
> --
> http://larry.masinter.net
>
>
>

[Xiaoshu Wang-3]

Richard Cyganiak wrote:
> Thanks Larry. I wish I could talk with such clarity.
>
> I want to take the discussion with Pat a bit further, but will do so
> off-list. (Tomorrow, Pat -- I need to mull it over a bit.)
>
> I initially joined the thread to say this: The HTTP spec, with Roy's
> proposed new 303 text, accommodates all Semantic Web use cases I can
> think of. Including using HTTP URIs to denote people. It's good to see
> httpRange-14 slowly "trickle down" into the specs.
If this is your purpose, I believe that you do need to mull it over
before talking to Pat.   Pat was trying to give httpRange-14 some wiggle
room  while you, who I have always thought to be a staunch supporters of
httpRange-14, was trying to prevent.

This raises an even bigger issue because it seems to me that, how you
have interpreted the principle of orthogonal specification seems quite
different from Pat's (I guess).  What the principle of orthogonal
specification supports is not a layering architecture but a scalable
architecture.  In other words, the semantic of one specification must be
independent of the other.  This is where httpRange-14 breaks because it
tempers the semantics of *200* code, which, by httpRange-14, relies on
the nature of resource.  303 is not critical because its semantics is
for all purpose, hence always *politically* correct.

Darn, no wonder I was confused.  I honestly don't know what you two were
fighting about. :-)

Xiaoshu

[Julian Reschke]

Larry Masinter wrote:
> This conversation is filling my mailbox. Some general
> observations:
> ...

Larry,

thanks a LOT for this reply.

My takeaway is that we (the HTTPbis WG) are willing to do minor word
smithing to clarify things, but that's it.

In draft 07, we already replaced "resource owner" by "URI owner", as
suggested by Roy.

In another mail
(<http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0044.html>),
Roy proposed another change:

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

I'm happy to make this change if there are no objections, and it does
make at least a few people less unhappy.

BR, Julian

[ray denenberg]

I for one would appreciate if as much of this discussion as possible remain
ON-list.  I really don't care if peoples' mailboxes are filling up or people
are offended by some off-color language or disagreeable arguments.  I've
learned more about this issue from this thread than from reading all the
"relevant" documents.

--Ray

----- Original Message -----
From: "Richard Cyganiak" <richard@...>
To: "Larry Masinter" <LMM@...>
Cc: "'Pat Hayes'" <phayes@...>; "'Roy T. Fielding'" <fielding@...>;
"'Jonathan Rees'" <jar@...>; "'Julian Reschke'"
<julian.reschke@...>; "'HTTP Working Group'" <ietf-http-wg@...>;
<www-tag@...>
Sent: Tuesday, July 14, 2009 9:11 PM
Subject: Re: Review of new HTTPbis text for 303 See Other

> Thanks Larry. I wish I could talk with such clarity.
>
> I want to take the discussion with Pat a bit further, but will do so
> off-list. (Tomorrow, Pat -- I need to mull it over a bit.)
>
> I initially joined the thread to say this: The HTTP spec, with Roy's
> proposed new 303 text, accommodates all Semantic Web use cases I can
> think of. Including using HTTP URIs to denote people. It's good to see
> httpRange-14 slowly "trickle down" into the specs.
>
> Cheers,
> Richard
>
>
> On 14 Jul 2009, at 21:46, Larry Masinter wrote:
>
>> This conversation is filling my mailbox. Some general
>> observations:
>>
>> (Pat, your arguments are laced with ad hominem, which makes reading
>> the dialog unpleasant. I don't think Richard is being
>> silly, intellectually dishonest, bloody arrogant, or any of the
>> other terms you've used, please refrain.)
>>
>> It's the nature of standards discussions that people speak
>> their point of view; doing so isn't arrogant.
>>
>> It is the nature of technical specifications that it is frequently
>> necessary to take normal English words in particular technical
>> way; it is not intellectually dishonest to do so.
>>
>> It is good practice for technical specifications in standards
>> groups to say as little as possible in order to meet the
>> needs of interoperability and the purpose for which the
>> specification is being written.
>>
>> It is not necessary or even possible for a technical specification
>> to answer questions that may be fundamental for applications
>> that are outside of its scope. It is common, reasonable,
>> and traditional for standards specifications to "not answer"
>> questions because answering the question isn't necessary
>> for the purpose for which the standard was written.
>>
>> It isn't necessary for the proper functioning of the web and
>> to accomplish interoperability of web clients and servers
>> to agree on how to use HTTP URIs and the HTTP protocol --
>> for that purpose, it isn't necessary to answer the question
>> of whether a HTTP URI can identify a person.
>>
>> It may be necessary to answer the question in a technical
>> specification for the semantic web and in the RDF
>> specification  -- but the answer more likely
>> belong in those specifications and not in the
>> IETF HTTP specification.
>>
>> It may be necessary for the IETF HTTP specification
>> be edited in a way that made it clear that it didn't
>> contain the answer to this question, but I'm not
>> sure where to draw the line of describing things
>> it doesn't answer.
>>
>> It's easy to imagine a system in which a URI is used
>> to identify a person for the purpose of that system.
>> But I can't see how IETF, W3C, or continued discussion
>> on any of our mailing lists are going to converge
>> any time soon on answers to the philosophical questions
>> that have been with us for millennia. What is it
>> that "Pat Hayes" identifies, anyway? Can I use
>> mailto:phayes@... as a URI to identify you?
>> Well, that's a question outside of the "mailto:"
>> URI spec, I think.
>>
>> Perhaps  there needs to be a better way of distinguishing
>> the statements "this specification does not limit the scope
>> of applicability" and "this specification applies in all
>> circumstances".
>>
>> If you had some better way of phrasing it so that it would
>> be clear the former was meant rather than the latter, I
>> think that would be helpful.
>>
>> The fact that something "does matter" -- to you, to the
>> RDF community, to the W3C, to the world at large --
>> does not mean that it is appropriate to "matter" in
>> the context of the HTTP spec.
>>
>> It is an important design principle for developing
>> specifications to keep specifications orthogonal: for the purposes
>> of the HTTP protocol, it does not matter what resources
>> are exactly. For the purpose of resource identification, it should
>> not matter what the protocol is; tying semantic web
>> interpretation to a particular error code in the HTTP
>> protocol seems like bad design to me.
>>
>> The idea that the HTTP working group should care about the
>> semantic web and change its specification to meet some
>> semantic web requirement for use of HTTP URIs in semantic
>> web applications  -- well, that raises several red flags
>> for me, that we're building specifications that are not
>> sufficiently orthogonal that things that *shouldn't* matter
>> are taken as important questions that *must* be answered.
>>
>> The HTTP specification is *not* about what a "resource" is.
>> It *is* about how to use and implement the HTTP protocol.
>> There continues to be some confusion in the discussion between
>> "URI" and "HTTP URI" that I find disturbing and confusing, because
>> I think sometimes statements about one are attributed to the
>> other. Not all URIs are HTTP URIs. Please try to be more careful.
>>
>> Regards,
>>
>> Larry
>> --
>> http://larry.masinter.net
>>
>>
>>
>
>

[Pat Hayes]

On Jul 14, 2009, at 10:20 AM, Xiaoshu Wang wrote:

> Pat Hayes wrote:
>>
>> On Jul 14, 2009, at 9:01 AM, Xiaoshu Wang wrote:
>>
>>> 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.
>>
>> As I said in another post, I think http-range-14 is terrible, but  
>> all the alternatives are worse.
> Of course there is no better alternative because there is *not* a  
> problem at the first place. The problem is created by pushing IR  
> into the Web architecture.  But just like the web architecture  
> should not deal with hamburgers, it should not deal with IR as well.
>
>>>>> 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.
>>
>> Of course not. But it also does not mean, "get me an  
>> awww:representation" of the hamburger. Or at least, it had better  
>> not mean that, since hamburgers don't have awww:representations.  
>> Web pages about hamburgers can represent (not awww:represent) a  
>> hamburger, and they of course have awww:representations. But an  
>> awww:repreresentation of a representation of X is not an  
>> awww:representation of X.
> I mentioned that let us not ignore *the existence of an agent* --  
> the one who implements the URI.  I do not know if a hamburger *can  
> or cannot* have an awww:representation because I am not a  
> hamburger.  But I do know that *I can* give a hamburger an  
> awww:representation.  You don't have to believe me, that is none of  
> my business.

True, I don't have to, but I would like to know a little more about  
HOW you would create an awww:representation - or, which I believe to  
be synonymous, a representation in  the sense used in Roy's REST  
thesis - of a hamburger. I will take mine without tomatoes, well done  
and dressed with mayo and mustard.  So, to check our understanding,  
this must be a representation, encoded in a byte stream, which stands  
in the same relation to a hamburger that the html which I get back  
from, say, the Amazon website stands in to that web page.

Maybe we should take this offline if it is annoying others, but I  
actually think it might be quite informative about our various  
clashing intuitions here.

Pat

>  But to say that no one should believe me, you cross the line for  
> being either ignorant (of being me) or arrogant (of being you).
>>> To think otherwise is to hallucinate.
>>
>> Quite.
>>
>>>
>>> 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.
>>
>> I don't like the terminology (and I don't think we need it, and  
>> especially do not need to be debating its exact meaning), but the  
>> general idea is clear enough: its the thing that HTTP returns the  
>> awww:representation of. That is certainly not a hallucination,  
>> because you just made HTTP contact with it.
> Then, it is fine with me.  You can call an HTTP server, FTP server,  
> Mailto server or any kind of information server -- an "information  
> resource".  That is denotation semantics of that word's use.  It is  
> fine with me because we might just call it "xyz" -- for the sake of  
> avoiding confusion.  But this denotation semantics should not affect  
> how *I* implement *my* URI.  Most of all, it should not affect how  
> *I* use the Web.
>
> 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

[David Booth-6]

[Off list]

FWIW, I wasn't able to follow Pat's point either, but I'd like to
understand it, so if you and Pat don't mind copying me on your
correspondence I would be interested.

Thanks,
David Booth

On Wed, 2009-07-15 at 03:11 +0200, Richard Cyganiak wrote:

> Thanks Larry. I wish I could talk with such clarity.
>
> I want to take the discussion with Pat a bit further, but will do so  
> off-list. (Tomorrow, Pat -- I need to mull it over a bit.)
>
> I initially joined the thread to say this: The HTTP spec, with Roy's  
> proposed new 303 text, accommodates all Semantic Web use cases I can  
> think of. Including using HTTP URIs to denote people. It's good to see  
> httpRange-14 slowly "trickle down" into the specs.
>
> Cheers,
> Richard
>
>
> On 14 Jul 2009, at 21:46, Larry Masinter wrote:
>
> > This conversation is filling my mailbox. Some general
> > observations:
> >
> > (Pat, your arguments are laced with ad hominem, which makes reading
> > the dialog unpleasant. I don't think Richard is being
> > silly, intellectually dishonest, bloody arrogant, or any of the
> > other terms you've used, please refrain.)
> >
> > It's the nature of standards discussions that people speak
> > their point of view; doing so isn't arrogant.
> >
> > It is the nature of technical specifications that it is frequently
> > necessary to take normal English words in particular technical
> > way; it is not intellectually dishonest to do so.
> >
> > It is good practice for technical specifications in standards
> > groups to say as little as possible in order to meet the
> > needs of interoperability and the purpose for which the
> > specification is being written.
> >
> > It is not necessary or even possible for a technical specification
> > to answer questions that may be fundamental for applications
> > that are outside of its scope. It is common, reasonable,
> > and traditional for standards specifications to "not answer"
> > questions because answering the question isn't necessary
> > for the purpose for which the standard was written.
> >
> > It isn't necessary for the proper functioning of the web and
> > to accomplish interoperability of web clients and servers
> > to agree on how to use HTTP URIs and the HTTP protocol --
> > for that purpose, it isn't necessary to answer the question
> > of whether a HTTP URI can identify a person.
> >
> > It may be necessary to answer the question in a technical
> > specification for the semantic web and in the RDF
> > specification  -- but the answer more likely
> > belong in those specifications and not in the
> > IETF HTTP specification.
> >
> > It may be necessary for the IETF HTTP specification
> > be edited in a way that made it clear that it didn't
> > contain the answer to this question, but I'm not
> > sure where to draw the line of describing things
> > it doesn't answer.
> >
> > It's easy to imagine a system in which a URI is used
> > to identify a person for the purpose of that system.
> > But I can't see how IETF, W3C, or continued discussion
> > on any of our mailing lists are going to converge
> > any time soon on answers to the philosophical questions
> > that have been with us for millennia. What is it
> > that "Pat Hayes" identifies, anyway? Can I use
> > mailto:phayes@... as a URI to identify you?
> > Well, that's a question outside of the "mailto:"
> > URI spec, I think.
> >
> > Perhaps  there needs to be a better way of distinguishing
> > the statements "this specification does not limit the scope
> > of applicability" and "this specification applies in all
> > circumstances".
> >
> > If you had some better way of phrasing it so that it would
> > be clear the former was meant rather than the latter, I
> > think that would be helpful.
> >
> > The fact that something "does matter" -- to you, to the
> > RDF community, to the W3C, to the world at large --
> > does not mean that it is appropriate to "matter" in
> > the context of the HTTP spec.
> >
> > It is an important design principle for developing
> > specifications to keep specifications orthogonal: for the purposes
> > of the HTTP protocol, it does not matter what resources
> > are exactly. For the purpose of resource identification, it should
> > not matter what the protocol is; tying semantic web
> > interpretation to a particular error code in the HTTP
> > protocol seems like bad design to me.
> >
> > The idea that the HTTP working group should care about the
> > semantic web and change its specification to meet some
> > semantic web requirement for use of HTTP URIs in semantic
> > web applications  -- well, that raises several red flags
> > for me, that we're building specifications that are not
> > sufficiently orthogonal that things that *shouldn't* matter
> > are taken as important questions that *must* be answered.
> >
> > The HTTP specification is *not* about what a "resource" is.
> > It *is* about how to use and implement the HTTP protocol.
> >
> > There continues to be some confusion in the discussion between
> > "URI" and "HTTP URI" that I find disturbing and confusing, because
> > I think sometimes statements about one are attributed to the
> > other. Not all URIs are HTTP URIs. Please try to be more careful.
> >
> > Regards,
> >
> > Larry
> > --
> > http://larry.masinter.net
> >
> >
> >
>
>
>
>

--
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

[Pat Hayes]

On Jul 14, 2009, at 2:46 PM, Larry Masinter wrote:

> This conversation is filling my mailbox. Some general
> observations:
>
> (Pat, your arguments are laced with ad hominem, which makes reading
> the dialog unpleasant. I don't think Richard is being
> silly, intellectually dishonest, bloody arrogant, or any of the
> other terms you've used, please refrain.)

Sorry if it gave offense, all the above was meant ad dicto, not ad  
hominem. And Im a Brit, so "bloody" is a friendly form of emphasis.

>
> It's the nature of standards discussions that people speak
> their point of view; doing so isn't arrogant.
>
> It is the nature of technical specifications that it is frequently
> necessary to take normal English words in particular technical
> way; it is not intellectually dishonest to do so.

Well, let me react to that. (This is an aside from the main topic, but  
it helps explain motivation and attitude.) True, Richard may have  
accidentally become the spokesperson here for an entire culture, which  
I regret if true, and apologize to him for having to bear the brunt of  
my frustration.) But I do feel that there seems to be what I can only  
describe as a somewhat arrogant double standard throughout the W3C  
regarding these issues of technical usage. The W3C documents use a  
number of words in VERY peculiar ways, ways which (1) do not  
correspond even remotely to their normal usage and (2) do not conform  
to the historical usage of these words even in the 'technical'  
literature out of which the W3C usages have grown, and yet every  
attempt to ask for clarification of these usages is rebuffed,  
sometimes angrily or impolitely; and there is nothing even remotely  
like a glossary available. (Contrast, say, the ISO's almost anal  
approach to giving definitions of every usage.)  My favorite example  
is "resource", of course (which was first used in this context by  
Engelbart, who meant it in close to its normal English sense), but  
"representation" is another, and "identity" (fortunately no longer in  
wide use) yet another. Seems to me that when your own technical  
audience has to use your words prefixed with 'awww:' in order to  
distinguish these deviant meanings from those used in the rest of the  
world, that there may be a slight issue here.

>
> It is good practice for technical specifications in standards
> groups to say as little as possible in order to meet the
> needs of interoperability and the purpose for which the
> specification is being written.

I strongly disagree. It may be good practice to be deliberately  
agnostic about technical details, but it is never good practice to be  
deliberately obscure about the meanings of the words one is using. And  
you cannot reasonably hold two positions, along the lines of "I am  
deliberately not going to say what I mean because it does not matter"  
and "Your interpretation is wrong because that isn't what I meant".  
Which is exactly what Richard did in this email thread.

>
> It is not necessary or even possible for a technical specification
> to answer questions that may be fundamental for applications
> that are outside of its scope.

Of course, but this IS in its scope. That is the whole point.

> It is common, reasonable,
> and traditional for standards specifications to "not answer"
> questions because answering the question isn't necessary
> for the purpose for which the standard was written.
>
> It isn't necessary for the proper functioning of the web and
> to accomplish interoperability of web clients and servers
> to agree on how to use HTTP URIs and the HTTP protocol --
> for that purpose, it isn't necessary to answer the question
> of whether a HTTP URI can identify a person.

I am not asking it to answer that question. That question is already  
answered: a URI *can* identify a person. Absolutely no doubt about  
that. What I am asking for is that the spec RECOGNIZE this and DEAL  
WITH IT. Richard told me that HTTP "does not care" what the URI  
identifies, or what counts as a representation of it. I took him at  
his word and gave him an immediate example of a resource and a  
representation of that resource, which according to what he had said,  
I was entirely able to do within the confines of the spec, since it  
DID NOT CARE about that stuff, and he rejected the example without  
comment on the grounds that it wasnt to do with computer architecture.  
Which was exactly my point. If HTTP does not care what a resource is,  
or what a representation of a resource is, then it should apply to  
examples like mine. Obviously, it does not: ergo, it DOES CARE what a  
URI identifies and what a representation is. Then the spec should say  
this, and say it clearly.

Its not enough to hide behind the defense that this is (obviously)  
just a technical spec in a technical area, and philosophy has nothing  
to do with that technical topic. That would be fine if URIs could not  
identify people and books, but they can. It might be OK if http codes  
didn't imply anything about what URIs denote, but (according to http-
range-14) they do. I know y'all don't want to be in this semantic/
philosophical stew, you just want to be technologists. But the fact  
is, you are in it whether you like it or not. HTTPrange14 put you in  
it. I didn't make this stew, but I am going to go on yelling as long  
as y'all refuse to recognize that this stew exists and it is your job  
to handle it properly, or at least not poison it.  The reason why we  
can't just all assume , in a kind of collegial technophile way, that  
we are all just talking about networks, is that these very technical  
usages of words on which you yourself rely to explain the spec have  
*already* been extended to a wider usage which makes no sense when we  
are only talking about networks. URIs *can* "identify" people, and  
other "resources"  that cannot possibly have a (n awww:)  
"representation".

>
> It may be necessary to answer the question in a technical
> specification for the semantic web and in the RDF
> specification  -- but the answer more likely
> belong in those specifications and not in the
> IETF HTTP specification.
>
> It may be necessary for the IETF HTTP specification
> be edited in a way that made it clear that it didn't
> contain the answer to this question, but I'm not
> sure where to draw the line of describing things
> it doesn't answer.
>
> It's easy to imagine a system in which a URI is used
> to identify a person for the purpose of that system.

For the purpose of the entire Web. It isn't something that can be  
closeted inside a 'system'.

> But I can't see how IETF, W3C, or continued discussion
> on any of our mailing lists are going to converge
> any time soon on answers to the philosophical questions
> that have been with us for millennia. What is it
> that "Pat Hayes" identifies, anyway? Can I use
> mailto:phayes@... as a URI to identify you?
> Well, that's a question outside of the "mailto:"
> URI spec, I think.

Sure. Im not asking you or anyone else to solve age-old problems. But  
I am asking you to recognize, and say, that HTTP now has some  
interaction with semantics. Its not a very deep or complex  
interaction. IMO, it can be entirely contained in the observation that  
a 200-coded response indicates that the URI denotes (refers to) the  
resource that it identifies, and a 303 doesn't indicate that. That's  
all you need to say[[**see below for less**]]:  questions of what  
exactly is the nature of that identified resource, etc., are outside  
the scope, of course. But you are already assuming that 'the resource  
identified by the URI' makes sense, right? Because if that is  
problematic, then the whole of HTTP is problematic.

>
> Perhaps  there needs to be a better way of distinguishing
> the statements "this specification does not limit the scope
> of applicability" and "this specification applies in all
> circumstances".
>
> If you had some better way of phrasing it so that it would
> be clear the former was meant rather than the latter, I
> think that would be helpful.
>
> The fact that something "does matter" -- to you, to the
> RDF community, to the W3C, to the world at large --
> does not mean that it is appropriate to "matter" in
> the context of the HTTP spec.

Well, it does it that thing that matters has been tied to a technical  
device - a 303 code- that is specified in this spec.

>
> It is an important design principle for developing
> specifications to keep specifications orthogonal: for the purposes
> of the HTTP protocol, it does not matter what resources
> are exactly.

I have never said that it did. I have always consistently said that  
http-range-14 is about URIs, not about resources.

> For the purpose of resource identification, it should
> not matter what the protocol is; tying semantic web
> interpretation to a particular error code in the HTTP
> protocol seems like bad design to me.
>
> The idea that the HTTP working group should care about the
> semantic web and change its specification to meet some
> semantic web requirement for use of HTTP URIs in semantic
> web applications  -- well, that raises several red flags
> for me, that we're building specifications that are not
> sufficiently orthogonal that things that *shouldn't* matter
> are taken as important questions that *must* be answered.

I understand about the red flag. But URI issues aren't really just  
about the semantic web. They are about the whole Web, which is slowly  
becoming semanticized. URIs convey meanings in all sorts of ways, they  
aren't purely a transfer protocol addressing mechanism any more.

[[**]]If you recall, my interaction on this thread arose from wanting  
the HTTP spec to simply say that a 303 response can be thrown  
basically on the server's whim: it needs no "I have no appropriate 200  
response to send" justification for the 303. Put another way, the  
server is not *obliged* to return a 200 response even when it does  
have a representation available that it *could* respond with. This is  
purely within the HTTP 'layer', but it is necessary to allow servers  
to respond with 303s *for semantic reasons* which may (should?) have  
absolutely nothing to do with the existence of awww:representations.  
And that is all: I would shut up immediately if that wording were to  
be used. BUt right now, the wording does have this must-send-200-if-
possible constraint in it, which is potentially operationally  
incompatible with the http-range-14 recommendation. Ironically, it is  
so precisely because of the orthogonality you want to preserve: the  
semantics of the URI need have nothing to do with the presence or  
absence of an awww:representation. It can be determined by other,  
loftier, matters to do with denotation, whatever that is. I think it  
would be helpful if the spec could just remark that the reason for  
this responding-code freedom is because 303 codes have these semantic  
uses, or that it is generally understood (informative ref httprange14)  
that 200 codes have semantic implications which might want to be  
avoided in some cases, or the like, but I also understand your  
reluctance to include anything in a spec that might come back to bite  
you.

>
> The HTTP specification is *not* about what a "resource" is.
> It *is* about how to use and implement the HTTP protocol.

I don't want it to be about what the resource is, but it does need to  
at least recognize that the resource might not have ANY possible  
connection with any computer ever made. It needs to at least show that  
it understands that not ALL resources are just on the other side of an  
http interface, even when they are identified by an http URI.

>
>
> There continues to be some confusion in the discussion between
> "URI" and "HTTP URI" that I find disturbing and confusing, because
> I think sometimes statements about one are attributed to the
> other. Not all URIs are HTTP URIs. Please try to be more careful.

Point taken.

Pat

>
> Regards,
>
> Larry
> --
> http://larry.masinter.net
>
>
>
>
>

------------------------------------------------------------
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 14, 2009, at 8:11 PM, Richard Cyganiak wrote:

> Thanks Larry. I wish I could talk with such clarity.
>
> I want to take the discussion with Pat a bit further, but will do so  
> off-list. (Tomorrow, Pat -- I need to mull it over a bit.

OK, but see quick remark below.

> )
>
> I initially joined the thread to say this: The HTTP spec, with Roy's  
> proposed new 303 text, accommodates all Semantic Web use cases I can  
> think of. Including using HTTP URIs to denote people.

And my entire beef with it is that there is a case it misses, which is  
a URI denoting a person but which resolves to an http endpoint which  
has access to a 200-codable representation of itself (not of the  
person, but of it, the resource on the other side of the http  
interface.) And that IS a possibility, and I can even imagine some  
very nice uses for it.

> It's good to see httpRange-14 slowly "trickle down" into the specs.

Agreed.

Pat

>
> Cheers,
> Richard
>
>
> On 14 Jul 2009, at 21:46, Larry Masinter wrote:
>
>> This conversation is filling my mailbox. Some general
>> observations:
>>
>> (Pat, your arguments are laced with ad hominem, which makes reading
>> the dialog unpleasant. I don't think Richard is being
>> silly, intellectually dishonest, bloody arrogant, or any of the
>> other terms you've used, please refrain.)
>>
>> It's the nature of standards discussions that people speak
>> their point of view; doing so isn't arrogant.
>>
>> It is the nature of technical specifications that it is frequently
>> necessary to take normal English words in particular technical
>> way; it is not intellectually dishonest to do so.
>>
>> It is good practice for technical specifications in standards
>> groups to say as little as possible in order to meet the
>> needs of interoperability and the purpose for which the
>> specification is being written.
>>
>> It is not necessary or even possible for a technical specification
>> to answer questions that may be fundamental for applications
>> that are outside of its scope. It is common, reasonable,
>> and traditional for standards specifications to "not answer"
>> questions because answering the question isn't necessary
>> for the purpose for which the standard was written.
>>
>> It isn't necessary for the proper functioning of the web and
>> to accomplish interoperability of web clients and servers
>> to agree on how to use HTTP URIs and the HTTP protocol --
>> for that purpose, it isn't necessary to answer the question
>> of whether a HTTP URI can identify a person.
>>
>> It may be necessary to answer the question in a technical
>> specification for the semantic web and in the RDF
>> specification  -- but the answer more likely
>> belong in those specifications and not in the
>> IETF HTTP specification.
>>
>> It may be necessary for the IETF HTTP specification
>> be edited in a way that made it clear that it didn't
>> contain the answer to this question, but I'm not
>> sure where to draw the line of describing things
>> it doesn't answer.
>>
>> It's easy to imagine a system in which a URI is used
>> to identify a person for the purpose of that system.
>> But I can't see how IETF, W3C, or continued discussion
>> on any of our mailing lists are going to converge
>> any time soon on answers to the philosophical questions
>> that have been with us for millennia. What is it
>> that "Pat Hayes" identifies, anyway? Can I use
>> mailto:phayes@... as a URI to identify you?
>> Well, that's a question outside of the "mailto:"
>> URI spec, I think.
>>
>> Perhaps  there needs to be a better way of distinguishing
>> the statements "this specification does not limit the scope
>> of applicability" and "this specification applies in all
>> circumstances".
>>
>> If you had some better way of phrasing it so that it would
>> be clear the former was meant rather than the latter, I
>> think that would be helpful.
>>
>> The fact that something "does matter" -- to you, to the
>> RDF community, to the W3C, to the world at large --
>> does not mean that it is appropriate to "matter" in
>> the context of the HTTP spec.
>>
>> It is an important design principle for developing
>> specifications to keep specifications orthogonal: for the purposes
>> of the HTTP protocol, it does not matter what resources
>> are exactly. For the purpose of resource identification, it should
>> not matter what the protocol is; tying semantic web
>> interpretation to a particular error code in the HTTP
>> protocol seems like bad design to me.
>>
>> The idea that the HTTP working group should care about the
>> semantic web and change its specification to meet some
>> semantic web requirement for use of HTTP URIs in semantic
>> web applications  -- well, that raises several red flags
>> for me, that we're building specifications that are not
>> sufficiently orthogonal that things that *shouldn't* matter
>> are taken as important questions that *must* be answered.
>>
>> The HTTP specification is *not* about what a "resource" is.
>> It *is* about how to use and implement the HTTP protocol.
>>
>> There continues to be some confusion in the discussion between
>> "URI" and "HTTP URI" that I find disturbing and confusing, because
>> I think sometimes statements about one are attributed to the
>> other. Not all URIs are HTTP URIs. Please try to be more careful.
>>
>> Regards,
>>
>> Larry
>> --
>> http://larry.masinter.net
>>
>>
>>
>
>
>

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

[Manfred Baedke]

Pat Hayes wrote:
> I strongly disagree. It may be good practice to be deliberately
> agnostic about technical details, but it is never good practice to be
> deliberately obscure about the meanings of the words one is using.
Yes, it is. Take any mathematical theory as an example showing how it
works perfectly to be deliberately obscure about the meaning of atomic
terms of a technical language.

Regards,
Manfred

--
Manfred Baedke

<green/>bytes GmbH
Hafenweg 16
D-48155 Münster
Germany
Amtsgericht Münster: HRB5782

[Xiaoshu Wang-3]

Pat Hayes wrote:

>
> On Jul 14, 2009, at 10:20 AM, Xiaoshu Wang wrote:
>
>> Pat Hayes wrote:
>>>
>>> On Jul 14, 2009, at 9:01 AM, Xiaoshu Wang wrote:
>>>
>>>> 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.
>>>
>>> As I said in another post, I think http-range-14 is terrible, but
>>> all the alternatives are worse.
>> Of course there is no better alternative because there is *not* a
>> problem at the first place. The problem is created by pushing IR into
>> the Web architecture.  But just like the web architecture should not
>> deal with hamburgers, it should not deal with IR as well.
>>
>>>>>> 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.
>>>
>>> Of course not. But it also does not mean, "get me an
>>> awww:representation" of the hamburger. Or at least, it had better
>>> not mean that, since hamburgers don't have awww:representations. Web
>>> pages about hamburgers can represent (not awww:represent) a
>>> hamburger, and they of course have awww:representations. But an
>>> awww:repreresentation of a representation of X is not an
>>> awww:representation of X.
>> I mentioned that let us not ignore *the existence of an agent* -- the
>> one who implements the URI.  I do not know if a hamburger *can or
>> cannot* have an awww:representation because I am not a hamburger.  
>> But I do know that *I can* give a hamburger an awww:representation.  
>> You don't have to believe me, that is none of my business.
>
> True, I don't have to, but I would like to know a little more about
> HOW you would create an awww:representation - or, which I believe to
> be synonymous, a representation in  the sense used in Roy's REST
> thesis - of a hamburger. I will take mine without tomatoes, well done
> and dressed with mayo and mustard.  So, to check our understanding,
> this must be a representation, encoded in a byte stream, which stands
> in the same relation to a hamburger that the html which I get back
> from, say, the Amazon website stands in to that web page.
>
> Maybe we should take this offline if it is annoying others, but I
> actually think it might be quite informative about our various
> clashing intuitions here.

[I will make this public as if our discussion were desired as Ray has
expressed.]

To answer your HOW-to question, allow me to use my proposed scheme-less
URI convention.

Assume that I own the domain name "xiaoshu.wang" and I designated the
(scheme-less) URI:  "//xiaoshu.wang/a.hamburger" to denote the hamburger
burning on the grill of my backyard on a sunny day.

In our traditional web jargon, the URI -- "//xiaoshu.wang/a.hamburger"
-- is an absolute URN, hence its semantics is only about denotation.

There are many ways that we can get a representation (in the most
general philosophical sense) of "//xiaoshu.wang/a.hamburger".

We can *see* it, i.e., by turning our head and opening our eyes so light
rays can bounce off the hamburger into our eyes.  Let's denote this
particular kind of representation retrieval with a URI scheme -- see, as
follows:

"see://xiaoshu.wang/a.hamburger"

In our web jargon, the above URI is a URL because it is bound with the
transportation protocol "SEE".  By this URL, we can get back a
representation, in the form of a bunch of photons delivered to our retina.

Similarly, we can

hear://xiaoshu.wang/a.hamburger (with air pressures as representations
delivered to our eardrum)
get://xiaoshu.wang/a.hamburger (some heat, pressure, as representations
delivered to our hand)
eat://xiaoshu.wang/a.hamburger (some fat, carbo, salt, as
representations shuffled down to our throat)
....
http://xiaoshu.wang/a.hamburger (some document packed in bits as
representations delivered to our laptop or desktop or your palmtop....)

So, what is the HOW that you want to know?  Is it "how do we see, hear,
eat, and HTTP"?  Then, take a biology class or in the latter case, read
the HTTP spec.  But here is the point: we don't need to know how we see
in order to see (i.e., to perceive the photons) because our body just
*can*.  By the same token, we don't need to know how the Web delivers an
awww:representation in order to use the  awww:representation because the
Web just *can*.

So, I do not think that is the reason for you to ask the know-HOW.  The
reason that you want to ask the KNOW-how is that you want to feel
confident in taking the content carried in a representation to be true
(or false).  This is a valid concern.  But the only way to increase that
confidence is to gather more information.  There is no other way
around.  For instance, even if you see the hamburger, don't you still
need some additional information to make sure what you see is not a
reflection from a mirror or simply not a mirage?  Does knowing how human
see helps you any more than not-knowing it? It is the same with
IR/httpRange-14.  Even if we all complied, don't you still need to know
if someone gets it right or wrong before committing to your truth?

For instance, if I take "http://xiaoshu.wang/a.hamburger" to denote a
hamburger.  When you de-reference that URI, you get back a 200.  But
after reading my awww:representation, you may say "No, you cannot do
that because ....".  But the real cause is that our interpretation about
HTTP could be different in the same way that our interpretation about
hamburger, dog, or IR could be different.  But aren't we taking about a
hamburger, what the heck does it has anything to do with dog, IR, or HTTP?

The cause of all these mess is either our confusion with messing up
representation with resource, or, the duality of HTTP-URI as both a name
and a locator.  If we separate "[http:]//xiaoshu.wang/a.hamburger" --
the URN -- from "http://xiaoshu.wang/a.hamburger" -- the URL, I don't
think you will have much concerns.  Do you?

Xiaoshu
 

[Pat Hayes]

On Jul 15, 2009, at 4:38 AM, Julian Reschke wrote:

> Larry Masinter wrote:
>> This conversation is filling my mailbox. Some general
>> observations:
>> ...
>
> Larry,
>
> thanks a LOT for this reply.
>
> My takeaway is that we (the HTTPbis WG) are willing to do minor word  
> smithing to clarify things, but that's it.
>
> In draft 07, we already replaced "resource owner" by "URI owner", as  
> suggested by Roy.
>
> In another mail (<http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0044.html 
> >), Roy proposed another change:
>
>> 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

Maybe I am misreading this. Consider an example, to help clarify. I  
have an HTTP URI which, for reasons that need not detain us here but  
which are set in stone, refers to a (non-information) resource, say  
Richard Cyganiak the person. A GET with that URI resolves to an  
endpoint which itself is (of course) a resource also, but not (of  
course) the one that the URI denotes ("identifies"). Let us call this  
resource R. This is the classical case that http-range-14 requires to  
have a 303 emitted to the client by R, or at least by the http  
endpoint associated with R. (I am never quite sure of exactly how the  
'resource' relates to the http endpoint, but let us try to ignore that  
issue here: the main point is that R, whatever it is, is certainly not  
Richard Cyganiak .) Now, in this scenario, what exactly is "the  
requested resource" in the above wording?  Is it R or is it Richard  
Cyganiak? Because I have been assuming that this must mean R; but if  
it can mean a non-Webbish thing like a person, then indeed the above  
makes perfect sense. In which case I would only ask that the spec  
wording make it absolutely clear that the "requested resource" need  
not be the resource that the URI resolves to in a GET request. If, on  
the other hand, this is what the phrase "requested resource" means, so  
that in my example it refers to R rather than to Richard, then I  
object to the above wording on the grounds that it is false: the 303  
response should *not* be taken to indicate that the server has no  
transferrable representation of R. It may well have one (the fact is  
irrelevant to the response) and indeed it may be able to make use of  
it under other circumstances, as for example when resolved to by a GET  
using a different URI. (For example, it might be important to be able  
to discover what is 'acting for' Richard Cyganiak in these http  
transactions, for security or trust purposes.)

The basic point is that http-range-14 means that there may be  
circumstances which have nothing whatever to do with  
awww:representations, but which nevertheless require a server to emit  
a 303 code; and the wording used should allow for this.

Pat

>> 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.
>
> I'm happy to make this change if there are no objections, and it  
> does make at least a few people less unhappy.
>
> BR, Julian
>
>
>

------------------------------------------------------------
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 15, 2009, at 11:15 AM, Xiaoshu Wang wrote:

> Pat Hayes wrote:
>>
>> On Jul 14, 2009, at 10:20 AM, Xiaoshu Wang wrote:
>>
>>> Pat Hayes wrote:
>>>>
>>>> On Jul 14, 2009, at 9:01 AM, Xiaoshu Wang wrote:
>>>>
>>>>> 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.
>>>>
>>>> As I said in another post, I think http-range-14 is terrible, but  
>>>> all the alternatives are worse.
>>> Of course there is no better alternative because there is *not* a  
>>> problem at the first place. The problem is created by pushing IR  
>>> into the Web architecture.  But just like the web architecture  
>>> should not deal with hamburgers, it should not deal with IR as well.
>>>
>>>>>>> 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.
>>>>
>>>> Of course not. But it also does not mean, "get me an  
>>>> awww:representation" of the hamburger. Or at least, it had better  
>>>> not mean that, since hamburgers don't have awww:representations.  
>>>> Web pages about hamburgers can represent (not awww:represent) a  
>>>> hamburger, and they of course have awww:representations. But an  
>>>> awww:repreresentation of a representation of X is not an  
>>>> awww:representation of X.
>>> I mentioned that let us not ignore *the existence of an agent* --  
>>> the one who implements the URI.  I do not know if a hamburger *can  
>>> or cannot* have an awww:representation because I am not a  
>>> hamburger.  But I do know that *I can* give a hamburger an  
>>> awww:representation.  You don't have to believe me, that is none  
>>> of my business.
>>
>> True, I don't have to, but I would like to know a little more about  
>> HOW you would create an awww:representation - or, which I believe  
>> to be synonymous, a representation in  the sense used in Roy's REST  
>> thesis - of a hamburger. I will take mine without tomatoes, well  
>> done and dressed with mayo and mustard.  So, to check our  
>> understanding, this must be a representation, encoded in a byte  
>> stream, which stands in the same relation to a hamburger that the  
>> html which I get back from, say, the Amazon website stands in to  
>> that web page.
>>
>> Maybe we should take this offline if it is annoying others, but I  
>> actually think it might be quite informative about our various  
>> clashing intuitions here.
> [I will make this public as if our discussion were desired as Ray  
> has expressed.]
>
> To answer your HOW-to question, allow me to use my proposed scheme-
> less URI convention.
>
> Assume that I own the domain name "xiaoshu.wang" and I designated  
> the (scheme-less) URI:  "//xiaoshu.wang/a.hamburger" to denote the  
> hamburger burning on the grill of my backyard on a sunny day.
> In our traditional web jargon, the URI -- "//xiaoshu.wang/
> a.hamburger" -- is an absolute URN, hence its semantics is only  
> about denotation.

Hmmm... I guess I was presupposing that we were talking about HTTP  
URIs in this forum. But as I don't think it makes any real difference,  
let us proceed:

>
> There are many ways that we can get a representation (in the most  
> general philosophical sense) of "//xiaoshu.wang/a.hamburger".

Oh, no disagreement there. But I didn't ask about getting a  
representation in a broad sense, but in the very narrow sense used in  
awww debates, where it means the kind of 'representation' which Roy  
talks about in his thesis REST model, and which HTTP talks about when  
it refers to representations of resources. This much narrower sense  
refers to a byte stream which is a sufficiently detailed and precise  
representation as to allow a close-to-identical copy of the resource  
to be assembled by the recipient of the message. For example, this  
kind of representation of a page of a book might be a high-resolution  
image of the page, or it might be a PDF file which can be  
reconstructed into an accurate digital rendering of the original page.  
But a mere description in RDF, for example, would not meet these very  
tight requirements on awww:representations. Seems to me that to do  
this with hamburgers requires a matter transporter or telekinesis.

>
> We can *see* it, i.e., by turning our head and opening our eyes so  
> light rays can bounce off the hamburger into our eyes.  Let's denote  
> this particular kind of representation retrieval with a URI scheme  
> -- see, as follows:
>
> "see://xiaoshu.wang/a.hamburger"
>
> In our web jargon, the above URI is a URL because it is bound with  
> the transportation protocol "SEE".  By this URL, we can get back a  
> representation, in the form of a bunch of photons delivered to our  
> retina.

But (1) we cannot send photons in a byte stream, and (2) I don't think  
that the light reflected back from a thing is a 'representation' of  
that thing in any useful sense. When we see things, our brains  
construct representations of them which constitute our visual  
awareness, but thats not done by the photons themselves and its not in  
any way isomorphic to the photons. Still, this is a philosophical  
quibble in  the context of this discussion, as you could run your  
point with a URI prefix of cognizes://

>
> Similarly, we can
>
> hear://xiaoshu.wang/a.hamburger (with air pressures as  
> representations delivered to our eardrum)
> get://xiaoshu.wang/a.hamburger (some heat, pressure, as  
> representations delivered to our hand)
> eat://xiaoshu.wang/a.hamburger (some fat, carbo, salt, as  
> representations shuffled down to our throat)
> ....
> http://xiaoshu.wang/a.hamburger (some document packed in bits as  
> representations delivered to our laptop or desktop or your  
> palmtop....)

They key is that its a DOCUMENT in this case, and the document  (not  
the hamburger) is the resource which is represented by the bits. And a  
representation of a representation of X is not a representation of X.  
Even denotation isn't transitive in this way: the Hollywood sign is  
called "Hollywood sign", and that phrase does not refer to Hollywood.

>
> So, what is the HOW that you want to know?  Is it "how do we see,  
> hear, eat, and HTTP"?  Then, take a biology class or in the latter  
> case, read the HTTP spec.  But here is the point: we don't need to  
> know how we see in order to see (i.e., to perceive the photons)  
> because our body just *can*.  By the same token, we don't need to  
> know how the Web delivers an awww:representation in order to use  
> the  awww:representation because the Web just *can*.

>
> So, I do not think that is the reason for you to ask the know-HOW.  
> The reason that you want to ask the KNOW-how is that you want to  
> feel confident in taking the content carried in a representation to  
> be true (or false).

Im not arguing here for boolean descriptive representations. Quite the  
contrary, in fact: I don't think that awww:representations can  
possibly be false (they can be *wrong*, but not *false*)

>  This is a valid concern.  But the only way to increase that  
> confidence is to gather more information.  There is no other way  
> around.  For instance, even if you see the hamburger, don't you  
> still need some additional information to make sure what you see is  
> not a reflection from a mirror or simply not a mirage?  Does knowing  
> how human see helps you any more than not-knowing it? It is the same  
> with IR/httpRange-14.  Even if we all complied, don't you still need  
> to know if someone gets it right or wrong before committing to your  
> truth?

I am not going along this line of thought here. Im not concerned about  
certitude or confidence in knowing the representation is correct or  
complete. (I actually don't agree with you about the only way being to  
get more information, BTW, but that really is a philosophical debate  
unsuited to this forum.) My only point is that there is genuine, if  
narrow, sense of representation in which the payload of a 200-coded  
HTTP reply is one of them, but things like descriptions, pictures,  
smells and sights are not; and are such that things that cannot be  
stored digitally in Web servers and given a http interface cannot have  
these representations. This is the sense of awww:representation used  
in the REST literature and often by Timbl in his writings and which  
the HTTP specs are presuming, I believe. And in this narrow sense of  
'representation', I am still quite convinced that a hamburger cannot  
have one of them. It cannot be awww:represented in the sense that,  
say, a Word document or a JPG image can be.

>
> For instance, if I take "http://xiaoshu.wang/a.hamburger" to denote  
> a hamburger.  When you de-reference that URI, you get back a 200.  
> But after reading my awww:representation

Of what? Not of the hamburger, surely.

> , you may say "No, you cannot do that because ....".  But the real  
> cause is that our interpretation about HTTP could be different in  
> the same way that our interpretation about hamburger, dog, or IR  
> could be different.  But aren't we taking about a hamburger, what  
> the heck does it has anything to do with dog, IR, or HTTP?
>
> The cause of all these mess is either our confusion with messing up  
> representation with resource, or, the duality of HTTP-URI as both a  
> name and a locator.  If we separate "[http:]//xiaoshu.wang/
> a.hamburger" -- the URN -- from "http://xiaoshu.wang/a.hamburger" --  
> the URL, I don't think you will have much concerns.  Do you?

Maybe not, but I fail to see how to make the URL/N distinction if they  
are indistinguishable textually. And I am still left wondering how to  
refer to a locatable thing like a Web page, if I have to use a URN to  
refer to it. Why not just use the name everyone else uses?

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]

>
>> [I will make this public as if our discussion were desired as Ray has
>> expressed.]
>>
>> To answer your HOW-to question, allow me to use my proposed
>> scheme-less URI convention.
>>
>> Assume that I own the domain name "xiaoshu.wang" and I designated the
>> (scheme-less) URI:  "//xiaoshu.wang/a.hamburger" to denote the
>> hamburger burning on the grill of my backyard on a sunny day.
>> In our traditional web jargon, the URI --
>> "//xiaoshu.wang/a.hamburger" -- is an absolute URN, hence its
>> semantics is only about denotation.
>
> Hmmm... I guess I was presupposing that we were talking about HTTP
> URIs in this forum. But as I don't think it makes any real difference,
> let us proceed:
>
>>
>> There are many ways that we can get a representation (in the most
>> general philosophical sense) of "//xiaoshu.wang/a.hamburger".
>
> Oh, no disagreement there. But I didn't ask about getting a
> representation in a broad sense, but in the very narrow sense used in
> awww debates, where it means the kind of 'representation' which Roy
> talks about in his thesis REST model, and which HTTP talks about when
> it refers to representations of resources. This much narrower sense
> refers to a byte stream which is a sufficiently detailed and precise
> representation as to allow a close-to-identical copy of the resource
> to be assembled by the recipient of the message. For example, this
> kind of representation of a page of a book might be a high-resolution
> image of the page, or it might be a PDF file which can be
> reconstructed into an accurate digital rendering of the original page.
> But a mere description in RDF, for example, would not meet these very
> tight requirements on awww:representations. Seems to me that to do
> this with hamburgers requires a matter transporter or telekinesis.

That is my point of argument.  What is this "close-to-identical" (the
fidelity as in this Sotomayor's defense) is non-sense.  The "fidelity"
is always be interpreted by some one or some group.  There is no escape
of this "personal" context.   Take your "high resolution"as an example,
how do you know if I am not wanting the high resolution in terms of the
molecular structure of that book, instead of its content or image? You
must define your 'resolution' before making it high.  You cannot say
compare two things without setting the criteria of comparison.  In other
word, you cannot say which thing is a better awww:representation better
than the other.  There is only one thing that is certain.

There is a awww:representation.  In the web, it is usually carried in
(or is ) a byte-stream.  You work with representation in the Web, which
HTTP is part of.  Just like you work with photons in your daily life,
which SEE is part of.  This is the only common ground.

>>
>> We can *see* it, i.e., by turning our head and opening our eyes so
>> light rays can bounce off the hamburger into our eyes.  Let's denote
>> this particular kind of representation retrieval with a URI scheme --
>> see, as follows:
>>
>> "see://xiaoshu.wang/a.hamburger"
>>
>> In our web jargon, the above URI is a URL because it is bound with
>> the transportation protocol "SEE".  By this URL, we can get back a
>> representation, in the form of a bunch of photons delivered to our
>> retina.
>
> But (1) we cannot send photons in a byte stream, and (2) I don't think
> that the light reflected back from a thing is a 'representation' of
> that thing in any useful sense. When we see things, our brains
> construct representations of them which constitute our visual
> awareness, but thats not done by the photons themselves and its not in
> any way isomorphic to the photons. Still, this is a philosophical
> quibble in  the context of this discussion, as you could run your
> point with a URI prefix of cognizes://

Thus, the protocol SEE is defined as a bunch of photons bombarded on my
retina over a time period.   And the representation of SEE is defined as
a collection of photons over my retina. This is *my* definition of SEE,
just as how HTTP is defined by its HTTP protocol of saying if and how to
fire off a bunch of bytes.  I am not talking about cognition.  I am
talking about protocol.

>>
>> Similarly, we can
>>
>> hear://xiaoshu.wang/a.hamburger (with air pressures as
>> representations delivered to our eardrum)
>> get://xiaoshu.wang/a.hamburger (some heat, pressure, as
>> representations delivered to our hand)
>> eat://xiaoshu.wang/a.hamburger (some fat, carbo, salt, as
>> representations shuffled down to our throat)
>> ....
>> http://xiaoshu.wang/a.hamburger (some document packed in bits as
>> representations delivered to our laptop or desktop or your palmtop....)
>
> They key is that its a DOCUMENT in this case, and the document  (not
> the hamburger) is the resource which is represented by the bits. And a
> representation of a representation of X is not a representation of X.
> Even denotation isn't transitive in this way: the Hollywood sign is
> called "Hollywood sign", and that phrase does not refer to Hollywood.

Nope.  The "document" is what is delivered to you.  Applying HTTP to
"//xiaoshu.wang/a.humburger" returns a document, not a hamburger.   I
don't know what "http://xiaoshu.wang/a.humburger" (the URL but not the
URN) denotes and I don't care.  Just like if you ask me what does "see a
hamburger" denotes, I don't know and I don't care.  I got an visual
image of (aka, SEE) a hamburger, that is all.

You can call whatever the referent of "http://xiaoshu.wang/a.humburger"
a document or IR.  That is fine.  But the difference is.  An IR exists  
-- not because of some a priori character that HTTP can apply to.  But
an IR exists as a posteriori -- only because an HTTP protocol is applied
to. A digitized file sitting in your hard-drive is not an IR.  It
becomes an IR only when you mapped your web server 's directory to it.  
Thus, it is *you* who made someone or something an information
resource.  Not the thing itself.

>>
>> So, what is the HOW that you want to know?  Is it "how do we see,
>> hear, eat, and HTTP"?  Then, take a biology class or in the latter
>> case, read the HTTP spec.  But here is the point: we don't need to
>> know how we see in order to see (i.e., to perceive the photons)
>> because our body just *can*.  By the same token, we don't need to
>> know how the Web delivers an awww:representation in order to use the  
>> awww:representation because the Web just *can*.
>
>>
>> So, I do not think that is the reason for you to ask the know-HOW.  
>> The reason that you want to ask the KNOW-how is that you want to feel
>> confident in taking the content carried in a representation to be
>> true (or false).
>
> Im not arguing here for boolean descriptive representations. Quite the
> contrary, in fact: I don't think that awww:representations can
> possibly be false (they can be *wrong*, but not *false*)

I will skip the truth part since it is not your concern.  (I thought it
is because Stuart has this concern before.)

My point with the URL/URN is.  Then, if we have a URN/URL distinction.  
Then, we will say

The URN of "http://exmaple.com/a.hamburger" denotes the hamburger.
The URL of "http://example.com/a.hamburger" denotes an information
resource, or whatever you want to call it.

Would you still have concern?  Would you still need to care if the URL
200 or not?

This is in the same essence of TBL's suggestion to use hash-URI as names
because the problem can only be solved through syntax because there
isn't a priori nature for something to be IR. (But the hash-URI has its
problem with existing use of slash URI and it still need to clarify its
meaning when conneg is considered).

Xiaoshu

[mnot]

With my HTTPbis WG chair hat on:

While some aspects of this thread have been related to HTTPbis' work,  
it appears that we've resolved that portion, and many of the other  
messages are not on-topic.

I'm generally tolerant of discussion that is related to HTTP even if  
it's not within our charter, but this thread is both voluminous and,  
in parts, quite distant from the focus of the WG.

Therefore, please desist from including the ietf-http-wg list unless a  
specific question needs to be discussed by the WG.

Thanks,



On 15/07/2009, at 11:01 PM, Ray Denenberg, Library of Congress wrote:

> I for one would appreciate if as much of this discussion as possible  
> remain ON-list.  I really don't care if peoples' mailboxes are  
> filling up or people are offended by some off-color language or  
> disagreeable arguments.  I've learned more about this issue from  
> this thread than from reading all the "relevant" documents.
>
> --Ray
>
> ----- Original Message ----- From: "Richard Cyganiak" <richard@...
> >
> To: "Larry Masinter" <LMM@...>
> Cc: "'Pat Hayes'" <phayes@...>; "'Roy T. Fielding'" <fielding@...
> >; "'Jonathan Rees'" <jar@...>; "'Julian Reschke'" <julian.reschke@...
> >; "'HTTP Working Group'" <ietf-http-wg@...>; <www-tag@...>
> Sent: Tuesday, July 14, 2009 9:11 PM
> Subject: Re: Review of new HTTPbis text for 303 See Other
>
>
>> Thanks Larry. I wish I could talk with such clarity.
>>
>> I want to take the discussion with Pat a bit further, but will do  
>> so off-list. (Tomorrow, Pat -- I need to mull it over a bit.)
>>
>> I initially joined the thread to say this: The HTTP spec, with  
>> Roy's proposed new 303 text, accommodates all Semantic Web use  
>> cases I can think of. Including using HTTP URIs to denote people.  
>> It's good to see httpRange-14 slowly "trickle down" into the specs.
>>
>> Cheers,
>> Richard
>>
>>
>> On 14 Jul 2009, at 21:46, Larry Masinter wrote:
>>
>>> This conversation is filling my mailbox. Some general
>>> observations:
>>>
>>> (Pat, your arguments are laced with ad hominem, which makes reading
>>> the dialog unpleasant. I don't think Richard is being
>>> silly, intellectually dishonest, bloody arrogant, or any of the
>>> other terms you've used, please refrain.)
>>>
>>> It's the nature of standards discussions that people speak
>>> their point of view; doing so isn't arrogant.
>>>
>>> It is the nature of technical specifications that it is frequently
>>> necessary to take normal English words in particular technical
>>> way; it is not intellectually dishonest to do so.
>>>
>>> It is good practice for technical specifications in standards
>>> groups to say as little as possible in order to meet the
>>> needs of interoperability and the purpose for which the
>>> specification is being written.
>>>
>>> It is not necessary or even possible for a technical specification
>>> to answer questions that may be fundamental for applications
>>> that are outside of its scope. It is common, reasonable,
>>> and traditional for standards specifications to "not answer"
>>> questions because answering the question isn't necessary
>>> for the purpose for which the standard was written.
>>>
>>> It isn't necessary for the proper functioning of the web and
>>> to accomplish interoperability of web clients and servers
>>> to agree on how to use HTTP URIs and the HTTP protocol --
>>> for that purpose, it isn't necessary to answer the question
>>> of whether a HTTP URI can identify a person.
>>>
>>> It may be necessary to answer the question in a technical
>>> specification for the semantic web and in the RDF
>>> specification  -- but the answer more likely
>>> belong in those specifications and not in the
>>> IETF HTTP specification.
>>>
>>> It may be necessary for the IETF HTTP specification
>>> be edited in a way that made it clear that it didn't
>>> contain the answer to this question, but I'm not
>>> sure where to draw the line of describing things
>>> it doesn't answer.
>>>
>>> It's easy to imagine a system in which a URI is used
>>> to identify a person for the purpose of that system.
>>> But I can't see how IETF, W3C, or continued discussion
>>> on any of our mailing lists are going to converge
>>> any time soon on answers to the philosophical questions
>>> that have been with us for millennia. What is it
>>> that "Pat Hayes" identifies, anyway? Can I use
>>> mailto:phayes@... as a URI to identify you?
>>> Well, that's a question outside of the "mailto:"
>>> URI spec, I think.
>>>
>>> Perhaps  there needs to be a better way of distinguishing
>>> the statements "this specification does not limit the scope
>>> of applicability" and "this specification applies in all
>>> circumstances".
>>>
>>> If you had some better way of phrasing it so that it would
>>> be clear the former was meant rather than the latter, I
>>> think that would be helpful.
>>>
>>> The fact that something "does matter" -- to you, to the
>>> RDF community, to the W3C, to the world at large --
>>> does not mean that it is appropriate to "matter" in
>>> the context of the HTTP spec.
>>>
>>> It is an important design principle for developing
>>> specifications to keep specifications orthogonal: for the purposes
>>> of the HTTP protocol, it does not matter what resources
>>> are exactly. For the purpose of resource identification, it should
>>> not matter what the protocol is; tying semantic web
>>> interpretation to a particular error code in the HTTP
>>> protocol seems like bad design to me.
>>>
>>> The idea that the HTTP working group should care about the
>>> semantic web and change its specification to meet some
>>> semantic web requirement for use of HTTP URIs in semantic
>>> web applications  -- well, that raises several red flags
>>> for me, that we're building specifications that are not
>>> sufficiently orthogonal that things that *shouldn't* matter
>>> are taken as important questions that *must* be answered.
>>>
>>> The HTTP specification is *not* about what a "resource" is.
>>> It *is* about how to use and implement the HTTP protocol.
>>> There continues to be some confusion in the discussion between
>>> "URI" and "HTTP URI" that I find disturbing and confusing, because
>>> I think sometimes statements about one are attributed to the
>>> other. Not all URIs are HTTP URIs. Please try to be more careful.
>>>
>>> Regards,
>>>
>>> Larry
>>> --
>>> http://larry.masinter.net
>>>
>>>
>>>
>>
>
>

--
Mark Nottingham     http://www.mnot.net/

[Alan Ruttenberg-2]

On Wed, Jul 15, 2009 at 6:01 PM, Xiaoshu Wang <xiao@...> wrote:
>
> That is my point of argument.  What is this "close-to-identical" (the fidelity as in this Sotomayor's defense) is non-sense.  The "fidelity" is always be interpreted by some one or some group.  There is no escape of this "personal" context.   Take your "high resolution"as an example, how do you know if I am not wanting the high resolution in terms of the molecular structure of that book, instead of its content or image? You must define your 'resolution' before making it high.  You cannot say compare two things without setting the criteria of comparison.  In other word, you cannot say which thing is a better awww:representation better than the other.

We are in a bit of trouble, then, unless we remove whatever
corresponds to rfc2616 section
3.9: 'Quality Values' from the new spec. That section presumes that it
is indeed possible to make assessments of similarity/quality (or
relative degradation) of a representation as compared to a resource.

BTW, this wouldn't be semantics creeping into the nice neat
specification, would it?

Here is what I expect the form of the answer will be, given the
previous parts of this conversation. The words "quality" and
"degradation" are not what you and I mean by "quality" (closest
wordnet http://www.golovchenko.org/cgi-bin/wnsearch?q=quality#2n) and
"degradation" (closes wordnet sense, nominalization of
http://www.golovchenko.org/cgi-bin/wnsearch?q=degrade#3v). They are
awww:quality and awww:degradation, terms which allow for some scale
along which to order representations, the exact nature of such
ordering this spec need not be concerned with.

-Alan

(ietf-http-wg cc removed per request of Mark)