> 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
> 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
> it's all about using the *protocol* in service of identifying. Why use
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
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
GET / HTTP/1.1
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.