Institutional Repositories vs Subject/Central Repositories

From: Stevan Harnad <amsciforum_at_GMAIL.COM>
Date: Sat, 7 Jun 2008 18:26:28 -0400

Beth Tillinghast wrote on the DSpace list:

>I have just run into my first case where I am finding our IR in
> competition with a Subject Repository...
> I am wondering if others have run into this dilemma and can provide
> me with many good reasons why submission should take place in and
> institutional repository rather than a subject repository?

The dilemma has a simple, optimal and universal solution:

Direct deposit should be in the IR. SRs and CRs can harvest from IRs.

That's what the OAI protocol is for. Institutions are the research
providers. They are the ones with the direct stake in the
record-keeping
and showcasing of their own research output, and in maximizing its
accessibility, visibility, usage and impact. Institutions are also in
the position to mandate that their own research output be deposited
in
their own IR; funder mandates can reinforce that, and can benefit
from
institutional monitoring and oversight (as long as they too mandate
institutional deposit and central harvesting, rather than direct
central
deposit).

Convergent institutional self-archiving makes sound sense and scales
systematically to cover all of research output space, whereas
divergent
self-archiving, willy-nilly in SRs and CRs is arbitrary and simply
produces confusion, conflict, and frustration in researchers, if they
need to deposit multiply.

(Before you reply to sing the praises of SRs and CRs, recall that
their
virtues are identical if they are harvested rather than the loci of
direct deposit. The overwhelming benefit of IR deposit is that that
is
the way to ensure that all research output is universally
self-archived.)

THE FEEDER AND THE DRIVER: Deposit Institutionally, Harvest Centrally
http://users.ecs.soton.ac.uk/harnad/Temp/Harnad-driverstate2.html

How To Integrate University and Funder Open Access Mandates
http://openaccess.eprints.org/index.php?/archives/369-guid.html

Optimize the NIH Mandate Now: Deposit Institutionally, Harvest
Centrally
http://openaccess.eprints.org/index.php?/archives/344-guid.html

Stevan Harnad

-----------------------------------------------------------------
From: Michele Kimpton <michele_at_dspace.org>

I can not directly answer your question, but I did want to let you
know that Policyarchive.net is a DSpace instance with Manakin.  Why
not have the content deposited in both?  Maybe you can even use SWORD
to facilitate this.  The IR being the "steward" of the content and
PolicyArchive having a rich collection of subject based documents.
 It
is also a good preservation strategy to have the same document in
different geographical locations under different management regimes.

I have just run into my first case where I am finding our IR in
competition with a Subject Repository. I've been working with an
institutional center which is outside of our university but very
closely affiliated with it. We were about to make some final
decisions about community and collection development when my contact
discovered a new Subject Repository supporting the type of research
conducted at their Center and wants to explore this alternative
before committing to submitting their work to our university
repository.

http://www.policyarchive.net/index.php

I am wondering if others have run into this dilemma and can provide
me with many good reasons why submission should take place in and
institutional repository rather than a subject repository?

Also, as a side question, I know you can item map within your own
DSpace instance, but is it possible to item map to another DSpace
instance?

Beth Tillinghast

Date: Fri, 6 Jun 2008 11:07:38 -0700
From: "Romulo Rivera" <rrivera_at_cgs.org>

My name is Romulo Rivera, Project Manager for PolicyArchive.  We are
also a
Dspace shop, so we'd be happy to work together with you on this
matter.
Maybe we can harvest the center's data from your repository. I will
follow-up with you.
Received on Sat Jun 07 2008 - 23:28:33 BST

This archive was generated by hypermail 2.3.0 : Fri Dec 10 2010 - 19:49:20 GMT