PKP Bugzilla – Bug 1443
Finer granularity for OAI interface
Last modified: 2012-09-24 08:44:01 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 <journal-path>/oai/). 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.
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! Andrea
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).
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!
Caitlin, the issue you're encountering is different from the one filed here; see bug #6733.
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!