[Dspace-general] The collective wisdom on handles?

[Stephen Thomas]

Thanks Robert. That gives me courage to continue with handles.

I guess I'd just reached that point of the project where one thinks,
"OMG, am I doing the right thing here?"


Thanks again,
Steve


Stephen Thomas, 
Senior Systems Analyst, 
University of Adelaide Library
UNIVERSITY OF ADELAIDE SA 5005
AUSTRALIA
Phone: +61 8 830 35190  Fax: +61 8 830 34369
Email: stephen.thomas at adelaide.edu.au 
URL: http://www.adelaide.edu.au/directory/stephen.thomas
 
CRICOS Provider Number 00123M
----------------------------------------------------------- 
This email message is intended only for the addressee(s) and contains
information that may be confidential and/or copyright.  If you are not
the intended recipient please notify the sender by reply email and
immediately delete this email. Use, disclosure or reproduction of this
email by anyone other than the intended recipient(s) is strictly
prohibited. No representation is made that this email or any attachments
are free of viruses. Virus scanning is recommended and is the
responsibility of the recipient.

 
> -----Original Message-----
> From: Robert Tansley [mailto:roberttansley at google.com]
> Sent: Friday, 25 August 2006 12:34 am
> To: Stephen Thomas
> Cc: dspace-general at mit.edu
> Subject: Re: [Dspace-general] The collective wisdom on handles?
> 
> 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