Repository usability review 3: new deposit protocols

This is one of a series of posts building towards a full paper on the use and testing of the repository deposit tools, specifically for deposit of in-progress work, developed in the JISC DepositMO project. In this post we continue and complete our review of repository usability studies, here considering repository deposit processes and protocols that increase the utility of deposit. If we have missed any relevant work that should be included, please leave a comment.

Looking forward, there have been glimpses of repository interfaces that might play a role for in-progress file deposit and management, where in-progress means as the work is written and created. Runner-up in the Developer Challenge at Open Repositories 2009 was a prototype called FedoraFS by Rebecca Koesar, who exposed Fedora as a desktop filestore using Fuse: “while only a command line prototype at this point the ease of overlaying a Graphical User Interface with file-folder icons is all but a done deal.”

At Open Repositories 2011 the same Developer Challenge was won by Repository as a Service (RaaS) based on the idea that with standard repository interfaces, to get data in and out the repository becomes a commodity that can be swapped. The entry demonstrated an Android mobile app that used SWORD to deposit photos into both DSpace and EPrints. A common interface was provided to access the items in the repository. Both EPrints and DSpace provided identical experiences because of the common interfaces.

Which brings us to SWORD (Simple Web service Offering Repository Deposit). The idea that repository deposit might be abstracted from repository software began in practice with SWORD in 2007. At the core of its proposition was, given the plethora of repositories and user interfaces, that users could choose a single interface for deposit in multiple repositories. It may thus be the single-most important development in repository user interfaces since the original repository softwares, but its impact is still more in principle than practice in terms of alternative interfaces that have attracted wide use. This may be due to a lack of interfaces, or lack of uptake, but it has not limited the number of potential use cases, as shown by Lewis, et al. (2012).

Or it could be due to limited functionality, which will be fixed by SWORD version 2, released in December 2011. We have written on this blog before about the key developments in SWORD v2, taking it from a ‘fire and forget’ deposit method that is limited in terms of what authors can do with their content after depositing in a repository, to a model where authors retain more control over their content and items can be created, updated, replaced, or deleted (CRUD) in the repository. SWORD v2 is the basis of DepositMO’s vision for in-progress deposit.

SWORD builds on AtomPub, the Atom Publishing Protocol. Many may be more familiar with Atom in the form of an RSS-like syndication protocol; AtomPub is the flip side, about pushing content into a dissemination resource rather than its receipt by readers (Snell 2006). SWORD 2.0 continues to build on AtomPub through the inclusion of the CRUD operations of AtomPub to enable the following kinds of interactions, described by the SWORD 2.0 Profile:

1. Clients may create resources by sending compound resources, such as archive files (tar, zip).
2. Workflows which may or may not include manual stages before deposited resources become available as web resources, are acknowledged and supported
3. Clients may update or delete the compound resources or associated metadata

In the progression to profile 2.0, SWORD becomes more explicitly a deposit lifecycle standard: “Most of the enhancements in SWORD 2.0 are around closing the deposit loop. This deposit process is only a portion of the full content lifecycle and does not attempt to provide support for collaborative or distributed authoring environments or policy management; it is focused entirely on the process of moving content from one location to another.”

During consultation over the new profile the adoption of more powerful publication protocols was advocated, but these have not so far been included, leaving the profile specification to note: “For standards to integrate detailed content management operations it is recommended to look at OASIS CMIS (Organization for the Advancement of Structured Information Standards – Content Management Interoperability Services), or the Google Documents (GData) List API.” It was this aim of bringing more powerful content management features to repositories that led to the DepositMO extensions using the platform and flexibility that SWORDv2 created with reference to these other publication protocols.

A similar publishing protocol connecting content-producing tools and repositories for learning resources and metadata is the Simple Publishing Interface (SPI), which also uses AtomPub. The main difference between SWORD and SPI, according to Ternier, et al. (2010), is in the submission of metadata. “In SWORD, metadata is available in a package and thus submitted to the repository as a part of the resource. In contrast, the SPI model makes a clear distinction between metadata and content at submission time. The rationale for this strict separation comes from the SPI application domain. Where SWORD is primarily concerned with depositing data, SPI is also intended for application scenarios where only metadata is considered.”

We have presented in this series of three posts a sweeping review of practical work on the usability of repository interfaces, most notably the deposit interface. Broadly these studies have found little wrong with current ‘fire and forget’ deposit interfaces while in some cases making adjustments for the structure and volume of metadata collected at deposit. Detailed and critical evidence on whether deposit interfaces make a substantive difference to levels of deposit, however, is hard to find. If we are to move towards more sophisticated Web 2.0-like interfaces for repositories, providing more interaction with authors using new protocols such as SWORD v2 to capture work at an earlier stage of creation, then users and usability will have to become much more central to repository testing.

This concludes our three-part review of repository usability focussing on user deposit. The next post will start to report the results of user testing of the repository deposit tools developed in DepositMO.