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:[log in to unmask]] On Behalf Of
>> Mike Taylor
>> Sent: Monday, March 30, 2009 11:30 AM
>> To: [log in to unmask]
>> 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.
>
>