SWORD Simple Web-service Offering

Repository Deposit

Julie Allinson

25th March 2009, British Library

SWORD Quick Introduction

Vision: “lowering barriers to deposit” Simple Web service Offering Repository

Deposit Aims to provide a standard mechanism for

‘doing deposit’ into repositories JISC funded project started 2007,

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 SWORD in IntraLibrary,

Fedora, DSpace and Eprints repositories SWORD clients – web-based, desktop, MS

Office plugin, Facebook, widgets

Motivations – why?

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, Seb Francois

Intrallect (IntraLibrary) – Sarah Currier, Andrew Robson, Martin Morrey

Jim Downing – standards development

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

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

A lightweight deposit web service can facilitate this transfer of object(s)

Scenario 1

DepositThe depositor can

choose one or more repositories to deposit into

A lightweight deposit web service can facilitate this transfer of object(s)

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

Scenario 2

SWORD AtomPub Profile

Standards

WebDAV (http://www.webdav.org/) JSR 170 (http://www.jcp.org/en/jsr/detail?id=170) JSR 283 (http://www.jcp.org/en/jsr/detail?id=283) SRW Update (http://www.loc.gov/standards/sru/) Flickr Deposit API (http://www.flickr.com/services/api/) Fedora Deposit API

(http://www.fedora.info/definitions/1/0/api/) OKI OSID (http://www.okiproject.org/) ECL (http://ecl.iat.sfu.ca/) ATOM Publishing Protocol

(http://www.ietf.org/htmlcharters/atompub-charter.html)

AtomPub

“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 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 SWORD supports accepting MIME types, but

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 Developing area

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

Future development could explore OAuth for creating trust relationships

More Features

No-Op (Dry Run) Verbose Output Client and Server Identity Auto-Discovery Error Documents Nested Service Description

SWORD APP Error Documents

SWORD adds new class of document to AtomPub to allow better error description ErrorContent ErrorChecksumMismatch ErrorBadRequest TargetOwnerUnknown MediationNotAllowed

SWORD Profile of AtomPub

Protocol Operations Retrieving Service Document Listing Collections Creating a Resource Editing/Deleting resource – not part of SWORD, optional

Service Documents new elements: version, verbose, noOp, maxUploadSize,

collectionPolicy, mediation, treatment, acceptPackaging, service

increasing requirement for persistent Atom Entry Documents

How it Works

Issue HTTP requests (GET, POST) from client to SWORD interface GET Service Document (explain/discover) POST ATOM document or file/package to

collection URI

HTTP response and ATOM document is returned

HTTP basic authentication should be supported

SWORD In Use

Implementations

Repository implementations DSpace EPrints IntraLibrary Fedora

Client implementations command-line, desktop and web clients Facebook Client Deposit from within MS Word & Powerpoint Feedforward / FOREsite and others

Java, PHP and .NET libraries

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 Collaberation with Nature Publishing Group possible York – funded project around SWORD

More Info and Contact

SWORD Website: http://www.swordapp.org General queries:

Adrian Stevensona.stevenson@ukoln.ac.uk

Technical queries: sword sourceforge list

sword-app-tech@lists.sourceforge.net

OAI-OREObject Re-use and Exchange

Julie Allinson

25th March 2009, British Library

ORE background

commenced October 2006 stands for ‘Object Reuse and Exchange’ falls in the remit of the Open Archives Initiative

(creators of OAI-PMH) funded by the Mellon Foundation, with support from

the National Science Foundation in the U.S. international focus and lots of interest a 2 year project, not the answer to all our problems ended September 2008

ORE Results

Primer – in heavy use for the presentation! User Guides

Resource Map implementation in ATOM, RDF/XML, RDFa, HTTP

Resource Map Discovery

Specifications – Abstract Model and Vocabulary

Tools and additional resources

Key terminology for ORE

Aggregations Web architecture – resource, URI,

representation, link Resource Maps Linked Data / Semantic Web RDF ATOM Serialization

ORE in one sentence

“ORE is a serialization format for describing aggregations of Web resources”

(according to me)

Relationship to OAI-PMH

OAI-ORE is NOT a replacement for OAI-PMH

OAI-PMH will continue to exist as one approach to interoperability OAI-PMH metadata-centric

OAI-ORE will complement with richer functionality, when this is desirable OAI-ORE is resource centric

An example

The ForeSite toolkit “Libraries for constructing, parsing,

manipulating and serializing OAI-ORE Resource Maps”

Demonstrator created Resource Maps of journals in JSTOR, delivered as ATOM documents via SWORD DSpace interface

That’s it.