[Dspace-general] The collective wisdom on handles?

[Robert Tansley]

Hi Stephen,

One of the reasons for the initial choice of Handles in DSpace is
precisely because it's independent of DSpace, and would enable folks
to move or replicate content into other systems.  It even lets you
track content replicated in multiple systems with the same identifier,
as the China Digital Museum project is exploring:
http://www.dlib.org/dlib/july06/tansley/07tansley.html

Since Handles give you a level of indirection, it's much easier to
keep the Handles pointing at the right content, whichever system your
content is stored in.  Otherwise, you'd have to make e.g. Digital
Commons 'understand' the DSpace URL space, and you'd have to keep the
host name the same.

But of course Handles (as well as the underlying content) don't
preserve themselves, and if you do migrate to another platform, it
will be up to you to make sure the Handles still work, it doesn't
happen by magic.  However the Handle infrastructure is designed to
make this as easy as possible (certainly easier than trying to
maintain a URL space with a particular domain name etc).  Plus, you
wouldn't even need the new system to support the Handle system
natively (although plenty, including FEDORA with a 3rd party add-on,
do) -- you could just run a Handle server that redirects Handle
resolutions to the appropriate page or service in your new system.

In terms of alternatives, lots of folks simply don't run a Handle
Service, and just:
- Configure 'handle.prefix' to be something like 'id'
- Fix appropriate points in the code so that the IDs appear as the URL
for the item display page, instead of http://hdl.handle.net/....

This basically means that the URLs for the item display pages *are*
the IDs for the objects.  To use another ID scheme with a separate
resolution mechanism would need some development work.  I hope some
pluggable API will make this easier to do in the future.

In terms of an exit strategy from Handles, that would be tricky.
Handles are displayed in the http://hdl.handle.net/... form because
that works in browsers, and we feared if the Handles didn't work in
browsers people just wouldn't use them.  That may or may not have been
a wise decision.  The hdl:12.34/56 form is probably more 'portable'
but people will still expect them to behave like Handles.

So at the end of the day, of all the choices you make in setting up a
long-term digital repository, identifiers is the one choice you're
pretty much stuck with ad infinitum.

However, the fact is that back in 2001/2002 as well as now, Handles
are a proven, supported, scalable standard for portable identifiers
(the fact that DOI is based on the Handle system has always given us a
degree of confidence) and alternatives with the same level of
functionality are thin on the ground, so they're as good a choice as
any IMO.

Plenty of notes on: http://wiki.dspace.org/PersistentIdentifiers

Rob

On 24/08/06, Stephen Thomas <stephen.thomas at adelaide.edu.au> wrote:
> One thing that is niggling away at the back of mind is the question of
> handles -- whether we should be using them at this stage.
>
> We've just launched our DSpace here, and its going well so far, and even
> limited promo is eliciting a lot of enthusiasm. Among its virtues, we're
> touting the use of handles for permanent links. But ... I can't help
> wondering if this is wise, or indeed honest. Because what I tell people
> is that the handles mean the links will always work, even if we migrate
> to a different platform, but in fact I don't really know how true this
> is.
>
> If we move to new hardware while retaining DSpace, I guess there's no
> problem. But ... and I'm not suggesting we will, but who knows what the
> future may bring ... if we migrate from DSpace to something else ...
> ARROW, Digital commons, whatever ... will we still be able to use our
> handles? Or will the reliability of our handle links be predicated on
> sticking with DSpace?
>
> So I'm wondering what others are doing in this respect. I note that many
> DSpace installations don't use handle.net, but some do. So I'd like to
> hear from others as to what their feelings are on this issue, whether
> they share my concerns, and whether they use handle.net or not, and why.
>
>
> Regards,
> Steve