Dear Peter,
I will briefly describe our setup which is "non traditional".
We have two communities at our repository:
- one community uses "external" handle server;
- the other uses the "bundled" handle server.
Another requirement is that we must be able to modify (even create)
specific handles using (xmlui) UI in the bundled handle server.
External handle server is hosted at http://www.pidconsortium.eu/ accessible
through specific REST API.
Our implementation uses the following configuration
# per community pid configurations for pid prefixes of the format:
# community=<community ID>,prefix=<prefix>,alternative_prefixes=<pipeline
separated list of alternative
prefixes>,type=<local|epic>,canonical_prefix=<URL of handle>,subpre
fix=<subprefix>
# multiple configurations can be given separated by semicolon
# default configuration should have asterisk as the community ID
# subprefix is only used for local handles
lr.pid.community.configurations =
community=12,prefix=11372,type=epic,canonical_prefix=
http://hdl.handle.net/,subprefix=LRT;community=*,prefix=11234,type=local,canonical_p
refix=http://hdl.handle.net/,subprefix=1
Our updated version of HandleManager.java
https://github.com/ufal/lindat-repository/blob/1a60d54197439496c4a9a333aa9af0baf68ee191/sources/dspace-api/src/main/java/org/dspace/handle/HandleManager.java
reads the configuration, based on the type either formats (using subprefix
e.g., PREFIX/SUBPREFIX-NUMBER) a local handle or registers an external one.
Few remarks:
- the clumsy but unavoidable part of DSpace is that items contain handles
in their url but you need the item url for handle registration. You can do
it in two steps registering a dummy url and later modifying it with the
correct item url;
- do not use a shared prefix for communities (collections) that may be
hosted somewhere else in the future because you will not be able to export
*only* a subset of handles to a different handle server in a clean way;
- it can make perfect sense to have a handle (PID) resolving to another
handle and that one to a url (even deeper hierarchies make sense for some
applications);
- the next version of the handle server should have REST API (the only
official information I found is here
http://www.handle.net/mail-archive/handle-info/msg00624.html but the dates
are not valid) which would solve quite a few issues;
Best,
Jozef
On 14 November 2014 17:02, Peter Dietz <pe...@longsight.com> wrote:
> Hi All,
>
> I've been reading up on the various configurations that you can run DSpace
> and the handle service in, and I was wondering if people would be willing
> to share their experiences with "non traditional" set ups.
>
> So, the out-of-the-box traditional setup, that I'm guessing 99% of us use
> is to run DSpace, and configure the start-handle-server to connect to
> DSpace using java (loads the dspace jars, gets access to DSpace API
> org.dspace.handle.HandlePlugin, tries to resolve the incoming request with
> that DSpace).
>
> So, for an upcoming project, imagine that someone wants to be able to take
> a collection OUT of DSpace, and put it into another application on their
> campus. If they wanted their handles to continue to resolve, the new
> application would need to speak handle, but the handle service would need
> to know how to resolve handles to multiple applications.
>
> I know there have been some enhancements to DSpace over the years, I was
> just wondering if anyone who had experience with them could share what is
> possible, or if there is work that still needs to be done in this area.
>
> One of the new enhancements to DSpace is to allow the handle service to be
> on an external server from DSpace:
> https://jira.duraspace.org/browse/DS-1637
>
> It adds some additional endpoints in XMLUI/JSPUI to respond in text, which
> an external handle service could use to resolve. Then the box that runs
> DSpace, can be properly firewalled, on a private IP address, and not have
> world accessible ports coming in. (Your external webserver, and external
> handle service would be public, but know how to internally connect to
> DSpace).
>
>
> So, some XMLUI endpoints, that external handle service could use to
> resolve:
>
> http://trydspace5.longsight.com/handleresolver/listprefixes
>
> ["123456789"]
>
> http://trydspace5.longsight.com/handleresolver/listhandles/123456789
>
>
> ["123456789/1","123456789/2","123456789/3","123456789/79","123456789/77","123456789/6","123456789/7"]
>
> http://trydspace5.longsight.com/handleresolver/resolve/123456789/79
>
> ["http://trydspace5.longsight.com/handle/123456789/79";]
>
>
> As far as I understand it. DSpace provides a route to allow a handle
> service to determine if DSpace contains that content. If you moved a
> collection from DSpaceA to repositoryX, you would need to have a handle
> service that knew how to lookup both DSpaceA and repositoryX to see if one
> of them can resolve that handle?
>
> And then another question along this same line. Say you have multiple
> applications on campus, and wanted each to be capable of minting handles,
> has anyone ever worked on a process to have each application contact this
> central handle resolver to ensure that the handle it wants to mint is
> available? I imagine this would be some type of transaction, to ensure that
> competition among consumer applications doesn't lead to a conflict. (Both
> apps ask if handle is in use, both hear no, each mints, each posts back to
> handle service that its has just minted it, and then, how to roll back, or
> handle that state). Ivan mentioned to me, that they just assign handle
> ranges to each application.
> i.e. DSpaceA = 0-(1M-1), DSpaceB = 1M-(2M-1)
> I suppose another route, would be to just use a UUID, and not worry about
> colliding. And then, another thing that I think would be possible, but I
> would need clarification is: handle prefixes with dots. Such as 1234.1 or
> 1234.thesis or 1234.dspace1. Are you allowed to claim an additional prefix
> with a dot, or do you have to ($) register that with the handle authority?
>
> Another thing I was just thinking, that instead of allocating million
> record chunks to each application, what if you prefixed your suffix, with
> the application that will be doing the minting? i.e. 1234/thesis-678,
> 1234/thesis-679, or 1234/a-678, or 1234/dspace1-678
>
> Another trick that I've just seen, not related to how handles will resolve
> inside your institution, but it appears that the CNRI handle authority now
> has an API to look at resolutions:
> http://hdl.handle.net/api/handles/10827/16924
>
> {"responseCode":1,"handle":"10827/16924","values":[{"index":100,"type":"URL","data":{"format":"string","value":"http://dc.statelibrary.sc.gov/handle/10827/16924"},"permissions":"1010","ttl":100,"timestamp":"1970-01-01T00:01:40Z"}]}
>
>
> So yes, apologies if this was lots of questions, but I'm thinking that
> since handles have been in use for so long, that people might be needing
> additional tools to help keep these identifiers persistent.
>
>
> ________________
> Peter Dietz
> Longsight
> www.longsight.com
> pe...@longsight.com
> p: 740-599-5005 x809
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> _______________________________________________
> DSpace-tech mailing list
> DSpace-tech@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
> List Etiquette:
> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
>
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
