update on the sword protocol & future directions

21
Update on the SWORD Protocol & Future Directions <sword />

Upload: ramiro-edling

Post on 14-Dec-2015

215 views

Category:

Documents


0 download

TRANSCRIPT

Update on the SWORD Protocol & Future Directions

<sword />

<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 />

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 />

Authentication

• Only one authentication method required:– HTTP BASIC

<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?

<sword />

The future…?

• SWORD 2– A follow-on project funded by JISC