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