Review of new HTTPbis text for 303 See Other

[Pat Hayes]

On Jul 20, 2009, at 8:37 PM, Henrik Nordstrom wrote:

> mån 2009-07-20 klockan 13:16 -0500 skrev Pat Hayes:
>
>> Apparently you have not understood my point, above. There are cases
>> where NO implementation of ANY KIND can POSSIBLY map a URI to the
>> resource it identifies. So one cannot simply toss this issue over the
>> wall to some other, unspecified, "implementer". Its nothing to do  
>> with
>> implementation.
>
> For the kinds of URIs that HTTP deals with it can, as far as HTTP is
> concerned with the definition of "resource" as used by http which for
> technical specification writing reasons is slightly narrower than the
> general URI definition of resource.

It is not 'slightly' narrower. The general definition of 'resource'  
has it meaning absolutely anything, real or imaginary, concrete or  
abstract, that can be referred to and distinguished from other things  
(the last five words inserted to make sense of the 'identify'  
language). This is not a 'slightly' wider sense than the one that you  
apparently have in mind. It is a spectacularly, transfinitely, almost  
cosmically wider sense. It is as wide as human language knows how wide  
to make a distinction.

>
>> I understand, but I am not talking about 'effects', but about  
>> semantics.
>
> And HTTP is completely ignorant of any semantics that the URIs  
> accessed
> via HTTP may have.
>
> What HTTP cares about is if there may be effects on the resource state
> by actions requested by HTTP. (i.e. DELETE is assumed to have certain
> effect when executed on the http resource)
>
>> My point is that you cannot completely ignore the rest of the world.
>
> When writing a technical specification you can, as the relevant part  
> of
> the world is then the parts that the specification intends to cover  
> and
> only those parts.

BUt when your specification is about a language or a notation, and in  
part about what that notation means, and when in fact that notation is  
being used to mean things in a certain (wide) category, then such  
usage does fall within the scope of your specification, and you should  
deal with it, if only by stating explicitly that you are not going to  
consider it.  But to ignore it and pretend that it isn't there, by re-
defining an existing terminology so as to avoid interfacing with other  
specifications, is both intellectually dishonest and socially  
irresponsible. Sorry, strong language, but I really do feel strongly  
about this, having had to face up to this issue myself when writing  
specifications.

>
>> BUt you yourself said that I was thinking about the wrong kind of
>> meaning, not the kind of meaning intended by the spec. Really, you
>> cannot have it both ways. Please make up your mind which is your
>> position, and stick to it.
>
> HTTP places absolutely no meaning at all on the general term  
> "resource"
> as used in english

Never mind the English meaning, which is now lost to history in these  
debates.

> or even the "resource" as defined by URI
> specifications.

But does it not strike you as inappropriate to simply ignore the  
normative definitions used in defining technical terms which you  
yourself use? What is the point of writing specifications if other  
specification writers are free to redefine the terminology which my  
specification defines normatively?

>
> The only kind of resource HTTP places any meaning on at all is the  
> very
> much narrowed down "resource" as defined by the HTTP specifications,  
> and
> even then it's just as an abstract concept to simplify the world
> description somewhat. To HTTP it does not matter at all what those
> resources are, only if they can be accessed and/or transmitted via  
> HTTP

I understand all this. But there are cases where the resource  
identified by the HTTP URI is, in fact, not one of these. That is -  
regardless of its true metaphysical nature, which I agree we will not  
delve into - whatever it really is - it is not something that can be  
accessed and/or transmitted. Such cases are REAL, they are out there  
in the actual world. If your spec refuses to acknowledge this, then it  
is simply an incomplete specification; and as such, it is less useful  
that it can and should be.

> or not as defined by whoever "owns" the resource and who also defines
> their intended URI semantics (again completely outside of HTTP
> specifications).
>
>> I know it does not wish to, but http-range-14 has left it no choice
>> but to care about it, at least a little.
>
> Has it? Care to explain that again then, using the term meanings as
> defined by HTTP.

http-range-14 specifies an HTTP-defined action (the use of a 303  
redirect) be used under circumstances which arise when the URI in  
question identifies a thing which is not a resource according to the  
narrow sense of 'resource' which you are arguing HTTP should restrict  
itself to.

>
>> The semantics of URIs has nothing at all to do with layering. It is
>> part of the specification **of URIs themselves**. When anyone talks
>> about the relationship between a URI and the resource it identifies,
>> or denotes, or refers to, or is used to request, or indeed pretty  
>> much
>> any relationship between a URI and a resource, they are talking about
>> semantics.
>
> Ok. My point here is that HTTP does not care about those semantics.

And my point is that it must, at least to the minimal extent required  
to state a normatively required action under circumstances which can  
only be described by referring to those semantics. (And also - though  
this is more controversial - I would argue that in fact, HTTP is  
already concerned with the semantics of URIs, even though it refuses  
to acknowledge this elementary fact.)

> All
> it possibly cares about is that the server is the ultimately  
> responsible
> for executing that semantic mapping

This is a conceptual mistake. Semantic mappings are not executable.

> of URI to resource (in URI terms),
> and that this mapping results in HTTP network accessible resources
> (which you seem to sometimes call a representation where HTTP calls  
> it a
> resource

I hope not. I try to keep the resource/representation distinction  
clear. There are however two or more notions of what counts as a  
'representation': when in doubt, I use the now-standard circumlocution  
awww:representation to refer to the narrow sense used in REST and (I  
assume) HTTP.

> ) and their possible representations as defined by HTTP.
>
>> Because the HTTP specs also talk about this. And it is generally a
>> good idea, when two specs talk about the same thing using the same
>> language, that some effort is expended to make sure they are  
>> intending
>> to use this language in the same way.
>
> Unfortunately if a new term is to be defined for every slight  
> variation
> there is of the term "resource" in this I am afraid it would be even
> more confusing.

As I have tried to emphasize, this is not a 'slight variation', and in  
any case I doubt if there are going to be any more changes once we  
have established that a resource can be absolutely anything.

>
> There is very good reasons why "resource" in the URI specifications
> broader than "resource" in HTTP specifications and both being narrower
> than the general English "resource".

No, the English meaning is actually narrower than the URI  
specifications sense, which is highly idiosyncratic and of fairly  
recent coinage (see the Wikipedia entry of 'resource' for a good  
history.)

>
>> I understand, but it refers to resources. If for example the spec  
>> says
>> (as I believe it does, currently) that if the server has available a
>> transmittable representation of the requested resource, then it must
>> return that with a 200 code, this statement makes no reference to the
>> URI that was used to identify the resource.
>
> The URI reference is implicit as the whole text is in the context of
> builiding a response to a request for a specific URI. Trying to read  
> the
> text outside that context is non-sense.

PLease read what I wrote more carefully. To say that the server has  
available a transmittable representation of the requested resource,  
without referring to the URI that was used to request the resouirce,  
is not nonsensical in any way at all. It implies, as I read it, that  
this condition holds independently of the URI, so that if the same  
resource is requested by different URIs then this condition either  
holds for both of them or for neither of them. So it rules out the  
possible case where the condition holds for one URI request but not  
for the other URI request, with a different URI but the same resource.

>

....

>
>> No, it is quite on the point. If the server can respond differently  
>> to
>> different URIs which both identify the same resource, that changes  
>> the
>> game.
>
> If the defined semantics of the URIs says the server should respond
> differently then they in the world as defined by HTTP refer to  
> different
> resources, but possibly very closely related such.
>
> It all boils down to the definition of what a resource is, and the  
> HTTP
> resource is as I already explained NOT as general as the URI resource.

No, the situation is far worse than this. According to your previous  
paragraph, we can have a situation where two URIs identify the same  
resource according to the URI spec, but must be understood by HTTP as  
corresponding to different resources. Just narrowing the sense of  
'resource' will not get you this horrible situation. This, if indeed  
you are right (nobody else has suggested this idea, so I hope you are  
wrong) makes the HTTP and URI specifications sharply **incompatible**  
with one another.

>
>>> In the terminology defined by HTTP the difference between an
>>> (HTTP-)URI
>>> and resource is more of a special case, and not related to any of  
>>> what
>>> you talk about.
>>
>> It is related. In fact it is critical.
>
> To me when talking about HTTP it's not.
>
>> Ah. That certainly makes sense, and indeed is what I understood  
>> when I
>> first became involved in these URI-meaning debates. But this position
>> is not consistent with what is said about resources in other
>> standards.  And moreover, if this is true, then the http-range-14
>> decision is simply untenable. For in that case, the 'requested
>> resource' is something that cannot possibly be inside a server.  
>> Julius
>> Caesar, let us say, might be the requested resource.
>
> And is what we have been saying all along. Trying to use Julius Casear
> as an example when talking about HTTP resources just does not make any
> sense as the two by definition can not be the same thing.

And yet, there are HTTP URIs which identify Julius Caesar, in the  
sense of "identify" used in the URI specs. And, moreover, Http-
range-14 actually places some conditions on what HTTP must do with  
such a URI, **because** it identifies a resource of that 'off-Web'  
kind. So the behavior of HTTP depends, in part, and can only be  
accurately specified by mentioning, the situation where a URI  
identifies a "non-HTTP" resource. And this DOES make sense. In fact ,  
it is actually TRUE.

>
>>> Yes it's a simplification, but defining or assume anything about
>>> resources anywhere beyond that is outside of HTTP scope and nothing
>>> HTTP
>>> cares about and is left to the application of HTTP and/or URIs.
>>
>> No, sorry, that position is simply untenable. See me earlier replies
>> to Richard on this point. HTTP cannot hide inside a 'layer' and
>> pretend it is only dealing with computational identifiers which 'map'
>> to computational artifacts. Both the uses and the specifications of
>> http URIs have extended its scope beyond that narrow purview.
>
> And I disagree. The semantics of the application of HTTP is and should
> be much broader than the semantics as used by the HTTP wire protocol.
>
>> The operation of HTTP, according to http-range-14, is ALREADY
>> concerned with how URIs denote real-world entities beyond the
>> operation of http.
>
> And my viewpoint is that that's completely outside of what the HTTP
> specifications or operations is concerned about. In fact it
> intentionally does not care about any such concerns and leaves that to
> the application of HTTP to any such entities.

And, to repeat, that view is untenable, precisely because semantics is  
not about computation. Your notions of layering simply do not apply  
when you are purporting to make decisions based upon meanings: which  
you are, whether you like it or not. HTTP-range-14 has made this  
choice for you. Don't argue with me, if you want to keep your nice  
tidy 'layering': go back and argue with whoever made the http-range-14  
ruling.

> Anyone is free to define
> HTTP applications for such entities, by defining HTTP resources  
> mapping
> to such entities as they please. HTTP only defines how one may  
> interface
> with those once defined in terms of HTTP resources. What relations  
> those
> HTTP resources have to any real-world entities is defined by that
> application, not by HTTP.
>
>> (Not, by the way, with how *resources* map to real-
>> world resources. In the cases in question, the relationship between
>> the URI and the real-world entity is direct, not mediated through  
>> some
>> other resource inside a server.)
>
> And in my world that's an impossible condition, as those real-world
> resources do not exists in HTTP terms

They do exist, you are just refusing to look at them.

> and need to be mediated via some
> server defined HTTP resource to be accessible via HTTP, or requests  
> for
> that HTTP-URI would simply result in a 404 until a such HTTP  
> resource is
> implemented for mapping to the real-world resource.
>
>
>> But the phrase "that can be used to interact with a resource" ALREADY
>> limits what a resource can be. You cannot interact with the number 27
>> or with Julius Caesar.
>
> Please note that this part is just explanatory text trying to explain
> the relationship between HTTP and URI specifications, not a normative
> definition.
>
> The definition of "resource" in the HTTP specifications is found in  
> the
> terminology section.
>
>
>>>       resource
>>>
>>>               A network data object or service
>>
>> That is not the definition of resource used in RFC3986, however.
>
> What I said, and why I highlighted it here. The definitions are
> different, and you need to use the right definition for each
> specification or you'll get confused when discussing borderline issues
> like this.
>
> For most practical considerations in the use of HTTP the difference is
> negligible however.

Not any more. Thats why I'm making such a fuss about it. And BTW,  
these are not 'borderline' issues.

>
>> HTTP
>> URIs can identify resources in the broader RFC3986 sense; and for
>> those URIs, there may well not be any resource in this narrow sense
>> identified by the URI at all. And yet, still, a GET on them might
>> resolve to an http endpoint. What does the http spec say about such a
>> case? What is the endpoint to do?
>
> Yes it's correct that HTTP URIs can identify resources in the broader
> sense, but not something the HTTP specifications as such concerns  
> itself
> about. HTTP specifications end at the http endpoint and it's http  
> mapped
> resource.

Hmm, so in these cases, the HTTP URI identifies **two** different  
resources? The URI one and the HTTP one? Is that what you are saying?  
I doubt if many people on the TAG would like this.

>
>> And my point was only
>> that in this case, it is at best confusing any maybe actually wrong  
>> to
>> say that IF the server has a transmittable representation available
>> then it must send it with a 200 code.
>
> And we don't. We say "suitable to be transmitted", which is quite
> different from "transmittable" as there is representations that MAY be
> transmittable in theory but which is still deemed unsuitable (by the
> http server endpoint or it's policy)

OK, I wasnt meaning to confuse this issue, just using 'transmittable'  
as a shorthand. Sorry.

>
>> For what are we to say about the
>> second case? It all depends on what is meant by the "requested
>> resource".
>
> The difference between a "resource" (as identified by a specific URI)
> and an HTTP "requested resource" not what you think. The two differ  
> when
> there are multiple independent representations available by the exact
> same URI, such as content in different language based on the language
> preferences of the client etc.

But they also differ, presumably, when the identified resource is  
Julius Caesar. Or do they? I really have no way to know.

>
>> (It seems to me that HTTP rather shoots itself in the foot by this
>> insistence that its specs must not refer to or even acknowledge the
>> existence of resources that are other than network data or services,
>> since it has defined out of existence the very case that it should be
>> able to refer to, if only to explicitly say that its not going to
>> specify what happens in it. This is rather an ostrich way of writing
>> specs, to pretend that all of the world that you don't like doesn't
>> exist, so that you aren't obliged to say anything about it.)
>
> I don¨t agree here. HTTP specifications places a technical limit on  
> what
> the word "resource" means within the HTTP specifications, which is
> purely a technical definition.

And says nothing about the cases when HTTP URIs are used to refer to  
other kinds of resource. Which is an ostrich way of writing  
specifications.

>
>
>>> My response is that
>>> it's the servers role to select a suitable representation of the
>>> resource based on the meaning of the URI.
>>
>> Does that mean, of the resource that the URI identifies? And does
>> "identify" mean, denote?
>
> Sorry if I am unclear some times. English is not at all my native
> language, and the word "denote" is not really part of my limited  
> English
> vocabulary.

Sorry. 'denotes' AKA 'refers to', 'identifies', 'is a name for', is  
used as a name for'. I will try to remember to say 'refers to' or  
'identifies'.

>
>> From my understanding of "denote" it's:
>
> Of the HTTP resource the HTTP-URI identifies.
>
> Where identifies as in is in the sense of how an Universal Resource
> Identifier identifies a network-accessible resource, ignoring  
> completely
> what that resource denotes in the broader sense.

But you cannot ignore this completely when the URI does *in fact*  
identify something other than a network-accessible resource.

>
>> ??!!? Of course two different URIs can refer to the same resource. If
>> HTTP is built on a different supposition, then HTTP is simply wrong.
>
> Sure they can. The points here is:
> * that HTTP does not care if they do

OK, but...

> * and that HTTP has the view that if the semantics of those URIs is
> different then they do in fact NOT refer to the same resource

That simply does not make sense. What you say here (seem to say here)  
is logical nonsense. Look, if two names refer to the same thing (call  
it a resource if you like) then there is only one thing that they both  
refer to. So to say that 'as far as X is concerned' they refer to  
different things, is simply meaningless. There aren't two things there  
to be referred to, in this case. So, sorry: they DO IN FACT refer to  
the same resource. If HTTP thinks otherwise, then HTTP is simply  
WRONG. There is no finer-grained identity than identity itself.

If you think I am technically mistaken on this topic, please refer me  
to some published work which makes semantic sense of the view of  
identity that you are basing this claim upon. (And as I have had this  
discussion many times before, if you are going to cite LISP at me:  
identity in LISP is EQ, not EQUAL.)

> They may
> refer to different facets of some larger/broader resource but not the
> same.

I have no idea what you mean by a facet of a resource. What 'facets'  
does Richard or J.C. have?

>
> If those URIs happens to really refer to the same resource both URIs
> will respond identically, and further is indistinguishable from two
> identical copies of the same resource.
>
>> ?? I am trying to make sense of this, and not sure I have it right.
>> Take the case in my email to Richard, where there is a URI denoting
>> him, Richard C., the actual person. (Note, this is not a topic that
>> HTTP gets to rule out or refuse to acknowledge, because this can in
>> fact happen. My question is about what HTTP should do in such a  
>> case.)
>
> HTTP handles the case by restricting it's notion of resource to the
> network-accessible resource used for interfacing with Richard C.

First, there is no such resource: Richard C. isn't the kind of thing  
that you can 'interface' with over a network. (Well, maybe by email,  
but then we would be talking about his emailbox.)  Second, its not  
important what HTTP 'restricts' itself to: the fact remains that (in  
the case described) the URI does **in fact** identify Richard, not  
some network-accessible thingie that stands in some relationship to  
him. (That thingie might have its own URI, of course, which does  
identify it.) So if what you say here is correct, I presume that HTTP  
simply treats the URI as not having a corresponding http:resource at  
all. Right? Because it is a basic assumption of the whole Web  
architecture that the resource identified by a URI is unique. So if  
the URI identifies Richard, it can't also identify the thingie.

> That
> resource MAY or MAY NOT have an actual interface with Richard C, HTTP
> does not care and need not care for it's operations.
>
>> In this case, according to Richard, he is the 'requested resource'.
>> The GET request is directed to a server which has some other resource
>> inside it, call this resource R. R is a resource in your narrower
>> sense (a network data object or service), but this is *not* the
>> requested resource in this case, even though the URI resolves to (the
>> server containing) R.
>
> In terms of HTTP R is the requested resource.

I thought you might say that. So what then is the relationship between  
a requested resource and the resource identified by a URI? Apparently  
they can be different, so we have at least two resources somehow  
connected with a URI. Are there any more?

>
>> (Do you agree?) In this case, http-range-14
>> requires that the server emit a 303 coded response, because even
>> though there may well be a transmittable (awww-) representation of R,
>> there is none of Richard C., and he is the requested resource.
>
> That's up to R (or whoever/whatever defines R) to decide.

No, it is not. It is simply a fact that there is no transmittable  
awww:representation of Richard. He isn't the kind of thing that has  
such representations.

But in any case, it appears that, on your account, the whole action of  
HTTP need have **absolutely nothing** to do with the resource that the  
URI identifies (in this case, Richard.) So tell me: here I am with a  
URI, and in order to find out more about what it identifies, I use it  
in an HTTP GET, and something happens. What, if anything, can I  
conclude about the resource that my URI identifies? AFAIK, the only  
possible answer is, on your account: nothing at all. Its all going to  
be mediated by the resource that the URI requests, and that need have  
nothing to do with what it identifies. Nor need the response codes  
have any connection with the resource identified by the URI: indeed,  
if the requested (not identified) resource has a 200-level-suitable  
awww:representation, then that is what the server must send me back,  
even though neither it not its source (that is, in the above example,  
neither the awww:representation of R not R itself) need have anything  
whatever to do with the identified resource (Richard). Right?

I agree this picture has a certain elegance and simplicity, but it  
makes complete nonsense of almost everything that has been said and  
written about URIs and resources for the past decade. It means that  
the picture of Web architecture promoted by the TAG is sharply and  
fatally different from that supported by HTTP.

Anyone else like to comment on this?

Pat

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

[Tim Berners-Lee]

On 2009-07 -20, at 16:27, Pat Hayes wrote:

[...]

. But this thread started because HTTPbis explicitly disagrees with RFC 3986 on what a resource is. Surely these various documents should at least agree on their uses of the basic technical terminology.

I agree. 

Historically, URIs were used to point to thinks like web pages and files and movies, on the web, useful documents, or "online resources" in the sense of useful things out there. FTP. Gopher and HTTP sites served up various types of online resources.  People got used to http://example.com/ being a web page and http://example.com/#contact being an anchor within it.

The Online Information community, into whose domain the web stuff was put for standardization at the IETF, referred to these things like web pages as resources, and changed the original "D" for "Document"  in "UDI" to "R".

Some felt that resource was more appropriate term, maybe because "document" wasn't wide enough to include things like movies.

Now the URI spec actually allowed URIs for completely different things, such as telephone end points, and wisely the URI spec does not make any arbitrary constraint on what a resource should be, especially a resource denoted by a URI in a new scheme to be invented.

Meanwhile, the HTTP spec was polished and elaborated basically as a document delivery system, plus other methods for updating documents, plus POST.  (POST started historically as a way of introducing a new web page  y posting it to a list, just as in NNTP.  It then almost immediately got used as a catch-all extension method. I will ignore it in this overview).

There was no real definition of what a resource or document was -- maybe because it seemed obvious. The HTTP spec did not even specify whether the URI denoted a person or a document about them, it just explained that the thing returned representation of the resource.

Roy's REST work then came along to formalize HTTP as REST and declared that a resource was a time-varying mapping between URI and representation. That was good enough for HTTP. It didn't have enough for the AWWW, when it came along, to be able to describe how the web worked.

In fact, the AWWW document, to explain how to use the web properly, had to add in a bunch of stuff about the social expectations -- things like, yes, the mapping from URI to representation is a function of time, but not just any old one -- a random function is not typically very useful. There are expectations about it can change with time.  Persistence, consistency, with various common patterns which allow the web to be a useful medium.  The AWWW decided to use the term "Information Resource" for a thing like a web page which contains information, and "Resource" for any old thing at all.

So HTTP and the REST work of was done very much in this space of document delivery, editing and update.  There was no philosophical need to talk about what he URI denoted (the person, the web page about the person) until RDF came along, when there was an immediate need.

When RDF was first developed, it was motivated by the need for data about resources very much in the online information sense: data about documents, or 'metadata'.  In fact it was designed to be able to describe anything, but many early users of RDF referred to it as metadata technology.  RDF used the word "resource" rather awkwardly in fact as it turned out.  In the beginning, many of the things being described were documents, and so the online information meaning of resource made sense. But in fact in RDF the resource was allowed to be anything at all. A class, rdf:Resource even used the term as the universal class of all things.  A little later, the Web Ontology Language decided to use Thing for that. 

RDF came along in what I think was a neat way.  It used completely existing web protocol extension devices to introduce a new system which was fundamentally different from the old HTTP+HTML one.  The HTML web was a hypertext model, which pages and anchors. The RDF model was a knowledge representation one of arbitrary things.  It did this by using the fact that a new language can define whatever it likes as what a local identifier denotes.  A graphic language might use local identifier to denote lines and points. HTML used local identifiers to identify hypertext anchors.  RDF used them to identify arbitrary concepts, people, whatever.

The web architecture gave all these languages a common way of building a global identifier for the thing denoted by a local identifier in a given document.   The semantics of the hash sign are defined web-wide to mean that "a#b" can be used to denote whatever is denoted by "b" in the document denoted by "a".

Worked a treat.  At the beginning of the century, people played around and gave all kinds of things URIs like "http://example.com/foo.rdf#color".  Some of us did lots of work and made all kinds of systems which exchanged and integrated data in this way.

Two snags occurred, as the years passed.  One was that a bunch of RDF users got the fact that it was good to use HTTP URIs, but didn't get the fact that you should put the foo.rdf online so that people can look up what #color means in it.  And as they didn't do that, they didn't actually bother with the "#" at all.  The second fly in the ointment was that some people wanting to use RDF for large systems found that they didn't want to use the "#". This was sometimes because the number of things defined in the same file was too low (like 1) or too large (like a million) and it was difficult to divide up the information into middle-sized chunks. Or they just didn't like the "#" because it looks weird. But for one reason or another people demanded the right to be able to use http://example.net/people/Pat to denote Pat rather than a web page about Pat.  

This potentially led to huge failures in the whole RDF world, with systems already built which just used   "http://example.net/people/Pat" to identify the document whether you like it or not.

I among others pushed back against using non-hash URIs for arbitrary things his but eventually gave in.

So in response to this, the HTTP protocol was, in fact, changed.

The spec wasn't changed.  The spec editors were not brought on board to the new model.  The spec was interpreted.  The TAG negotiated in a way a truce between the existing HTTP spec, RDF systems, and people who wanted to use HTTP URIs without "#" to identify people.  That truce was HTTPRange-14, which said that yoiu don't a priory know that a hashless HTTP URI denoted a document, but if the server responded with a 200 then you did, and you had a representation of the document.   If you did a get on one of these new URIs which identified things were not documents (people, RDF properties, classes, etc) them the server must not return 200, it can return 303 pointing to a document which explains more.

So the HTTP protocol was, effectively,  changed.  The HTTP protocol as extended now allows HTTP to be used not only for Documents but for arbitrary Things.  It extends the set of things which you can ask a web server about from documents to anything.  It isn't a very bad design, nor very beautiful.  Other designs would have worked, but that one was the only one which didn't have major problems for some community.  It could be extended, but basically it works. It would be very expensive to reverse it in terms of systems which have been deployed.

It is also very expensive to go on debating it as though it is an open issue. It is reasonable to try to make the documents more consistent. 

Anyway, that is a simplified version of the history of all this as I saw it. 

I would like to see what the documents all look like if edited to use the words Document and Thing, and eliminate Resource. That's my best bet as to two english words which mean as close as we can get to what we want. Note however that the web is a new system, a design in which new concepts are created, so we can't expect english words to exist to capture exactly the concepts. So we take those nearby and abuse them as little as we can as far as we can tell at the time, and then write them in initial caps to recognize that that is what we have done.

Tim  

[Michael(tm) Smith-4]

Tim Berners-Lee <timbl@...>, 2009-08-01 22:14 -0400:

>  I would like to see what the documents all look like if edited to use the
>  words Document and Thing, and eliminate Resource. That's my best bet as to
>  two english words which mean as close as we can get to what we want. Note
>  however that the web is a new system, a design in which new concepts are
>  created, so we can't expect english words to exist to capture exactly the
>  concepts. So we take those nearby and abuse them as little as we can as far
>  as we can tell at the time, and then write them in initial caps to recognize
>  that that is what we have done.

I wonder if Content and Thing or Contents and Things might also
work. And when it's necessary to refer to non-Things in singular,
"an instance of Content". (I do realize that's a lot more
cumbersome than Document.)

  --Mike

--
Michael(tm) Smith
http://people.w3.org/mike/

[Michael(tm) Smith-4]

"Michael(tm) Smith" <mike@...>, 2009-08-02 14:42 +0900:

> Tim Berners-Lee <timbl@...>, 2009-08-01 22:14 -0400:
>
> >  I would like to see what the documents all look like if edited to use the
> >  words Document and Thing, and eliminate Resource. That's my best bet as to
> >  two english words which mean as close as we can get to what we want. Note
> >  however that the web is a new system, a design in which new concepts are
> >  created, so we can't expect english words to exist to capture exactly the
> >  concepts. So we take those nearby and abuse them as little as we can as far
> >  as we can tell at the time, and then write them in initial caps to recognize
> >  that that is what we have done.
>
> I wonder if Content and Thing or Contents and Things might also
> work. And when it's necessary to refer to non-Things in singular,
> "an instance of Content". (I do realize that's a lot more
> cumbersome than Document.)

Or maybe even "Content Instance" (CI). Slightly less cumbersome, and
also has the advantage of being more obviously a specific term of art.

  --Mike

--
Michael(tm) Smith
http://people.w3.org/mike/

[Alan Ruttenberg-2]

Nice concise history :)

On Sat, Aug 1, 2009 at 10:14 PM, Tim Berners-Lee<timbl@...> wrote:
> I would like to see what the documents all look like if edited to use the
> words Document and Thing, and eliminate Resource. That's my best bet as to
> two english words which mean as close as we can get to what we want. Note
> however that the web is a new system, a design in which new concepts are
> created, so we can't expect english words to exist to capture exactly the
> concepts. So we take those nearby and abuse them as little as we
> can as far as we can tell at the time, and then write them in initial caps to
> recognize that that is what we have done.

If you were to go in that direction, I think you ought to consider
adding "Service" as a third category. Thing at the top, with the
children document and service disjoint (not a complete partition,
obviously).

The reason is that services operate very differently than documents,
even though they can sometimes return documents. And what we consider
to be reasonable representations (web sense) of documents have a very
different flavor than the representations returned by services. If
this distinction was clear then we might have a much better go at
starting to more clearly document expectations on what are reasonable
representations to return in each case, something that is sorely
missing in the current documentation. (The usual answer - the
representation is whatever the owner wants it to be - not very
satisfying).

As an example we could then say that POSTs to a URI that denotes a
document are intended to change that document. And we could contrast
that with POSTs to services, which do all sorts of things, for example
run queries.

-Alan


-Alan

[Ashok Malhotra]

Would weather.com where I type in my zipcode to get local weather be
classified as a service?
Clearly Google maps is a service.  Are all interactive sites services?
All the best, Ashok


Alan Ruttenberg wrote:

> Nice concise history :)
>
> On Sat, Aug 1, 2009 at 10:14 PM, Tim Berners-Lee<timbl@...> wrote:
>  
>> I would like to see what the documents all look like if edited to use the
>> words Document and Thing, and eliminate Resource. That's my best bet as to
>> two english words which mean as close as we can get to what we want. Note
>> however that the web is a new system, a design in which new concepts are
>> created, so we can't expect english words to exist to capture exactly the
>> concepts. So we take those nearby and abuse them as little as we
>> can as far as we can tell at the time, and then write them in initial caps to
>> recognize that that is what we have done.
>>    
>
> If you were to go in that direction, I think you ought to consider
> adding "Service" as a third category. Thing at the top, with the
> children document and service disjoint (not a complete partition,
> obviously).
>
> The reason is that services operate very differently than documents,
> even though they can sometimes return documents. And what we consider
> to be reasonable representations (web sense) of documents have a very
> different flavor than the representations returned by services. If
> this distinction was clear then we might have a much better go at
> starting to more clearly document expectations on what are reasonable
> representations to return in each case, something that is sorely
> missing in the current documentation. (The usual answer - the
> representation is whatever the owner wants it to be - not very
> satisfying).
>
> As an example we could then say that POSTs to a URI that denotes a
> document are intended to change that document. And we could contrast
> that with POSTs to services, which do all sorts of things, for example
> run queries.
>
> -Alan
>
>
> -Alan
>
>
>  

[Alan Ruttenberg-2]

On Sun, Aug 2, 2009 at 10:46 AM, ashok
malhotra<ashok.malhotra@...> wrote:
> Would weather.com where I type in my zipcode to get local weather be
> classified as a service?

yes

> Clearly Google maps is a service.  Are all interactive sites services?

Mostly, I think. At the border would be, e.g. a site that uses the
user agent string to provide a different experience for reading a book
- perhaps search with a book. However I would still expect an ordinary
GET to retrieve a manifestation of the book in one of the typical
formats for such.

-Alan

>
>
> Alan Ruttenberg wrote:
>>
>> Nice concise history :)
>>
>> On Sat, Aug 1, 2009 at 10:14 PM, Tim Berners-Lee<timbl@...> wrote:
>>
>>>
>>> I would like to see what the documents all look like if edited to use the
>>> words Document and Thing, and eliminate Resource. That's my best bet as
>>> to
>>> two english words which mean as close as we can get to what we want. Note
>>> however that the web is a new system, a design in which new concepts are
>>> created, so we can't expect english words to exist to capture exactly the
>>> concepts. So we take those nearby and abuse them as little as we
>>> can as far as we can tell at the time, and then write them in initial
>>> caps to
>>> recognize that that is what we have done.
>>>
>>
>> If you were to go in that direction, I think you ought to consider
>> adding "Service" as a third category. Thing at the top, with the
>> children document and service disjoint (not a complete partition,
>> obviously).
>>
>> The reason is that services operate very differently than documents,
>> even though they can sometimes return documents. And what we consider
>> to be reasonable representations (web sense) of documents have a very
>> different flavor than the representations returned by services. If
>> this distinction was clear then we might have a much better go at
>> starting to more clearly document expectations on what are reasonable
>> representations to return in each case, something that is sorely
>> missing in the current documentation. (The usual answer - the
>> representation is whatever the owner wants it to be - not very
>> satisfying).
>>
>> As an example we could then say that POSTs to a URI that denotes a
>> document are intended to change that document. And we could contrast
>> that with POSTs to services, which do all sorts of things, for example
>> run queries.
>>
>> -Alan
>>
>>
>> -Alan
>>
>>
>>
>

[Tim Berners-Lee]

On 2009-08 -02, at 07:04, Alan Ruttenberg wrote:

> Nice concise history :)
>
> On Sat, Aug 1, 2009 at 10:14 PM, Tim Berners-Lee<timbl@...> wrote:
>> I would like to see what the documents all look like if edited to  
>> use the
>> words Document and Thing, and eliminate Resource. That's my best  
>> bet as to
>> two english words which mean as close as we can get to what we  
>> want. Note
>> however that the web is a new system, a design in which new  
>> concepts are
>> created, so we can't expect english words to exist to capture  
>> exactly the
>> concepts. So we take those nearby and abuse them as little as we
>> can as far as we can tell at the time, and then write them in  
>> initial caps to
>> recognize that that is what we have done.
>
> If you were to go in that direction, I think you ought to consider
> adding "Service" as a third category. Thing at the top, with the
> children document and service disjoint (not a complete partition,
> obviously).
>
> The reason is that services operate very differently than documents,
> even though they can sometimes return documents. And what we consider
> to be reasonable representations (web sense) of documents have a very
> different flavor than the representations returned by services. If
> this distinction was clear then we might have a much better go at
> starting to more clearly document expectations on what are reasonable
> representations to return in each case, something that is sorely
> missing in the current documentation. (The usual answer - the
> representation is whatever the owner wants it to be - not very
> satisfying).

Yes, I agree adding Service would help relieve some confusion. I  
deliberately avoided it in the short history. There is a use in some  
ways for an ontology which ignores POST services completely, as many  
systems are just buil;t by making webs.

> As an example we could then say that POSTs to a URI that denotes a
> document are intended to change that document. And we could contrast
> that with POSTs to services, which do all sorts of things, for example
> run queries.

In general POSTs to arbitrary things.   The case of POST to a list  
page creating a new page (from the posted content) and creating a  
entry in the list linking to the new content (like net news) I have  
not really seen used.
There is a special case in the read-write data we are playing with in  
which a POST to a document may contact a SPARQL/Update message to make  
an atomic change to the graph.  But in general a service tends to have  
arbitary semantics.  Of course it makes sense to me that if you do a  
GET on the service URI the service should give you some data about  
itself. (Should it us 303?)


>
> -Alan
>
>
> -Alan

[Xiaoshu Wang-3]

Alan Ruttenberg wrote:

> Nice concise history :)
>
> On Sat, Aug 1, 2009 at 10:14 PM, Tim Berners-Lee<timbl@...> wrote:
>  
>> I would like to see what the documents all look like if edited to use the
>> words Document and Thing, and eliminate Resource. That's my best bet as to
>> two english words which mean as close as we can get to what we want. Note
>> however that the web is a new system, a design in which new concepts are
>> created, so we can't expect english words to exist to capture exactly the
>> concepts. So we take those nearby and abuse them as little as we
>> can as far as we can tell at the time, and then write them in initial caps to
>> recognize that that is what we have done.
>>    
>
> If you were to go in that direction, I think you ought to consider
> adding "Service" as a third category. Thing at the top, with the
> children document and service disjoint (not a complete partition,
> obviously).
>  

I doubt how that can be useful.  Service, document, content are all
essentially the same thing when you view it from a communication point
of view.  And the problem is not how an actual definition can be made.

It is not that people don't understand -- in a rough and intuitive way
-- what a document or a service is.  We all do.  The issue is whether
your set contains exactly the same set as mine.  More importantly, what
kind of pragmatic difference does it make by making these kind of
distinction? I heard a lot of blanket statement and I have never seen
one case that is broken by it.

Xiaoshu

> The reason is that services operate very differently than documents,
> even though they can sometimes return documents. And what we consider
> to be reasonable representations (web sense) of documents have a very
> different flavor than the representations returned by services. If
> this distinction was clear then we might have a much better go at
> starting to more clearly document expectations on what are reasonable
> representations to return in each case, something that is sorely
> missing in the current documentation. (The usual answer - the
> representation is whatever the owner wants it to be - not very
> satisfying).
>
> As an example we could then say that POSTs to a URI that denotes a
> document are intended to change that document. And we could contrast
> that with POSTs to services, which do all sorts of things, for example
> run queries.
>
> -Alan
>
>
> -Alan
>  

[Karl Dubost-3]

Le 2 août 2009 à 15:48, Tim Berners-Lee a écrit :
> On 2009-08 -02, at 07:04, Alan Ruttenberg wrote:
>> If you were to go in that direction, I think you ought to consider
>> adding "Service" as a third category. Thing at the top, with the
>> children document and service disjoint (not a complete partition,
>> obviously).
[…]
> Yes, I agree adding Service would help relieve some confusion. I  
> deliberately avoided it in the short history. There is a use in some  
> ways for an ontology which ignores POST services completely, as many  
> systems are just buil;t by making webs.


This gives me the feeling of  the tree hidding the forest. HTTP gives  
a very simple set of words (GET, PUT, POST, DELETE, …) to deal with an  
information space. These words are being abused in many ways. (Julia  
Kristeva, poetic language and intertextuality?)

Basically we are adding a layer of meaning by fragmenting a generic  
meaning: From "Resource" to "Document, Thing and Service". It seems  
like going from abstract to more defined material things. This might  
help momentarily but will just push the limit to the next iteration of  
"abuse", the next layer of fragmentation.



--
Karl Dubost
Montréal, QC, Canada
http://twitter.com/karlpro

[Alan Ruttenberg-2]

On Mon, Aug 3, 2009 at 9:50 PM, Karl Dubost<karl+w3c@...> wrote:

>
> Le 2 août 2009 à 15:48, Tim Berners-Lee a écrit :
>>
>> On 2009-08 -02, at 07:04, Alan Ruttenberg wrote:
>>>
>>> If you were to go in that direction, I think you ought to consider
>>> adding "Service" as a third category. Thing at the top, with the
>>> children document and service disjoint (not a complete partition,
>>> obviously).
>
> […]
>>
>> Yes, I agree adding Service would help relieve some confusion. I
>> deliberately avoided it in the short history. There is a use in some ways
>> for an ontology which ignores POST services completely, as many systems are
>> just buil;t by making webs.
>
>
> This gives me the feeling of  the tree hidding the forest. HTTP gives a very
> simple set of words (GET, PUT, POST, DELETE, …) to deal with an information
> space. These words are being abused in many ways. (Julia Kristeva, poetic
> language and intertextuality?)
>
> Basically we are adding a layer of meaning by fragmenting a generic meaning:
> From "Resource" to "Document, Thing and Service". It seems like going from
> abstract to more defined material things. This might help momentarily but
> will just push the limit to the next iteration of "abuse", the next layer of
> fragmentation.

We call this "categorization". It doesn't fragment, it organizes. With
the organization come benefits: predictability, auditability,
understandability. Whereas we have at the beginning "anything is
possible in all cases" (which we know isn't really true - we recognize
brokenness on the web all the time) with this sort of categorization
we can start to articulate why some things work as expected and other
things don't.

The web verbs you mention each made sense for particular sorts of
things when they were first thought of. As the web has evolved, the
scope of things to which they can (according to specification) applied
has grown, and with this growth there have become too many cases where
they don't make sense. If a HTTP URI can denote a person, then what is
the verb DELETE supposed to do?

There are a number of possible paths, as I see it:

 - Let the verbs be used however anyone wants to and have them lose
any distinct meaning. As an example of the sort of direction this
leads us in is one of the ways AWWSW tried to make sense of
Information Resource, by calling it a "200 responder".  Circular, and
not very informative.
 - Restrict the scope of things HTTP URIs can refer to, paring the
possibilities to those sorts of things conceived of when HTTP was
first created.  I get the sense that some in this forum would have it
that way, but the direction the Semantic Web is going says otherwise.
 - Start introducing some distinctions into the specifications and
therefore letting there be room again for the verbs to retain some
meaning, albeit by perhaps saying that some of them can't be said
about various sort of things, and that they may mean different things
when applied to different sorts of things.

-Alan


>
>
>
> --
> Karl Dubost
> Montréal, QC, Canada
> http://twitter.com/karlpro
>
>

[Karl Dubost-3]

Le 4 août 2009 à 00:57, Alan Ruttenberg a écrit :
> If a HTTP URI can denote a person, then what is
> the verb DELETE supposed to do?

DELETE the URI (of the information space), not the person (of the  
physical space). That is all the difference.
HTTP does *not* define how the information is manipulated by the server.


On Tue, 04 Aug 2009 09:47:49 GMT
In Paper tigers and hidden dragons » Untangled
At http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons

Web architects must understand that resources are
just consistent mappings from an identifier to
some set of views on server-side state. If one
view doesn’t suit your needs, then feel free to
create a different resource that provides a better
view (for any definition of “better”). These views
need not have anything to do with how the
information is stored on the server, or even what
kind of state it ultimately reflects. It just
needs to be understandable (and actionable) by the
recipient.

[Tim Berners-Lee]

On 2009-08 -04, at 00:57, Alan Ruttenberg wrote:

On Mon, Aug 3, 2009 at 9:50 PM, Karl Dubost<karl+w3c@...> wrote:

Le 2 août 2009 à 15:48, Tim Berners-Lee a écrit :

On 2009-08 -02, at 07:04, Alan Ruttenberg wrote:

If you were to go in that direction, I think you ought to consider

adding "Service" as a third category. Thing at the top, with the

children document and service disjoint (not a complete partition,

obviously).

[…]

Yes, I agree adding Service would help relieve some confusion. I

deliberately avoided it in the short history. There is a use in some ways

for an ontology which ignores POST services completely, as many systems are

just buil;t by making webs.

This gives me the feeling of  the tree hidding the forest. HTTP gives a very

simple set of words (GET, PUT, POST, DELETE, …) to deal with an information

space. These words are being abused in many ways. (Julia Kristeva, poetic

language and intertextuality?)

Basically we are adding a layer of meaning by fragmenting a generic meaning:

From "Resource" to "Document, Thing and Service". It seems like going from

abstract to more defined material things. This might help momentarily but

will just push the limit to the next iteration of "abuse", the next layer of

fragmentation.

This isn't fragmentation. I am only talking about "Resource", not about other terms,

and the problem is simply that it has been used differently in different specs and sometimes

ambiguously.

We call this "categorization". It doesn't fragment, it organizes. With
the organization come benefits: predictability, auditability,
understandability. Whereas we have at the beginning "anything is
possible in all cases" (which we know isn't really true - we recognize
brokenness on the web all the time) with this sort of categorization
we can start to articulate why some things work as expected and other
things don't.

Yes.

The web verbs you mention each made sense for particular sorts of
things when they were first thought of. As the web has evolved, the
scope of things to which they can (according to specification) applied
has grown, and with this growth there have become too many cases where
they don't make sense. If a HTTP URI can denote a person, then what is
the verb DELETE supposed to do?

Yes.

There are a number of possible paths, as I see it:

- Let the verbs be used however anyone wants to and have them lose
any distinct meaning. As an example of the sort of direction this
leads us in is one of the ways AWWSW tried to make sense of
Information Resource, by calling it a "200 responder".  Circular, and
not very informative.
- Restrict the scope of things HTTP URIs can refer to, paring the
possibilities to those sorts of things conceived of when HTTP was
first created.  I get the sense that some in this forum would have it
that way, but the direction the Semantic Web is going says otherwise.
- Start introducing some distinctions into the specifications and
therefore letting there be room again for the verbs to retain some
meaning, albeit by perhaps saying that some of them can't be said
about various sort of things, and that they may mean different things
when applied to different sorts of things.

The latter is what I propose, and really the way we went with HTTP-Range14

and 303.  The TAG did it by talking about "Information Resource" as a subclass

of "Resource", but I'm just thinking "document" (and service) as a subclass of "thing"

will make better matches with the existing cognitive associations for typical engineers.

Tim

-Alan

Karl Dubost

[Alan Ruttenberg-2]

On Tue, Aug 4, 2009 at 5:53 AM, Karl Dubost<karl+w3c@...> wrote:
>
> Le 4 août 2009 à 00:57, Alan Ruttenberg a écrit :
>>
>> If a HTTP URI can denote a person, then what is
>> the verb DELETE supposed to do?
>
> DELETE the URI (of the information space), not the person (of the physical
> space). That is all the difference.
> HTTP does *not* define how the information is manipulated by the server.

Hello Karl,

I'm afraid the spec does not agree. Here is what it says:

"The DELETE method requests that the origin server delete the resource
identified by the request-target."

By simple substitution, based on your assertion and the current
httpbis draft, we would conclude that the "resource identified by the
request-target" is the same as "the URI (of the information space)",
i.e. that URIs identify URIs.

> On Tue, 04 Aug 2009 09:47:49 GMT
> In Paper tigers and hidden dragons » Untangled
> At http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons
>
> Web architects must understand that resources are
> just consistent mappings from an identifier to
> some set of views on server-side state. If one
> view doesn’t suit your needs, then feel free to
> create a different resource that provides a better
> view (for any definition of “better”). These views
> need not have anything to do with how the
> information is stored on the server, or even what
> kind of state it ultimately reflects. It just
> needs to be understandable (and actionable) by the
> recipient.

This quote represents yet *another* view of what resources are. With
regard to this I would say two things.

First, it is clearly at odds with the view presented by AWWW ("By
design a URI identifies one resource. We do not limit the scope of
what might be a resource.") and httpRange-14

Second, if this is the theory which one wants to use then it ought to
be fleshed out and documented in the specification. Web architects
aren't going to be able to understand *anything* if the spec is so
ambiguous that it admits too many alternative theories on the one
hand, and speaks inconsistently on the other.

-Alan

[Julian Reschke]

Alan Ruttenberg wrote:
> ...
> "The DELETE method requests that the origin server delete the resource
> identified by the request-target."
> ...

That is a bug in the spec we need to address.

BR, Julian

[Alan Ruttenberg-2]

On Tue, Aug 4, 2009 at 6:24 AM, Tim Berners-Lee<timbl@...> wrote:
>
> On 2009-08 -04, at 00:57, Alan Ruttenberg wrote:

> There are a number of possible paths, as I see it:
>
> - Let the verbs be used however anyone wants to and have them lose
> any distinct meaning. As an example of the sort of direction this
> leads us in is one of the ways AWWSW tried to make sense of
> Information Resource, by calling it a "200 responder".  Circular, and
> not very informative.
> - Restrict the scope of things HTTP URIs can refer to, paring the
> possibilities to those sorts of things conceived of when HTTP was
> first created.  I get the sense that some in this forum would have it
> that way, but the direction the Semantic Web is going says otherwise.
> - Start introducing some distinctions into the specifications and
> therefore letting there be room again for the verbs to retain some
> meaning, albeit by perhaps saying that some of them can't be said
> about various sort of things, and that they may mean different things
> when applied to different sorts of things.
>
>
> The latter is what I propose, and really the way we went with HTTP-Range14
> and 303.  The TAG did it by talking about "Information Resource" as a
> subclass
> of "Resource", but I'm just thinking "document" (and service) as a subclass
> of "thing"
> will make better matches with the existing cognitive associations for
> typical engineers.

Yes, I recognize that. But given the conversation we're having I think
there's a lot more that has to be done. Scanning through the httpbis
draft still finds language plenty of language that is unfortunate, for
example:

    The "http" scheme is used to locate network resources via the HTTP  protocol

(it does more than locate network resources - it is used to get
information about any resources)

    "The action performed by the POST method might not result in a
resource that can be identified by a URI"

(any resource *can* be identified by a URI)

etc.

-Alan

[Julian Reschke]

Alan Ruttenberg wrote:
> ...
> Yes, I recognize that. But given the conversation we're having I think
> there's a lot more that has to be done. Scanning through the httpbis
> draft still finds language plenty of language that is unfortunate, for
> example:
>
>     The "http" scheme is used to locate network resources via the HTTP  protocol
> ...

Again, this is an area that currently is work-in-progress, see
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#http.uri>
for the latest and greatest (not published as an internet draft yet).

> ...

Best regards, Julian

[Xiaoshu Wang-3]

Alan Ruttenberg wrote:

> On Mon, Aug 3, 2009 at 9:50 PM, Karl Dubost<karl+w3c@...> wrote:
>  
>> Le 2 août 2009 à 15:48, Tim Berners-Lee a écrit :
>>    
>>> On 2009-08 -02, at 07:04, Alan Ruttenberg wrote:
>>>      
>>>> If you were to go in that direction, I think you ought to consider
>>>> adding "Service" as a third category. Thing at the top, with the
>>>> children document and service disjoint (not a complete partition,
>>>> obviously).
>>>>        
>> […]
>>    
>>> Yes, I agree adding Service would help relieve some confusion. I
>>> deliberately avoided it in the short history. There is a use in some ways
>>> for an ontology which ignores POST services completely, as many systems are
>>> just buil;t by making webs.
>>>      
>> This gives me the feeling of  the tree hidding the forest. HTTP gives a very
>> simple set of words (GET, PUT, POST, DELETE, …) to deal with an information
>> space. These words are being abused in many ways. (Julia Kristeva, poetic
>> language and intertextuality?)
>>
>> Basically we are adding a layer of meaning by fragmenting a generic meaning:
>> From "Resource" to "Document, Thing and Service". It seems like going from
>> abstract to more defined material things. This might help momentarily but
>> will just push the limit to the next iteration of "abuse", the next layer of
>> fragmentation.
>>    
>
> We call this "categorization". It doesn't fragment, it organizes. With
> the organization come benefits: predictability, auditability,
> understandability. Whereas we have at the beginning "anything is
> possible in all cases" (which we know isn't really true - we recognize
> brokenness on the web all the time) with this sort of categorization
> we can start to articulate why some things work as expected and other
> things don't.
>  

It is true -- that "it organizes".  But the issue is what is suppose to
be organized.  Don't you all feel strange that all your discussions have
never mentioned the word "representation"? GET, POST, DELETE neither
GET/POST/DELETE a URI nor a Resource.  It GET/POST/DELETE a
representation.

Resource/things are not web-specific.  The Web is designed to help us
(humans) organize things.  But the Web should post no constrains on how
each of us should organize our things.  Aligning "document" or
"information resource" with resource, i.e., lies in the heart of all
these troubles. Try the other way, align document with representation,
all things will start to fall in places.

Xiaoshu

> The web verbs you mention each made sense for particular sorts of
> things when they were first thought of. As the web has evolved, the
> scope of things to which they can (according to specification) applied
> has grown, and with this growth there have become too many cases where
> they don't make sense. If a HTTP URI can denote a person, then what is
> the verb DELETE supposed to do?
>
> There are a number of possible paths, as I see it:
>
>  - Let the verbs be used however anyone wants to and have them lose
> any distinct meaning. As an example of the sort of direction this
> leads us in is one of the ways AWWSW tried to make sense of
> Information Resource, by calling it a "200 responder".  Circular, and
> not very informative.
>  - Restrict the scope of things HTTP URIs can refer to, paring the
> possibilities to those sorts of things conceived of when HTTP was
> first created.  I get the sense that some in this forum would have it
> that way, but the direction the Semantic Web is going says otherwise.
>  - Start introducing some distinctions into the specifications and
> therefore letting there be room again for the verbs to retain some
> meaning, albeit by perhaps saying that some of them can't be said
> about various sort of things, and that they may mean different things
> when applied to different sorts of things.
>
> -Alan
>
>
>  
>>
>> --
>> Karl Dubost
>> Montréal, QC, Canada
>> http://twitter.com/karlpro
>>
>>
>>    

[Alan Ruttenberg-2]

On Tue, Aug 4, 2009 at 9:32 AM, Xiaoshu Wang<xiao@...> wrote:

> Alan Ruttenberg wrote:
>>
>> We call this "categorization". It doesn't fragment, it organizes. With
>> the organization come benefits: predictability, auditability,
>> understandability. Whereas we have at the beginning "anything is
>> possible in all cases" (which we know isn't really true - we recognize
>> brokenness on the web all the time) with this sort of categorization
>> we can start to articulate why some things work as expected and other
>> things don't.
>>
>
> It is true -- that "it organizes".  But the issue is what is suppose to be
> organized.  Don't you all feel strange that all your discussions have never
> mentioned the word "representation"?

No. I personally try to avoid using it whenever possible because as
far as words go, it's one of the more inconsistently used. I can't
remember how many senses of "representation" we've gone over in AWWSW
but it's more than one wants.

> GET, POST, DELETE neither
> GET/POST/DELETE a URI nor a Resource.  It GET/POST/DELETE a representation.

Yet *another* interpretation of the verbs. Are people afraid enough yet?

> Resource/things are not web-specific.  The Web is designed to help us
> (humans) organize things.  But the Web should post no constrains on how each
> of us should organize our things.

I don't know what you are talking about. First, we're not talking
about constraining the web, we're talking about ways of communicating.
Second it is the nature of protocols to constrain things so that it's
possible to have coordination. That's why there's only a handful of
verbs and response codes. If any server could respond in any which way
to any request then we wouldn't be able to build browsers.

> Aligning "document" or "information resource" with resource, i.e., lies in the heart of all these troubles. Try
> the other way, align document with representation, all things will start to fall in places.

There's nothing to align to. Representation, in the web spec, is a
term effectively defined as "200 responder". It is whatever a server
chooses to return. And we're having a little problem pinning down
"Document", as well. So I don't see how to move forward with your
suggestion.

-Alan

[Xiaoshu Wang-3]

Alan Ruttenberg wrote:

> On Tue, Aug 4, 2009 at 9:32 AM, Xiaoshu Wang<xiao@...> wrote:
>  
>> Alan Ruttenberg wrote:
>>    
>>> We call this "categorization". It doesn't fragment, it organizes. With
>>> the organization come benefits: predictability, auditability,
>>> understandability. Whereas we have at the beginning "anything is
>>> possible in all cases" (which we know isn't really true - we recognize
>>> brokenness on the web all the time) with this sort of categorization
>>> we can start to articulate why some things work as expected and other
>>> things don't.
>>>
>>>      
>> It is true -- that "it organizes".  But the issue is what is suppose to be
>> organized.  Don't you all feel strange that all your discussions have never
>> mentioned the word "representation"?
>>    
>
> No. I personally try to avoid using it whenever possible because as
> far as words go, it's one of the more inconsistently used. I can't
> remember how many senses of "representation" we've gone over in AWWSW
> but it's more than one wants.
>  

This is where AWWW fails.  Sure, like "resource", the word
"representation" has various kind of senses.  But within the Web, the
concept of "representation" should be quite clear.  It is what we (both
human and machines) work with.  We never work with "resources" in the
Web.  We work with representations.  What GET/POST/DELETE, etc., must
work through it as well.  It is as simple as that.  I said before, to
think otherwise is to hallucinate.

To ignore representation is what fails the AWWW.  I am extremely baffled
by the insistence of aligning our technical term with how the word is
used in other context.  It can never be done.  Of course, choosing a
closely related word may help describing the concept but let us be clear
about the difference between a *description* with a *definition*.

A definition aims at usage.  A description aims at comprehension.

If the word "resource" is used in the Web to mean all things that URI
can denote.  It is how it is used.  Who gives a damn if the word
"resource" is used in some senses in some other context.  We are using
the word "resource" in the context of the Web.  We might as well name it
with "xyz", what kind of difference does it make in terms of the usage?

It is the same with the word "representation".  AWWW has never bothered
to define it.  But  it should.  We know, in fact very clearly, that in
the Web a "representation" is carried by a byte-stream.   We know, also
as a matter of fact, that a "representation" has a structure -- think
the HTTP message.  We also know, in fact very pragmatically, that a
"representation" carries a "document", again a structure that is parsed
from a "representation" and displayed by a browser or handled by some
other agents.  This is what can be clearly and objectively defined.  To
categorize it on the "resource" side will inevitably forces one personal
metaphysical viewpoint onto others.  It is dangerous to do the latter
because then the Web issue is no longer an engineer issue but a
political and a religious one.  Don't do that.

>> GET, POST, DELETE neither
>> GET/POST/DELETE a URI nor a Resource.  It GET/POST/DELETE a representation.
>>    
>
> Yet *another* interpretation of the verbs. Are people afraid enough yet?
>  
It is the only interpretation that makes pragmatic sense.  It also fits
the reality and is also productive.  As  I  said before, there is a
context  -- the URI owner -- for all web communications.  And that
context stops any kind of useless argument.

>> Resource/things are not web-specific.  The Web is designed to help us
>> (humans) organize things.  But the Web should post no constrains on how each
>> of us should organize our things.
>>    
>
> I don't know what you are talking about. First, we're not talking
> about constraining the web, we're talking about ways of communicating.
> Second it is the nature of protocols to constrain things so that it's
> possible to have coordination. That's why there's only a handful of
> verbs and response codes. If any server could respond in any which way
> to any request then we wouldn't be able to build browsers.
>  

Yes, "representation" is the *web* ways of communication. It is our
tools and try to focus on define how to organize that but not organizing
resource.  That latter is our purpose.  

>> Aligning "document" or "information resource" with resource, i.e., lies in the heart of all these troubles. Try
>> the other way, align document with representation, all things will start to fall in places.
>>    
>
> There's nothing to align to. Representation, in the web spec, is a
> term effectively defined as "200 responder". It is whatever a server
> chooses to return. And we're having a little problem pinning down
> "Document", as well. So I don't see how to move forward with your
> suggestion.
>  

See above.  In the worse case, i.e., if there is nothing to align to,
then just forget the word -- "document" or "information resource".  Will
the web hurt by that? I haven't seen any -- not even a valid
hypothetical example.

Xiaoshu