Wednesday, February 22, 2012

The EJME plugin: improving OJS for articles with data

The EJME project has wrapped up and delivered! To quote the press release from SURFfoundation: "Enhanced Publications now possible with Open Journal Systems - Research results published within tried-and-tested system using plug-ins". That's all great, and so is the documentation, but aimed at those in the know already. A little more explanation is needed.


Who is EJME for?
Any journal that uses OJS for publishing and that wants to make it possible to have data files attached to articles (and as of December 2011, that's 11,500 Journals!).

What does it do?
Three things:
  1. improves the standard OJS handling of article 'attachments': files are available to editors and peers during the review process, and the submission process has been made (a little) easier; 
  2. plays nicely with external data repositories: an attachment can be a link to a file residing elsewhere (but work just like an internal OJS attachment in the review and publishing stage), and an internal attachment that an author has submitted with the article can also be submitted to a data repository, creating a 'one-stop-shop' experience for the author;
  3. on publication, it automagically creates machine-readable descriptions of an article and its data files (in tech-speak: these are small XML files, so-called Resource Maps, in the OAI-ORE standard). These can be harvested by aggregators such as the Dutch site Narcis that can then do more great and wonderful things with it, for example slick visualizations.

Great, but I only want some of that!
That's perfectly possible. If you want only improved handling, they're included in the latest OJS version. The other two are in separate plug ins, install only what you need. Though I do recommend to install the resource map plug-in, it won't require any work after installing.

What does it cost?
Just like OJS itself, the plug-in is open source and free of cost. Installation is as easy as most OJS plug-ins.

What does the journal have to do?
Of course, software is only a tool. The real question is deciding what to do with it. Does the journal want a mandatory Data Access policy? Is there a data repository in the field to cooperate with? Once these questions are answered, the journal policy and editorial guidelines will need to changed to reflect them.

Why would my journal want data along with articles?
As science becomes more and more data-oriented (and that includes the humanities), publishing data along with articles becomes essential for the peer review system to function. There have been too many examples lately of data manipulation that would have been found out by reviewers if they would have checked the data. And for that, they need access to the data. Reviewers of course won't change their habits suddenly once data is available to them, but it's a necessary first step.
(There are many other reasons, both carrots and sticks, for the greater good or the benefit of journal and author, but IMHO this is the pivotal point).

Q: Why name it EJME, such a silly name?
Enhanced Journals Made Easy was a little optimistic, I admit. Enhanced Journals Made (A Little) Easier would have been better. You live and learn!


Want to know more about EJME? Get started with the documentation.

2 comments:

Hilmar said...

Do you happen to know whether the plugin would work with OCS, too?

Driek said...

No, I don't know. The plugins depend on a few 'hooks' that turned out buggy in OJS, hence the need to either use the latest version or apply the patch. It's likely that OCS has the same bugs, in which case you'd have to manually make the same changes as in the patch.

If you have an OCS install at hand to test it'd be the quickest to just install the plugins and see if they work. I'd be very interested to hear the results!