Our main tasks at ULCC during the SAS Open Journals project were
- to set-up the instance of PKP's OJS software
- to enable SWORD deposits to the SAS-Space repository
- to configure OJS such that digital objects were referenced from
the repository where possible.
The first two steps were straightforward enough. We installed OJS-2.3.4
which has a generic SWORD plugin. However in order to retain as much
metadata richness as possible during the SWORD transfer we opted to
use EPXML to describe the object rather than METS. Although the generic SWORD
plugin only deposited using METS, we were comfortable in forgoing
using the METS standard since there was only to be a single deposit point (SAS-Space) and deposits would be
managed solely by OJS administrators.
The changes made to OJS mentioned below and in "Integrating OJS and SNEEP" can be obtained at the project site:
in the form of a patch and some additions to OJS-2.3.4
A form field (formatNS) was added to the deposit point template plugins/generic/sword/depositPointForm.tpl. This allowed
the administrator to specify the schema used to describe the item
metadata. Values for this can be "http://eprints.org/ep2/data/2.0/"
or the default "http://www.loc.gov/METS/". Changes were made to
plugins/generic/sword/SwordImportExportPlugin.inc.php to handle this
new form field and to classes/sword/OJSSwordDeposit.inc.php to make a
decision on the sort of XML file to be included in the SWORD deposit
package based on the new parameter. The file
lib/pkp/lib/swordapp/packager_epxml_swap.php was added and this
handled the construction on the EPXML file.
Another issue we faced using the generic SWORD plug-in was that it
did not appear to store information on deposit items within the OJS system.
This was essential in order to allow
objects to be referenced by OJS from the repository. To achieve this
we cannibalised an old version of the SWORD OJS plugin and added
classes/sword/SwordDepositDAO.inc.php which allowed us to keep a
record of deposited items within OJS.
With this record in the OJS system we could add a getSwordDeposit
function to classes/article/ArticleGalley.inc.php which would check
to see if a SWORD deposit was available and that the address
recorded for the file resolved, before redirecting requests to the
And then, finally, some changes to the article template, and the first three
tasks were complete.
There is however a caveat: the embedded plugin PDF viewer, invisibly redirecting to a
third party (ie SAS-Space) seemed to fall foul of some browser's
security regimes. If the security was based on the domain, then we
were on safe ground as the redirect was from the journal domain (journals.sas.ac.uk) to the repository (sas-space.sas.ac.uk). However Internet Explorer (at least, as installed on SAS
desktop machines) did not seem to like the redirect within the
embedded viewer. For this we implemented a fall back to the local