Hi Sandy,
I'll respond inline on some of your questions
On Mon, Jun 4, 2012 at 11:04 AM, Sandy De Groote <[email protected]> wrote:
> We do have handles so that does seem as though this makes this process
> inadvisable. One of our primary reasons for splitting into different
> instances is so that they are two different repositories. There are over
> 7000 records of the archival content that interferes with searching the
> retrieval of the smaller scholarly content. The archives in the IR was
> only supposed to be temporary....
>
Do you anticipate that the archives content you describe was intended to be
citable? Certainly if you have no interest in sustaining any citations to
those archive collection contents, then you could take down and restore
that content into another service entirely, abandoning the assigned handles.
Alternatively, if improving the discovery experience of your users is the
primary concern, and you do ned to maintain the archive for citation
purposes, I concur with Bram, and I extend his recommendation that you
might also consider reorganizing the current communities under two separate
top level communities and refining your themeing so that you only show two
search options on your repository landing page. One to search the archival
content, the other to search the smaller community of scholarly content.
Then you are only enhancing the presentation and organization of your
items rather than working to restructure the actual storage location and
identification of the content.
>
> Would there be a way to split the two repositories if we only maintain the
> handles for one of the instances? In other words, the research side would
> maintain the handles but the archives would be assigned all new handles.
> Is that possible? (I realize the suggestion throws aside the whole
> purpose of having life long handles assigned to an item.)
>
I notice my last post only went to you and not the community at large, I
am reposting it to the community for the benefit of this dialog as it
presents an alternative to splitting the repository contents and
establishment of an external handle server to support persistence of handle
identification and resolution outside of DSpace itself.
On Fri, Jun 1, 2012 at 8:14 PM, Mark Diggory <[email protected]> wrote:
> I suspect this is going to be a difficult task, the real question is
> addressing what to do with the handle resolution services. Your going to
> be trying to split the handle resolution such that it resolves to content
> stored on more than one system.
DSpace does not currently support an external handle server, but patches
> are out there experimenting with the concept and @mire and some of our
> partners are working together to create more flexibility for this in future
> versions of DSpace.
There is a rather old patch that Robert Tansley had put into the old
> sourceforge issue tracker, I resurrected it and placed it here to
> revitalize that option because there were past requests on the solution.
> https://jira.duraspace.org/browse/DS-1171. It does need some work to
> make compatible with new versions of DSpace.
>
> I believe your approach would be to:
> 1.) Migrate to use an external handler server to publish and resolve your
> handles.
> 2.) Replicate all your existing handles against the current
> DSpace instance into this server, registering it with CNRI to become the
> default handle resolver for any services you need to support handles on.
> 3.) Migrate copies of your content you wish to place on the second server.
> 4.) Update the standalone Handle server handles to point at the new server
> instead of the original one.
> 5.) Remove the items from the original server once you've determined those
> moved Items still resolve properly.
> 6.) Modify both dspace instances HandleManager such that it can register
> their handles in the external handle server rather than the
> existing embedded DSpace Handle Server.
> Note, while working with various clients, we realized that there was a
> great need for greater external identifier support in DSpace. We started
> the the "IdentifierService" subproject to provide such capabilities within
> the "Item Level Versioning" contribution we are planning for DSpace 3.0.
> It takes the above patch and extends DSpace to support more identifier
> services than just handles (arks, purls, doi, so on).
>
> https://wiki.duraspace.org/display/DSPACE/Item+Versioning+Support#ItemVersioningSupport-IdentifierService
The take home message is that future enhancements to Identifier support in
DSpace will set the stage for the type of separation of Persistent
Identification from resolution and publication of resources you are
originally proposing. However, if you do not have any other strong
requirement for this separation other than improving the branding and
discovery of sub-collections of your repository content, you might instead
focus on reorganizing and branding your repository to support separate
search experiences for your users.
Cheers,
Mark
--
[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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
