Working with SWORD and Moodle

February 15th, 2010 by jamesballard

Our project has successfully implemented a SWORD deposit tool within Moodle, however it is felt that the affordances of Moodle and ePrints have not yet been greatly improved by this. This is mainly due to limitations of interoperability offered by the SWORD library. In particular once a deposit is made Moodle and ePrints no longer communicate which proves a significant barrier to wider implementation unless the purpose is to merely get content out of Moodle. It already seems that the repository API in Moodle 2.0 will improve such relationships and make SWORD less relevant for this process where each repository will define its own interactions.

What we implemented

The plug-in comes in 2 parts – a block and a resource type, which allow deposits made using SWORD to be accessed directly from within Moodle. A single repository or multiple repositories can be configured as options to work with the plug-in. This supports our use case scenario of a tutor or librarian depositing copyright content into the repository and controlling student access to this via Moodle. Both Moodle and ePrints keep a detailed audit record of who has accessed the resource and where it has been accessed from (e.g. which courses).

Further Improvements

The most significant improvement would be improvements to the interoperable transactions offered through this interface. It seems that more powerful interoperability could be achieved without SWORD than with it though. There is much that can be improved in the interface and interoperability, for example being able to search and classify resources, however adding this into the Moodle library, doesn’t really benefit SWORD or wider interoperability and start making the metadata redundant.


Here is a summary of some key issues encountered while developing the CLASM plugins for Moodle with SWORD:

  • No concept of change control – if you delete or expire the file in ePrints or Moodle this is not reflected in the other system. In terms of interoperability this has huge issues as the two systems may easily fall out of sync. Moodle’s Repository API seems far better placed to manage this without the need for SWORD.
  • Poor documentation and governance – while upgrading through versions of the SWORD deposit tool, the integration broke the functionality with little documentation to explain this. After upgrading the SWORD library from 0.6 to 0.9 the interface returned no response, making it impossible to diagnose the issue. The relationship between the client are the upgrade is unclear.
  • Discrepancies between SWORD App and Client – there is little consistency between interactions between the app and the client. In all cases we had to hard-code in an awareness of different handling of repository type (e.g. DSPACE, ePrints, Fedora) and in some cases configuration of the repository itself. An interoperable application needs to be agnostic of specific SWORD clients, otherwise it may be easier to simply work with each repository directly as this would be more powerful;
  • Poor reporting – bug reporting and notices between the client and the application were almost non-existent. Most reports of fatal internal errors died without any useful debugging information. For example, the client returns invalid XML to the application if it fails, which then cannot be accepted by the SWORD App; this is useless information for diagnostic testing.


CLASM on Google Code

February 14th, 2010 by Richard M. Davis

CLASM Moodle plugins is available on Google Code (it has been for some time – we’ve had a bit of a blog blockage).

Key points:

  • Same version works on both 1.9 and using emulator function;
  • Works as deposit block or as a resource type;
  • Moodle logs resource views;
  • Uses SWORD 0.6;

Documentation needs copying to the Google Code wiki.

CLASM briefly

August 18th, 2009 by Richard M. Davis
This screenshot shows the home page for the demo course as it would be seen by an administrator or course-designer (teacher with edit permissions).On the right is the CLASM SWORD plugin widget, which offers the options to

  • Deposit a file
  • View previously deposited files
This screenshot shows the Deposit File form.

At the top you can choose which repository to deposit in. The available options are set when the plugin is installed and configured. If only one repository is configured, this option is not available.

When depositing to DSpace repositories, the target collection can be selected.

This screenshot shows a basic list of Deposited Files. The Moodle plugin maintains a list of URLs of its objects in the repository, based on the information returned by the SWORD app on successful upload.

Breaking radio silence

August 17th, 2009 by Richard M. Davis

I don’t know quite why this blog never took off at the start of the project. A combination of infelicities with the JISCInvolve blog, that we kept putting off sorting out (multiple accounts and very nasty themes), and the fact that we had already setup the CLASM wiki as the default home for our endeavours. Maybe we should have set up our own blog there too – I tend to feel more attached to blogs that I’ve a bit more control over.

Anyway, making up for lost time, we’ve a few updates waiting in the wings, they’ll be coming over the next few days.

SWORD Deposits from Moodle

June 10th, 2009 by jamesballard

We have developed a Moodle depositing interface for Moodle versions 1.9.x and 2.0 that has successfully deposited to installations of ePrints, DSPACE and FEDORA. This began with a simple block that could deposit to one repository and has now been extended so that administrators can potentially add multiple potential repositories from which a user may choose.

The developments use a simple plug-in and configuration architecture so can be made available to any Moodle and SWORD repository system.But what does this achieve? Currently it demonstrates that depositing to a repository can be made just as simple as uploading files to Moodle’s somewhat arbitrary folder structure. Once we have identified the value-added that repositories have above and beyond folder based storage we can then develop this into the interface. This could be meta-tagging, Open Access, Copyright control etc which can then inform user access to these files from within Moodle.

Hello world!

April 20th, 2009 by Richard M. Davis

Welcome to This is your first post. Edit or delete it, then start blogging!