Meanwhile, there are others who are arguing just as strongly that
identifiers should _always_ be resolvable.
Seriously, this debate has been going on in a while in other forums, we
aren't the first to have it. I can see both sides, neither seems
obviously right to me. Which I guess suggests that we need room for
both resolvable identifiers and non-resolvable identifiers. (And then
people will start arguing on whether http uri's provide all the room we
need for non-resolvable ones or not. That argument has been had before
too, and I see both sides there too!)
Some hints of the existing argument in other forums can be found in this
post by Stu Weibel, and the other posts it links to.
http://weibel-lines.typepad.com/weibelines/2006/08/uncoupling_iden.html
Jonathan
Houghton,Andrew wrote:
From: Code for Libraries [mailto:[email protected]] On Behalf Of
Mike Taylor
Sent: Monday, March 30, 2009 11:30 AM
To: [email protected]
Subject: Re: [CODE4LIB] registering info: uris?
Ross Singer writes:
> There should be no issue with having both, mainly because like I
> mentioned earlier, nobody cares about info:uris.
>
> Take, for instance, DOIs. What do you see in the wild? Do you ever
> see info:uris (except in OpenURLs)? If you don't see
> http://dx.doi.org/ URIs you generally see doi:10... URIs. It seems
> like having http and info URIs would *have* to be fine, since
> info:uris *not being dereferenceable* are far less useful (I won't
go
> so far as 'useless') on the web, which is where all this is
happening.
What on earth does dereferencing have to do with this?
We're talking about an identifier.
Exactly, that is what people don't understand about RFC 3986. URIs are
just identifiers and have nothing to do with dereferencing. Dereferencing
only comes into play when the URI is used with an actual protocol like
HTTP. The only thing the http:, e.g., URI scheme, starting the URI tells
you is what the syntax of the rest of the URI looks like. This is where
the authors of info URIs missed the boat. They conflated the URI scheme,
e.g., http:, with dereferencing and used it as a justification for a new
URI scheme. The authors were told of that misconception before info
became an RFC by both the IETF and W3C, but they decided to proceed
anyway creating another library specific standard that no one else will
use.
If people would just follow the prescribed practice by the W3C:
<http://www.w3.org/TR/webarch/>
Architecture of the Web says:
2.3.1. URI aliases
Best practice: "A URI owner SHOULD NOT associate arbitrarily different URIs with the
same resource."
2.4. URI Schemes
Best practice: "A specification SHOULD reuse an existing URI scheme (rather than
create a new one) when it provides the desired properties of identifiers and their
relation to resources."
Quote: "While Web architecture allows the definition of new schemes, introducing a
new scheme is costly. Many aspects of URI processing are scheme-dependent, and a large
amount of deployed software already processes URIs of well-known schemes. Introducing a
new URI scheme requires the development and deployment not only of client software to
handle the scheme, but also of ancillary agents such as gateways, proxies, and caches.
See [RFC2718] for other considerations and costs related to URI scheme design."
<http://www.w3.org/2001/tag/doc/URNsAndRegistries-50>
This tag finding pretty much debunks all the reasons given by the info URI authors for creating a new URI scheme. I think Erik Hetzner also referenced it in his posts.
Andy.
