SWORD parameters

From DigiRepWiki

SWORD Home | SWORD Wiki | SWORD Project Background

Contents 1 Overview 2 Deposit 3 Explain 4 Receipt

Overview

This brainstorm document makes the following assumptions:

• Level 0: the repository will support all mandatory parameters
• Level 1: Repository can configure it’s response to support optional parameters.

• Mandatory = Level 0
• Mandatory + Optional = Level 1

• Description = human-readable text and/or url
• Extensions in other namespaces must be accepted but may be ignored (e.g. for additional parameters not supported by SWORD).

Deposit

• Content:binary CDATA (M) any type of content, constrained only by what a repository supports
• Format (O) ID-recommended URI - this is over and above the mime-type over http, enables a repository to reject objects
  • does this need a vocabulary of format types?;
  • possible formats: zip, mets, ims cp, mpeg didl, ead etc.
  • gdfr/pronom
• TransactionID (O) client-generated identifier for the process; if supplied, repository should return it in the response
• TargetCollection (O)
  • implementation detail: how is this target specified, by url or by parameter
• Verbose true||false (O)
• NoOp true||false (O) facility to test protocol without actually posting
• Checksum (O) checksum for the deposit
• ChecksumAlgorithm (O) md5 as default
• TargetOwner (O) identity of user on behalf of whom the deposit is being made, by a mediated human user or machine user agent

Explain

ExplainRequest

• onBehalfOf TargetUser

how will authentication affect the ExplainRequest? how much is dependent on the authenticated and/or target user?

ExplainResponse:

Wrapper:

• ServerLevel 0||1 1=support all mandatory and optional elements
• Version 0.1

Response:

Repository:

• ID (M)
• Policy (O) description, cdata or url
• VerboseSupported true||false (O) for developers - verbose response for a human being for testing/programming
• NoOpSupported true||false (O) for developers, facility to 'simulate' put
• ChecksumAlgorithmSupported default=none [string]
• MediationAllowed true||false

Collections (O) recommended authorised collections only

• ID (O)
• Name (O)
• Description (O)
• Default true||false
• DescribeFormat (O) list additional format(s) (1..n), need vocabularly for formats - if no formats are listed, the repository may accept anything, retaining the option to reject deposits
  • FormatID (O)
  • FormatDescription (O)
• TreatmentDescription (O) human-readable description of what the repository will do with a deposit, e.g. will it maintain the exact SIP as deposited
• CollectionPolicy (O) [description, cdata or url]

Receipt

Wrapper:

• ServerLevel 0||1
• Version 0.1

Receipt:

• TransactionID (O) client-generated identifier for the process
• IdentifierURI (M) unique identifier for the ingested digital object, may not persist, but it should persist if the ingested object is accepted
  • ObjectURL (O) a locator for the digital object or package
  • DisplayURL (O) a locator for the splash page, jump-off page, metadata record etc.; may not yet resolve to the right thing, e.g. for pending records

• DepositStatus (M)
  • Accepted (M)
  • Rejected (M)
  • Error (M)
• ErrorCode (M)
  • ErrorContent (O)
  • ErrorParse (O)
  • ErrorChecksumMismatch (O) required if a checksum is sent
  • ErrorUnknownChecksumAlgorithm (O) required if a checksum is sent
  • ErrorBadRequest (M) where parameters are not understood
  • TargetUserUnknown (M)
  • MediationNotAllowed (M)
• ErrorDescription (M)
• TreatmentDescription (M) what the repository has done or may have done with a deposit, e.g. policy applied - can be very simplistic
• FormatHandled (O)
  • ID 0..n (O)
• VerboseDescription (O)
• NoOp true||false (O)
• Checksum (O)
• ChecksumType (O) default=MD5