- From: Pat Hayes <phayes@ihmc.us>
- Date: Tue, 14 Jul 2009 11:59:33 -0500
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: "Roy T. Fielding" <fielding@gbiv.com>, Jonathan Rees <jar@creativecommons.org>, Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>, "www-tag@w3.org WG" <www-tag@w3.org>
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 (850)434 8903 or
>>>>>> (650)494 3973
>>>>>> 40 South Alcaniz St. (850)202 4416 office
>>>>>> Pensacola (850)202 4440 fax
>>>>>> FL 32502 (850)291 0667 mobile
>>>>>> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ------------------------------------------------------------
>>>> IHMC (850)434 8903 or
>>>> (650)494 3973
>>>> 40 South Alcaniz St. (850)202 4416 office
>>>> Pensacola (850)202 4440 fax
>>>> FL 32502 (850)291 0667 mobile
>>>> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>> ------------------------------------------------------------
>> IHMC (850)434 8903 or (650)494
>> 3973
>> 40 South Alcaniz St. (850)202 4416 office
>> Pensacola (850)202 4440 fax
>> FL 32502 (850)291 0667 mobile
>> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
>>
>>
>>
>>
>>
>
>
>
>
------------------------------------------------------------
IHMC (850)434 8903 or (650)494 3973
40 South Alcaniz St. (850)202 4416 office
Pensacola (850)202 4440 fax
FL 32502 (850)291 0667 mobile
phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Tuesday, 14 July 2009 17:00:56 UTC