Interoperability Fundamentals: SWORD 2
Upcoming SlideShare
Loading in...5

Interoperability Fundamentals: SWORD 2



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

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



Total Views
Views on SlideShare
Embed Views



1 Embed 1 1


Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Interoperability Fundamentals: SWORD 2 Interoperability Fundamentals: SWORD 2 Presentation Transcript

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