 |
 |
It's interesting that there are at least three, if not four, viewpoints being represented in this conversation. The first argument is over whether all identifiers should be resolvable or not. While I respect the argument that it's _useful_ to have resolvable (to something) identifiers , I think it's an unneccesary limitation to say that all identifiers _must_ be resolvable. There are cases where it is infeasible on a business level to support resolvability. It may be for as simple a reason as that the body who actually maintains the identifiers is not interested in providing such at present. You can argue that they _ought_ to be, but back in the real world, should that stand as a barrier to anyone else using URI identifiers based on that particular identifier system? Wouldn't it be better if it didn't have to be? [ Another obvious example is the SICI -- an identifier for a particular article in a serial. Making these all resolvable in a useful way is a VERY non-trivial exersize. It is not at all easy, and a solution is definitely not cheap (DOI is an attempted solution; which some publishers choose not to pay for; both the DOI fees and the cost of building out their own infrastructure to support it). Why should we be prevented from using identifiers for a particular article in a serial until this difficult and expensive problem is solved?] So I don't buy that all identifiers must always be resolvable, and that if we can't make an identifier resolvable we can't use it. That excludes too much useful stuff. The next argument is, okay, so many all identifiers don't have to be resolvable, but even if it's not resolvable you can still use an http uri for it, just one that doesn't actually resolve. Formally, this is certainly correct. There's no formal requirement that an http URI go anywhere, that there even be an HTTP server responding at the hostname mentioned _at all_. So you _could_ use an http uri like that. But it gets confusing quickly, in part because the first argument referenced is still going on, and some people assume that any http URI _ought_ to be resolvable (to _something_; to _what_ is another argument). Using a non-http uri is a way to avoid confusion over your intentions, stating that you acknolwedged from the start that it was infeasible at the present time to provide http resolution for these identifiers. Jonathan Houghton,Andrew wrote: >> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of >> Jonathan Rochkind >> Sent: Monday, March 30, 2009 12:16 PM >> To: [log in to unmask] >> Subject: Re: [CODE4LIB] registering info: uris? >> >> 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 >> > > Unfortunately, Stu is an author of the info URI specification and the > he makes the same arguments that they made for the justification of > the info URI RFC which has been debunked by the W3C: > > <http://www.w3.org/2001/tag/doc/URNsAndRegistries-50> > > Having unresolvable URIs is anti-Web since the Web is a hypertext > system where links are required to make it useful. Exposing > unresolvable links in content on the Web doesn't make the Web > more useful. > > > Andy. > >