Re: Request Copy and Restricted Access

From: Stevan Harnad <>
Date: Sun, 20 Jan 2008 19:22:47 +0000

On Fri, 18 Jan 2008, Alvin Hutchinson (Smithsonian Institution
Libraries) wrote (on the DSpace list):

> I wonder how many people are using the 'Request Copy' button
> to restrict access to repository content on a case-by-case
> basis. If you are not familiar with this, you can learn more at:
> To see what it looks like in practice, go to:
> My question is whether some repository harvesting sites such
> as OpenDOAR, Google Scholar and/or the OAI-PMH harvesters would
> object to having content 'restricted' in this sense. Most of the
> harvester/aggregator sites ask that all content be freely available
> before they will include a Dspace installation in their index.
> Technically such items are freely available to any user (with the
> consent of the author) and there is no requirement to register and/or
> pay for the material.
> Does anyone have any thoughts on this? Would it be inappropriate to
> open my repository up to these services if some (most, all, few?) contents
> are limited in this way? Your opinions are greatly appreciated.

(1) Neither the DSpace "Request Copy" Button nor the EPrints "Request a
Button (on which it was based) "restrict access to repository content".

(2) What makes it possible to deposit a document and metadata, and then
restrict access to the metadata alone is both the DSpace and the EPrints
software, which offer both an Open Access and a Closed Access deposit

(3) There are many reasons depositors might wish to use the Closed
Access deposit option. The main reason is that some publishers impose
an access-embargo of 6-12 months or more. Another is that in some
cases the author might want direct control over -- or a record of --
who accesses his paper.

(4) Both OpenDOAR and ROAR as well as
OAIster harvest the metadata of all suitable
OAI-compliant repositories, regardless of whether the full-text item
itself is Open Access or Closed Access. (Google Scholar only harvests
accessible full-texts, though it displays cited items undeposited items
too, and links to Google as another way to find a link to the item.)

(5) It is for this reason that the combination of Closed Access
full-text, open-access metadata and the Button is called "almost-open
access" and not open access.

(6) Once the IDOA (Immediate-Deposit/Optional-Access) mandates, with the
help of the Closed Access plus Button option, spread to all universities
and funders worldwide, access embargoes will soon die a natural and
well-deserved death under the mounting demand for open access.

So the upshot is this: For years now, researchers have failed to
deposit their full-texts in sufficient numbers on their own initiative
to provide 100% OA, partly because of concerns about copyrights and
embargoes. IDOA mandates will now remedy that. 100% of articles will
now be deposited. At least 62% of them will be immediately OA. The
remainder will initially be almost OA.

And once those keystrokes -- which were the only things standing between
the research community and 100% OA all along -- are at last behind us,
100% OA will follow in short order. (You can quote me on that.) A little
more patience for now, after all this fruitless waiting for spontaneous
deposit: Concentrate on adopting a local institutional IDOA mandate
and getting everything deposited, rather than worrying about whether
the deposits will/would be picked up immediately by google. All will
be well...

Meanwhile, once your university has a deposit mandate, please register
it in ROARMAP:

Stevan Harnad

If you have adopted or plan to adopt a policy of providing Open Access
to your own research article output, please describe your policy at:

    BOAI-1 ("Green"): Publish your article in a suitable toll-access journal
    BOAI-2 ("Gold"): Publish your article in an open-access journal if/when
    a suitable one exists.
    in BOTH cases self-archive a supplementary version of your article
    in your own institutional repository.
Received on Sun Jan 20 2008 - 19:55:34 GMT

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