SWORD v2.0: Deposit Lifecycle

Table of Contents
There are 77 comments in this document

Introduction (8)
The Key Limitations of SWORD (14)
Impact (4)
Identifiers (10)
Manifest (24)
Overview (2)
Extending the Specification (2)
Manifest Serialisation (4)
State Description (3)
Example Implementation (2)
Conclusions (4)
References (0)
Contact Details (0)

SWORD is a hugely successful JISC project which has kindled repository
interoperability and built a community around the software and the problem space. It
explicitly deals only with creating new repository resources by package deposit ­ a
simple case which is at the root of its success but also its key limitation. This next
version of SWORD will push the standard towards supporting full repository deposit
lifecycles by using update, retrieve and delete extensions to the specification. This will
enable the repository to be integrated into a broader range of systems in the scholarly
environment, by supporting an increased range of behaviours and use cases.

The document can be downloaded here (PDF)

Author / SWORD v2.0 Release Technical Lead: Richard Jones, Symplectic Ltd
Funded By: UKOLN, JISC
Acknowledgements: Jim Downing, David Flanders, Graham Klyne, Stuart Lewis, Adrian
Stevenson, Paul Walk

SWORD [1] has, since its inception in 2007, become a very high profile JISC [2] project which has had a huge impact on the repository community. It was set up to tackle the problem of how to allow repositories to interoperate, and how to enable them to be embedded into other information systems. This is not an insignificant challenge, and SWORD chose to tackle it by concerning itself with the simplest possible use case that was still of value: the deposit of a package of content, both files and […]

1. External systems have to do some of the work of a repository Because SWORD requires that deposits are fully pre­prepared bundles of content and metadata before they can be deposited in the repository, a burden is placed on the client system: that they are able to store and manage structured files and metadata prior to deposit in the repository. Since repositories are designed precisely to store and manage structured files and metadata, this is duplication of effort. There is a strong argume […]

The advantages of alleviating or removing the above limitations would be huge. It would make it easier to integrate the repository into other systems, both user­facing and administrative, by providing a coherent and fully functional content storage and retrieval ser vice. It would give repositories and repository managers the opportunities to access content earlier in its lifecycle, and to engage more readily in the archiving and publishing aspects of the repository’s mission. It would also m […]

The SWORD deposit receipt currently provisions the following identifiers [SWORD spec section B.9.6], with the associated possible interpretations: An atom:content element which provides the URI to one of: The splash page for the repository item; A machine readable description of the repository item; The originally deposited package; Some combination of (i) and (ii) (for example, RDFa embedded in a splash page); Some other identifier, u […]

The other major addition that we propose for SWORD is the content which lies under the “manifest” link. The following information may be of use to rich deposit clients to enhance the user experience: 1. The state of the item in the repository Most repositories, at a high level, have 3 states that items are likely to be in (based on analysis of DSpace, EPrints and Fedora software): In preparation: this typically lasts a short while, and is the state that new repository items begin li […]

Figure 1: An overview of the additions for the SWORD 2.0 specification

Among the outputs of the SWORD 3 project is a new proposed specification which, among other things, improved on the previous version by breaking it down into several smaller distinct specifications: Extensions to ATOM and AtomPub Extensions to HTTP Packaging An application profile which demonstrates how to orchestrate these independent specifications (including HTTP and AtomPub) into the full SWORD standard. The advancements suggested in this paper are also specified in th […]

It is suggested that the default manifest is based upon OAI-ORE [18], and its RDF serialisations [19]. This standard was developed to enable the description of web based complex digital objects, and is therefore well suited to describing the structure of repository objects in a way which is compatible with the ethos of SWORD. In fact, some repositories have already implemented some form of support for this standard either as embedded RDFa in web pages or in explicit publication of ORE Resourc […]

So what should happen when the client de-references the resource in the sword:state-description element? To remain in keeping with SWORD, it’s recommended that this is an Atom Entry document with particular emphasis on the atom:title and atom:summary elements to convey the appropriate information. The advantage of this is that due to the extensible nature of Atom, if it becomes apparent that this state description could benefit from including further information this will be trivial to inc […]

Much of the work which has led up to this paper has been carried out at Symplectic [21] while implementing a full CRUD (Create, Retrieve, Update, Delete) API against a number of digital repositories using AtomPub with SWORD extensions [22]. The objective of this work was to integrate their publications management system (Symplectic Elements [23]) into a variety of digital repositories, to allow the provision of a rich deposit client which integrated smoothly with the researcher’s day-to-d […]

This next version of SWORD is about giving the client the tools that it needs to give users a rich and compelling experience. It aims to introduce aspects which provide the client with a more certain understanding of what the repository has done with the content, with well defined identifiers allowing for follow-up action which improves the interactivity of the repository. This paper has described the two major developments that the SWORD 4 project plans to undertake: To add stric […]

[1] SWORD: Home page: http://www.swordapp.org/ ; Specification: http://www.swordapp.org/sword/specifications [2] JISC: http://www.jisc.ac.uk/ [3] DSpace: http://www.dspace.org/ [4] EPrints: http://www.eprints.org/ [5] Fedora: http://www.fedoracommons.info/ [6] arXiv.org: http://arxiv.org/ [7] Microsoft Zentity: http://research.microsoft.com/en-us/projects/zentity/ [8] Intrallect IntraLibrary http://www.intrallect.com [9] Facebook SWORD App by Stuart Lewi […]

Technical Discussion List: https://lists.sourceforge.net/lists/listinfo/sword-app-tech Project Manager: Adrian Stevenson, UKOLN, [email protected] Author: Richard Jones, Symplectic Ltd, [email protected] Further Contact Details: http://www.swordapp.org/contact-us