We are moving to Git Issues for bug tracking in future releases. During transition, content will be in both tools. If you'd like to file a new bug, please create an issue.

Bug 1443 - Finer granularity for OAI interface
Finer granularity for OAI interface
Status: NEW
Product: OJS
Classification: Unclassified
Component: OAI
All All
: P2 normal
Assigned To: PKP Support
Depends on:
  Show dependency treegraph
Reported: 2005-04-26 01:07 PDT by Kevin Jamieson
Modified: 2012-09-24 08:44 PDT (History)
4 users (show)

See Also:
Version Reported In:
Also Affects:


Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Jamieson 2005-04-26 01:07:41 PDT
Currently the OAI interface is a site config option only, although the contents
of journal archives can be accessed individually as well (i.e., through

We may want to consider a finer granularity of control over the OAI interface,
e.g., allowing it to be enabled/disabled for individual journals, integration
with subscription restrictions, etc.
Comment 1 Andrea Kosavic 2009-08-21 12:47:18 PDT
I would like to add a use case to this suggestion for finer granularity of the OAI interface.  

At York University Libraries, we are using VuFind http://www.vufind.org/ to create a portal that allows users to search multiple library resources.  One of the resources that we are aggregating into this portal is our OJS instance, which hosts multiple journals.  We would like to be able to exclude several of our journals from OAI harvesting as they are not yet ready for prime time and we have "hidden" them by locking them down as much as we can through OJS.

Are there plans to develop more OAI granularity so that specific journals can be excluded?

Many thanks!
Comment 2 Alec Smecher 2009-08-21 12:56:43 PDT
Andrea, this is well and truly on the back burner at the moment -- but a good work-around is to register each journal with your OAI harvester separately, rather than registering the whole installation. As per Kevin's (2005-era) note, you can do this by using http://.../path/to/ojs/index.php/[journalPath]/oai as the OAI URL rather than http://.../path/to/ojs/index.php/index/oai (which would give you the entire site).
Comment 3 Caitlin Nelson 2011-07-01 12:11:20 PDT
I'd like to add a request to expedite this feature if possible.  We are using a single instance of OJS as a portal to many different journals.  In addition, and potentially more importantly, we have a number of journals in the instance that are "hidden" from web view but which do show up in the OAI interface.  These are not meant to be publicly viewable and certainly not OAI harvestable.  However, overall we would like people to be able to harvest from one source: the main OJS index page.

If you all are not planning to provide this "disable" feature any time soon, can you make a recommendation on how to configure it on our end to prevent the harvesting of data?  Thanks!
Comment 4 Alec Smecher 2011-07-04 09:00:49 PDT
Caitlin, the issue you're encountering is different from the one filed here; see bug #6733.
Comment 5 Caitlin Nelson 2011-07-05 06:54:14 PDT
Hi Alec, thanks for referring me and thanks for the patches - we'll have to upgrade ASAP to add them.  However, I'm still in support of having greater control over OAI data at the instance-level, rather than at the journal-level, so I hope this will be a feature added in the future.  Thanks again for your great support!