The SWORD Course

Module6 Introducing

SWORD v2

Module objectives

• By the end of this module you will:– Appreciate the limitations of SWORD v1– Know about this history of SWORD v2– Understand how SWORD v2 works– Have a knowledge of the extra use cases

supported by SWORD v2

SWORD v1

• SWORD v1 was designed to be a:– Simple– Web-service– Offering– Repository– Deposit

• This was at the heart of its success, but the root of its limitations.

SWORD v1

• SWORD v1 supports– ‘Fire and forget’

• Perform a deposit, but no way to interact with it subsequently– Modify / Replace / Augment / Delete

• No standardized packaging format

The history of SWORD v2

• SWORD project wrote a discussion paper proposing SWORD v2

• Paper outlined what needed to be added• Paper circulated at OR10 in Madrid for

comment via open commenting system– http://sword2depositlifecycle.jiscpress.org/

The history of SWORD v2

• Proposal for funding submitted to JISC– Employ a Technical Lead and Community Manager– Gather community requirements– Form a Technical Advisory Panel– Write SWORD v2 standard– Employ repository and client developers– Develop draft specification– Finalize specification

SWORD v2 implementations

• SWORD v2 project funded:– Repositories:• DSpace• EPrints• Fedora

– Clients:• Java• PHP• Ruby (+ BibApp)• Python

Who is involved

• Consortium project– UKOLN (lead)– Cottage Labs– University of Southampton– MediaShelf– Freelance staff

Why develop SWORD v2?

• Overcome limitations– Fire and forget– Standardized package format

• Enable new use cases– Support for the whole deposit lifecycle

SWORD v2 – How does it work?

• Service Documents– GET service documents– Very similar to v1

SWORD v2 – How does it work?

• Package Deposit– POST packages– Very similar to v1

SWORD v2 – How does it work?

• Two other methods of (standardized) deposit:– POST Atom Entry• Deposits metadata

– POST Multipart deposit• Atom Entry + file

– Same method as used for email + attachment

SWORD v2 – How does it work?

• The deposit receipt:– An Atom entry– Contains some further URLs:• EDIT-URI / EDIT-IRI• EDIT-MEDIA-URI / EM-IRI• STATEMENT-URI / STATE-IRI• CONTENT-URI / CONT-IRI• SWORD-EDIT-URI / SE-IRI

SWORD v2 – How does it work?

• What can we do with these extra URIs?

SWORD v2 – How does it work?

• What can we do with these extra URIs?– GET on the Edit-URI• Retrieve back a copy of the Deposit Receipt

– GET on the Content-URI / Edit Media-URI• Retrieve a copy of the content as a package• Can request different packaging formats if supported

SWORD v2 – How does it work?

• What can we do with these extra URIs?– PUT on the Edit Media-URI• Replace the file content

– PUT on the Edit-URI• Replace the file and metadata via a package

– Or

• Replace the metadata via an Atom entry

SWORD v2 – How does it work?

• What can we do with these extra URIs?– POST to the Edit Media-URI• Add an extra content file

– POST to the SWORD Edit-URI• Add extra file and metadata via a package

– Or

• Add extra file an metadata via multipart deposit– Or

• Add extra metadata via an Atom entry

SWORD v2 – How does it work?

• What can we do with these extra URIs?– DELETE on the Edit Media-URI• Delete the content of the item (not the item)

– DELETE on the Edit-URI• Delete the container (the item)

SWORD v2 – How does it work?

• A few other bells and whistles:– In-Progress header:• Consider the deposit ‘in progress’, for completion later

– Deposit statement• Describes the structure and the state of the deposit• Serialized as Atom or OAI-ORE documents

Credits

• This course has been produced by:– Stuart Lewis and Richard Jones

• The SWORD project– http://swordapp.org/

• Funded by JISC– http://www.jisc.ac.uk/

• Licence– Creative commons

Photo Credits• Lecture hall: http://www.flickr.com/photos/iamthebestartist/2008790/