 |
 |
Well, the thing is, those sem web folks LIKE what has resulted. They think it's _good_ that http:// can be resolved with a certain protocol in some cases, but can be an arbitrary identifier untied to protocol in others. It definitely is convenient in some cases. I have mixed feelings, I don't think it's a disaster, but I'm not sure it's always a good idea. Jonathan ________________________________________ From: Code for Libraries [[log in to unmask]] On Behalf Of Mike Taylor [[log in to unmask]] Sent: Thursday, April 02, 2009 2:33 PM To: [log in to unmask] Subject: Re: [CODE4LIB] resolution and identification (was Re: [CODE4LIB] registering info: uris?) 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 > 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.