SWORD APP evaluation

SWORD Parameter

APP / ATOM

Possible extensions

Notes / questions

ExplainRequest

     GET to Service Document

-

?conditional GET to return a particular set of information in the service document? (e.g. related to authentication)

--onBehalfOf TargetUser

no

is it possible to include this in a GET? where does authentication fit in here?

ExplainResponse

Service Document

-

-Wrapper

<app:service>

-

--ServerLevel

no

<sword:level>0|1

--Version

no

-

not required if using APP

-Repository

<workspace>

-

workspace = repository

--ID (M)

<atom:title>

<dc:identifier> or <baseURL> (http://www.openarchives.org/OAI/2.0/provenance.xsd)

<atom:title> is mandatory in atom (human-readable name for the workspace); <app:workspace> can be extended, <dc:identifier> or <baseURL> from the oai-pmh provenance schema could be used to identify the repository if necessary.

--Policy

no

<dcterms:accrualPolicy>

<app:workspace> could be extended with <dcterms:accrualPolicy> with text and/or URI for a policy statement.

--VerboseSupported

no

<sword:verboseSupport>true|false

--NoOpSupported

no

<sword:noOpSupport>true|false

--ChecksumTypeSupported

no

<sword:checksumType>true|false

Recommend MD5?

--MediationAllowed true||false

no

<sword:mediation>true|false

-Collections

<app:collection>

--ID

<app:collection href”atomURI”>

Collection URI is captured as an attribute of the <app:collection> element and is mandatory; is this enough? An additional <dc:identifier> could be created as an extension if necessary.

--Name

<atom:title>

<atom:title> is mandatory in atom

--Description

no

<dcterms:abstract>

<app:collection> could be extended with a <dcterms:abstract> element

--Default

no

<sword:defaultCollection>true|false

Presence of one collection could indicate default? Is an extension necessary?

--DescribeFormat

<accept>

<sword:format>

Specifies a comma-separated list of media-ranges; is this enough, do we need a vocabulary of formats and an element extension to <app:collection>? Do we need to distinguish between different xml documents (didl, mods, ims etc.)

---FormatID

media type

<dc:format> (with vocab)

as mime media type only

---FormatDescription

No

<sword:formatDescription>

possible extension to allow more detailed description/identification of accepted formats, see note about; could extend this to support namespace and schema (see oai-pmh)

--TreatmentDescription

no

<sword:treatment>

--CollectionPolicy

no

<dcterms:accrualPolicy>

<app:collection> could be extended with <dcterms:accrualPolicy> with text and/or URI for a policy statement.

Deposit

     POST to URI of Collection

--TargetCollection

Collection URI

--Format

Content-Type in POST; <atom:content type=””>

<dc:format> (using vocab)

mime media type in either case; <atom:content> can also contain the content (e.g. xml); if extending with <sword:format> elements, some kind of description of what a zip file might be useful?

--TransactionID

<atom:id>

There is some confusion between <atom> and <app> regarding the <atom:id>. Atom defines is as 'permanent universally unique identifier for an entry or feed'; whereas APP states that 'The Entry created and returned by the Collection might not match the Entry POSTed by the client. A server MAY change the values of various elements in the Entry, such as the atom:id, atom:updated and atom:author values' – this requires some clarification in the SWORD profile.

--Verbose

no

<sword:verbose>true|false

--NoOp

no

<sword:noOp>true|false

--Checksum

no

<sword:checksum>

Or use content-MD5 http header value?

--ChecksumType

no

<sword:checksumType>

Recommend MD5?

--TargetOwner

<atom:author>

Possible foaf extensions for a username (for both author and contributor)

atom:contributor could be used for depositor; with atom:author for the target 'owner' (will this always be the 'author'? Can we assume/profile our use of author/contributor in this way); or might extend this with dcterms:mediator?

Receipt

HTTP Response:

201 Created

Location: Member Entry URI

-Wrapper

No

not used; response would be a HTTP response

--ServiceLevel 0||1

no

is this necessary here?

--Version

no

not necessary if using APP

-Receipt

Atom Entry

--TransactionID

<atom:id>

See notes above about confusion wrt <atom:id>

--IdentifierURI (M)

Location: (MemberURI) in response

In app, the URI of the Media Link Entry is mandatory in the response (as Location:)

---ObjectURL

<link rel=”edit-media” href=””>

<atom:content type=”” src””>

URI for the media resource; these do not have to be the same.

---DisplayURL

<link rel=”edit” href=””> (MemberURI)

URI for the Media Link Entry

--DepositStatus (M)

http status codes returned in the response

---Accepted

201 Created

202 Accepted could be used for cases where there will be a delay in processing

---Rejected

415 Unsupported Media Type

---Error

http 4xx or 5xx codes (see below)

--ErrorCode

4xx or 5xx codes

Do we need to specify sword-specific error codes returned as xml (see oai-pmh), or are those returned in http responses sufficient?

---ErrorContent

404 Not Found

For cases where the server cannot access the material to be deposited

---ErrorParse

no

Is this necessary?

---ErrorChecksumMismatch

no

Could this be included in the atom entry? would there be an atom entry if the deposit had failed? If content-MD5 http header was used, how would a mismatch be identified

---ErrorUnknownChecksumType

no

see above

---ErrorBadRequest

400 Bad Request

---ErrorTargetUserUnknown

401 Unauthorised or 407 Proxy Authorisation Required

---ErrorMediationNotAllowed

403 Forbidden

--ErrorDescription (M)

yes

--TreatmentDescription (M)

no

<sword:treatment>

--FormatHandled

content-type (in <atom:entry> and response)

<dc:format> (from vocab)

--VerboseDescription

No

<dc:description>

--NoOp true||false

no

<sword:noOp>true|false

--Checksum

no

<sword:checksum>

--ChecksumType

no

<sword:checksumType>

Do we need to support multiple checksum types, or is MD5 enough?