Interoperability Fundamentals: SWORD 2

1,944 views

Published on

A presentation for the SUETr Interoperability Workshop, London School of Economics Library, 9th December 2008

Published in: Education, Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,944
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Interoperability Fundamentals: SWORD 2

  1. 1. UKOLN is supported by: Interoperability Fundamentals: SWORD 2 8 th December 2008 SUETr Interoperability Workshop, London School of Economics Adrian Stevenson SWORD 2 Project Manager
  2. 2. SWORD Quick Introduction <ul><li>Simple Web service Offering Repository Deposit </li></ul><ul><li>JISC funded project 2007 </li></ul><ul><li>To provide a standard mechanism for ‘doing deposit’ into repositories </li></ul><ul><li>Continuation funding for SWORD 2 from June 2008 </li></ul>
  3. 3. What is it? <ul><li>A lightweight protocol for deposit </li></ul><ul><li>A profile of the Atom Publishing Protocol </li></ul><ul><li>Implementations of the SWORD deposit interface in IntraLibrary, Fedora, DSpace and Eprints </li></ul><ul><li>A number of deposit clients – web-based, command-line, desktop, Facebook </li></ul>
  4. 4. Background <ul><li>Before SWORD there was Deposit API </li></ul><ul><li>Discussions at the JISC-CETIS Conference 2005 focussed on the lack of a deposit ‘standard’ </li></ul><ul><li>Rachel Heery and Repositories Research Team at UKOLN facilitated a working group of repository developers </li></ul><ul><li>to address this requirement for a standard interface for deposit </li></ul>
  5. 5. Motivations <ul><li>no standard interface for tagging, packaging or authoring tools to upload objects into a repository </li></ul><ul><li>no standard interface for transferring digital objects between repositories </li></ul><ul><li>no way to deposit into more than one repository with one ‘click’ </li></ul><ul><li>no way of initiating a deposit workflow from outside a repository system </li></ul>
  6. 6. The Project Partners <ul><li>SWORD partners: </li></ul><ul><ul><li>UKOLN, University of Bath and University of York (Project Management) – Adrian Stevenson & Julie Allinson </li></ul></ul><ul><ul><li>University of Aberystwyth (DSpace, Fedora, & clients) – </li></ul></ul><ul><ul><li>Stuart Lewis, Neil Taylor, Glen Robson, Richard Jones </li></ul></ul><ul><ul><li>University of Southampton (EPrints) – Les Carr </li></ul></ul><ul><ul><li>Intrallect (IntraLibrary) –Sarah Currier </li></ul></ul><ul><li>Plus some friendly advisors </li></ul><ul><ul><li>Jim Downing, Richard Green </li></ul></ul>
  7. 7. The Acronym <ul><li>Simple – lightweight, agile and fit-for-purpose </li></ul><ul><li>Web service – independent of proprietary software, supports standard interfaces </li></ul><ul><li>Offering </li></ul><ul><li>Repository – or any system which wants to put or receive content </li></ul><ul><li>Deposit – or put, or post, or register, or add – a little step in the ingest workflow </li></ul>
  8. 8. Use Cases <ul><li>Deposit from a Desktop/Online tool </li></ul><ul><li>Multiple deposit - e.g. deposit to institutional and (mandated) funders’ repository with one action </li></ul><ul><li>Machine deposit - e.g. automated deposit from a laboratory machine </li></ul><ul><li>Migration/transfer - e.g. to a preservation service </li></ul><ul><li>Mediated deposit - e.g. deposit by a nominated representative, to additional repositories </li></ul>
  9. 9. Scenario 1 : Author deposits using a desktop authoring system to a mediated multiple deposit service A lightweight deposit web service can facilitate this transfer of object(s) Librarian L completes the deposit through the repository interface id Librarian L invokes deposit of a surrogate into arxiv.org Deposit id Author A deposits via an easy-deposit desktop application into the institutional repository's mediated deposit queue
  10. 10. Scenario 3 : Deposit in multiple repositories A lightweight deposit web service can facilitate this transfer of object(s) Deposit The depositor can choose one or more repositories to deposit into A depositor is required to submit to a Research Council repository, but they also wish to deposit into their institutional repository and a relevant subject repository
  11. 11. SWORD AtomPub Profile
  12. 12. Standards <ul><li>WebDAV (http://www.webdav.org/) </li></ul><ul><li>JSR 170 (http://www.jcp.org/en/jsr/detail?id=170) </li></ul><ul><li>JSR 283 (http://www.jcp.org/en/jsr/detail?id=283) </li></ul><ul><li>SRW Update (http://www.loc.gov/standards/sru/) </li></ul><ul><li>Flickr Deposit API (http://www.flickr.com/services/api/) </li></ul><ul><li>Fedora Deposit API (http://www.fedora.info/definitions/1/0/api/) </li></ul><ul><li>OKI OSID (http://www.okiproject.org/) </li></ul><ul><li>ECL (http://ecl.iat.sfu.ca/) </li></ul><ul><li>ATOM Publishing Protocol (http://www.ietf.org/htmlcharters/atompub-charter.html) </li></ul>
  13. 13. “ the Atom Publishing Protocol is an application-level protocol for publishing and editing Web resources” <ul><li>benefits </li></ul><ul><ul><li>supports many of our parameters and requirements, in particular file deposit </li></ul></ul><ul><ul><li>it already exists and has growing support </li></ul></ul><ul><ul><li>it is well-used in popular applications </li></ul></ul><ul><ul><li>it has an extension mechanism </li></ul></ul><ul><ul><li>good fit with the Web architecture </li></ul></ul><ul><li>drawbacks / risks </li></ul><ul><ul><li>too much of a retrofit? </li></ul></ul><ul><ul><li>it is designed for a single package/file OR an atom document – this means that we need to package up metadata and files </li></ul></ul>
  14. 14. SWORD AtomPub Profile <ul><li>SWORD profile builds on AtomPub </li></ul><ul><li>Provides set of extensions, constraint relaxations and enforcements when: </li></ul><ul><ul><li>Clients post compound resources (zip,tar) </li></ul></ul><ul><ul><li>Mediated deposit required </li></ul></ul><ul><ul><li>Workflows involved </li></ul></ul><ul><li>SWORD compliance does not preclude AtomPub compliance </li></ul>
  15. 15. SWORD APP Package Support <ul><li>AtomPub uses MIME to describe resources </li></ul><ul><li>Inadequate for compound types e.g. </li></ul><ul><ul><li>Zip, tar </li></ul></ul><ul><ul><li>METS, SCORM, MPEG21, DIDL packages </li></ul></ul><ul><li>SWORD extends AtomPub: </li></ul><ul><ul><li>sword:acceptPackaging element </li></ul></ul><ul><ul><li>Value taken from SWORD package types </li></ul></ul>
  16. 16. SWORD APP Mediated Deposit <ul><li>SWORD deposit client user may not be owner of resource </li></ul><ul><li>SWORD allows clients to set a HTTP header: </li></ul><ul><ul><li>X-On-Behalf-Of </li></ul></ul><ul><li>Assumes trust between owner and mediating user </li></ul>
  17. 17. SWORD APP Developer Features <ul><li>No-Op (Dry Run) </li></ul><ul><li>Verbose Output </li></ul><ul><li>Client and Server Identity </li></ul><ul><li>Auto-Discovery </li></ul><ul><li>Error Documents </li></ul><ul><li>Nested Service Desription </li></ul>
  18. 18. SWORD APP Error Documents <ul><li>SWORD adds new class of doc to AtomPub to allow better error description </li></ul><ul><ul><li>ErrorContent </li></ul></ul><ul><ul><li>ErrorChecksumMismatch </li></ul></ul><ul><ul><li>ErrorBadRequest </li></ul></ul><ul><ul><li>TargetOwnerUnknown </li></ul></ul><ul><ul><li>MediationNotAllowed </li></ul></ul>
  19. 19. SWORD Profile of AtomPub <ul><li>Part B follows AtomPub specification highlighting where SWORD profile diverges </li></ul><ul><li>Part B covers: </li></ul><ul><ul><li>Protocol Operations </li></ul></ul><ul><ul><ul><li>Retrieving Service Document </li></ul></ul></ul><ul><ul><ul><li>Listing Collections </li></ul></ul></ul><ul><ul><ul><li>Creating a Resource </li></ul></ul></ul><ul><ul><ul><li>Editing a Resource - Not currently implemented </li></ul></ul></ul><ul><ul><li>Category Documents – MUST NOT be required </li></ul></ul><ul><ul><li>Service Documents </li></ul></ul><ul><ul><ul><li>new elements: version, verbose, noOp, maxUploadSize </li></ul></ul></ul>
  20. 20. How it Works <ul><li>APP works by issuing HTTP requests (GET, POST) </li></ul><ul><ul><li>GET Service Document (explain/discover) </li></ul></ul><ul><ul><li>POST ATOM document or file to collection URI </li></ul></ul><ul><li>HTTP response and ATOM document is returned </li></ul><ul><li>HTTP basic authentication is required </li></ul>
  21. 21. Examples – Get (explain) GET /sword-app/servicedocument HTTP/1.1 Host: www.myrepository.ac.uk X-On-Behalf-Of: lcarr
  22. 22. Examples – Post (Deposit) POST /burning-collection HTTP/1.1 Host: www.myrepository.ac.uk/sword-app Content-Type: application/zip Authorization: Basic ZGFmZnk6c2VjZJldA== Content-length: nnn Content-MD5: md5-digest Content-Disposition: filename=mydeposit.zip X-On-Behalf-Of: lcarr X-Format-Namespace: METS
  23. 23. SWORD 2 Profile Updates <ul><li>SWORD Profile Version 1.3 includes: </li></ul><ul><li>Revised deviations from AtomPub and Atom </li></ul><ul><ul><li>increasing requirement for persistent Atom Entry Documents </li></ul></ul><ul><li>Includes description of SWORD specific extensions </li></ul><ul><li>Removed notion of levels of compliance </li></ul><ul><li>Added sword:userAgent, sword:error, sword:service, sword:version and sword:maxUploadSize elements </li></ul>
  24. 24. SWORD In Use
  25. 25. Implementations <ul><li>Repository implementations </li></ul><ul><ul><li>DSpace </li></ul></ul><ul><ul><li>EPrints </li></ul></ul><ul><ul><li>IntraLibrary </li></ul></ul><ul><ul><li>Fedora </li></ul></ul><ul><li>Client implementations </li></ul><ul><ul><li>Java & PHP libraries </li></ul></ul><ul><ul><li>command-line, desktop and web clients </li></ul></ul><ul><ul><li>Facebook Client </li></ul></ul><ul><ul><li>Deposit from within MS Word & Powerpoint </li></ul></ul><ul><ul><li>Feedforward / FOREsite and others at: http://www.swordapp.org/sword/implementations </li></ul></ul>
  26. 28. Facebook Client
  27. 29. OfficeSWORD Add-on <ul><li>http://www.codeplex.com/OfficeSWORD </li></ul>
  28. 30. SWORD in use <ul><li>In addition to the case study implementations: </li></ul><ul><ul><li>Feedforward has already implemented </li></ul></ul><ul><ul><li>ICE project is looking at SWORD </li></ul></ul><ul><ul><li>DSpace and EPrints installations already exist </li></ul></ul><ul><ul><li>Microsoft eChemistry work </li></ul></ul><ul><ul><li>OAI-ORE - FOREsite work </li></ul></ul><ul><ul><li>more are planned </li></ul></ul><ul><li>NISO activity around deposit - hopefully this will recognise </li></ul><ul><li>Collaberation with Nature Publishing Group </li></ul>
  29. 31. More Info and Contact <ul><li>SWORD Website: </li></ul><ul><li>http://www.swordapp.org </li></ul><ul><li>General queries: </li></ul><ul><ul><li>Adrian Stevenson [email_address] </li></ul></ul><ul><li>Technical queries: </li></ul><ul><ul><li>Sword sourceforge list [email_address] </li></ul></ul>
  30. 32. Questions <ul><li>SWORD Website </li></ul><ul><li>http://www.swordapp.org </li></ul><ul><li>Adrian Stevenson, UKOLN </li></ul><ul><li>[email_address] </li></ul>

×