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