Use cases for Handle identifiers?
Reading Adam Smith's D-Lib article has got me thinking about identifiers again. I don't agree with some of the assertions in the section titled "A Persistent Identifier Primer" — URIs are in fact persistent; we just break them through poor management — and so I'm led to a fundamental question: what are the good use cases for Handle (or ARK, or PURL) identifiers?
I get the need for persistent and globally unique identifiers; I'm just wondering why one needs special software with a separate URI namespace to gain persistence.
One potential use case might be resources that are outside of the organization's control — i.e., licensed content from vendors — but surely folks are using Handles for many resources that are created and managed within the organization. And I'm curious why they have decided that Handles are more durable than native URIs (the URIs to which Handles redirect), and how they deal with the problem of downstream (post-redirection) citation and bookmarking. How useful is this sort of identifier scheme if your users never even see the supposedly more persistent URI for a resource?
As a former proponent of Handles and ARKs, this may seem like a hypocritical question to pose. If I had to answer my own question, I would say that Handles seem like a good option because they save you some work and headaches in the short-term; you don't need to get together with your web team and come up with a scalable and sustainable URI policy; just assign native URIs in the usual haphazard way and generate Handles to compensate for a lack of identifier policies.
But if you're already making an organizational commitment to identifier persistence — and if you're rolling out Handles, I'd wager that's likely — why not do so by minting carefully-considered cool URIs? Less management and technology overhead and less confusion for your users are two good reasons to consider it.
Trackbacks
Use this link to trackback from your own site.
Our organization runs multiple digital content / digital library publishing platforms, all with different URI schemes. In this case, the *resources* may be within our control, but the minting of URIs is not easy to get a handle on.
It seems we are either faced with a) modifying the software to match a developed URI policy (ugh and/or not possible); b) running a translation scheme at the sever level (e.g. Apache mod_rewrite) (semi-ugh); or c) running some kind of resolver service, whether it be Handles or something else. In that accounting, Handles seem pretty reasonable to me — what do you think?
Aaron,
Good point. Even local resources may be bound to URI schemes not of our choosing. The ideal solution would be if the software were configurable such that URIs could be crafted per organization policy. But I don't see that happening anytime soon.
I'm not sure how much better option c is than option b since you're already running Apache (probably). Both are susceptible to the downstream citation problem which to my mind is a major knock on the persistence of an identifier. Apache + mod_proxy might be a better solution in terms of the problem, but I haven't wrapped my mind fully around the amount of management overhead that would be required in this scheme.
Thanks for jogging my memory. And I do think Handles are a reasonable way to deal with the situation — assuming the downstream citation problem is not an overriding issue.