An account that has a depressing ring of accuracy to it.
Ray Denenberg, Library of Congress writes:
> You're right, if there were a "web:" URI scheme, the world would be a
> better place. But it's not, and the world is worse off for it.
> It shouldn't surprise anyone that I am sympathetic to Karen's criticisms.
> Here is some of my historical perspective (which may well differ from
> Back in the old days, URIs (or URLs) were protocol based. The ftp scheme
> was for retrieving documents via ftp. The telnet scheme was for telnet. And
> so on. Some of you may remember the ZIG (Z39.50 Implementors Group) back
> when we developed the z39.50 URI scheme, which was around 1995. Most of us
> were not wise to the ways of the web that long ago, but we were told, by
> those who were, that "z39.50r:" and "z39.50s:" at the beginning of a URL
> are explicit indications that the URI is to be resolved by Z39.50.
> A few years later the semantic web was conceived and alot of SW people began
> coining all manner of http URIs that had nothing to do with the http
> protocol. By the time the rest of the world noticed, there were so many
> that it was too late to turn back. So instead, history was altered. The
> company line became "we never told you that the URI scheme was tied to a
> Instead, they should have bit the bullet and coined a new scheme. They
> didn't, and that's why we're in the mess we're in.
> ----- Original Message -----
> From: "Houghton,Andrew" <[log in to unmask]>
> To: <[log in to unmask]>
> Sent: Thursday, April 02, 2009 9:41 AM
> Subject: Re: [CODE4LIB] resolution and identification (was Re: [CODE4LIB]
> registering info: uris?)
> >> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
> >> Karen Coyle
> >> Sent: Wednesday, April 01, 2009 2:26 PM
> >> To: [log in to unmask]
> >> Subject: Re: [CODE4LIB] resolution and identification (was Re:
> >> [CODE4LIB] registering info: uris?)
> >> This really puzzles me, because I thought http referred to a protocol:
> >> hypertext transfer protocol. And when you put "http://" in front of
> >> something you are indicating that you are sending the following string
> >> along to be processed by that protocol. It implies a certain
> >> application
> >> over the web, just as "mailto:" implies a particular application. Yes,
> >> "http" is the URI for the hypertext transfer protocol. That doesn't
> >> negate the fact that it indicates a protocol.
> > RFC 3986 (URI generic syntax) says that "http:" is a URI scheme not a
> > protocol. Just because it says "http" people make all kinds of
> > assumptions about type of use, persistence, resolvability, etc. As I
> > indicated in a prior message, whoever registered the http URI scheme
> > could have easily used the token "web:" instead of "http:". All the
> > URI scheme in RFC 3986 does is indicate what the syntax of the rest
> > of the URI will look like. That's all. You give an excellent
> > example: mailto. The mailto URI scheme does not imply a particular
> > application. It is a URI scheme with a specific syntax. That URI
> > is often resolved with the SMTP (mail) protocol. Whoever registered
> > the mailto URI scheme could have specified the token as "smtp:"
> > instead of "mailto:".
> >> My reading of Cool URIs is
> >> that they use the protocol, not just the URI. If they weren't intended
> >> to take advantage of http then W3C would have used something else as a
> >> URI. Read through the Cool URIs document and it's not about
> >> identifiers,
> >> it's all about using the *protocol* in service of identifying. Why use
> >> http?
> > I'm assuming here when you say "My reading of Cool URIs..." means reading
> > the "Cool URIs for the Semantic Web" document and not the "Cool URIs Don't
> > Change" document. The "Cool URIs for the Semantic Web" document is about
> > linked data. Tim Burners-Lee's four linked data priciples state:
> > 1. Use URIs as names for things.
> > 2. Use HTTP URIs so that people can look up those names.
> > 3. When someone looks up a URI, provide useful information.
> > 4. Include links to other URIs. so that they can discover more things.
> > (2) is an important aspect to linking. The Web is a hypertext based
> > system
> > that uses HTTP URIs to identify resources. If you want to link, then you
> > need to use HTTP URIs. There is only one protocol, today, that accepts
> > HTTP URIs as "currency" and its appropriately called HTTP and defined by
> > RFC 2616.
> > The "Cool URIs for the Semantic Web" document describes how an HTTP
> > protocol
> > implementation (of RFC 2616) should respond to a dereference of an HTTP
> > URI.
> > Its important to understand the URIs are just tokens that *can* be
> > presented
> > to a protocol for resolution. Its up to the protocol to define the
> > "currency"
> > that it will accept, e.g., HTTP URIs, and its up to an implementation of
> > the
> > protocol to define the "tokens" of that "currency" that it will accept.
> > It just so happens that HTTP URIs are accepted by the HTTP protocol, but
> > in
> > the case of mailto URIs they are accepted by the SMTP protocol. However,
> > it is important to note that a HTTP user agent, e.g., a browser, accepts
> > both HTTP and mailto URIs. It decides that it should send the mailto URI
> > to an SMTP user agent, e.g., Outlook, Thunderbird, etc. or it should
> > dereference the HTTP URI with the HTTP protocol. In fact the HTTP
> > protocol
> > doesn't directly accept HTTP URIs. As part of the dereference process the
> > HTTP user agent needs to break apart the HTTP URI and present it to the
> > HTTP
> > protocol. For example the HTTP URI: http://example.org/ becomes the HTTP
> > protocol request:
> > GET / HTTP/1.1
> > Host: example.org
> > Think of a URI as a minted token. The New York subway mints tokens to
> > ride
> > the subway to get to a destination. Placing a U.S. quarter or a Boston
> > subway token in a turn style will not allow you to pass. You must use the
> > New York subway minted token, e.g., "currency". URIs are the same. OCLC
> > can mint HTTP URI tokens and LC can mint HTTP URI tokens, both are using
> > the HTTP URI "currency", but sending LC HTTP URI tokens, e.g., Boston
> > subway
> > tokens, to OCLC's Web server will most likely result in a 404, you cannot
> > pass since OCLC's Web server only accepts OCLC tokens, e.g., New York
> > subway
> > tokens, that identify a resource under its control.
> > Andy.