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)
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.
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].
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.
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]
The requirements placed on the client are:
GET Col-IRI HTTP/1.1 Host: example.org Authorization: Basic ZGFmZnk6c2VjZXJldA== Accept: application/atom+xml;type=feed
The requirements placed on the server here are:
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.
Head IRI HTTP/1.1 Host: example.org 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
[AtomPub] Gregario, J. and B. de hOra, "The Atom Publishing Protocol", RFC 5023, October 2007. http://www.ietf.org/rfc/rfc5023.txt (see also non-normative html version at http://bitworking.org/projects/atom/rfc5023.html)
[RFC2616] Fielding et al, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999 http://www.w3.org/Protocols/rfc2616/rfc2616.html
[SWORD 2.0] Jones, R. "SWORD 2.0 Profile", 2011. http://sword-app.svn.sourceforge.net/viewvc/sword-app/spec/trunk/SWORDProfile.html