DepositMO Profile

1. Introduction
2. Notational Conventions
3. Terminology
4. Protocol Operations
  4.1. Retrieving a List of Deposited Items
  4.2. Ensuring a local and remote resource are in sync
5. References


DepositMO Technical Lead: David Tarrant, University of Southampton

DepositMO Project Manager: Steve Hitchcock, University of Southampton

DepositMO Technical Advisory Group
Richard Jones, Cottage Labs
Tim Brody, University of Southampton
David Flanders, JISC
Mark MacGillivray, Cottage Labs
Ian Stuart, University of Edinburgh

Further acknowledgements of input
Tim Donohue (DuraSpace), Peter Sefton (University Of Southern Queensland), Robin Taylor (Edina)

1. Introduction

The SWORD 2.0 [SWORD 2.0] Protocol extends the Atom Publishing Protocol [AtomPub] and provides a simple mechanism to manage resources in a repository or SWORD 2.0 server.

The SWORD 2.0 profile continues to build upon AtomPub and HTTP ([RFC2616]) through the inclusion of the Create, Retrieve, Update and Delete (CRUD) operations of AtomPub, in order to enable the following kinds of interactions:

The JISC DepositMO Project (changing the Modus Operandi for Repository Deposit) extensions outlined in this document are designed to extend and be complementary to the SWORD 2.0 specification, to enable features such as resource discovery and synchronisation. These will allow the following kinds of interaction:

With the deposit life cycle encompassing more than just a "fire and forget" of resources it is important to empower users with the ability to synchronize and discover resources already deposited in a repository and track their status, edit content and allow downloading onto many platforms.

2. Notational Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. Terminology

No specific terminology is used in this specification however users may wish to refer to the SWORD 2.0 [SWORD 2.0] and Atom Publishing specification [AtomPub] for further details on possible IRIs mentioned throughout.

4. Protocol Operations

While specific HTTP status codes are used below, a client should be prepared to handle any status code as per the HTTP status code definitions [RFC2616]

4.1. Retrieving a List of Deposited Items

  1. The client sends a GET request to a SWORD endpoint within the repository.
  2. The server responds with list of the resources that the requesting user owns.

The requirements placed on the client are:

Authorization: Basic ZGFmZnk6c2VjZXJldA==
Accept: application/atom+xml;type=feed

The requirements placed on the server here are:

4.2 Ensuring a local and remote resource are in sync

As each resource was deposited the server will have returned an IRI to the client. By being able to query these IRIs for changes to the relevant objects the client can keep synchronised with any changes which are happening beyond its control.

  1. The client performs a HEAD operation on an IRI about which it knows information.
  2. The server responds with equivalent information about this object.

Client Requirements

Head IRI HTTP/1.1
Authorization: Basic ZGFmZnk6c2VjZXJldA==

HTTP/1.1 200 OK
Date: Wed, 17 Mar 2004 18:00:49 GMT
Last-Modified: Wed, 25 Feb 2004 22:37:23 GMT
ETag: "1450013-6514-e905eec0"
Accept-Ranges: bytes
Content-Length: 25876
Content-Type: text/plain

Server Requirements:

5. References

[AtomPub] Gregario, J. and B. de hOra, "The Atom Publishing Protocol", RFC 5023, October 2007. (see also non-normative html version at

[RFC2616] Fielding et al, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999

[SWORD 2.0] Jones, R. "SWORD 2.0 Profile", 2011.