 |
 |
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 others'). 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 protocol". 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. --Ray ----- 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.