Re: Issue-57

As far as I can tell, there is only one issue. The definition of IR and the treatment of it. All other issues come back to it.

I concur with Tim that this isn't the issue at all. Moreover I have stated and I firmly believe that virtually anyone can easily understand the distinction between information and that which the information is about. That doesn't mean they *like* the means of advertising the distinction, or see the *need*.

"Information" is another ambiguous word. If it is as easy as you described, a lot of philosophers would have lost their jobs.

The "easy" part is that it is easy for people to understand that the "thing" that they retrieved from a URI is not necessarily the thing that URI references. (If you take the former as information and the latter about, then it is not difficult) Hence, the wording by Tim in his previous response is a significant improvement over the 'official resolution' because the URI would identify something a client would 'see', I.e., a web page parsed by their browser.


This is why the "resolution" that you referred is seriously wrong. It forces me, along with many others, to honor some metaphysical categorization that no one in the world can objectively define.

The important part of the resolution is: "they may mint "http" URIs for any resource". This says that http URLs can refer to anything.

A URI, -- be it ftp, http, or file, -- is a symbol. And a symbol can be used to mean anything. What a symbol means depends on how it is used in a community. This is the theory of "Meaning is use" by Wittgenstein.  TAG's intent to promote using URI (esp. HTTP-URL) to name everything is a good thing but its httpRange-14 is a bad one. Web/Semantic Web can move on without httpRange-14. A lot of ontologies Foaf gets popular without worrying about 303.


What is it suppose to accomplish then? I think it has been around five years since the httpRange-14? Can TAG shows us how many has followed httpRange-14 and what, if any, have we gained from that?

Since then http URIs have been used in, important uses case, to refer to anything. This is an advance because it documents that one need not invent new schemes to refer to, e.g., cars, and hence reduces the complexity of implementation of systems that need to refer to entities other than web pages. Because of this, for instance, LSID's reason to exist has essentially been removed and it has fallen out of use, which is good, and there are more applications that are comfortably deployed to the web.


Casting the issue as a matter of accepting diversity is as appropriate here as it would be in a discussion of the format of TCP headers. If there isn't agreement about which bytes specify the source port versus destination port the damned thing won't work and the same thing is true here.

No, it is not the same as the format issue. Promoting XML, for instance, does not prevent the development and the thriving of other formats, such as YAML/JSON etc. The httpRange-14 is an entirely different beast. As I have argued a long time ago, httpRange-14 forces me to answer a metaphysical question that I cannot answer before I can put a thing on the web.

It does not. It provides you a means to escape *any* implication about what the nature of a resource is, namely by following the 303 protocol. It opens the web up to *more* than was previously able to be put "on the web". Read carefully. If there is any burden it is in interpreting what URIs that are 200 responders refer to, but this doesn't interfere with *you* putting anything on the web without preconception.

I try to avoid coming back to the same problem or argument. Hence, in the earlier passage, I didn't pursue the catch of referring to what you get back. If a URI is used to refer to what a client get, then a URI will be used to refer not one but many things because, physically, what you get from http://www.w3c.org is not the same as the one I get. This is why (I guess) Tim has worded it in such: " then the response contains the content of the document identified by that URI;" If you try to come up a definition of the content and document, I guess that you will go back to something like information resource.

So, let's try not. Unless someone can come up a definition as easily understandable as 1+1=2, let's not to say or imply that it is easy.

What I would like to suggest is let's start the web architecture that would tolerate everyone. Let's make 200 code as it was before. That is: a 200 code says nothing except that a request has been successfully responded.

If TAG thinks that it is critical to make the distinction with regard to the nature of what the URI is used for, then invent some extra 2xx code as Tim suggested. For example, 209 = Information Resource (or Content of Document). 210 for non-information resource (or non content of a document).

Wouldn't this be a better way to serve the world?

Xiaoshu Wang