SWORD

More information is available from the SWORD website

In order to make repositories interoperable with each other, and with external systems, they must adhere to agreed protocols. SWORD is a common interface for depositing items into a repository.

What is SWORD?

SWORD stands for Simple Web Service Offering Repository Deposit. At its basic level SWORD allows two types of interaction with a repository:

1. Query a repository to find out what collections a user can deposit items into

2. Perform a deposit into a repository collection

Rather than implementing a wholly new standard, SWORD is a profile of the Atom Publishing Protocol (AtomPub). AtomPub is often used by blogging software to allow the remote posting of items into a blog, and also forms the basis of other well-known standards such as GData, the Google Data API.

SWORD uses AtomPub but extends it with repository-specific extensions that adapt it to make it fit with the way that we use repositories. This brings the benefit of using a widely-adopted standard, but with the specifics required by the repository domain.

How does SWORD work?

A typical SWORD deposit will take place in two steps.

1. The first step will typically require the user to provide their username and password that allows the repository software to construct a service document. The service document describes the collections into which a user may deposit items

2. Once a user has decided which collection they wish to deposit an item into, they send a file to the deposit URL of that particular collection. The repository will then ingest the item and put it through any workflows that it is set up for

Users do not interact with SWORD directly; rather they make use of a client tool, in much the same way as we interact with websites through a web browser. SWORD clients can be:

• Standalone applications integrated into web browsers

• Built in to publishers workflows to deposit items automatically into an author's institutional repository

• Incorporated into other software products such as word processors

• Included in websites such as social networking sites where a deposit could also trigger alerts being sent to colleagues alerting them to the new item

One of the benefits of using a standardised protocol such as SWORD for repository deposit is that a user is free to choose which SWORD client they use depending upon their working preferences, and an institution is free to choose which repository they implement as all clients and repositories will interoperate. A list of clients and code libraries to write your own clients are available from the SWORD website.

How can SWORD be used?

There are several scenarios where SWORD could be used:

• A desktop deposit tool: Rather than interacting directly with a repository, authors could deposit via a user-friendly desktop application

• 'Save-As' in a word processor: Authors could deposit an item directly into a repository by using a 'Save-As' plugin for their word processor that deposits the item in a repository rather than saving it to a disk

• Multiple simultaneous deposit: If a user needs to deposit their work in both an institutional and a funder's repository, they could deposit once and SWORD could be used to perform the other deposits

• Deposit by machines: Laboratory equipment might deposit experiment results into a repository without requiring human intervention

What is the difference between SWORD and AtomPub?

SWORD has added a number of extensions to AtomPub to allow it to fit in with the way repositories work. The extensions are:

1. Allowing the depositor to deposit on behalf of another user. By configuring an optional setting, the depositor can say that they are performing the deposit on behalf of another user. Only if the user has the right to deposit on behalf of that user will the deposit be accepted. This facility may be used where an agent (person or machine) is depositing for another user

2. Rather than depositing single files, SWORD allows the deposit of a package, along with a description of the package. A Package might be a zipped file of metadata and content files, such as an IMS package

3. Extra metadata such as collection policies can be described in the service document

4. There are developer-friendly extensions to request verbose output about what the server has done, and to perform 'noOp' (no operation) deposits which are only tests, and not actually ingested into the repository