update on the sword protocol & future directions
TRANSCRIPT
<sword />
Let’s start at the beginning…
• What is SWORD?– Simple Web-service Offering Repository Deposit
– In essence…. a standardised deposit mechanism
<sword />
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
<sword />
Later on that year…
• November 2006– JISC call for funding• Examples of ideas included repository interfaces,
specifically the Deposit API
<sword />
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
<sword />
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)
<sword />
The Project
• Workpackage 2: Technical development– Repository implementations• DSpace• EPrints• Fedora• intraLibrary
– Client implementations• Java client library
– Command-line, desktop application & web interfaces
<sword />
The Project
• Workpackage 3: User testing and feedback– Four case studies commissioned• arXiv• SOURCE• SPECTRa• White Rose Research Online
• FeedForward
<sword />
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
<sword />
GET a Service Document
• HTTP ‘GET’– X-On-Behalf-Of header
• Example:
GET /app/servicedocument HTTP/1.1Host: repository.example.comX-On-Behalf-Of: [email protected]
<sword />
GET a Service Document<?xml version="1.0" encoding='utf-8'?><service xmlns="http://www.w3.org/2007/app" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sword="http://purl.org/net/sword/" xmlns:dcterms="http://purl.org/dc/terms/"><sword:level>1</sword:level><sword:verbose>true</sword:verbose><sword:noOp>true</sword:noOp><workspace>
<atom:title>Main Site</atom:title><collection href="http://www.myrepository.ac.uk/geography-
collection" > <atom:title>My Repository : Geography
Collection</atom:title><accept>application/xml</accept>
<accept>application/zip</accept><sword:collectionPolicy>Collection
Policy</sword:collectionPolicy><dcterms:abstract>Collection
description</dcterms:abstract><sword:mediation>true</sword:mediation><sword:treatment>treatment
description</sword:treatment></collection>
</workspace>
<sword />
POST an item
• HTTP POST
• Example:
POST /geography-collection HTTP/1.1Host: www.myrepository.ac.ukContent-Type: application/zipAuthorization: Basic ZGFmZnk6c2VjZXJldA== Content-Length: nnnX-On-Behalf-Of: [email protected]
...binary data...
<sword />
SWORD extensions to APP
• SWORD level– 0• APP plus the support for <sword:level>
– 1• APP plus
– <sword:collectionPolicy>– <dcterms:abstract>– <sword:formatNamespace> / X-Format-Namespace– <sword:treatment> <sword:mediation>– X-On-Behalf-Of– Content-Disposition
<sword />
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
<sword />
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 <head> of a logical high-level page (home page or similar) which points to the location of their sword implementation(s), e.g. <link rel="sword" href="/sword-app/servicedocument"/>
<sword />
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
<sword />
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
<sword />
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?