2. 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
3. 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.
4. 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
5. 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/
6. 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
8. Who is involved Consortium project UKOLN (lead) Cottage Labs University of Southampton MediaShelf Freelance staff
9. Why develop SWORD v2? Overcome limitations Fire and forget Standardized package format Enable new use cases Support for the whole deposit lifecycle
10. SWORD v2 – How does it work? Service Documents GET service documents Very similar to v1
11. SWORD v2 – How does it work? Package Deposit POST packages Very similar to v1
12. 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
13. 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
14. SWORD v2 – How does it work? What can we do with these extra URIs?
15. 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
16. 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
17. 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
18. 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)
19. 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
20. 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
