Update on the SWORD Protocol & Future Directions

Let’s start at the beginning… What is SWORD? – Simple Web-service Offering Repository Deposit – In essence…. a standardised deposit mechanism

Some history… End of 2005: JISC/CETIS conference, repositories themed workshop – Identified lack of standard deposit API as #1 issue 2006: creation of Repository Deposit working group – 2 meetings in 2006 – Feb + July 2006 – Also ‘Augmenting interoperability across scholarly repositories’ New York, April 2006

Later on that year… November 2006 – JISC call for funding Examples of ideas included repository interfaces, specifically the Deposit API

Later on that year… November 2006 – Bid submitted for SWORD Project Partners: – Project managed by Julie Allinson (UKOLN) – CASIS at Aberystwyth University (DSpace / Fedora / Clients) – Southampton (EPrints) – Intrallect (intraLibrary) – Members of the Deposit API group Proposed a lightweight and agile project

The Project Workpackage 1: Standards and Protocol – Evaluate existing standards WebDAV JSR OKI OSID ECL SRW Update SPI Google Data API ATOM Publishing Protocol (APP)

The Project Workpackage 2: Technical development – Repository implementations DSpace EPrints Fedora intraLibrary – Client implementations Java client library – Command-line, desktop application & web interfaces

The Project Workpackage 3: User testing and feedback – Four case studies commissioned arXiv SOURCE SPECTRa White Rose Research Online FeedForward

How does SWORD work? Two stages – Discover Where can I deposit? What are the policies of the Collections into which I can deposit? GET a Service Document – Deposit Deposit an item POST an item to the URI of the Collection

GET a Service Document HTTP ‘GET’ – X-On-Behalf-Of header Example: GET /app/servicedocument HTTP/1.1 Host: repository.example.com X-On-Behalf-Of:

GET a Service Document 1 true Main Site My Repository : Geography Collection application/xml application/zip Collection Policy Collection description true treatment description

POST an item HTTP POST Example: POST /geography-collection HTTP/1.1 Host: Content-Type: application/zip Authorization: Basic ZGFmZnk6c2VjZXJldA== Content-Length: nnn X-On-Behalf-Of: data...

SWORD extensions to APP SWORD level – 0 APP plus the support for – 1 APP plus – – / X-Format-Namespace – – X-On-Behalf-Of – Content-Disposition

SWORD extensions to APP X-On-Behalf-Of – Depositing on behalf of another user X-Verbose – Request a verbose response X-No-Op – Do not actually perform the deposit X-Format-Namespace – The namespace of the format being used in the deposit

Discovering SWORD interfaces SWORD RECOMMENDS that the APP implementation is accessed from /sword-app SWORD RECOMMENDS that the service document is accessed from /sword-app/servicedocument SWORD RECOMMENDS that where repositories support a public SWORD interface they should embed a HTML link element within the of a logical high-level page (home page or similar) which points to the location of their sword implementation(s), e.g.

Authentication Only one authentication method required: – HTTP BASIC

Use cases 1) Deposit from a desktop tool – Desktop ‘smart’ deposit client E.g. FeedForward client Drag and drop functionality – Deposit from within an application E.g. Word processor

Use cases 2) Machine deposit – Laboratory equipment depositing results 3) Multiple simultaneous deposit – Deposit into institutional and subject repositories 4) Moving / copying items – A deposit interface for migration tools

What can be deposited? Packages – Any package supported by the repository DSpace / EPrints: ZIP files with a METS manifest file in SWAP format, with files Fedora: Image files / METS documents (pull in referenced datastreams) intraLibrary: IMS content packages OAI-ORE resource maps? – No required packaging format Perhaps a weakness?

The future…? SWORD 2 – A follow-on project funded by JISC