JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for JISC-REPOSITORIES Archives


JISC-REPOSITORIES Archives

JISC-REPOSITORIES Archives


JISC-REPOSITORIES@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

JISC-REPOSITORIES Home

JISC-REPOSITORIES Home

JISC-REPOSITORIES  February 2010

JISC-REPOSITORIES February 2010

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: Funder mandated deposit in centralised or subject based

From:

Stevan Harnad <[log in to unmask]>

Reply-To:

Stevan Harnad <[log in to unmask]>

Date:

Sun, 21 Feb 2010 16:21:11 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (209 lines)

On Sun, Feb 21, 2010 at 8:55 AM, Kiley ,Robert <[log in to unmask]> wrote:

> we want to avoid a situation where a researcher is required to
> deposit papers in both an IR (to meet their institutions mandate) and a
> central repository, like PMC and UKPMC, (to meet the needs of a funder
> such as the Wellcome Trust).

It is so gratifying to hear that the Wellcome Trust -- the very first
research funder to mandate OA self-archiving -- is looking into
resolving the problem of multiple deposit (IRs and multiple CRs,
Central Repositories)..

The solution will have to be bottom-up (IRs to CRs) not top-down (CRs
to IRs) for the simple reason that the Institutions are the providers
of *all* research, not just funded research, and the solution has to
be one that facilitates universal institutional deposit mandates, not
just funder mandates.

IRs and CRs are interoperable. So, in principle, automatic
import/export could be from/to either direction.

But since Institutions are the universal providers of all research
output, funded and unfunded, across all disciplines, it is of the
greatest importance that the solution should be systematically
compatible with inducing all institutions to mandate self-archiving.

For an institution that has already mandated self-archiving, the
capability of automatically back-harvesting some of its own research
output is fine (but, if you think about it, not even necessary). If it
has already mandated self-archiving for all of its output,
back-harvesting is redundant, since forward harvesting (IR to CR) is
the only thing that's still left to be done.

For an institution that has *not* yet mandated self-archiving, however
(and that means most institutions on the planet, so far!) it makes an
*immense* difference whether funders mandate IR deposit or CR deposit.

If funders mandate CR deposit (even with the possibility of automatic
back-harvesting to the author's IR), institutions that have not yet
mandated self-archiving are not only left high and dry (if they aren't
mandating local self-archiving for any of their research output, they
couldn't care less about back-harvesting the funded subset of it); but
the synergistic opportunity for funder mandates to encourage the
institutions to mandate self-archiving for the rest of their research
output is lost -- unless funders systematically mandate IR deposit.
For funder-mandated IR deposit launches and seeds IRs, and makes the
adoption of an institutional mandate for the rest of the institutional
research output all the more natural and attractive.

Funder mandates requiring institute-external deposit (even if they
offer an automatic back-harvesting option) not only fail to encourage
institutional deposit and institutional deposit mandates, but they
increase the disincentive, and in two ways:

(1) Authors, already obliged to deposit funded research
institution-externally, will resist all the more the prospect of
having to do institutional deposit too (whether for funded or unfunded
research); hence they will be less favorably disposed toward
institutional mandates rather than more favorably (as they would be if
they were already doing their funder deposits institutionally);
consequently their institution's management too will be less favorably
disposed toward adopting an institutional mandate.

(2) Worse, some funder mandates (including, unfortunately, the
Wellcome Trust mandate) allow fulfillment to be done by *publishers*
doing the (central) deposit instead of authors. That adds yet another
layer of divergent confusion to deposit mandates (apart from making it
all the harder for funders to monitor compliance with their mandates),
since fundee responsibility for "compliance" is offloaded onto
publishers, who are not only not fundees (hence not bound by the
mandate), but not all that motivated to deposit any sooner than
absolutely necessary. (This is also, of course, a conflation with Gold
OA publishing, where the funders are paid for the OA.)

The natural, uniform, systematic and optimal solution that solves all
these problems -- including the funders' problem of systematically
monitoring compliance with their mandate -- is for *all*
self-archiving mandates -- institutional and funder -- to stipulate
that deposit should be in the author's IR (convergent deposit). That
way institutions are maximally motivated to adopt mandates of their
own; authors have only one deposit to make, for all papers, in one
place, their own IRs; institutions can monitor funder mandate
compliance as part of grant fulfillment, and the automatic harvesting
can be done in the sole direction it is really needed: IR to CR.

Robert mentions two other points below: publisher resistance to CR
deposit and the question of XML:

(a) In the OAI-compliant, interoperable age, there is no need for the
full-texts to be located in more than one place (except for
redundancy, back-up and preservation, of course). If the full-text is
already in the IR, all the CR needs to harvest is the metadata and the
link.

(Besides, once universal OA mandates usher in universal Green OA,
everything will change and optimize even further, But for now, the
real hurdle is getting to universal Green OA, and the retardant is
institutional sluggishness in mandating self-archiving. That is what
makes convergent reinforcement -- instead of divergent competition --
from funder mandates so crucial at this time.)

(b) Not so long from now, authors will all be providing XML. What is
urgently missing today is those all-important refereed-article
full-texts (final refereed drafts), not XML. It would be exceedingly
short-sighted to put needless hurdles in the path of getting that
urgently needed full-text OA content today, because we are in such an
unnecessary hurry for XML!

(Again, once we have universal Green OA, all kinds good of things will
happen, and happen fast, as a matter of natural course. But right now,
we are needlessly -- and very short-sightedly -- over-reaching for
non-necessities like XML, and central full-texts (and, for that
matter, authors' addenda and Gold OA) at the cost of year upon year
failing to do the little it would take to usher in universal Green
OA.)

> To... simply use the SWORD protocol to move content from repository
> A to repository B... does not address the rights issues....some publishers
> ... allow authors to self-archive papers in an IR, but... NOT [in a CR]

But the question we need to clear-headedly ask ourselves about this
fact is: So what?

What we need now is universal Green OA, regardless of locus. There is
no particular rush for CR full-texts, and Green publishers have
already blessed immediate IR deposit. Why balk at that, and needlessly
insist on more, only to get much less? (This is *precisely* what has
been going on year after year now, with the counterproductive
divergence of funder mandates from institutional mandates.

> In addition to the rights-management problem, there are other issues we
> need to address such as how a manuscript, ingested from an IR, could be
> attached to the relevant funder grant, and how a researcher could be
> motivated to "sign-off" the version of the document in PMC/UKPMC, given
> that they would have already deposited in the IR.  [As you may be aware,
> every author manuscript in PMC and UKPMC is converted to XML.  To ensure
> that no errors are introduced through this exercise, authors are
> required to sign-off the conversion before it can be released to the
> public archive.]

But why, why all this? There's an urgent need for the full-texts.
There's no urgent need for the XML. There's an urgent need for an OA
version *somewhere*, but no urgent need that it must be in a CR. The
CR need merely harvest the metadata. Nothing to sign off. Nothing to
convert. And the eager institutions will be only too happy to monitor
and ensure compliance both for deposit (which should be immediately
upon acceptance of the final refereed draft for publication) and for
setting access to the deposit as OA (whenever the allowable embargo,
if any, elapses).

Unnecessary pseudo-problems are being allowed to get in the way of
powerful practical possibilities in these complicated and arbitrary
self-imposed criteria. (Let us not forget that this has all been
improvised in the past 6 years; we are not talking about longstanding
canonical criteria here!)

> In view of these issues our preferred approach is to encourage
> researchers to deposit centrally, and then provide IR's with a simple
> mechanism whereby this content can be ingested into their repository.
> Of course, even with the UKPMC to IR approach there may be rights
> management issues to address.
>
> This development work has only just begun but I will keep you (and this
> list) abreast of progress.

I hope some thought will be given to the many reasons that the
proposed solution (CR deposit and automatic IR import capability) is
needlessly far from being the optimal solution, which is the simple,
pragmatic alternative that would deliver far more OA at no loss
whatsoever: both funders and institutions mandate IR deposit and CRs
harvest the metadata from the IRs.

Stevan Harnad

> Robert Kiley
> Head of Digital Services
> Wellcome Library
>
> -----Original Message-----
> From: Repositories discussion list
> [mailto:[log in to unmask]]
> On Behalf Of Garret McMahon
> Sent: 18 February 2010 12:05
> To: [log in to unmask]
> Subject: Funder mandated deposit in centralised or subject based
> repositories
>
> Dear All,
>
> I have a general query regarding funder requirements that stipulate
> deposit into a centralised or subject based repository such as PubMed
> Central. Is anybody meeting such a requirement by developing processes
> that incorporate the institutional repository as the primary point of
> ingest and subsequently uploading content to the centralised service?
> I'm particularly interested in two aspects of this question. Firstly,
> how an institutional policy supporting the home repository does not find
> itself at variance with funder deposit policies that specify a
> preference for locus of deposit external to the institution. Secondly,
> what is critical to the home and centralised repositories in terms of
> service design in any such collaboration.
>
> Kind Regards,
>
> Garret McMahon
> Institutional Repository Content Manager - www.tara.tcd.ie Systems
> Office Ussher Library Trinity College Dublin 2 Ireland
> Tel: +353 1 896 1646
> email:[log in to unmask]

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2024
March 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
November 2005
October 2005


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager