Integrating OJS and SNEEP

A little while ago I blogged about the implementation of SNEEP (Social Networking Extensions for Eprints) in the SAS-Space repository.With thanks to Rory McNicholl, here is a report on the next step. Rory writes:

"The next step was to integrate SNEEP content from SAS-Space into the OJS interface. Thankfully SNEEP has a RESTful API (more than by happy accident than by design), so making requests of it was reasonably straightforward. A proxy script (sneep_proxy.php) that utilised cURL was added to the OJS docroot to deal with any inter-domain AJAX requests. Using the SWORD-deposit condition within the OJS article template the necessary javascript and html was inserted. This allowed OJS to display tags and comments associated with the repository item. See it in action here.

There is a caveat: this rather simple integration with SNEEP only uses the publicly accessible content and functions. The private notes that users can add in SAS-Space are not displayed. Neither is it yet possible for users to add tags and comments in OJS directly. 

Further integration of SNEEP and OJS would require more work on the sharing of authentication. Single sign-on for SNEEPish authentication was one of the matters explored in the JJISC-funded PICT project. However in this case we wanted the user-generated content to be the same between the OJS and Repository pages; a different relationship to the one set up by PICT. In this particular case, the fact that both SAS-Space and SAS Open Journals use the University of London LDAP authentication server may mean that there is scope for overcoming SNEEP user-identification-from-a-far, with further work, with different funding.

Making OJS and EPrints play nicely

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:

http://code.google.com/p/sasojs/

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 repository.

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 OJS copy.

Populating OJS from EPrints

Now that a full complement of Amicus Curiae articles has been loaded into the SAS-Space repository, I have been looking at ways to populate the OJS database automatically using the metadata available in the repository.

We are fortunate, as ever, that EPrints provides a wide range of export formats for individual item records and for sets of records. On the Amicus Curiae Collection page, we can see that EPrints gives us the option to export the metadata for the whole collection as a bibliographic citation (plain text or HTML), in formats for reference management software (Reference Manager, BibTex, EndNote) and in several other bibliographic data formats, including Dublin Core and METS.

However, I've chosen to base our process on the EP3 XML format of EPrints, which I've worked with before (when we migrated SAS-Space from DSpace to EPrints). It is the native EPrints export/import format, and arguably contains the most faithful serialisation of item metadata in the repository.

I've now created an XSLT stylesheet that transforms the EP3 XML for the Amicus Curiae collection into the "native.dtd" XML format which is the native import/export format for OJS. The biggest challenge in XSLT was grouping the journal articles by issue number, as required by the OJS native format, but once I'd found a way to do that, the rest is just fiddling about, as it so often is with metadata mapping.

Once the EP3 XML is transformed to OJS format, then, with a Journal already defined in OJS, we can use the OJS import function to import a complete set of issues, each containing its full complement of articles. It's also possible to include a cover image for each issue (if one is available), and the article in PDF form can either be embedded in the XML using Base64 encoding, or linked-to using a URL. Since our articles are already online in the SAS-Space repository, I used the URL option. (It seems that this imports the object into OJS filestore: we will investigate whether it's possible to prevent this, and have the online journal simply link straight to the item in SAS-Space.)

At the moment the XSLT stylesheet is working for our purposes, but offers the intriguing prospect that it could be enhanced to work over any result set in an EPrints repository, and made available as an EPrints Export Plug-in. This way, anyone wanting to quickly assemble, or reassemble, an online journal in OJS, can do so from articles deposited in a repository.

This could be an attractive scenario for anyone trying to retrospectively assemble an online journal from scans of a printed journal: once the materials are deposited in the repository (with sufficient metadata, of course, and, ideally, OCRed), then the data needed to implement a fully working journal in OJS is only a click away.

Existing OJS journal managers might even choose to manage their deposit and review workflow using the repository, and export to OJS when ready. This project gives us an interesting opportunity to compare the two approaches to item submission workflow, and I hope we'll be able to report back on that later.