Where the SWORDv1 specification allowed resources to be Created in a repository, SWORDv2 has focussed on adding Retrieve, Update and Delete functions, thus providing full CRUD support. DepositMO focussed on use cases requiring extra functionality beyond basic CRUD but which could still use standard, already available specifications.

With DepositMO and SWORD v2 projects running in parallel this provided a set of clear requirements to enable complete interactive control of repository resources via a set of abstracted interfaces. By building upon existing, well developed and widely implemented standards (including HTTP and AtomPub), both projects utilise these standards to enhance digital repositories.

As both projects essentially outline the ideal RESTful implementation for discovery and control of resources in a digital repository, the specifications of the SWORDv2 and DepositMO projects have been integrated into the core of EPrints (v3.3). As a result, the RESTful interface to EPrints is as powerful and flexible as the built-in web interface, providing the following features:

1. All first-class objects can be managed via the REST interface. All EPrints, Documents, Files, Users and anything else identifiable by a URI can be created, updated and deleted via the REST interface.

2. All import plug-ins are now generic and can be utilised via the REST interface, doubling the number of supported package formats which can be deposited via SWORD. Additional plug-ins, which can be installed in a single click, are also available via the EPrints Bazaar app store.

3. The same permissions model is applied both via the SWORD/REST interface as via the normal EPrints interface. The permissions system provides a granular model via which users can be granted permissions based on item status, item type and even an individual item itself. Basically, if editing is possible via the web interface, then it is possible via SWORD.

4. The SWORDv2 specification supports the notion of “in-progress” items, so it has been possible to reduce the number of SWORD deposit endpoints in EPrints to ONE. This has many benefits:

• This endpoint represents a user’s deposits (or repository contents), closely aligning it with the Google Docs implementation and extensions of the AtomPub specification on which SWORDv2 is based.
• SWORD clients are easier to write.
• The user requires less context about which “collection” their content belongs to – it belongs to their collection.

In EPrints, the collection in which an item belongs is represented as a piece of metadata, a significant difference from DSpace. Rather than managing and connecting with several collections, a user can deposit and discover all of their resources via ONE URI, which is the same URI for every user (typically http://myrepo.org/contents). While the SWORDv2 specification outlines how this URI can be used for deposit, DepositMO mandates that a client should also be able to perform the inverse operation and request a complete list of deposit contents via this same URI, regardless of the status of the object.

4. A unique identifier (in the form of a URI) is assigned to every object (including EPrints, Documents, Files, Users etc…) as soon as it is created regardless of the stage in the workflow. This URI will NEVER be reused or overwritten, and can thus be used to reference an object throughout its entire lifecycle in the repository.

5. All URIs support all REST operations: PUT/POST, HEAD, GET and DELETE. The DepositMO profile of SWORDv2 adds the requirement that each URI must accept a HTTP HEAD request. Using this HEAD request, a client is able to request information about an object, such as last changed date, without needing to download the whole object to find this out. This enables each object to be synchronised with a local copy, allowing two-way update with clients that are keeping a local up-to-date copy, an important requirement in distributed systems.

6. All URIs can be content negotiated, meaning that you can get an RDF/XML, Atom, csv… serialisation of every object in the repository. These plug-ins are the inverse of the import plug-ins, so not only can you ingest items in any format, you can also export them in that same format. Again further plug-ins can be installed in one click from the EPrints Bazaar.

In summary, SWORDv2 and DepositMO on EPrints represents a major leap forward in repository flexibility. By utilising the built-in power of the EPrints identifiers, permissions model and Bazaar Store for plug-ins (all of which have been key parts of the EPrints 3.3 development), the HTTP CRUD interface supports SWORDv2 and DepositMO specifications as core functionality, replicating the functionality available via the web interface. This gives users the power to interact fully with their repository and content via an interface or client which suits their way of working, in their environment!

SWORDv2 officially began in late 2010, and DepositMO started at around the same time, alongside a number of other JISC deposit related projects including DURA and RePosit. When SWORDv2 set up the Technical Advisory Panel in early 2011, representatives from these projects were invited to join to share their deposit scenarios and technical expertise. Of the 3 projects, DepositMO was by far the most closely aligned to the goals of SWORDv2 and also the most technical project.

The SWORDv2 mission was to support the full range of CRUD (Create, Retrieve (Read), Update, Delete) operations for scholarly systems, and to maintain the use-cases which had driven SWORDv1, including mediated deposit and most importantly of all Packaging. DepositMO, meanwhile, was focussing on desktop-to-repository deposit and two-way synchronisation.

This meant that DepositMO would need to take full advantage of the CRUD protocol operations offered by SWORD, although both mediated deposit and packaging were not so relevant. The project would therefore be a valuable resource for a number of critical aspects of SWORDv2:

• A sounding board for core profile developments: DepositMO had a vested interest in the CRUD protocol operations and had explicitly no interest in the packaging aspects. This meant that the protocol operations would go through thorough review while the need for every packaging related concept would be questioned as to its necessity. As such, the SWORDv2 profile received extensive and sustained review throughout the project which has hardened it against many counter-arguments.
• A testing base for software development: DepositMO is being implemented against DSpace and EPrints, as is SWORDv2. Since it was clear from the outset that DepositMO is providing some extensions to SWORDv2, the majority of the codebase for both systems is the same. Extensions to SWORDv2 have been developed for both repositories by the project though. This means that not only has the core software been through some important testing, but its capacity to be extended has also been examined.
• Representation of a critical use case: the desktop-to-repository use case is one of the most under-developed in our community, so it was very interesting to have a project focussing on it to represent that use case throughout discussions. With services such as Dropbox and Ubuntu-One becoming common, the deposit applications developed by DepositMO will no doubt be an important demonstrator as to the way academics will interact with repositories in the future.

In addition to the base operations provided by SWORDv2, the DepositMO project has also specified the following extensions:

• That Collections be able to list their content items which belong to the authenticated user.
• That individual files behave RESTfully and in line with the rest of the SWORDv2 specification. This means that replace and delete operations can be carried out on the individual files in an object.

The SWORDv2 project therefore considers it to be a realistic possibility that a SWORD 2.1 specification may be produced in the future incorporating the DepositMO extensions in addition to any suitable extensions from other projects using the protocol.