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