DepositMO has contributed to reducing the distance between users and content held in digital repositories. In a world where people are ‘always connected’, the Internet is now being used to both store data as well as transfer it. Content stored ‘online’ can be accessed from any device, such as smartphones, and from desktop applications. ‘Disks’ are disappearing in favour of constantly connected clouds of data. Although the physical distance to the data bits increases, for the user, because their content is available on any ‘connected’ device, the distance to their content is simply that to the nearest connected device.

The repository is one item in this connected cloud and must provide the same types of services. The SWORDv2 and DepositMO extensions replicate much of the functionality of the proprietary web interfaces of repository systems and allow control to be decoupled from the content storage. This decoupling is the key enabler to reducing the distance between content and users.

During the course of the project, two platforms – EPrints and DSpace - were enabled with SWORDv2 and DepositMO extensions, and two clients developed (Watch Folder and the Word Add-in). The Watch Folder client was developed as a result of comments about services not reflecting the usability of Dropbox “Drag Drop Share”. Watch Folder was developed as a demonstration that this type of client could be implemented on top of the SWORDv2 and DepositMO protocols. The initial feedback was positive, but it is not DropBox, and the client still needs some polishing. The protocol is in place, however, and would support a more fully-fledged client.

Since the implementation on EPrints, two developments which utilise both protocols have been undertaken for customers by EPrints Services, a repository services provider: one to harvest tweets into a repository, and the other to automatically manage internal and external repositories of the same items. Significantly, both took less than a week to develop (combined!), demonstrating the understandability of not only the specification documents but also the implementations against the repository platform.

DepositMO set out to enable a conversation between a user and a repository. Unlike generic data storage, a repository is able to provide specific services to a user. Through creating a conversation with the repository it is envisaged that an environment can be created in which the repository is providing added value to the user. Within the project this conversation allows distributed item curation and continued editing. Essentially all this boils down to making users’ lives easier and making these services appeal to new users. Why click 20 buttons and fill in three forms when you can just click one button?

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!

Content Management Systems (CMSs) should allow a number of basic functions to be carried out by a user, and digital repositories are no exception. Historically, such repositories have provided pretty web-based, human-focused interfaces through which users can manually perform the tasks of creating and publishing resources. With the development of SWORD, the creation and management of resources became something which, in part, could be carried out using an automated, machine-based client.

In SWORD version 1, this process was focused on making the operation of publishing a completed resource simpler. Further interaction (including retrieval of the same object) was not defined as a requirement. Thus this first specification, while useful, fell short of being a complete CMS system.

It was the intention of SWORDv2 and the DepositMO project to address these shortcomings. In addition, a DepositMO implementation of SWORDv2, the DepositMO profile, extends the functionality of SWORDv2 using a number of the as yet unused parts of the protocols SWORDv2 is based on – AtomPub and HTTP.

This post describes the features SWORDv2 provides to turn repositories into full CMSs, and details two extensions implemented in the DepositMO profile. While the DepositMO profile is a technical document, here we show how the extensions support two particular use cases, and how the DepositMO-developed deposit clients exploit SWORDv2 and the extensions.

Extending repositories as full content management systems

Figure 1 shows some of the basic operations that need to be supported by a digital repository-based CMS system.

Discover: The ability to provide simple description services which allow the client to choose the best method for deposit. Additionally, a client should be able to discover existing resources in the repository, thus skipping Create directly to Update.

Create: Provides a way for a client to create a resource  - a publication object – in the repository. It is this object that is then populated with relevant content.

Update: By making the repository a workspace, content should also be changeable.

Publish: Provide users with a way of describing an object as being suitable for publishing, making it public.

Retrieve: A critical aspect of any CMS system, a user must be able to retrieve their own content.

Delete: Similar to update, a user may be able to delete any resources they own. This is not always the case in digital repositories due to the ties of such systems with the classic publication model (a physical printed copy is hard to ‘delete’).

Use cases for DepositMO extensions to SWORDv2

As well as playing a key role in developing SWORDv2, the DepositMO specification details two key extensions to the SWORDv2 specification:

1. A user/client must be able to retrieve a list of their content regardless of the status of that content (edit, review, published, etc.).
2. A client must be able to obtain basic information about individual objects such that distributed copies can be kept synchronised and up to date.

To demonstrate the importance of these aspects consider the following two use cases:

• A user creates a formal paper which on completion is deposited and published in a repository for a conference. At the conference the author gives a presentation to accompany this submission. Logically this presentation should also accompany the publication already in the repository. Using the DepositMO discovery specification, the presentation software can list all the resources already in the repository and the user can “attach” the presentation as a complementary resource.
• A user is working on a publication for a conference, but wants to work both at home and at work without having to carry around a laptop or a USB memory stick, which will get lost just like half  a pair of socks. By using the repository as a workspace, two clients can maintain synchronisation of the same resource. To save download and comparing the document, which might be of substantial size, a DepositMO extension can be used to check the state of the object without having to download it.

As part of the DepositMO project two clients were produced – a Microsoft Word Add-in client, and a Watch Folder drag-and-drop deposit tool that works with file managers on standard PCs – to demonstrate the principles of these use cases. Although neither the most complete or prettiest clients, they do demonstrate the power of the two combined DepositMO extensions to the SWORDv2 specifications.

DropBox-style repository resource control – Watch Folder client

DropBox is easy. You drag stuff in, it is shared, simple. The barrier to entry for such services is low, meaning that people use them for convenience and uptake is high.

During the DepositMO project, questions were asked about how digital repositories, a trusted authority, could keep up with such technologies. This led to the development within DepositMO of a DropBox-style client for a digital repository.

Called “Watch Folder”, this client enables a user to create a folder, representing their resource, in a standard file manager on a personal computer, and then to add objects that are part of this resource to this folder.

As an example, the repository could contain a collection of images (the objects) relating to a single art exhibition (the resource, folder). As each object is copied into the folder it is simultaneously uploaded to the repository. View and edit links also appear as files on the desktop, connecting the user directly with the corresponding object in the digital repository.

As with DropBox, if an object is deleted or updated via either the repository or desktop interface then this change is instantly reflected in both locations. This functionality is not possible without the DepositMO extensions to the SWORDv2 specification.

The Watch Folder client demonstrates the ideal simplicity of a SWORDv2/DepositMO client to the user.

Windows application integration – Word add-in client

The second client produced as part of the DepositMO project integrates Microsoft Word with a digital repository. Although not a new concept – a similar client was produced by Microsoft to conform with the SWORDv1 specification – the DepositMO version integrates the complete CMS functionality as detailed by the SWORDv2 and DepositMO specifications.

From the start the Windows development separated the low-level driver from application integration. In this way the driver connects the application to the SWORDv2/DepositMO server via an easy-to-use API. This has the beneficial side-effect that the same driver can be used by many applications, saving substantial amounts of time when developing further clients.

The Microsoft Word add-in adds a new tab to the menu “ribbon” in Office 2010. Using this tab a user can set up their credentials with the repository, which can then be used to create and edit resources. Again, the user remains connected to their content whether on the local machine or in the repository.

Future of the DepositMO profile of SWORDv2

The DepositMO profile complements the SWORDv2 specification in order to provide more advanced functionality to deposit clients. For now the DepositMO specification remains an extension to SWORDv2, albeit one that is already integrated into the core of the latest EPrints and DSpace softwares, as will be revealed in the next two posts here. It would not be a huge leap to include the two simple DepositMO extensions in a future SWORDv2 specification, as without them many simple operations are just not possible.

Deliverables

The following software deliverables are proposed:

D0. Interaction Specification: At the core of the project as required by all subsequent development, this deliverable will define the method for interaction between the client and server components required to build deposit directly into authors’ everyday workflows. Here clients are those defined by D1 (MS Office) and D4 (Operating Systems) and the servers are those consuming the content defined in D2 (EPrints and DSpace). A common and extensible specification is required to allow all of these softwares to interoperate. The development of this specification will be a beta after 4 months followed by an enhanced specification towards the end of the project.

D1. Office – Repository Conversation Addin: Allowing extended metadata, document components and multiple formats to be packaged into a single SWORD deposit. This is the desktop client side of the protocol. Three phases consist of scoping, developing and enhancing. See deliverable D2 for the matching repository server component.

D2(a/b). Repository Conversation Plugin: the repository software components that allow additional metadata and file formats to be requested for a SWORD package to interface with D1.

D3. Office Media Licensing Addin: similar to “Insert Picture”, except it takes CC images from Flickr / Google or purchased images directly from iStockPhoto. Also annotates all media (e.g. images pasted from Web Browser) with explicit provenance/rights management metadata.

D4. Desktop integration. This deliverable is similar to D1 except that the interaction is done directly with the operating system rather than office. Full interactivity should be available without the limitation of the office platform. Windows, MAC and Linux (Ubuntu) operating systems are in scope

D5. Repository Virtual File System: this deliverable has been dropped from the workplan.

The following training deliverables are proposed:

D6. Deskside coaching kit (DSC) consisting of technical training resources, academic how‐to materials and support and problem-solving documentation.

D7. Virtual kit (VDSC) consisting of web tutorials, short video walkthroughs, wiki supported by project team.

The following community activities are proposed:

D8. Researcher community workshops for archaeology, chemistry, materials science and educators.

D9. OfficeSWORD community building via Codeplex and DepositMO websites, and dev8D Code Dojo and Developer Challenge (2011).

The following reports are proposed, that include evaluation results:

D10. Analysis of culture change at Southampton / Edinburgh

D11. Analysis of culture change for discipline researchers

Deliverables D1, D3 and D4 are independent of the repository platform and will assume a primarily Windows/Office desktop environment due to the time restrictions of the project. Deliverable D2 is dependent on repository platform, and will be coded for both DSpace and EPrints.

Deliverable D9 will focus on building sustainable community of OfficeSWORD developers, in collaboration with Microsoft.