· 20th December 2011 · Comments Off · Categories: Repositories

The creation of an online version of Amicus Curiae, the opening salvo of the SAS-Journals project, was based on organising existing articles in PDF form. It is also the case that new content for upcoming editions of the journal will continue to be uploaded to OJS also as finished PDFs. This works well for Amicus which has long had a print edition of which the creation of PDFs is a by-product.

However there are different ways to approach the publication of online journals; and issues surrounding this were discussed toward the end of the project, notably during the workshop on 20th October. The OJS software already supports the creation of articles ‘from scratch’ itself, using the XML-galleys plugin. The default output of this is based on NLM’s XML schema for publishing journal articles. This approach gives more potential flexibility when it comes to offering different formats for the finished um… article.

OJS seems reasonably agnostic concerning the formats it will allow for submissions, and this makes life easier for authors. However, editors and journal managers may wish to be more rigid in the format in which they wish to present the articles once published (eg. must be PDF!). So what options are there for converting submitted manuscripts from one format to another?

This discussion on the PKP BB gives an insight in to some of the possibilities.

OpenOffice is generally the go-to tool for an open-source solution to document format conversion. It can be run “headless” (ie. without the GUI) and used either to batch process conversions or possibly as part of a plugin for OJS.

The good news for OJS administrators is that lemon8-XML a web-based application that operates separately from the OxS suite was released by PKP in 2009. This uses a headless instantiation of OpenOffice to convert Word or OpenOffice files into NXML.

So we could imagine a workflow like this:

Oo & Doc -> lemon8-XML -> NXML -> XSLT -> PDF & HTML

It is worth noting that there is a significant amount more jiggery-pokery required when going from XML to PDF than to HTML. As far as I am aware there would need to be an intermediary step involving something like FOP.  I’m sure someone has implemented something like this by now… anyone?

· 1st November 2011 · Comments Off · Categories: Repositories

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.

· 14th July 2011 · Comments Off · Categories: Repositories

From the SAS Open Journals project blog.

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.

More »

PRIMO ScreenshotThe PRIMO Steering Committee met last week to discuss next steps towards the launch of the final version.

There will be quite a few changes from the current beta version. Many of these are the result of Professor Katharine Ellis’s extensive advocacy and consultation, among both the musical research community, who will be the system’s users, and among the repositories community, at events like the JISC Rights workshop, and the Repository Fringe in Edinburgh. Others have been made possible as a result of the experience we’ve gained on other Eprints projects, like Linnean Online, Their Past Your Future and SNEEP.

As you can see from the screenshot, we’ve freshened up the overall look, and Rory has had considerable success with the embedded Flash player, which is going to make both video and audio content in PRIMO far more usable and accessible than the present, download-oriented system.

There are more changes and enhancements and a snag list as long as your arm, but we’re confident that when PRIMO gets its full and final launch in January, it will be a major improvement. There is also exciting new content currently being reviewed by the Committee, that will showcase the potential value of PRIMO to its community, and, we hope, encourage other musical researchers to contribute their own research-in-practice.

PRIMO logo PRIMO (Performance as Research in Music Online) was launched at Senate House last Friday (26th October) to an invited group of music researchers. Katharine Ellis gave an excellent explanation of the repository’s purpose, which is to provide a Trusted Repository for audio-visual records of musical research-in-practice. I followed on with a brief demo. Katharine and Valerie had prepared an excellent PRIMO promotional leaflet, as well as laying on some drinks. Mick Kahn and Andy McGregor (our JISC project manager) also attended.

More »