Lighton,
These are all very strong points as well. I was being more specific to the
resolving technology for handles and DOI being the same foundation made by
CNRI. The points about DOI continuing to evolve more accurately reflect the
services for registration and management that are being layered on top of
the platform by the DOI stakeholders. Ultimately your choice of technology
is dependent on ease of use and tractability. The trade offs with DOI
integration for DSpace just not getting into the next release will force
you to wiegh that which is currently achievable against that which will be
ideal once Identifier Services are released into DSpace.
Best,
Mark
On Sunday, July 15, 2012, Ryan Scherle wrote:
> Lighton,
>
> Here are a few more things to consider. First a few brief words about
> cost, and then my technology rant....
>
> == About Cost ==
>
> Yes, DOIs cost more than handles. The actual cost structure depends on
> which RA you choose, so it's hard to say how much it will cost you, but
> DOIs will definitely cost more. See EZID fees at
> http://n2t.net/ezid/home/pricing and CrossRef fees at
> http://www.crossref.org/02publishers/20pub_fees.html
>
> Mark mentioned several benefits that you receive for the cost of DOIs -- I
> agree with all of those. Essentially, DOIs and the metadata associated with
> the DOIs are visible/usable by a broader audience than Handles. There are
> many external services that read data from the DOI system. There are many
> tools that know how to use DOIs. New tools created in the future are likely
> to support DOIs. They are somewhat less likely to support Handles.
>
> Personally, I think you should consider the "cost" of starting out with
> Handles and then later switching to DOIs. Or vice versa. Once your
> identifiers are publicly available, you'll need to support them forever. It
> is better if you make the right decision up front. Otherwise, you may end
> up supporting both systems.
>
> == About Technology ==
>
> Here, I completely disagree with Mark. Yes, DOIs *are* technically
> superior to Handles. Although the core technologies were the same, the DOI
> system has evolved and is still getting better, while the Handle system has
> stayed nearly the same for many years. A few issues to consider:
>
> 1) In my experience, new users of DSpace always require a full day to
> register an Handle prefix and properly configure a Handle server -- hardly
> "out of the box". The process for registering a Handle server involves
> generating a binary file and sending this binary file to a human, who will
> then decode the binary file and configure the central Handle system. Why
> can't the DSpace administrator do this configuration directly with an
> online tool? Simply because the Handle system hasn't been updated in a very
> long time. Contrast this with DOIs: Assuming the DSpace code supports your
> RA, the only setup required will be editing a few fields in a configuration
> file.
>
> 2) The Handle system requires you to run a "Handle server" on your DSpace
> machine. The Handle server is a separate process, which is one more piece
> of technology to manage. It requires the sysadmin to open a separate port
> to the outside world. It requires maintenance like any other process:
> ensuring the process starts correctly when a machine is rebooted,
> monitoring the process to ensure it is working correctly, managing log
> files, etc. Although all of these are small issues, they add just a little
> more to the hidden cost of running the system. DOIs don't require an extra
> process running on your server; they can use the existing DSpace processes.
>
> 3) The Handle system only recognizes machines by IP address, not by DNS
> name. Our production server moved a few weeks ago, and a change of IP
> address was required. The DOIs continued to work correctly, because they
> followed the DNS name to the new machine. The Handles "broke", because I
> forgot to send the new IP address to CNRI. And due to the poor
> implementation discussed above, even though I "know" what I'm doing and I
> have good documentation, fixing this problem took about 2 hours.
>
> Some of these problems are documented by CNRI:
> http://www.handle.net/support.html
>
> I think many people in the DSpace community have come to accept the pain
> of the Handle technology as part of the "cost" of running a repository,
> which is sad.
>
> --- Ryan Scherle
> --- Data Repository Architect
> --- Dryad Digital Repository
>
> On Jul 15, 2012, at 8:32 PM, Mark Diggory wrote:
>
> Lighton,
>
> We are working on a contribution to DSpace 3.0 that includes functionality
> to assign external identifiers such as DOI in DSpace. This is based on
> work at @mire did with NESCent on Dryad, but also on some funded
> contribution work that is also happening this summer with WHOI to improve
> the contribution. Our current situation with DOI integration is that you
> will need to be registered with an RA. For Dryad, that provider was
> originally Datacite, but now is EZID. The API used in this situation is
> novel and unstandardized, each situation we've encountered required custom
> coding in DSpace, thus what is being contributed is specifically designed
> to support customizable ID providers on the backend.
>
> You will find that the Handle RA is significantly more cost effective than
> any of the existing DOI RA, this is one of the original intents of using
> the Handle platform for repositories, where costs are a significant
> concern. What you are getting with those additional DOI costs are
> additional services being matketed by those various RA providers, 1.
> someone else's guarantee for the resolution records in a centralized
> registry rather than their resolution being dependent on internal calls
> back to your DSpace server, 2. Metadata/citation registration, linked data
> exposure, 3. Automatic indexing of your items into aggregated catologs, and
> so on. Unless you have a really critical need to integrate based on
> policies or decisions that were made in your organization, I would wiegh
> the overall cost benefits before getting yourselves vested in having to
> maintain DOI on your repository items. Consider that Handles are not only
> the more cost effective route, they are supported "out of the box" on your
> current DSpace release.
>
> So there are important management questions independent of implementing
> DOI that you will need to answer first. We don't necessarily perceive DOI
> as being technically any better than Handles or other identifier systems at
> this moment, just much more marketed by SaaS providers. Thus our intent
> for future DSpace PID support is that it be extensible and plural in
> nature. I would start with Handles given the low cost of entry, then
> consider adding DOI after a longer "needs analysis" on what benefits DOI
> will bring to your repository.
>
> Mark
>
>
>
> On Sunday, July 15, 2012, Lighton Phiri wrote:
>
> We are at a stage where we would like to integrate a DSpace instance
> with persistent identifiers and would want to make use of DOIs. I
> would like to find out if there is anyone who has had luck doing this,
> just so we know if going the Handle System route may be the only
> viable option.
>
> I should mention here that other than this relatively old forum post
> [1], I haven't found anything comprehensive on the wiki pages or
> online.
>
> [1] https://sourceforge.net/mailarchive/message.php?msg_id=28698555
>
> Lighton Phiri
> http://lightonphiri.org
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> DSpace-tech mailing list
> DSpace-tech@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>
>
>
> --
> [image: @mire Inc.]
> *Mark Diggory *(Schedule a Meeting <https://tungle.me/markdiggory>
>
>
--
[image: @mire Inc.]
*Mark Diggory *(Schedule a Meeting <https://tungle.me/markdiggory>)
*2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
*Esperantolaan 4, Heverlee 3001, Belgium*
http://www.atmire.com
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
