DepositMO for DSpace

DepositMO for DSpace is implemented as an extension to the standard SWORDv2 module implemented as part of the SWORD project. It provides additional features to list the items in a DSpace Collection, and to support a full range of CRUD (create, retrieve, update, delete) operations on individual files. The base SWORDv2 implementation recommends support for these kinds of operations, and provides documentation to aid development, but they are not part of the profile as a whole.

The current release of DSpace is version 1.8, and SWORDv2 is a part of that release. As such, the DepositMO extensions to DSpace have also been rolled into the release (with the exception of the packagers, discussed below). This is a significant development, as it means that new DSpace installations will be able to support the DepositMO extensions “out of the box”, which will be in-line with the EPrints support.

There are a number of notable features of the DSpace implementation which may differ from the EPrints experience:

1. DSpace has a full hierarchical collection structure (called Communities and Collections) which EPrints does not. As such, DSpace Service Documents at least list all of the DSpace Collections as deposit endpoints, but can further offer a full hierarchy of Service Documents containing nested endpoints some of which do not accept deposits but which have sub-collections which do. The consequence of this is that the desktop tools have to be configured with the deposit endpoint of the Collection to which the user will actually be depositing content. There is no option for the user to select an endpoint at deposit-time, and adding such an option would no doubt bring unacceptable complexity in the user experience. Instead the desktop tools must be pre-configured, making them as simple to use as the EPrints version, but at the cost of a less well categorised repository holding. This issue is well known in the DSpace community, and it is therefore not a significant problem.
2. DSpace’s permissions model is relatively complex and there are known issues with providing the end-user with the appropriate rights to modify their own content via remote APIs under various circumstances. For this reason, the prototyping done for DepositMO utilises relatively privileged users for the demonstration. A real production implementation would have a more carefully crafted user model in DSpace.
3. DSpace’s collections represent actual collections of content, while EPrints only has a single collection in SWORDv2 which represents the user’s Inbox. This means that all operations in EPrints work only on items which are in the user’s inbox. Since the connection between SWORD Collection and the user’s workspace in DSpace does not exist, the DepositMO extensions have been constructed to ensure that all the content being worked on remains in the user’s workspace to mimic the EPrints implementation. This is actually the ideal implementation, as significant complexity and the need for versioning multiply rapidly once users can modify content which has left the workspace and entered either the review workflow or the archive itself.
4. DSpace does not provide stable identifiers for objects until they have reached the “archive” itself: items in the workspace or workflow do not have public or even linkable URLs. Since DepositMO requires such URLs to direct users to their repository content, and that content is necessarily in the workspace (see point 3) this presents a problem. To circumvent this problem we have extended the SWORDv2 implementation in DSpace to provide URLs which do resolve to the item in the workspace for both of the application’s web interfaces (JSPUI and XMLUI). The user can therefore follow a link from their desktop to their working item (via a login screen). This feature only works for items in the workspace, as items in the workflow are not directly accessible to the submitting user. This means that the DepositMO desktop client cannot simply remember the identifier for the item on initial deposit, but must regularly check for updates, in case the identifier has changed.

In addition to these developments, the DSpace implementation of DepositMO also provides two Packagers. These are plugins to DSpace which implement SWORD’s ingestion interface and can be brought to bear on incoming content types. As part of the project basic XIF and DocX ingesters were written (utilising pre-existing code contributions by other DSpace developers), and made available open source. These packagers, due to their basic nature, have not been included in the DSpace 1.8 release, but are available separately here.

Overall, the implementation of the DepositMO extensions has been a very natural extension to the SWORDv2 implementation, and will no doubt be valuable to future users of the interface.