module 6 - introducing sword v2
TRANSCRIPT
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/