Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
branch: master
Fetching contributors…

Cannot retrieve contributors at this time

2535 lines (2007 sloc) 148.482 kb
<html>
<head>
<title>SWORD 2.0 Profile</title>
<style type="text/css">
body {
font-family: sans-serif;
font-size: 12pt;
}
.toc {
font-size: 10pt;
}
.code {
font-family: monospace;
background: #ffffaa;
padding-left: 15px;
padding-right: 15px;
padding-top: 5px;
padding-bottom: 5px;
margin-top: 5px;
margin-bottom: 5px;
font-size: 10pt;
}
.code_inline {
font-family: monospace;
background: #ffffaa;
padding-right: 5px;
padding-left: 5px;
padding-top: 3px;
padding-bottom: 3px;
font-size: 10pt;
}
</style>
</head>
<body>
<h1>SWORD 2.0 Profile</h1>
<table cellspacing="20" class="toc">
<tr><td valign="top">
<strong><a href="#introduction">1. Introduction</a><br/></strong>
<strong><a href="#notationalconventions">2. Notational Conventions</a></strong><br/>
<strong><a href="#terminology">3. Terminology</a></strong><br/>
<strong><a href="#namespaces">4. Namespaces</a></strong><br/>
&nbsp;&nbsp;<a href="#namespaces_sword">4.1. SWORD Namespaces</a><br/>
&nbsp;&nbsp;<a href="#namespaces_referenced">4.2. Referenced Namespaces</a><br/>
<strong><a href="#iris">5. IRIs</a></strong><br/>
<strong><a href="#protocoloperations">6. Protocol Operations</a></strong><br/>
&nbsp;&nbsp;<a href="#protocoloperations_retreivingservicedocument">6.1. Retrieving a Service Document</a><br/>
&nbsp;&nbsp;<a href="#protocoloperations_listingcollections">6.2. Listing Collections</a><br/>
&nbsp;&nbsp;<a href="#protocoloperations_creatingresource">6.3. Creating a Resource</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#protocoloperations_creatingresource_binary">6.3.1. Creating a Resource with a Binary File Deposit</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#protocoloperations_creatingresource_multipart">6.3.2. Creating a Resource with a Multipart Deposit</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#protocoloperations_creatingresource_entry">6.3.3. Creating a Resource with an Atom Entry</a><br/>
&nbsp;&nbsp;<a href="#protocoloperations_retrievingcontent">6.4. Retrieving the content</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#protocoloperations_retrievingcontent_feed">6.4.1. Atom Feed Representations of Media Resources</a><br/>
&nbsp;&nbsp;<a href="#protocoloperations_editingcontent">6.5. Replacing the Content of a Resource</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#protocoloperations_editingcontent_binary">6.5.1. Replacing the File Content of a Resource</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#protocoloperations_editingcontent_metadata">6.5.2. Replacing the Metadata of a Resource</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#protocoloperations_editingcontent_multipart">6.5.3. Replacing the Metadata and File Content of a Resource</a><br/>
&nbsp;&nbsp;<a href="#protocoloperations_deletingcontent">6.6. Deleting the Content of a Resource</a><br/>
&nbsp;&nbsp;<a href="#protocoloperations_addingcontent">6.7. Adding Content to a Resource</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#protocoloperations_addingcontent_mediaresource">6.7.1. Adding Content to the Media Resource</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#protocoloperations_addingcontent_metadata">6.7.2. Adding New Metadata to a Container</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#protocoloperations_addingcontent_multipart">6.7.3. Adding New Metadata and Packages or Files to a Resource with Multipart</a><br/>
&nbsp;&nbsp;<a href="#protocoloperations_deleteconteiner">6.8. Deleting the Container</a><br/>
&nbsp;&nbsp;<a href="#protocoloperations_statement">6.9. Retrieving the Statement</a><br/>
&nbsp;&nbsp;<a href="#protocoloperations_swordactionableiris">6.10. SWORD Actionable IRIs</a><br/>
&nbsp;&nbsp;<a href="#protocoloperations_arbitrary">6.11. Use of SWORD with arbitrary IRIs</a><br/>
<strong><a href="#packaging">7. Packaging</a></strong><br/>
&nbsp;&nbsp;<a href="#packaging_servicedescription">7.1. Package support in Service description</a><br/>
&nbsp;&nbsp;<a href="#packaging_creation">7.2. Package support during resource creation</a><br/>
&nbsp;&nbsp;<a href="#packaging_entrydocuments">7.3. Package description in Entry documents</a><br/>
&nbsp;&nbsp;<a href="#packaging_negotiation">7.4. Negotiating for package formats</a><br/>
</td><td valign="top">
<strong><a href="#authenticationmediateddeposit">8. Authentication and Mediated Deposit</a></strong><br/>
&nbsp;&nbsp;<a href="#authenticationmediateddeposit_servicedescription">8.1. Mediation In Service Description</a><br/>
&nbsp;&nbsp;<a href="#authenticatedmediateddeposit_recordingusers">8.2. Recording Depositing Users</a><br/>
<strong><a href="#continueddeposit">9. Continued Deposit</a></strong><br/>
&nbsp;&nbsp;<a href="#continueddeposit_complete">9.1. Deposit Complete</a><br/>
&nbsp;&nbsp;<a href="#continueddeposit_incomplete">9.2. Deposit Incomplete</a><br/>
&nbsp;&nbsp;<a href="#continueddeposit_complete">9.3. Completing a Previously Incomplete Deposit</a><br/>
<strong><a href="#depositreceipt">10. Deposit Receipt</a></strong><br/>
<strong><a href="#statement">11. The SWORD Statement</a></strong><br/>
&nbsp;&nbsp;<a href="#statement_predicates">11.1. Predicates used by the Statement</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#statement_predicates_originaldeposit">11.1.1. sword:originalDeposit</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#statement_predicates_state">11.1.2. sword:state</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#statement_predicates_packaging">11.1.3. sword:packaging</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#statement_predicates_depositedon">11.1.4. sword:depositedOn</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#statement_predicates_depositedby">11.1.5. sword:depositedBy</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#statement_predicates_obo">11.1.6. sword:depositedOnBehalfOf</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#statement_predicates_description">11.1.7. sword:stateDescription</a><br/>
&nbsp;&nbsp;<a href="#statement_requirements">11.2. Statement Requirements</a><br/>
&nbsp;&nbsp;<a href="#statement_oaiore">11.3. OAI-ORE Serialisation</a><br/>
&nbsp;&nbsp;<a href="#statement_atom">11.4. Atom Serialisation</a><br/>
<strong><a href="#errordocuments">12. Error Documents</a></strong><br/>
&nbsp;&nbsp;<a href="#errordocuments_uris">12.1. Error URIs</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#errordocuments_uris_content">12.1.1. sword:ErrorContent</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#errordocuments_uris_checksum">12.1.2. sword:ErrorChecksumMismatch</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#errordocuments_uris_badrequest">12.1.3. sword:ErrorBadRequest</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#errordocuments_uris_unknown">12.1.4. sword:TargetOwnerUnknown</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#errordocuments_uris_mediation">12.1.5. sword:MediationNotAllowed</a><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#errordocuments_uris_notallowed">12.1.6. sword:MethodNotAllowed</a><br/>
&nbsp;&nbsp;<a href="#errordocuments_example">12.2. Error Document Example</a><br/>
<strong><a href="#autodiscovery">13. Auto-Discovery</a></strong><br/>
&nbsp;&nbsp;<a href="#autodiscovery_servicedocuments">13.1. For Service Documents</a><br/>
&nbsp;&nbsp;<a href="#autodiscovery_deposit">13.2. For Deposit Endpoints</a><br/>
&nbsp;&nbsp;<a href="#autodiscovery_resources">13.3. For Resources</a><br/>
<strong><a href="#references">14. References</a></strong>
</td></tr></table>
<h2>Credits</h2>
<p>
<strong>SWORD 2.0 Technical Lead</strong>: Richard Jones, Cottage Labs
</p>
<p>
<strong>SWORD 2.0 Community Manager</strong>: Stuart Lewis, University of Auckland
</p>
<p>
<strong>SWORD 2.0 Technical Advisory Group</strong><br/>
Julie Allinson, University of York<br/>
Tim Brody, University of Southampton<br/>
David Flanders, JISC<br/>
Graham Klyne, University of Oxford<br/>
Alister Miles, University of Oxford<br/>
Ben O'Steen, Cottage Labs<br/>
Mark MacGillivray, Cottage Labs<br/>
Rob Sanderson, LANL<br/>
Nick Sheppard, Leeds Metropolitan University<br/>
Eddie Shin, MediaShelf<br/>
Ian Stuart, University of Edinburgh<br/>
Ed Summers, Library of Congress<br/>
David Tarrant, University of Southampton<br/>
Graham Triggs, BioMed Central<br/>
Scott Wilson, University of Bolton<br/>
</p>
<p>
<strong>Further acknowledgements of input</strong><br/>
Aaron Birkland (Cornell University), Tim Donohue (DuraSpace), Jim Downing (University of Cambridge), Ross Gardler (OSS Watch), Steve Midgley (US Department of Education), Glen Robson (National Library of Wales), Peter Sefton (University Of Southern Queensland), Adrian Stevenson (UKOLN), Paul Walk (UKOLN), Nigel Ward (University of Queensland)
</p>
<h2><a name="introduction">1. Introduction</a></h2>
<p>
The Atom Publishing Protocol ([<a href="#atompub">AtomPub</a>]) provides a simple, extensible mechanism for the creation of Web Resources.
The first major version of SWORD [<a href="#sword13">SWORD 1.3</a>] built upon the Resouce creation aspects of AtomPub to enable package deposit onto a server.
</p>
<p>
This approach of fire-and-forget deposit, where the depositor has no further interaction with the server is of significant value in certain use cases, but there are others where this is insufficient. Consider, for example, that the depositor wishes to construct a digital artifact file by file over a period of time before deciding that it is time to archive it. In these cases, a higher level of interactivity between the participating systems is required, and this is the role that SWORD 2.0 is intended to fulfil.
</p>
<p>
The SWORD 2.0 profile continues to build upon AtomPub and HTTP ([<a href="#rfc2616">RFC2616</a>]) through the inclusion of the Create, Retrieve, Update and Delete (CRUD) operations of AtomPub, in order to enable the following kinds of interactions:
</p>
<ul>
<li>Clients may create resources by sending compound resources, such as archive files (tar, zip).</li>
<li>Both non-interactive and 3rd party mediated operation are required.</li>
<li>Workflows which may or may not include manual stages before deposited resources become available as web resources, are acknowledged and supported</li>
<li>Clients may update or delete the compound resources or associated metadata</li>
</ul>
<p>
The role that SWORD aims to fulfil is that of a thin integration layer between any two scholarly systems aiming to exchange content, but not to provide tight integration between them. For standards to integrate detailed content management operations it is recommended to look at OASIS CMIS [<a href="#cmis">CMIS</a>], or the GData API [<a href="#gdata">GData</a>]. In contrast to these, SWORD is a deposit lifecycle standard, which supports the users and the participating systems in effectively exchanging content. Most of the enhancements in SWORD 2.0 over SWORD 1.3 are around closing the deposit loop to give the client software the opportunity to provider a richer environment to the user.
</p>
<p>
The scope of SWORD v2 will be limited to the deposit process between any two scholarly systems or between a user facing system and a service provider. This deposit process is only a portion of the full content lifecycle and does not attempt to provide support for collaborative or distributed authoring environments or policy management; it is focused entirely on the process of moving content from one location to another.
</p>
<p>
The deposit lifecycle encompasses the process of delivering content to a SWORD server which may have an ingest workflow in place. The content that has been deposited is then considered to be in the deposit process for the duration of that ingest workflow, during which time the client system may wish to interact with the submission. It may be that the client needs to make changes to the submission during the workflow process, either autonomously or when prompted for additional input by the server. Or it may be that the client wants to track the progress of the submission, at its leisure. Eventually the content will be formally accepted into the system and the client needs a way to know that this is happened and a route to follow to locate the deposited content.
</p>
<p>
The practical details of the extensions used in the SWORD Profile are provided in the following Internet Drafts:
</p>
<ol>
<li>Packaged Content Delivery over HTTP [<a href="#sword001">SWORD001</a>]</li>
<li>AtomPub Extensions for Packaged Content [<a href="#sword002">SWORD002</a>]</li>
<li>AtomPub Extensions for Scholarly Systems [<a href="#sword003">SWORD003</a>]</li>
<li>Atom Multipart Extensions for Packaged Content [<a href="#sword004">SWORD004</a>]</li>
</ol>
<h2><a name="notationalconventions">2. Notational Conventions</a></h2>
<p>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [<a href="#rfc2119">RFC2119</a>].
</p>
<h2><a name="terminology">3. Terminology</a></h2>
<p>
Throughout this document we will regularly refer to identifiers which are used by SWORD. The following IRIs are part of the specification:
</p>
<dl>
<dt><strong>SD-IRI</strong></dt>
<dd>The <strong>Service Document IRI</strong>. This is the IRI from which the root service document can be located. If the server supports nesting of service documents, then these sub-service documents are also subject to the same rules as <strong>SD-IRI</strong> and should be considered the same.</dd>
<dt><strong>Col-IRI</strong></dt>
<dd>The IRI of a <strong>SWORD Collection</strong>. This is the IRI to which the initial deposit will take place, and which are listed in the <strong>Service Document</strong>.</dd>
<dt><strong>Cont-IRI</strong><dt>
<dd>The <strong>Content IRI</strong>. This is the IRI from which the client will be able to retrieve representations of the object as it resides in the SWORD server (which representation is returned will be through package format negotiation, as discussed later).</dd>
<dt><strong>EM-IRI</strong></dt>
<dd>The <strong>Atom Edit Media IRI</strong>. This is almost always going to be the same as the <strong>Cont-IRI</strong>, but the Atom spec requires that these identifiers be allowed to differ [<a href="#atompub">AtomPub</a>]. Throughout this document we will mostly refer to the <strong>EM-IRI</strong>. An important thing to note about the <strong>EM-IRI</strong> and the <strong>Cont-IRI</strong> is that they do not refer to the resource as deposited by the client (e.g. the original zip), but to all the content stored in the item on the server, and the format that this IRI returns is obtained by content negotiation. This will be discussed in more detail in <a href="#depositreceipt">Section 10. Deposit Receipt</a>.</dd>
<dt><strong>Edit-IRI</strong></dt>
<dd>The <strong>Atom Entry Edit IRI</strong>. This is the IRI of the Atom Entry of the object, and therefore also of the container within the SWORD server.</dd>
<dt><strong>SE-IRI</strong></dt>
<dd>The <strong>SWORD Edit IRI</strong>. This is the IRI to which clients may POST additional content to an Atom Entry Resource. This MAY be the same as the <strong>Edit-IRI</strong>, but is defined separately as it supports HTTP POST explicitly while the <strong>Edit-IRI</strong> is defined by [<a href="#atompub">AtomPub</a>] as limited to GET, PUT and DELETE operations.</dd>
<dt><strong>State-IRI</strong></dt>
<dd>The <strong>SWORD Statement IRI</strong>. This is one of the IRIs which can be used to retrieve a description of the object from the sword server, including the structure of the object and its state. This may be the same as the IRI used for content management operations that the server implements beyond the behaviours defined by SWORD. See <a href="#statement">Setion 11: The SWORD Statement</a> for more details.</dd>
</dl>
<p>
Note that although there are 7 IRIs defined above, only 2 of them are added by SWORD: <strong>State-IRI</strong> and <strong>SE-IRI</strong>, the rest are replicated from [<a href="#atompub">AtomPub</a>] and are labelled here for convenience. Furthermore, the <strong>SE-IRI</strong> MAY be the same as the <strong>Edit-IRI</strong>. Meanwhile the <strong>EM-IRI</strong> may be the same as the <strong>Cont-IRI</strong>, so implementers can implement the entire specification with only 5 differentiable IRIs.
</p>
<h2><a name="namespaces">4. Namespaces</a></h2>
<h3><a name="namespaces_sword">4.1. SWORD Namespaces</a></h3>
<p>
All SWORD extensions are defined within the namespace:
</p>
<div class="code">
http://purl.org/net/sword/
</div>
<p>
Beneath this URI, we use the following extensions for the various parts of the standard:
</p>
<p>
For all predicates associated with SWORD:
</p>
<div class="code">
http://purl.org/net/sword/terms/
</div>
<p>
This document uses the prefix <strong>sword</strong> for this namespace name; for example <strong>sword:originalDeposit</strong>
</p>
<p>
Root registry for any SWORD recognised package formats including "zip" and "binary":
</p>
<div class="code">
http://purl.org/net/sword/package/
</div>
<p>
Root namespace for any Error documents which SWORD can produce:
</p>
<div class="code">
http://purl.org/net/sword/error/
</div>
<p>
Root namespace for any State terms that SWORD wishes to provide:
</p>
<div class="code">
http://purl.org/net/sword/state/
</div>
<h3><a name="namespaces_referenced">4.2. Referenced Namespaces</a></h3>
<p>
The AtomPub [<a href="#atompub">AtomPub</a>] namespace is:
</p>
<div class="code">
http://www.w3.org/2007/app
</div>
<p>
This document uses the prefix <strong>app</strong> for the namespace name; for example <strong>app:collection</strong>.
</p>
<p>
The Atom Syndication Format [<a href="#atom">Atom</a>] namespace is:
</p>
<div class="code">
http://www.w3.org/2005/Atom
</div>
<p>
This document uses the prefix <strong>atom</strong> for the namespace name; for example <strong>atom:feed</strong>
</p>
<p>
The DCMI Terms [<a href="#dublincore">DublinCore</a>] namespace is:
</p>
<div class="code">
http://purl.org/dc/terms/
</div>
<p>
This document uses the prefix <strong>dcterms</strong> for the namespace name; for example <strong>dcterms:title</strong>
</p>
<p>
The RDF [<a href="#rdf">RDF</a>] namespace is:
</p>
<div class="code">
http://www.w3.org/1999/02/22-rdf-syntax-ns#
</div>
<p>
This document uses the prefix <strong>rdf</strong> for the namespace name; for example <strong>rdf:Description</strong>
</p>
<p>
The OAI-ORE [<a href="#oaiore">OAIORE</a>] namespace is:
</p>
<div class="code">
http://www.openarchives.org/ore/terms/
</div>
<p>
This document uses the prefix <strong>ore</strong> for the namespace name; for example <strong>ore:aggregates</strong>
</p>
<h2><a name="iris">5. IRIs</a></h2>
<p>
The packaging format which represents a binary file which should not be unpacked by the server
</p>
<div class="code">
http://purl.org/net/sword/package/Binary
</div>
<p>
The primitive SWORD packaging format, which represents a plain ZIP file during resource creation or update, and in Atom Multipart [<a href="#atommultipart">AtomMultipart</a>] deposit indicates that the Media Part is a plain ZIP file.
</p>
<div class="code">
http://purl.org/net/sword/package/SimpleZip
</div>
<h2><a name="protocoloperations">6. Protocol Operations</a></h2>
<p>
While specific HTTP status codes are used below, a SWORD client should be prepared to handle any status code as per the HTTP status code definitions [<a href="#rfc2616">RFC2616</a>]
</p>
<h3><a name="protocoloperations_retreivingservicedocument">6.1. Retrieving a Service Document</a></h3>
<em>See Sections 5.1 and 8 of [<a href="#atompub">AtomPub</a>], for details.</em>
<ol>
<li>The client sends a GET request to the IRI of the Service Document.</li>
<li>The server responds with a Service Document enumerating the IRIs of a group of Collections and the capabilities of those Collections supported by the server. The content of this document can vary based on aspects of the client request, including, but not limited to, authentication credentials.</li>
</ol>
<p>
The client may also supply the <span class="code_inline">On-Behalf-Of</span> header [<a href="#sword001">SWORD001</a>] to provide the username of a target user on whose behalf a deposit will be made. See <a href="#authenticationmediateddeposit">Section 8: Authentication and Mediated Deposit</a> for more details.
</p>
<div class="code">
<pre>
GET SD-IRI HTTP/1.1
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Host: example.org
<strong>On-Behalf-Of: [username]</strong>
</pre>
</div>
<p>
When a server that supports mediated deposit receives an <span class="code_inline">On-Behalf-Of</span> header [<a href="#sword001">SWORD001</a>], the returned Service Document SHOULD identify only those collections to which the combination of mediated user and authenticated user might successfully deposit. If the target server does not support mediated deposit, the returned Service Document SHOULD contain a <span class="code_inline">sword:mediation</span> [<a href="#sword002">SWORD002</a>] extension element with a value of <span class="code_inline">false</span>.
</p>
<p>
The service document supplied in response MUST meet the following criteria in addition to those specified in [<a href="#atompub">AtomPub</a>]:
</p>
<ul>
<li>The SWORD server MUST specify the <span class="code_inline">sword:version</span> element with a value of <span class="code_inline">2.0</span> [<a href="#sword003">SWORD003</a>]</li> as a child of the <span class="code_inline">app:service</span> element.
<li>The SWORD server MAY specify the <span class="code_inline">sword:maxUploadSize</span> (in kB) of content that can be uploaded in one request [<a href="#sword003">SWORD003</a>] as a child of the <span class="code_inline">app:service</span> element. If provided this MUST contain an integer.</li>
<li>The SWORD server MUST specify the <span class="code_inline">app:accept</span> element for the <span class="code_inline">app:collection</span> element. If the Collection can take any format content type, it should specify <span class="code_inline">*/*</span> as its value [<a href="#atompub">AtomPub</a>]. It MUST also specify an <span class="code_inline">app:accept</span> element with an <span class="code_inline">alternate</span> attribute set to <span class="code_inline">multipart-related</span> as required by [<a href="#atommultipart">AtomMultipart</a>]. The formats specified by <span class="code_inline">app:accept</span> and <span class="code_inline">app:accept@alternate="multipart-related"</span> are RECOMMENDED to be the same.</li>
<li>The SWORD server MAY include one <span class="code_inline">sword:collectionPolicy</span> [<a href="#sword003">SWORD003</a>] as a child of the <span class="code_inline">app:collection</span> element</li>
<li>The SWORD server SHOULD include one <span class="code_inline">sword:mediation</span> element as a child of the <span class="code_inline">app:collection</span> element with a value of <span class="code_inline">true</span> or <span class="code_inline">false</span> [<a href="#sword002">SWORD002</a>]</li>
<li>The SWORD server MAY include one <span class="code_inline">sword:treatment</span> element [<a href="#sword003">SWORD003</a>]as a child of the <span class="code_inline">app:collection</span> element</li>
<li>The SWORD server MAY include zero or more <span class="code_inline">sword:acceptPackaging</span> elements [<a href="#sword002">SWORD002</a>] as a children of the <span class="code_inline">app:collection</span> element. The value SHOULD be a IRI for a known packaging format (where such IRIs exist)</li>
<li>The SWORD server MAY include zero or more <span class="code_inline">sword:service</span> [<a href="#sword003">SWORD003</a>] elements as children of the <span class="code_inline">app:collection</span> element containing references to nested service descriptions</li>
</ul>
<p>
Example:
</p>
<div class="code">
<pre>
HTTP 1.1 200 OK
Content-Type: application/atomserv+xml
&lt;?xml version="1.0" ?&gt;
&lt;service xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:sword="http://purl.org/net/sword/terms/"
xmlns:atom="http://www.w3.org/2005/Atom"
xmlns="http://www.w3.org/2007/app"&gt;
&lt;sword:version&gt;2.0&lt;/sword:version&gt;
&lt;sword:maxUploadSize&gt;16777216&lt;/sword:maxUploadSize&gt;
&lt;workspace&gt;
&lt;atom:title&gt;Main Site&lt;/atom:title&gt;
&lt;collection href="http://swordapp.org/col-iri/43"&gt;
&lt;atom:title&gt;Collection 43&lt;/atom:title&gt;
&lt;accept&gt;*/*&lt;/accept&gt;
&lt;accept alternate="multipart-related"&gt;*/*&lt;/accept&gt;
&lt;sword:collectionPolicy&gt;Collection Policy&lt;/sword:collectionPolicy&gt;
&lt;dcterms:abstract&gt;Collection Description&lt;/dcterms:abstract&gt;
&lt;sword:mediation&gt;false&lt;/sword:mediation&gt;
&lt;sword:treatment&gt;Treatment description&lt;/sword:treatment&gt;
&lt;sword:acceptPackaging&gt;http://purl.org/net/sword/package/SimpleZip&lt;/sword:acceptPackaging&gt;
&lt;sword:acceptPackaging&gt;http://purl.org/net/sword/package/METSDSpaceSIP&lt;/sword:acceptPackaging&gt;
&lt;sword:service&gt;http://swordapp.org/sd-iri/e4&lt;/sword:service&gt;
&lt;/collection&gt;
&lt;/workspace&gt;
&lt;/service&gt;
</pre>
</div>
<p>
The following requirements are placed on the client in receipt of a service document:
</p>
<ul>
<li>If no <span class="code_inline">sword:maxUploadSize</span> is specified, the client MUST assume that no size limit exists, but this specification RECOMMENDS that clients limit themselves to reasonably small file sizes unless special arrangements with the server have been made.</li>
<li>If no <span class="code_inline">sword:mediation</span> element is specified, the client MUST assume a value of <span class="code_inline">false</span>.
<li>If no <span class="code_inline">sword:acceptPackaging</span> element is specified, the client MUST assume that the server will not formally support packaging formats (see <a href="#iris">Section 5: IRIs</a> and <a href="#packaging">Section 7: Packaging</a> for more details).</li>
<li>The client SHOULD NOT attempt to deposit files with a packaging format that is not in the <span class="code_inline">sword:acceptPackaging</span> elements, although the client MAY specify the binary package format (see <a href="#iris">Section 5: IRIs</a> and <a href="#packaging">Section 7: Packaging</a> for more details) in order to deposit opaquely packaged content</li>
</ul>
<h3><a name="protocoloperations_listingcollections">6.2 Listing Collections</a></h3>
<em>See Section 5.2 of [<a href="#atompub">AtomPub</a>] for details.</em>
<p>
AtomPub states that Collection Resources MUST provide representations in the form of Atom Feed Documents. Under the SWORD profile, implementations SHOULD provide such representations. Clients MUST NOT require a Collection Feed Document for deposit operation.
</p>
<h3><a name="protocoloperations_creatingresource">6.3. Creating a Resource</a></h3>
<h4><a name="protocoloperations_creatingresource_binary">6.3.1. Creating a Resource with a Binary File Deposit</a></h4>
<em>See Sections 5.3 and 9.2 of [<a href="#atompub">AtomPub</a>] for details.</em>
<p>
The client can create a resource by POSTing the binary content as the body of an HTTP request to the <strong>Col-IRI</strong>, with the <span class="code_inline">Content-Type</span>, <span class="code_inline">Content-Disposition</span>, and <span class="code_inline">Packaging</span> headers, with the following requirements:
</p>
<ul>
<li>The client SHOULD supply a <span class="code_inline">Content-Type</span> header</li>
<li>The client MUST supply a <span class="code_inline">Content-Disposition</span> header with a <span class="code_inline">filename</span> parameter (note that this requires the filename be expressed in ASCII).</li>
<li>The client SHOULD supply a <span class="code_inline">Content-MD5</span> header with the MD5 checksum hex encoded for the binary content</li>
<li>The client SHOULD supply a <span class="code_inline">Packaging</span> header [<a href="#sword001">SWORD001</a>] providing the IRI (or other allowed) of the packaging format used. See <a href="#packaging">Section 7: Packaging</a> for more details.</li>
<li>The client MAY provide an <span class="code_inline">In-Progress</span> header with a value of <span class="code_inline">true</span> or <span class="code_inline">false</span> [<a href="#sword001">SWORD001</a>]. See <a href="#continueddeposit">Section 9: Continued Deposit</a> for more details.</li>
<li>The client MAY provide an <span class="code_inline">On-Behalf-Of</span> header [<a href="#sword001">SWORD001</a>]. See <a href="#authenticationmediateddeposit">Section 8: Authentication and Mediated Deposit</a> for more details.</li>
<li>The client MAY supply a <span class="code_inline">Slug</span> header providing a suggested identifier for the deposited content</li>
</ul>
<div class="code">
<pre>
POST Col-IRI HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Type: application/zip
Content-Length: [content length]
Content-MD5: [md5-digest]
Content-Disposition: attachment; filename=[filename]
Packaging: http://purl.org/net/sword/package/METSDSpaceSIP
In-Progress: true
On-Behalf-Of: jbloggs
Slug: [suggested identifier]
[request entity]
</pre>
</div>
<p>
The requirements placed on the server here are:
</p>
<ul>
<li>If no <span class="code_inline">Content-Type</span> header is supplied the server MUST behave as per Section 7.2.1 in [<a href="#rfc2616">RFC2616</a>]</li>
<li>The server SHOULD verify the <span class="code_inline">Content-MD5</span> header against the content. If the check fails, the server MUST respond with 412 Precondition Failed. See <a href="#errordocuments">Section 12: Error Documents</a>.</li>
<li>Server implementations MUST adopt the behaviour and requirements in [<a href="#rfc2183">RFC2183</a>] with respect to the <span class="code_inline">Content-Disposition</span> header.</li>
<li>If there is no <span class="code_inline">Packaging</span> header, the server SHOULD assume that it is the binary packaging format (See <a href="#iris">Section 5: IRIs<a/></li>
<li>Server implementations MUST adopt the behaviour and requirements in Section 9.7 of [<a href="#atompub">AtomPub</a>] with respect to the <span class="code_inline">Slug</span> header.</li>
<li>If there is no <span class="code_inline">In-Progress</span> header, the server MUST assume that it is <span class="code_inline">false</span>, and MUST behave as described in <a href="#continueddeposit">Section 9: Continued Deposit</a></li>
<li>The server MUST carry out authentication and mediated deposit as described in <a href="#authenticationmediateddeposit">Section 8: Authentication and Mediated Deposit</a></li>
<li>The server MUST create a new resource containing content equivalent to or derived from the deposited content, or return an error document.</li>
</ul>
<p>
Once the server has processed the request it SHOULD return a Deposit Receipt as described in <a href="#depositreceipt">Section 10: Deposit Receipt</a> with the HTTP status code <span class="code_inline">201 (Created)</span>. The Deposit Receipt MUST be available under the <strong>Edit-IRI</strong> (Member Entry IRI), as supplied in the <span class="code_inline">Location</span> header.
</p>
<p>
For example:
</p>
<div class="code">
<pre>
201 Created
Location: [Edit-IRI]
[optional Deposit Receipt]
</pre>
</div>
<h4><a name="protocoloperations_creatingresource_multipart">6.3.2. Creating a Resource with a Multipart Deposit</a></h4>
<em>See [<a href="#atommultipart">AtomMultipart</a>] for details.</em>
<p>
In order to ensure that all SWORD clients and servers can exchange a full range of file content and metadata, the use of Atom Multipart [<a href="#atommultipart">AtomMultipart</a>] is permitted to combine a package (possibly a simple ZIP) with a set of Dublin Core metadata terms [<a href="#dublincore">DublinCore</a>] embedded in an Atom Entry.
</p>
<p>
The SWORD server is not required to support packaging formats, but this profile RECOMMENDS that the server be able to accept a ZIP file as the Media Part of an Atom Multipart request (See <a href="#iris">Section 5: IRIs</a> and <a href="#packaging">Section 7: Packaging</a> for more details).
<p>
The client can create a resource by POSTing a multipart mime message to the <strong>Col-IRI</strong> with two parts: An Atom Entry containing the metadata for the deposit (known as the <strong>Entry Part</strong>), and the binary content as the second part (known as the <strong>Media Part</strong>), with the following requirements:
</p>
<ul>
<li>The client MUST comply with the rules laid out in [<a href="#atommultipart">AtomMultipart</a>]</li>
<li>The client MUST supply a <span class="code_inline">Content-Disposition</span> header of type <span class="code_inline">attachment</span> on the Entry Part with a <span class="code_inline">name</span> parameter set to <span class="code_inline">atom</span> [<a href="#sword004">SWORD004</a>]</li>
<li>The client MUST supply a <span class="code_inline">Content-Disposition</span> header of type <span class="code_inline">attachment</span> on the Media Part with a <span class="code_inline">name</span> parameter set to <span class="code_inline">payload</span> and a <span class="code_inline">filename</span> parameter [<a href="#sword004">SWORD004</a>] (note that this requires the filename be expressed in ASCII).</li>
<li>The client SHOULD supply a <span class="code_inline">Content-MD5</span> header with the MD5 checksum hex encoded for the binary content on the Media Part</span>
<li>The client SHOULD supply a <span class="code_inline">Packaging</span> header [<a href="#sword001">SWORD001</a>] providing the IRI (or other allowed) of the packaging format used on the Media Part</li>
<li>The client MAY provide an <span class="code_inline">In-Progress</span> header with a value of <span class="code_inline">true</span> or <span class="code_inline">false</span> [<a href="#sword001">SWORD001</a>] on the main HTTP header</li>
<li>The client MAY provide an <span class="code_inline">On-Behalf-Of</span> header [<a href="#sword001">SWORD001</a>] on the main HTTP header</li>
<li>The client MAY supply a <span class="code_inline">Slug</span> header providing a suggested identifier for the deposited content on the main HTTP header</li>
<li>The client SHOULD add Dublin Core [<a href="#dublincore">DublinCore</a>] terms to the Atom Entry as foreign markup (if appropriate); the terms MUST be embedded as direct children of the <span class="code_inline">atom:entry</span> element, if present.</li>
<li>The client MAY add any other metadata formats or foreign markup to the <span class="code_inline">atom:entry</span> element</li>
</ul>
<p>
For example:
</p>
<div class="code">
<pre>
POST Col-IRI HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: [content length]
Content-Type: multipart/related;
boundary="===============1605871705==";
type="application/atom+xml"
In-Progress: true
On-Behalf-Of: jbloggs
Slug: [suggested identifier]
MIME-Version: 1.0
Media Post
--===============1605871705==
Content-Type: application/atom+xml; charset="utf-8"
Content-Disposition: attachment; name="atom"
MIME-Version: 1.0
&lt;?xml version="1.0"?&gt;
&lt;entry xmlns="http://www.w3.org/2005/Atom"
xmlns:dcterms="http://purl.org/dc/terms/"&gt;
&lt;title&gt;Title&lt;/title&gt;
&lt;id&gt;urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a&lt;/id&gt;
&lt;updated&gt;2005-10-07T17:17:08Z&lt;/updated&gt;
&lt;author&gt;&lt;name&gt;Contributor&lt;/name&gt;&lt;/author&gt;
&lt;summary type="text"&gt;The abstract&lt;/summary&gt;
&lt;!-- some embedded metadata --&gt;
&lt;dcterms:abstract&gt;The abstract&lt;/dcterms:abstract&gt;
&lt;dcterms:accessRights&gt;Access Rights&lt;/dcterms:accessRights&gt;
&lt;dcterms:alternative&gt;Alternative Title&lt;/dcterms:alternative&gt;
&lt;dcterms:available&gt;Date Available&lt;/dcterms:available&gt;
&lt;dcterms:bibliographicCitation&gt;Bibliographic Citation&lt;/dcterms:bibliographicCitation&gt;
&lt;dcterms:contributor&gt;Contributor&lt;/dcterms:contributor&gt;
&lt;dcterms:description&gt;Description&lt;/dcterms:description&gt;
&lt;dcterms:hasPart&gt;Has Part&lt;/dcterms:hasPart&gt;
&lt;dcterms:hasVersion&gt;Has Version&lt;/dcterms:hasVersion&gt;
&lt;dcterms:identifier&gt;Identifier&lt;/dcterms:identifier&gt;
&lt;dcterms:isPartOf&gt;Is Part Of&lt;/dcterms:isPartOf&gt;
&lt;dcterms:publisher&gt;Publisher&lt;/dcterms:publisher&gt;
&lt;dcterms:references&gt;References&lt;/dcterms:references&gt;
&lt;dcterms:rightsHolder&gt;Rights Holder&lt;/dcterms:rightsHolder&gt;
&lt;dcterms:source&gt;Source&lt;/dcterms:source&gt;
&lt;dcterms:title&gt;Title&lt;/dcterms:title&gt;
&lt;dcterms:type&gt;Type&lt;/dcterms:type&gt;
&lt;/entry&gt;
--===============1605871705==
Content-Type: application/zip
Content-Disposition: attachment; name=payload; filename=[filename]
Packaging: http://purl.org/net/sword/package/SimpleZip
Content-MD5: [md5-digest]
MIME-Version: 1.0
[...binary package data...]
--===============1605871705==--
</pre>
</div>
<p>
The requirements placed on the server here are:
</p>
<ul>
<li>The server SHOULD verify the <span class="code_inline">Content-MD5</span> header against the Media Part. If the check fails, the server MUST respond with 412 Precondition Failed. See <a href="#errordocuments">Section 12: Error Documents</a>.</li>
<li>Server implementations MUST adopt the behaviour and requirements in [<a href="#rfc2183">RFC2183</a>] with respect to the <span class="code_inline">Content-Disposition</span> header for the Media Part</li>
<li>If there is no <span class="code_inline">Packaging</span> header on the Media Part, the server SHOULD assume that it is the binary packaging format (See <a href="#iris">Section 5: IRIs</a>)</li>
<li>Server implementations MUST adopt the behaviour and requirements in Section 9.7 of [<a href="#atompub">AtomPub</a>] with respect to the <span class="code_inline">Slug</span> header</li>
<li>If there is no <span class="code_inline">In-Progress</span> header, the server MUST assume that it is <span class="code_inline">false</span>, and MUST behave as described in <a href="#continueddeposit">Section 9: Continued Deposit</a></li>
<li>If there is an <span class="code_inline">On-Behalf-Of</span> header, the server MUST behave as described in <a href="#authenticationmediateddeposit">Section 8: Authentication and Mediated Deposit</a></li>
<li>The server MUST create a new resource containing content equivalent to or derived from the deposited content, or return an error document.</li>
<li>The server MUST be able to record and later reflect the Dublin Core [<a href="#dublincore">DublinCore</a>] foreign markup in the <span class="code_inline">atom:entry</span> element, but MAY NOT understand any other embedded formats.</li>
</ul>
<p>
Once the server has processed the request it SHOULD return a Deposit Receipt as described in <a href="#depositreceipt">Section 10: Deposit Receipt</a> with the HTTP status code <span class="code_inline">201 (Created)</span>. The Deposit Receipt MUST be available under the <strong>Edit-IRI</strong> (Member Entry IRI), as supplied in the <span class="code_inline">Location</span> header.
</p>
<p>
For example:
</p>
<div class="code">
<pre>
201 Created
Location: [Edit-IRI]
[optional Deposit Receipt]
</pre>
</div>
<h4><a name="protocoloperations_creatingresource_entry">6.3.3. Creating a Resource with an Atom Entry</a></h4>
<em>See Sections 5.3 and 9.2 of [<a href="#atompub">AtomPub</a>] for details.</em>
<p>
Clients can create a container within a SWORD server and optionally provide it with metadata without adding any binary content to it. This is done by POSTing an Atom Entry to the <strong>Col-IRI</strong> with the following requirements:
</p>
<ul>
<li>The client SHOULD supply a <span class="code_inline">Content-Type</span> header with the value <span class="code_inline">application/atom+xml;type=entry</span></li>
<li>The client MAY provide an <span class="code_inline">In-Progress</span> header with a value of <span class="code_inline">true</span> or <span class="code_inline">false</span> [<a href="#sword001">SWORD001</a>]. See <a href="#continueddeposit">Section 9: Continued Deposit</a> for more details.</li>
<li>The client MAY provide an <span class="code_inline">On-Behalf-Of</span> header [<a href="#sword001">SWORD001</a>]. See <a href="#authenticationmediateddeposit">Section 8: Authentication and Mediated Deposit</a> for more details.</li>
<li>The client MAY supply a <span class="code_inline">Slug</span> header providing a suggested identifier for the deposited content</li>
<li>The client SHOULD add Dublin Core [<a href="#dublincore">DublinCore</a>] terms to the Atom Entry as foreign markup (if appropriate); the terms MUST be embedded as direct children of the <span class="code_inline">atom:entry</span> element, if present.</li>
<li>The client MAY add any other metadata formats or foreign markup to the <span class="code_inline">atom:entry</span> element</li>
</ul>
<p>
For example:
</p>
<div class="code">
<pre>
POST Col-IRI HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: [content length]
Content-Type: application/atom+xml;type=entry
In-Progress: true
On-Behalf-Of: jbloggs
Slug: [suggested identifier]
&lt;?xml version="1.0"?&gt;
&lt;entry xmlns="http://www.w3.org/2005/Atom"
xmlns:dcterms="http://purl.org/dc/terms/"&gt;
&lt;title&gt;Title&lt;/title&gt;
&lt;id&gt;urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a&lt;/id&gt;
&lt;updated&gt;2005-10-07T17:17:08Z&lt;/updated&gt;
&lt;author&gt;&lt;name&gt;Contributor&lt;/name&gt;&lt;/author&gt;
&lt;summary type="text"&gt;The abstract&lt;/summary&gt;
&lt;!-- some embedded metadata --&gt;
&lt;dcterms:abstract&gt;The abstract&lt;/dcterms:abstract&gt;
&lt;dcterms:accessRights&gt;Access Rights&lt;/dcterms:accessRights&gt;
&lt;dcterms:alternative&gt;Alternative Title&lt;/dcterms:alternative&gt;
&lt;dcterms:available&gt;Date Available&lt;/dcterms:available&gt;
&lt;dcterms:bibliographicCitation&gt;Bibliographic Citation&lt;/dcterms:bibliographicCitation&gt;
&lt;dcterms:contributor&gt;Contributor&lt;/dcterms:contributor&gt;
&lt;dcterms:description&gt;Description&lt;/dcterms:description&gt;
&lt;dcterms:hasPart&gt;Has Part&lt;/dcterms:hasPart&gt;
&lt;dcterms:hasVersion&gt;Has Version&lt;/dcterms:hasVersion&gt;
&lt;dcterms:identifier&gt;Identifier&lt;/dcterms:identifier&gt;
&lt;dcterms:isPartOf&gt;Is Part Of&lt;/dcterms:isPartOf&gt;
&lt;dcterms:publisher&gt;Publisher&lt;/dcterms:publisher&gt;
&lt;dcterms:references&gt;References&lt;/dcterms:references&gt;
&lt;dcterms:rightsHolder&gt;Rights Holder&lt;/dcterms:rightsHolder&gt;
&lt;dcterms:source&gt;Source&lt;/dcterms:source&gt;
&lt;dcterms:title&gt;Title&lt;/dcterms:title&gt;
&lt;dcterms:type&gt;Type&lt;/dcterms:type&gt;
&lt;/entry&gt;
</pre>
</div>
<p>
The requirements placed on the server here are:
</p>
<ul>
<li>Server implementations MUST adopt the behaviour and requirements in Section 9.7 of [<a href="#atompub">AtomPub</a>] with respect to the <span class="code_inline">Slug</span> header</li>
<li>If there is no <span class="code_inline">In-Progress</span> header, the server MUST assume that it is <span class="code_inline">false</span>, and MUST behave as described in <a href="#continueddeposit">Section 9: Continued Deposit</a></li>
<li>If there is an <span class="code_inline">On-Behalf-Of</span> header, the server MUST behave as described in <a href="#authenticationmediateddeposit">Section 8: Authentication and Mediated Deposit</a></li>
<li>The server MUST create a new resource, or return an error document.</li>
<li>The server MUST be able to record and later reflect the Dublin Core [<a href="#dublincore">DublinCore</a>] foreign markup in the <span class="code_inline">atom:entry</span> element, but MAY NOT understand any other embedded formats.</li>
<li>The server MUST supply an <strong>EM-IRI</strong> for the client to use in future update operations, even though this EM-IRI may at this stage not return any content under HTTP GET.</li>
</ul>
<p>
Once the server has processed the request it SHOULD return a Deposit Receipt as described in <a href="#depositreceipt">Section 10: Deposit Receipt</a> with the HTTP status code <span class="code_inline">201 (Created)</span>. The Deposit Receipt MUST be available under the <strong>Edit-IRI</strong> (Member Entry IRI), as supplied in the <span class="code_inline">Location</span> header.
</p>
<p>
For example:
</p>
<div class="code">
<pre>
201 Created
Location: [Edit-IRI]
[optional Deposit Receipt]
</pre>
</div>
<h3><a name="protocoloperations_retrievingcontent">6.4. Retrieving the content</a></h3>
<em>See section 5.4 of [<a href="#atompub">AtomPub</a>] for details.</em>
<p>
The Deposit Receipt contains two IRIs which can be used to retrieve content from the server: <strong>Cont-IRI</strong> and <strong>EM-IRI</strong>. These are provided in the <span class="code_inline">atom:content@src</span> element and the <span class="code_inline">atom:link@rel="edit-media"</span> elements respectively. Their only functional difference is that the client MUST NOT carry out any HTTP operations other than GET on the <strong>Cont-IRI</strong>, while all operations are permitted on the <strong>EM-IRI</strong>. It is acceptable, but not required, that both IRIs to be the same, and in this section we refer only to the <strong>EM-IRI</strong> but in all cases it can be substituted for the <strong>Cont-IRI</strong>.
</p>
<p>
The Deposit Receipt contains zero or more <span class="code_inline">sword:packaging</span> elements [<a href="#sword002">SWORD002</a>], indicating to the client what package formats can be retrieved from the server. For example:
</p>
<div class="code">
<pre>
&lt;entry xmlns="http://www.w3.org/2005/Atom"
xmlns:sword="http://purl.org/net/sword/"&gt;
[...]
&lt;content type="application/zip" src="http://swordapp.org/cont-IRI/43/my_deposit"/&gt;
&lt;link rel="edit-media" href="http://swordapp.org/em-IRI/43/my_deposit"/&gt;
&lt;sword:packaging&gt;http://purl.org/net/sword/package/SimpleZip&lt;/sword:packaging&gt;
&lt;sword:packaging&gt;http://purl.org/net/sword/package/METSDSpaceSIP&lt;/sword:packaging&gt;
&lt;sword:packaging&gt;http://purl.org/net/sword/package/BagIt&lt;/sword:packaging&gt;
&lt;/entry&gt;
</pre>
</div>
<p>
Requests to retrieve the Media Resource here refer to the Media Resource <em>as a whole</em>, as per [<a href="#atompub">AtomPub</a>], and not to any of the component parts of a complex Media Resource. That is, the response to a request for the Media Resource should be considered a representation of the entire content of the object on the server, and it is not permissable to attempt to content negotiate for a particular part of the Media Resource. Implementers who wish to access the parts of a Media Resource should see <a href="#protocoloperations_retrievingcontent_feed">Section 6.4.1. Atom Feed Representations of Media Resources</a> below.
</p>
<p>
To retrieve the content in the desired packaging format, the client makes an HTTP GET request to the <strong>EM-IRI</strong> and MAY supply an <span class="code_inline">Accept-Packaging</span> header [<a href="#sword001">SWORD001</a>] with the IRI from one of the <span class="code_inline">sword:packaging</span> elements.
</p>
<p>
If the content is not in a publicly available space on the server, the user agent may be required to authenticate. In these cases the client MAY supply the <span class="code_inline">On-Behalf-Of</span> header [<a href="#sword001">SWORD001</a>] for informational purposes.
</p>
<p>
The server will respond in different ways depending on a number of conditions:
</p>
<ol>
<li>If the <span class="code_inline">Accept-Packaging</span> header is not supplied, the server SHOULD assume a simple ZIP packaging format (see <a href="#iris">Section 5: IRIs</a>), but MAY elect another format if it wishes. The server MUST then supply the client with a package which meets these specifications, and SHOULD provide the SimpleZip IRI in a <span class="code_inline">Packaging</span> header on the response.</li>
<li>If the <span class="code_inline">Accept-Packaging</span> header is supplied, and contains the IRI (or other allowed value) of a format that the server supports, the server MUST then supply the client with a package which meets these specifications, and SHOULD provide an IRI (or other allowed value) of the format being returned in a <span class="code_inline">Packaging</span> header on the response.</li>
<li>If the <span class="code_inline">Accept-Packaging</span> header is supplied but contains a IRI (or other allowed value) for a format that the server does not support, the server MUST respond with 406 Not Acceptable and MAY include an error document as per <a href="#errordocuments">Section 12: Error Documents</a>.</li>
</ol>
<p>
Upon receiving a successful response, if no <span class="code_inline">Packaging</span> header is provided in the response the client SHOULD assume that it is a SimpleZip.
</p>
<p>
For more details about the packaging process, see <a href="#packaging">Section 7: Packaging</a>
</p>
<h4><a name="protocoloperations_retrievingcontent_feed">6.4.1. Atom Feed Representations of Media Resources</a></h4>
<em>See sections 11.2 and 12.1 of [<a href="#atompub">AtomPub</a>] for details.</em>
<p>
It is RECOMMENDED that implementations provide an EM-IRI in the Deposit Receipt with a type of <span class="code_inline">application/atom+xml;type=feed</span> in addition to any other types available.
</p>
<p>For example, the Depoisit Receipt would contain:</p>
<div class="code">
<pre>
&lt;entry xmlns="http://www.w3.org/2005/Atom"
xmlns:sword="http://purl.org/net/sword/"&gt;
[...]
&lt;link rel="edit-media" href="http://swordapp.org/em-IRI/43/my_deposit"/&gt;
&lt;link rel="edit-media" type="application/atom+xml;type=feed" href="http://swordapp.org/em-IRI/43/my_deposit.feed"/&gt;
[...]
&lt;/entry&gt;
</pre>
</div>
<p>
The exact contents of the Feed representation are unspecified, but it is RECOMMENDED that this is a list of <span class="code_inline">atom:entry</span> elements which represent the individual media items which together form the Media Resource. Each <span class="code_inline">atom:entry</span> element MUST have an edit-media IRI which SHOULD be actionable as per <a href="protocoloperations_swordactionableiris">Section 6.10</a>.
</p>
<p>
NOTE that this is not the same as the Statement, which is a representation of the entire object on the server, not just the Media Resource. See <a href="#statement">Section 11: The SWORD Statement</a> for details
</p>
<h3><a name="protocoloperations_editingcontent">6.5. Replacing the Content of a Resource</a></h3>
<h4><a name="protocoloperations_editingcontent_binary">6.5.1. Replacing the File Content of a Resource</a></h4>
<em>See section 5.4 and 9.3 of [<a href="#atompub">AtomPub</a>] for details.</em>
<p>
The client can replace the existing content of a resource by performing an HTTP PUT of some new binary content to the <strong>EM-IRI</strong>, with the following requirements:
</p>
<ul>
<li>The client SHOULD supply a <span class="code_inline">Content-Type</span> header</li>
<li>The client MUST supply a <span class="code_inline">Content-Disposition</span> header with a <span class="code_inline">filename</span> parameter (note that this requires the filename be expressed in ASCII).</li>
<li>The client SHOULD supply a <span class="code_inline">Content-MD5</span> header with the MD5 checksum hex encoded for the binary content</li>
<li>The client SHOULD supply a <span class="code_inline">Packaging</span> header [<a href="#sword001">SWORD001</a>] providing the IRI (or other allowed) of the packaging format used</li>
<li>The client MAY provide an <span class="code_inline">On-Behalf-Of</span> header [<a href="#sword001">SWORD001</a>]</li>
<li>The client MAY provide a <span class="code_inline">Metadata Relevant</span> header [<a href="#sword001">SWORD001</a>] with the value <span class="code_inline">true</span> or <span class="code_inline">false</span>. This should be set to <span class="code_inline">true</span> if the server should consider the file a potential source of metadata extraction, or <span class="code_inline">false</span> if the server should not attempt to extract any metadata from the deposit.
</ul>
<p>
For example:
</p>
<div class="code">
<pre>
PUT EM-IRI HTTP/1.1
Host: example.org
Content-Type: application/zip
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: [content length]
Content-MD5: [md5-digest]
Content-Disposition: attachment; filename=[filename]
Packaging: http://purl.org/net/sword/package/METSDSpaceSIP
On-Behalf-Of: jbloggs
[request entity]
</pre>
</div>
<p>
The requirements placed on the server here are:
</p>
<ul>
<li>The server SHOULD verify the <span class="code_inline">Content-MD5</span> header against the content. If the check fails, the server MUST respond with 412 Precondition Failed. See <a href="#errordocuments">Section 12: Error Documents</a>.</li>
<li>Server implementations MUST adopt the behaviour and requirements in [<a href="#rfc2183">RFC2183</a>] with respect to the <span class="code_inline">Content-Disposition</span> header</li>
<li>If there is no <span class="code_inline">Packaging</span> header, the server SHOULD assume that it is the binary packaging format (See <a href="#iris">Section 5: IRIs</a>)</li>
<li>If the container to which the deposit is being made has been previously marked as "in progress", the server SHOULD continue to respect that assertion as per <a href="#continueddeposit">Section 9: Continued Deposit</a>.</li>
<li>If there is an <span class="code_inline">On-Behalf-Of</span> header, the server MUST behave as described in <a href="#authenticationmediateddeposit">Section 8: Authentication and Mediated Deposit</a></span>.</li>
<li>If no <span class="code_inline">Metadata-Relevant</span> header is provided the server MAY assume that it is <span class="code_inline">true</span> and MAY attempt to extract metadata from the deposit. If <span class="code_inline">Metadata-Relevant</span> is <span class="code_inline">false</span> the server SHOULD NOT attempt to extract metadata from the deposit.</li>
<li>The server MUST effectively replace all the existing content in the item, although implementations may choose to provide versioning or some other mechanism for retaining the overwritten content.</li>
</ul>
<p>
Once the server has processed the request it MUST return an HTTP status code <span class="code_inline">204 (No Content)</span>, or an appropriate error code.
</p>
<h4><a name="protocoloperations_editingcontent_metadata">6.5.2. Replacing the Metadata of a Resource</a></h4>
<em>See section 5.4 and 9.3 of [<a href="#atompub">AtomPub</a>] for details.</em>
<p>
The client can replace the metadata of a resource by performing an HTTP PUT of a new Atom Entry on the <strong>Edit-IRI</strong>. The client can only be sure that the server will support this process when using the default format supported by SWORD: Qualified Dublin Core XML embedded directly in the <span class="code_inline">atom:entry</span>. Other metadata formats MAY be supported by a particular server, but this is not covered by the SWORD profile.
</p>
<ul>
<li>The client SHOULD supply a <span class="code_inline">Content-Type</span> header with the value <span class="code_inline">application/atom+xml</span> or <span class="code_inline">application/atom+xml;type=entry</span></li>
<li>The client MAY provide an <span class="code_inline">On-Behalf-Of</span> header [<a href="#sword001">SWORD001</a>]</li>
<li>The client MAY provide an <span class="code_inline">In-Progress</span> header with a value of true or false [<a href="#sword001">SWORD001</a>]. See <a href="#continueddeposit">Section 9: Continued Deposit</a> for more details.</li>
</ul>
<p>
For example:
</p>
<div class="code">
<pre>
PUT Edit-IRI HTTP/1.1
Host: example.org
Content-Type: application/atom+xml
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: [content length]
On-Behalf-Of: jbloggs
&lt;?xml version="1.0"?&gt;
&lt;entry xmlns="http://www.w3.org/2005/Atom"
xmlns:dcterms="http://purl.org/dc/terms/"&gt;
&lt;title&gt;Title&lt;/title&gt;
&lt;id&gt;urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a&lt;/id&gt;
&lt;updated&gt;2005-10-07T17:17:08Z&lt;/updated&gt;
&lt;author&gt;&lt;name&gt;Contributor&lt;/name&gt;&lt;/author&gt;
&lt;summary type="text"&gt;The abstract&lt;/summary&gt;
&lt;!-- some embedded metadata --&gt;
&lt;dcterms:abstract&gt;The abstract&lt;/dcterms:abstract&gt;
&lt;dcterms:accessRights&gt;Access Rights&lt;/dcterms:accessRights&gt;
&lt;dcterms:alternative&gt;Alternative Title&lt;/dcterms:alternative&gt;
&lt;dcterms:available&gt;Date Available&lt;/dcterms:available&gt;
&lt;dcterms:bibliographicCitation&gt;Bibliographic Citation&lt;/dcterms:bibliographicCitation&gt;
&lt;dcterms:contributor&gt;Contributor&lt;/dcterms:contributor&gt;
&lt;dcterms:description&gt;Description&lt;/dcterms:description&gt;
&lt;dcterms:hasPart&gt;Has Part&lt;/dcterms:hasPart&gt;
&lt;dcterms:hasVersion&gt;Has Version&lt;/dcterms:hasVersion&gt;
&lt;dcterms:identifier&gt;Identifier&lt;/dcterms:identifier&gt;
&lt;dcterms:isPartOf&gt;Is Part Of&lt;/dcterms:isPartOf&gt;
&lt;dcterms:publisher&gt;Publisher&lt;/dcterms:publisher&gt;
&lt;dcterms:references&gt;References&lt;/dcterms:references&gt;
&lt;dcterms:rightsHolder&gt;Rights Holder&lt;/dcterms:rightsHolder&gt;
&lt;dcterms:source&gt;Source&lt;/dcterms:source&gt;
&lt;dcterms:title&gt;Title&lt;/dcterms:title&gt;
&lt;dcterms:type&gt;Type&lt;/dcterms:type&gt;
&lt;/entry&gt;
</pre>
</div>
<p>
The requirements placed on the server here are:
</p>
<ul>
<li>If there is no <span class="code_inline">In-Progress</span> header, the server MUST assume that it is <span class="code_inline">false</span>, and MUST behave as described in <a href="#continueddeposit">Section 9: Continued Deposit</a></li>
<li>If there is an <span class="code_inline">On-Behalf-Of</span> header, the server MUST behave as described in <a href="#authenticationmediateddeposit">Section 8: Authentication and Mediated Deposit</a></span>.</li>
<li>The server MUST effectively replace all the existing metadata in the item, although implementations may choose to provide versioning or some other mechanism for retaining the overwritten metadata.</li>
</ul>
<p>
Once the server has processed the request it MUST return an HTTP status code <span class="code_inline">200 (OK)</span> or <span class="code_inline">204 (No Content)</span>, or an appropriate error code.
</p>
<h4><a name="protocoloperations_editingcontent_multipart">6.5.3. Replacing the Metadata and File Content of a Resource</a></h4>
<em>See [<a href="#atommultipart">AtomMultipart</a>] for details.</em>
<p>
The client can replace both the metadata and content of a resource by performing an HTTP PUT on the <strong>Edit-IRI</strong> with a multipart mime message, as per <a href="#protocoloperations_creatingresource_multipart">Section 6.3.2. Creating a Resource with a Multipart Deposit</a>
</p>
<ul>
<li>The client MUST comply with the rules laid out in [<a href="#atommultipart">AtomMultipart</a>]</li>
<li>The client MUST supply a <span class="code_inline">Content-Disposition</span> header of type <span class="code_inline">attachment</span> on the Entry Part with a <span class="code_inline">name</span> parameter set to <span class="code_inline">atom</span> [<a href="#sword004">SWORD004</a>]</li>
<li>The client MUST supply a <span class="code_inline">Content-Disposition</span> header of type <span class="code_inline">attachment</span> on the Media Part with a <span class="code_inline">name</span> parameter set to <span class="code_inline">payload</span> and a <span class="code_inline">filename</span> parameter [<a href="#sword004">SWORD004</a>] (note that this requires the filename be expressed in ASCII).</li>
<li>The client SHOULD supply a <span class="code_inline">Content-MD5</span> header with the MD5 checksum hex encoded for the binary content on the Media Part</span>
<li>The client SHOULD supply a <span class="code_inline">Packaging</span> header [<a href="#sword001">SWORD001</a>] providing the IRI (or other allowed) of the packaging format used on the Media Part</li>
<li>The client MAY provide an <span class="code_inline">In-Progress</span> header with a value of <span class="code_inline">true</span> or <span class="code_inline">false</span> [<a href="#sword001">SWORD001</a>] on the main HTTP header</li>
<li>The client MAY provide an <span class="code_inline">On-Behalf-Of</span> header [<a href="#sword001">SWORD001</a>] on the main HTTP header</li>
<li>The client SHOULD add Dublin Core [<a href="#dublincore">DublinCore</a>] terms to the Atom Entry as foreign markup (if appropriate); the terms MUST be embedded as direct children of the <span class="code_inline">atom:entry</span> element, if present.</li>
<li>The client MAY add any other metadata formats or foreign markup to the <span class="code_inline">atom:entry</span> element</li>
</ul>
<p>
For example:
</p>
<div class="code">
<pre>
PUT Edit-IRI HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: [content length]
Content-Type: multipart/related;
boundary="===============1605871705==";
type="application/atom+xml"
In-Progress: true
On-Behalf-Of: jbloggs
MIME-Version: 1.0
Media Post
--===============1605871705==
Content-Type: application/atom+xml; charset="utf-8"
Content-Disposition: attachment; name="atom"
MIME-Version: 1.0
&lt;?xml version="1.0"?&gt;
&lt;entry xmlns="http://www.w3.org/2005/Atom"
xmlns:dcterms="http://purl.org/dc/terms/"&gt;
&lt;title&gt;Title&lt;/title&gt;
&lt;id&gt;urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a&lt;/id&gt;
&lt;updated&gt;2005-10-07T17:17:08Z&lt;/updated&gt;
&lt;author&gt;&lt;name&gt;Contributor&lt;/name&gt;&lt;/author&gt;
&lt;summary type="text"&gt;The abstract&lt;/summary&gt;
&lt;!-- some embedded metadata --&gt;
&lt;dcterms:abstract&gt;The abstract&lt;/dcterms:abstract&gt;
&lt;dcterms:accessRights&gt;Access Rights&lt;/dcterms:accessRights&gt;
&lt;dcterms:alternative&gt;Alternative Title&lt;/dcterms:alternative&gt;
&lt;dcterms:available&gt;Date Available&lt;/dcterms:available&gt;
&lt;dcterms:bibliographicCitation&gt;Bibliographic Citation&lt;/dcterms:bibliographicCitation&gt;
&lt;dcterms:contributor&gt;Contributor&lt;/dcterms:contributor&gt;
&lt;dcterms:description&gt;Description&lt;/dcterms:description&gt;
&lt;dcterms:hasPart&gt;Has Part&lt;/dcterms:hasPart&gt;
&lt;dcterms:hasVersion&gt;Has Version&lt;/dcterms:hasVersion&gt;
&lt;dcterms:identifier&gt;Identifier&lt;/dcterms:identifier&gt;
&lt;dcterms:isPartOf&gt;Is Part Of&lt;/dcterms:isPartOf&gt;
&lt;dcterms:publisher&gt;Publisher&lt;/dcterms:publisher&gt;
&lt;dcterms:references&gt;References&lt;/dcterms:references&gt;
&lt;dcterms:rightsHolder&gt;Rights Holder&lt;/dcterms:rightsHolder&gt;
&lt;dcterms:source&gt;Source&lt;/dcterms:source&gt;
&lt;dcterms:title&gt;Title&lt;/dcterms:title&gt;
&lt;dcterms:type&gt;Type&lt;/dcterms:type&gt;
&lt;/entry&gt;
--===============1605871705==
Content-Type: application/zip
Content-Disposition: attachment; name=payload; filename=[filename]
Packaging: http://purl.org/net/sword/package/SimpleZip
Content-MD5: [md5-digest]
MIME-Version: 1.0
[...binary package data...]
--===============1605871705==--
</pre>
</div>
<p>
The requirements placed on the server here are:
</p>
<ul>
<li>The server SHOULD verify the <span class="code_inline">Content-MD5</span> header against the Media Part. If the check fails, the server MUST respond with 412 Precondition Failed. See <a href="#errordocuments">Section 12: Error Documents</a>.</li>
<li>Server implementations MUST adopt the behaviour and requirements in [<a href="#rfc2183">RFC2183</a>] with respect to the <span class="code_inline">Content-Disposition</span> header for the Media Part</li>
<li>If there is no <span class="code_inline">Packaging</span> header on the Media Part, the server SHOULD assume that it is the binary packaging format (See <a href="#iris">Section 5: IRIs</a>)</li>
<li>If there is no <span class="code_inline">In-Progress</span> header, the server MUST assume that it is <span class="code_inline">false</span>, and MUST behave as described in <a href="#continueddeposit">Section 9: Continued Deposit</a></li>
<li>If there is an <span class="code_inline">On-Behalf-Of</span> header, the server MUST behave as described in <a href="#authenticationmediateddeposit">Section 8: Authentication and Mediated Deposit</a></li>
<li>The server MUST overwrite the existing metadata and content with metadata and content equivalent to or derived from the deposited content, or return an error document. Servers may choose to implement versioning to retain previous copies of the content.</li>
<li>The server MUST be able to record and later reflect the Dublin Core [<a href="#dublincore">DublinCore</a>] foreign markup in the <span class="code_inline">atom:entry</span> element, but MAY NOT understand any other embedded formats.</li>
</ul>
<p>
Once the server has processed the request it MUST return an HTTP status code <span class="code_inline">200 (OK)</span> or <span class="code_inline">204 (No Content)</span>, or an appropriate error code.
</p>
<h3><a name="protocoloperations_deletingcontent">6.6. Deleting the Content of a Resource</a></h3>
<em>See Sections 5.4 and 9.4 of [<a href="#atompub">AtomPub</a>] for details.</em>
<p>
The client can remove all the content of a resource without removing the resource itself by issuing an HTTP DELETE request on the <strong>EM-IRI</strong>.
</p>
<p>
After the delete operation, the container (represented by the <strong>Edit-IRI</strong>) must still have an <strong>EM-IRI</strong>, but it is an implementation decision as to whether to remove the old <strong>EM-IRI</strong> and provide a new one for subsequent addition of content, or whether to keep the original. This document RECOMMENDS keeping the original for simplicity.
</p>
<p>
The following rules apply to the client request:
</p>
<ul>
<li>The client MAY provide an <span class="code_inline">On-Behalf-Of</span> header [<a href="#sword001">SWORD001</a>]</li>
</ul>
<p>
For example:
</p>
<div class="code">
<pre>
DELETE EM-IRI HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
On-Behalf-Of: jbloggs
</pre>
</div>
<p>
The requirements placed on the server here are:
</p>
<ul>
<li>If the container to which the deposit is being made has been previously marked as "in progress", the server SHOULD continue to respect that assertion as per <a href="#continueddeposit">Section 9: Continued Deposit</a>.</li>
<li>If there is an <span class="code_inline">On-Behalf-Of</span> header, the server MUST behave as described in <a href="#authenticationmediateddeposit">Section 8: Authentication and Mediated Deposit</a>.</li>
<li>The server MUST effectively delete all the existing content in the item (subject to the rules associated with Metadata Handling), although implementations may choose to provide versioning or some other mechanism for retaining the deleted content, and may choose to re-use the <strong>EM-IRI</strong> (recommended).</li>
</ul>
<p>
Once the server has processed the request it MUST return an HTTP status code <span class="code_inline">204 (No Content)</span> upon success, or an appropriate error code.
</p>
<h3><a name="protocoloperations_addingcontent">6.7. Adding Content to a Resource</a></h3>
<p>
This section covers operations which allow you to add new files, packages and metadata to an existing resource on a
SWORD server.
</p>
<p>
<strong>NOTE</strong>: [<a href="#atompub">AtomPub</a>] does not have a well-defined mechanism for adding new content
to an Entry, and therefore does not clarify the difference between <em>new</em> content to be added to an existing resource and <em>alternative</em> content to be created as a separate media resource (e.g. a translation of a document). This document explicitly does not attempt to deal with this issue.
</p>
<h4><a name="protocoloperations_addingcontent_mediaresource">6.7.1. Adding Content to the Media Resource</a></h4>
<p>The client can add more content to the Media Resource itself by performing an HTTP POST request on the <strong>EM-IRI</strong>. This has the effect of placing new files into the Media Resource.</p>
<p>
If the client wishes to add more content to an existing item on the server, it can send a package or an individual file to the <strong>EM-IRI</strong>. When the client sends an individual file (without a <span class="code_inline">Packaging</span> header), then the server will respond with an HTTP <span class="code_inline">Location</span> header which points to the location of the deposited resource. If a package is supplied, the <span class="code_inline">Location</span> header will refer to the Media Resource itself, and the client will need to refer to the Deposit Receipt for details as to the fate of the unpackaged content, or request an Atom Feed of the Media Resource (as per <a href="#protocoloperations_retrievingcontent_feed">Section 6.4.1. Atom Feed Representations of Media Resources</a>).
</p>
<p>
For files with extractable metadata, or packages which contain metadata relevant to the container, there is a <span class="code_inline">Metadata-Relevant</span> header which can be defined to indicate whether the deposit can be used to augment the metadata of the container.
</p>
<p>
Note that this section places tighter restrictions on the use of the <span class="code_inline">Packaging</span> header than other sections of this document, as there is increased scope for confusion here.
</p>
<p>When carrying out this operation, the requirements for the client are:</p>
<ul>
<li>The client SHOULD supply a <span class="code_inline">Content-Type</span> header</li>
<li>The client MUST supply a <span class="code_inline">Content-Disposition</span> header with a <span class="code_inline">filename</span> parameter (note that this requires the filename be expressed in ASCII).</li>
<li>The client SHOULD supply a <span class="code_inline">Content-MD5</span> header with the MD5 checksum hex encoded for the binary content</li>
<li>If sending a package, the client MUST supply a <span class="code_inline">Packaging</span> header [<a href="#sword001">SWORD001</a>] providing the IRI (or other allowed) of the packaging format used (absence of a <span class="code_inline">Packaging</span> header will be interpreted as an opaque file)</li>
<li>The client MAY provide an <span class="code_inline">On-Behalf-Of</span> header [<a href="#sword001">SWORD001</a>]</li>
<li>The client MAY provide a <span class="code_inline">Metadata-Relevant</span> header, with the value <span class="code_inline">true</span> or <span class="code_inline">false</span>. This should be set to <span class="code_inline">true</span> if the server should consider the file or package a potential source of metadata extraction, or <span class="code_inline">false</span> if the server should not attempt to extract any metadata from the deposit.</li>
</ul>
<div class="code">
<pre>
POST EM-IRI HTTP/1.1
Host: example.org
Content-Type: application/pdf
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: [content length]
Content-MD5: [md5-digest]
Content-Disposition: attachment; filename=[filename]
On-Behalf-Of: jbloggs
[request entity]
</pre>
</div>
<p>
The requirements placed on the server here are:
</p>
<ul>
<li>The server SHOULD verify the <span class="code_inline">Content-MD5</span> header against the content. If the check fails, the server MUST respond with 412 Precondition Failed, and MAY return a SWORD Error document. See <a href="#errordocuments">Section 12: Error Documents</a>.</li>
<li>Server implementations MUST adopt the behaviour and requirements in [<a href="#rfc2183">RFC2183</a>] with respect to the <span class="code_inline">Content-Disposition</span> header</li>
<li>If there is no <span class="code_inline">Packaging</span> header, the server MUST assume that it is the binary packaging format (See <a href="#iris">Section 5: IRIs</a>)</li>
<li>If there is an <span class="code_inline">On-Behalf-Of</span> header, the server MUST behave as described in <a href="#authenticationmediateddeposit">Section 8: Authentication and Mediated Deposit</a>.</li>
<li>The server SHOULD NOT overwrite any existing content, and MUST add content equivalent to or derived from the deposited content to the existing container or respond with an error document.</li>
<li>If there is no <span class="code_inline">Metadata-Relevant</span> header, the server MAY assume that it is <span class="code_inline">true</span> and MAY attempt to extract metadata from the deposit. If the <span class="code_inline">Metadata-Relevant</span> is <span class="code_inline">false</span> the server SHOULD NOT attempt to extract metadata from the deposit.</li>
</ul>
<p>
Once the server has processed the request it is RECOMMENDED that it returns a Deposit Receipt as described in <a href="#depositreceipt">Section 10: Deposit Receipt</a> with the HTTP status code <span class="code_inline">201 (Created)</span>. The server MAY, though, return any response which it feels appropriate, and this profile does not limit the response types in any way. Nonetheless, the server MUST include an HTTP <span class="code_inline">Location</span> header with the IRI of the created resource (in the case of an individual file deposit) or the Media Resource itself (in the case of a package deposit). If an individual file has been deposited, the IRI of the created resource SHOULD be actionable as per <a href="#protocoloperations_swordactionableiris">Section 6.10: SWORD Actionable IRIs</a>.
</p>
<p>
For example:
</p>
<div class="code">
<pre>
201 Created
Location: [File-IRI]
[optional Deposit Receipt]
</pre>
</div>
<h4><a name="protocoloperations_addingcontent_metadata">6.7.2. Adding New Metadata to a Container</a></h4>
<p>
The client can update the metadata attached to a resource by issuing an HTTP POST of a new Atom Entry document containing metadata embedded as foreign markup to the <strong>SE-IRI</strong>.
</p>
<p><strong>Note: this section does not instruct the server on the best way to handle metadata, only that metadata SHOULD be added and not overwritten; in certain circumstances this may not produce the desired behaviour. Clients who wish to have full control over the metadata content should refer to <a href="#protocoloperations_editingcontent_metadata">Section 6.5.2.</a> instead.</strong></p>
<p>
This operation is intended to allow the client to add metadata to an existing resource without overwriting existing metadata. This could be used, for example, by a self-claim system which allows authors to identify their items and to send to the server metadata pertaining to that particular user without affecting any of the other metadata already associated with the item. This operation is analagous to <a href="#protocoloperations_creatingresource_entry">Section 6.3.3.</a>, although not all metadata sent in this case will necessarily be acted upon. Clients looking for precise control over the metadata record associated with an entry should refer to <a href="#protocoloperations_editingcontent_metadata">Section 6.5.2.</a> instead.
</p>
<p>The client must fulfill the following requirements:</p>
<ul>
<li>The client MUST supply a <span class="code_inline">Content-Type</span> header with the value <span class="code_inline">application/atom+xml</span> or <span class="code_inline">application/atom+xml;type=entry</span></li>
<li>The client MAY provide an <span class="code_inline">In-Progress</span> header with a value of <span class="code_inline">true</span> or <span class="code_inline">false</span> [<a href="#sword001">SWORD001</a>]</li>
<li>The client MAY provide an <span class="code_inline">On-Behalf-Of</span> header [<a href="#sword001">SWORD001</a>].</li>
<li>The client MAY add Dublin Core [<a href="#dublincore">DublinCore</a>] terms to the Entry as foreign markup; the terms MUST be embedded as direct children of the <span class="code_inline">atom:entry</span> element.</li>
<li>The client MAY add any other metadata format or foreign markup to the <span class="code_inline">atom:entry</span> element</li>
</ul>
<div class="code">
<pre>
POST SE-IRI HTTP/1.1
Host: example.org
Content-Type: application/atom+xml;type=entry
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: [content length]
In-Progress: true
On-Behalf-Of: jbloggs
[entry document]
</pre>
</div>
<p>
The requirements placed on the server here are:
</p>
<ul>
<li>If there is no <span class="code_inline">In-Progress</span> header, the server MUST assume that it is <span class="code_inline">false</span>, and MUST behave as described in <a href="#continueddeposit">Section 9: Continued Deposit</a>.</li>
<li>If there is an <span class="code_inline">On-Behalf-Of</span> header, the server MUST behave as described in <a href="#authenticationmediateddeposit">Section 8: Authentication and Mediated Deposit</a>.</li>
<li>The server MUST be able to interpret and later reflect the Dublin Core [<a href="#dublincore">DublinCore</a>] foreign markup in the <span class="code_inline">atom:entry</span> element, but MAY NOT understand any other embedded formats, but MUST NOT generate an error on the presence of not-understood markup.</li>
<li>The server SHOULD only add metadata and not overwrite any existing metadata, but exact implementation will depend on the functions of the server. For example, if the server's metadata schema permits only a single instance a particular field, then the original value should be kept and the new value discarded; wheras if the schema permits multiple instances of a field the server may add the new values to the existing values without overwriting.</li>
</ul>
<p>
Once the server has processed the request it SHOULD return a Deposit Receipt as described in <a href="#depositreceipt">Section 10: Deposit Receipt</a> with the HTTP status code <span class="code_inline">200 (OK)</span>. The Deposit Receipt MUST be available under the <strong>Edit-IRI</strong> (Member Entry IRI), which the server MAY supply in the <span class="code_inline">Location</span> header.
</p>
<p>
For example:
</p>
<div class="code">
<pre>
200 OK
Location: [Edit-IRI]
[optional Deposit Receipt]
</pre>
</div>
<h4><a name="protocoloperations_addingcontent_multipart">6.7.3. Adding New Metadata and Packages or Files to a Resource with Multipart</a></h4>
<p>
The client can add new content and update the metadata attached to a resource by issuing an HTTP POST of an Atom Multipart [<a href="#atommultipart">AtomMultipart</a>] document to the <strong>SE-IRI</strong>.
</p>
<p><strong>Note: this section does not instruct the server on the best way to handle metadata or content: only that metadata SHOULD be added and not overwritten and that the content SHOULD be added to the existing Media Resource. If the client requires detailed control over metadata and content see <a href="#protocoloperations_editingcontent_metadata">Section 6.5.2</a> and <a href="#protocoloperations_addingcontent_mediaresource">Section 6.7.1</a> instead.</strong></p>
<p>
This operation is intended to allow the client to add metadata and content to an existing resource without overwriting existing metadata. The client would do this, perhaps, in a collaborative authoring environment when both files and metadata associated with them are coming from multiple sources. This operation is analagous to <a href="#protocoloperations_creatingresource_multipart">Section 6.3.2.</a> except that the target IRI is the <strong>EM-IRI</strong> as the container already exists and may already contain content and metadata. Clients looking for detailed control over metadata and content should see <a href="#protocoloperations_editingcontent_metadata">Section 6.5.2</a> and <a href="#protocoloperations_addingcontent_mediaresource">Section 6.7.1</a> instead.</strong>
</p>
<p>The client must fulfill the following requirements:</p>
<ul>
<li>The client MUST comply with the rules laid out in [<a href="#atommultipart">AtomMultipart</a>]</li>
<li>The client MUST supply a <span class="code_inline">Content-Disposition</span> header of type <span class="code_inline">attachment</span> on the Entry Part with a <span class="code_inline">name</span> parameter set to <span class="code_inline">atom</span> [<a href="#sword004">SWORD004</a>]</li>
<li>The client MUST supply a <span class="code_inline">Content-Disposition</span> header of type <span class="code_inline">attachment</span> on the Media Part with a <span class="code_inline">name</span> parameter set to <span class="code_inline">payload</span> and a <span class="code_inline">filename</span> parameter [<a href="#sword004">SWORD004</a>] (note that this requires the filename be expressed in ASCII).</li>
<li>The client SHOULD supply a <span class="code_inline">Content-MD5</span> header with the MD5 checksum hex encoded for the binary content on the Media Part</li>
<li>The client SHOULD supply a <span class="code_inline">Packaging</span> header [<a href="#sword001">SWORD001</a>] providing the IRI (or other allowed) of the packaging format used on the Media Part</li>
<li>The client MAY provide an <span class="code_inline">In-Progress</span> header with a value of <span class="code_inline">true</span> or <span class="code_inline">false</span> [<a href="#sword001">SWORD001</a>] on the main HTTP header</li>
<li>The client MAY provide an <span class="code_inline">On-Behalf-Of</span> header [<a href="#sword001">SWORD001</a>] on the main HTTP header</li>
<li>The client MAY add Dublin Core [<a href="#dublincore">DublinCore</a>] terms to the Entry as foreign markup; the terms MUST be embedded as direct children of the <span class="code_inline">atom:entry</span> element.</li>
<li>The client MAY add any other metadata format to the <span class="code_inline">atom:entry</span> element</li>
<li>The client MAY provide a <span class="code_inline">Metadata-Relevant</span> header, with the value <span class="code_inline">true</span>, although this is largely redundant (and is mentioned here only for a complete understanding of the behaviour the server will exhibit). A value of <span class="code_inline">false</span> is not permitted.</li>
</ul>
<p>
For example:
</p>
<div class="code">
<pre>
POST SE-IRI HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: [content length]
Content-Type: multipart/related;
boundary="===============1605871705==";
type="application/atom+xml"
In-Progress: true
On-Behalf-Of: jbloggs
Slug: [suggested identifier]
MIME-Version: 1.0
Media Post
--===============1605871705==
Content-Type: application/atom+xml; charset="utf-8"
Content-Disposition: attachment; name="atom"
MIME-Version: 1.0
&lt;?xml version="1.0"?&gt;
&lt;entry xmlns="http://www.w3.org/2005/Atom"
xmlns:dcterms="http://purl.org/dc/terms/"&gt;
&lt;title&gt;Title&lt;/title&gt;
&lt;id&gt;urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a&lt;/id&gt;
&lt;updated&gt;2005-10-07T17:17:08Z&lt;/updated&gt;
&lt;author&gt;&lt;name&gt;Contributor&lt;/name&gt;&lt;/author&gt;
&lt;summary type="text"&gt;The abstract&lt;/summary&gt;
&lt;!-- some embedded metadata --&gt;
&lt;dcterms:abstract&gt;The abstract&lt;/dcterms:abstract&gt;
&lt;dcterms:accessRights&gt;Access Rights&lt;/dcterms:accessRights&gt;
&lt;dcterms:alternative&gt;Alternative Title&lt;/dcterms:alternative&gt;
&lt;dcterms:available&gt;Date Available&lt;/dcterms:available&gt;
&lt;dcterms:bibliographicCitation&gt;Bibliographic Citation&lt;/dcterms:bibliographicCitation&gt;
&lt;dcterms:contributor&gt;Contributor&lt;/dcterms:contributor&gt;
&lt;dcterms:description&gt;Description&lt;/dcterms:description&gt;
&lt;dcterms:hasPart&gt;Has Part&lt;/dcterms:hasPart&gt;
&lt;dcterms:hasVersion&gt;Has Version&lt;/dcterms:hasVersion&gt;
&lt;dcterms:identifier&gt;Identifier&lt;/dcterms:identifier&gt;
&lt;dcterms:isPartOf&gt;Is Part Of&lt;/dcterms:isPartOf&gt;
&lt;dcterms:publisher&gt;Publisher&lt;/dcterms:publisher&gt;
&lt;dcterms:references&gt;References&lt;/dcterms:references&gt;
&lt;dcterms:rightsHolder&gt;Rights Holder&lt;/dcterms:rightsHolder&gt;
&lt;dcterms:source&gt;Source&lt;/dcterms:source&gt;
&lt;dcterms:title&gt;Title&lt;/dcterms:title&gt;
&lt;dcterms:type&gt;Type&lt;/dcterms:type&gt;
&lt;/entry&gt;
--===============1605871705==
Content-Type: application/zip
Content-Disposition: attachment; name=payload; filename=[filename]
Packaging: http://purl.org/net/sword/package/SimpleZip
Content-MD5: [md5-digest]
MIME-Version: 1.0
...binary package data...
--===============1605871705==--
</pre>
</div>
<p>
The requirements placed on the server here are:
</p>
<ul>
<li>The server SHOULD verify the <span class="code_inline">Content-MD5</span> header against the Media Part. If the check fails, the server MUST respond with 412 Precondition Failed. See <a href="#errordocuments">Section 12: Error Documents</a>.</li>
<li>Server implementations MUST adopt the behaviour and requirements in [<a href="#rfc2183">RFC2183</a>] with respect to the <span class="code_inline">Content-Disposition</span> header for the Media Part.</li>
<li>If there is no <span class="code_inline">Packaging</span> header on the Media Part, the server SHOULD assume that it is the binary packaging format (See <a href="#iris">Section 5: IRIs</a>)</li>
<li>Server implementations MUST adopt the behaviour and requirements in Section 9.7 of [<a href="#atompub">AtomPub</a>] with respect to the <span class="code_inline">Slug</span> header</li>
<li>If there is no <span class="code_inline">In-Progress</span> header, the server MUST assume that it is <span class="code_inline">false</span>, and MUST behave as described in <a href="#continueddeposit">Section 9: Continued Deposit</a>.</li>
<li>If there is an <span class="code_inline">On-Behalf-Of</span> header, the server MUST behave as described in <a href="#authenticationmediateddeposit">Section 8: Authentication and Mediated Deposit</a>.</li>
<li>The server MUST be able to interpret the Dublin Core [<a href="#dublincore">DublinCore</a>] foreign markup in the <span class="code_inline">atom:entry</span> element, but MAY NOT understand any other embedded formats, but MUST NOT generate an error on encountering not-understood foreign markup.</li>
<li>The server SHOULD only add metadata and not overwrite any existing metadata, but exact implementation will depend on the functions of the server. For example, if the server's metadata schema permits only a single instance a particular field, then the original value should be kept and the new value discarded; wheras if the schema permits multiple instances of a field the server may add the new values to the existing values without overwriting.</li>
<li>The server SHOULD add all of the content delivered in this operation to the pre-existing Media Resource, although it MAY take advantage of instructions in the packaging format as to how to structure the content appropriately; for example if the packaging format indicates multiple representations of the resource in different languages, these may be described as separate Media Resources with their <span class="code_inline">hreflang</span> attribute set appropriately in the Deposit Receipt</li>
<li>If there is no <span class="code_inline">Metadata-Relevant</span> header, the server MUST assume that it is <span class="code_inline">true</span> and SHOULD use the Entry Part of the deposit as a source of metadata.</li>
</ul>
<p>
Once the server has processed the request it is RECOMMENDED that it returns a Deposit Receipt as described in <a href="#depositreceipt">Section 10: Deposit Receipt</a> with the HTTP status code 201 (Created). The server MAY, though, return any response which it feels appropriate, and this profile does not limit the response types in any way. Nonetheless, the server MUST include an HTTP <span class="code_inline">Location</span> header with the IRI of the Media Resource itself (i.e. the <strong>EM-IRI</strong>).
</p>
<p>
For example:
</p>
<div class="code">
<pre>
201 Created
Location: [EM-IRI]
[optional Deposit Receipt]
<pre>
</div>
<h3><a name="protocoloperations_deleteconteiner">6.8. Deleting the Container</a></h3>
<p>
The client can delete the entire object on the server by issuing an HTTP DELETE request on the <strong>Edit-IRI</strong>, with the following requirements:
</p>
<ul>
<li>The client MAY provide an <span class="code_inline">On-Behalf-Of</span> header [<a href="#sword001">SWORD001</a>]</li>
</ul>
<div class="code">
<pre>
DELETE Edit-IRI HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
On-Behalf-Of: jbloggs
</pre>
</div>
<p>
The requirements placed on the server here are:
</p>
<ul>
<li>If there is an <span class="code_inline">On-Behalf-Of</span> header, the server MUST behave as described in <a href="#authenticationmediateddeposit">Section 8: Authentication and Mediated Deposit</a>.</li>
<li>The server MUST effectively remove the Container and all its content, although implementations may choose to provide versioning or some other mechanism for retaining the deleted content.</li>
<li>The <strong>Edit-IRI</strong> MUST return a 404 Not Found on any future requests.</li>
</ul>
<p>
Once the server has processed the request is MUST respond with an HTTP status code <span class="code_inline">204 (No Content)</span> and leave the response body empty.
</p>
<h3><a name="protocoloperations_statement">6.9. Retrieving the Statement</a></h3>
<p>
The Statement can be retrieved by requesting the IRI provided in the <span class="code_inline">atom:link@rel="http://purl.org/net/sword/terms/statement"</span> element. The format of the statement is identified by the <span class="code_inline">type</span> attribute of the <span class="code_inline">atom:link@rel="http://purl.org/net/sword/terms/statement"</span> element and MUST be <span class="code_inline">application/rdf+xml</span> for an OAI-ORE Resource Map, or <span class="code_inline">application/atom+xml;type=feed</span> for an Atom Feed.
</p>
<p>
It MAY also be possible to content negotiate for the statement on the <strong>Edit-IRI</strong>. All negotiable formats MUST also be available as <span class="code_inline">atom:link</span> elements with <span class="code_inline">@rel="http://purl.org/net/sword/terms/statement"</span>.
</p>
<p>
For details on these serialisations see <a href="#statement">Section 11: The SWORD Statement</a>.
</p>
<p>Servers MAY restrict access to the statement to authenticated users. In either case, the client MAY supply an <span class="code_inline">On-Behalf-Of</span> header for the purposes of indicating provenance to the server.</p>
<h3><a name="protocoloperations_swordactionableiris">6.10. SWORD Actionable IRIs</a></h3>
<p>
In some cases the SWORD protocol will allow the server to provide IRIs to the client which refer to individual file resources (not the <strong>EM-IRI</strong>). This document RECOMMENDS that these IRIs are actionable to the extent that they support not only GET but also PUT and DELETE.
</p>
<p>
If these IRIs are not actionable as defined above then attempts to PUT or DELETE to them MUST result in a <span class="code_inline">403 (Forbidden)</span> or a <span class="code_inline">405 (Method Not Allowed)</span> HTTP response.
</p>
<p>
If these IRIs are actionable as defined above, they SHOULD support the headers as defined in <a href="#protocoloperations_arbitrary">Section 6.11</a>. Responses to action requests MUST be the appropriate HTTP response codes.
</p>
<h3><a name="protocoloperations_arbitrary">6.11. Use of SWORD with arbitrary IRIs</a></h3>
<p>
During normal operation the SWORD server may respond to requests by the client with documents (such as the Statement) which contain IRIs for resources which are not formally covered by this profile. For example, the Statement may include IRIs to files unpacked from an original deposit package and made available independently. Or an implementation of a content management protocol such as CMIS [<a href="#cmis">CMIS</a>] or GData [<a href="#gdata">GData</a>] may provide IRIs for resources or collections of resources.
</p>
<p>
The following headers MAY be used by the client under the following conditions on any IRI outside of the scope of this profile, where the meanings of the headers are as defined in [<a href="#sword001">SWORD001</a>]:
</p>
<table>
<tr><th>Header</th><th>HTTP Method</th></tr>
<tr><td>Packaging</td><td>POST, PUT</td></tr>
<tr><td>Accept-Packaging</td><td>GET</td></tr>
<tr><td>On-Behalf-Of</td><td>GET, POST, PUT, DELETE</td></tr>
<tr><td>Metadata-Relevant</td><td>POST, PUT</td></tr>
</table>
<p>
The client MUST NOT assume that a SWORD server will support these headers for arbitrary IRIs. It is likely that the use of these headers by the client will be through explicit agreement between client and server implementation pairs that these headers will be supported alongside any content management API implemented in addition to SWORD.
</p>
<h2><a name="packaging">7. Packaging</a></h2>
<p>
AtomPub uses the MIME mechanism to describe the data encoding for resources. This mechanism is inadequate where compound types are involved, such as tar archive files, METS packages, SCORM packages, MPEG21 DIDL packages etc. For example, a server might support certain METS profiles but not others. Other servers might be agnostic towards packaging, but support only certain contents within an archive.
</p>
<p>
In order to support package deposit and retrieval, SWORD uses the mechanisms described in [<a href="#sword002">SWORD002</a>] to extend AtomPub.
</p>
<h3><a name="packaging_servicedescription">7.1. Package support in Service description</a></h3>
<p>
The SWORD Service Document uses the <span class="code_inline">sword:acceptPackaging</span> element from [<a href="#sword002">SWORD002</a>] to indicate that a SWORD collection will accept deposits of a particular packaging format. The client SHOULD assume that all packaging formats identified in this element apply to both binary and multipart deposits, and make reasonable requests based on this information. Content Negotiation is an inexact process where multiple "accept" fields are concerned, and it is RECOMMENDED that server implementations provide as coherent a set of rules as possible.
</p>
<p>
Clients should refer to the <span class="code_inline">sword:treatment</span> description in the Service Document to find out the treatment for a particular packaging type.
</p>
<p>
Packages formats SHOULD be identified by a IRI (as per [<a href="#sword002">SWORD002</a>]), but MAY be identified by an arbitrary string.
</p>
<p>
If no <span class="code_inline">sword:acceptPackaging</span> element is supplied the client MUST assume that the server does not formally support any package formats, and should expect everything to be treated as per the server's policies with regard to the mimetype as per the <span class="code_inline">app:accept</span> element.
<div class="code">
<pre>
&lt;?xml version="1.0" encoding='utf-8'?&gt;
&lt;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/"&gt;
&lt;sword:version&gt;2.0&lt;/sword:version&gt;
&lt;workspace&gt;
&lt;atom:title&gt;Main Site&lt;/atom:title&gt;
&lt;collection href="http://www.swordserver.org/atom/geography-collection" &gt;
&lt;atom:title&gt;My Repository : Geography Collection&lt;/atom:title&gt;
&lt;accept&gt;application/zip&lt;/accept&gt;
&lt;sword:collectionPolicy&gt;Collection Policy&lt;/sword:collectionPolicy&gt;
&lt;dcterms:abstract&gt;Collection description&lt;/dcterms:abstract&gt;
<strong> &lt;sword:acceptPackaging&gt;http://purl.org/net/sword/package/METSDSpaceSIP&lt;/sword:acceptPackaging&gt;</strong>
<strong> &lt;sword:acceptPackaging&gt;http://purl.org/net/sword/package/BagIt&lt;/sword:acceptPackaging&gt;</strong>
<strong> &lt;sword:treatment&gt;Treatment description&lt;/sword:treatment&gt;</strong>
&lt;/collection&gt;
&lt;/workspace&gt;
&lt;/service&gt;
</pre>
</div>
<h3><a name="packaging_creation">7.2. Package support during resource creation</a></h3>
<p>
When creating Media Resources, the client SHOULD indicate the archive file MIME type using the HTTP <span class="code_inline">Content-Type</span> header, and SHOULD also give information about content packaging using the <span class="code_inline">Packaging</span> HTTP header [<a href="#sword001">SWORD001</a>].
</p>
<p>
The value of the <span class="code_inline">Packaging</span> header SHOULD match one of values the server has advertised as acceptable for the collection in the manner described in <a href="#packaging_servicedescription">Section 7.1.</a>.
</p>
<p>
If a server receives a POST with an unacceptable <span class="code_inline">Packaging</span> header value, it MUST reject the POST by returning an HTTP response with a status code of <span class="code_inline">415 (Unsupported Media Type)</span> and a SWORD Error document with URI <span class="code_inline">http://purl.net/org/sword/terms/ErrorContent</span> (See <a href="#errordocuments">Section 12: Error Documents</a>), or store the content without further processing (as per [<a href="#sword001">SWORD001</a>]).
</p>
<div class="code">
<pre>
POST Col-IRI HTTP/1.1
Host: example.org
Content-Type: application/zip
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: [content length]
Content-MD5: [md5-digest]
Content-Disposition: filename=myDSpaceMETSItem.zip
<strong>Packaging: http://purl.org/net/sword/package/METSDSpaceSIP</strong>
User-Agent: MyJavaClient/0.1 Restlet/2.0
</pre>
</div>
<h3><a name="packaging_entrydocuments">7.3. Package description in Entry documents</a></h3>
<p>
When describing packaged resources in Media Entry documents, servers MUST use the <span class="code_inline">atom:content@type</span> attribute to describe the MIME type of the resource, and MAY add <span class="code_inline">sword:packaging</span> elements to the <span class="code_inline">atom:entry</span>.
</p>
<p>
If the server does not supply any <span class="code_inline">sword:packaging</span> elements, the client MUST assume that the server only supports a simple zip file packaging format (See <a href="#iris">Section 5: IRIs</a>).
</p>
<div class="code">
<pre>
&lt;?xml version="1.0"?&gt;
&lt;entry xmlns="http://www.w3.org/2005/Atom"
xmlns:sword="http://purl.org/net/sword/"&gt;
&lt;title&gt;My Deposit&lt;/title&gt;
&lt;id&gt;info:something:1&lt;/id&gt;
&lt;updated&gt;2008-08-18T14:27:08Z&lt;/updated&gt;
&lt;author&gt;&lt;name&gt;jbloggs&lt;/name&gt;&lt;/author&gt;
&lt;summary type="text"&gt;A summary&lt;/summary
&lt;generator uri="http://www.swordserver.org/engine" version="1.0"/&gt;
<strong> &lt;content type="application/zip" src="http://swordapp.org/col-IRI/43/my_deposit/package.zip"/&gt;</strong>
<strong> &lt;sword:packaging&gt;http://purl.org/net/sword/package/METSDSpaceSIP&lt;/sword:packaging&gt;</strong>
<strong> &lt;sword:packaging&gt;http://purl.org/net/sword/package/BagIt&lt;/sword:packaging&gt;</strong>
&lt;link rel="edit" href="http://swordapp.org/col-IRI/43/my_deposit.atom" /&gt;
&lt;/entry&gt;
</pre>
</div>
<h3><a name="packaging_negotiation">7.4. Negotiating for package formats</a></h3>
When retrieving a package identified in the <span class="code_inline">atom:content</span> element, the client MAY specify an <span class="code_inline">Accept-Packaging</span> HTTP header [<a href="#sword001">SWORD001</a>] indicating its desired package format. The value of this header SHOULD be one of the formats identified in the <span class="code_inline">sword:packaging</span> elements in the Deposit Receipt. If a packaging format is requested which is not available, the server MUST reject the GET by returning an HTTP response with a status code of <span class="code_inline">406 (Not Acceptable)</span> and a SWORD Error document with URI <span class="code_inline">http://purl.net/org/sword/terms/ErrorContent</span> (See <a href="#errordocuments">Section 12: Error Documents</a>).
<p>For example:</p>
<div class="code">
<pre>
GET /43/my_deposit/package.zip HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: [content length]
<strong>Accept-Packaging: http://purl.org/net/sword/package/METSDSpaceSIP</strong>
User-Agent: MyJavaClient/0.1 Restlet/2.0
</pre>
</div>
<p>
If there are multiple <span class="code_inline">atom:content</span> elements then it will not be clear which support which package formats. Servers are RECOMMENDED to provide as coherent a set of contents as possible.
</p>
<h2><a name="authenticationmediateddeposit">8. Authentication and Mediated Deposit</a></h2>
<p>
In [<a href="#atompub">AtomPub</a>] Section 14, implementations MUST support HTTP Basic Authentication in conjunction with a TLS connection. The SWORD Profile relaxes this requirement: SWORD client and server implementations SHOULD be capable of being configured to use HTTP Basic Authentication [<a href="#rfc2617">RFC2617</a>] in conjunction with a TLS connection as specified by [<a href="#rfc2818">RFC2818</a>].
</p>
<p>
In a number of situations the authenticated user using a SWORD client is not the owner of the deposited resource. SWORD provides a way of representing this usage by allowing clients to set a HTTP header field <span class="code_inline">On-Behalf-Of</span> which, if present SHOULD contain a user principle for the owner of the resource. It is also possible to use this SWORD mediation mechanism for situations such as non-interactive batch deposit in which the authenticated user is a software acting on behalf of a user.
</p>
<p>
The mediation technique described by SWORD is not intrinsically secure - it is assumed that trust between the owning user and the mediating user will be established by extending SWORD, or outside the scope of a resource creation, using a mechanism such as that described by [<a href="#oauth">OAUTH</a>].
</p>
<h3><a name="authenticationmediateddeposit_servicedescription">8.1. Mediation In Service Description</a></h3>
<p>
SWORD servers SHOULD indicate whether they support mediated deposit by including a <span class="code_inline">sword:mediation</span> element containing a text element of either <span class="code_inline">true</span> or <span class="code_inline">false</span> in <span class="code_inline">app:collection</span> elements in Service Documents.
</p>
<p>
Clients SHOULD use the <span class="code_inline">On-Behalf-Of</span> header when retrieving Service Documents if they intend to use the feature for resource creation. Servers MAY use this header information along with authentication and any other information in constructing the Service Document representation returned. For example, the server might include only collections to which the <span class="code_inline">On-Behalf-Of</span> can deposit.
</p>
<div class="code">
<pre>
&lt;?xml version="1.0" encoding='utf-8'?&gt;
&lt;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/"&gt;
&lt;sword:version&gt;2.0&lt;/sword:version&gt;
&lt;workspace&gt;
&lt;atom:title&gt;Main Site&lt;/atom:title&gt;
&lt;collection href="http://swordapp.org/col-IRI/43" &gt;
&lt;atom:title&gt;Collection 43&lt;/atom:title&gt;
&lt;accept&gt;application/xml&lt;/accept&gt;
&lt;accept&gt;application/zip&lt;/accept&gt;
&lt;accept&gt;application/atom+xml&lt;/accept&gt;
&lt;sword:collectionPolicy&gt;Collection Policy&lt;/sword:collectionPolicy&gt;
&lt;dcterms:abstract&gt;Collection description&lt;/dcterms:abstract&gt;
<strong> &lt;sword:mediation&gt;true&lt;/sword:mediation&gt;</strong>
&lt;sword:treatment&gt;treatment description&lt;/sword:treatment&gt;
&lt;sword:packaging&gt;http://purl.org/net/sword/package/BagIt&lt;/sword:packaging&gt;
&lt;/collection&gt;
&lt;/workspace&gt;
&lt;/service&gt;
</pre>
</div>
<p>
If the authentication credentials supplied fail, the server SHOULD respond with an HTTP status <span class="code_inline">401 (Unauthorized)</span>. If the authentication is successful but the user in the <span class="code_inline">On-Behalf-Of</span> header is not recognised the server SHOULD respond with an HTTP status <span class="code_inline">403 (Forbidden)</span> and SHOULD include a SWORD Error document with the URI <span class="code_inline">http://purl.org/net/sword/error/TargetOwnerUnknown</span> (see <a href="#errordocuments">Section 12: Error Documents</a> for details).
</p>
<h3><a name="authenticatedmediateddeposit_recordingusers">8.2. Recording Depositing Users</a></h3>
<p>
In all cases (mediated or not) where a user has authenticated to make a deposit, servers SHOULD preserve the user's identity in the <span class="code_inline">sword:depositedBy</span> property of the SWORD Statement. In mediated deposit, the value given in the <span class="code_inline">On-Behalf-Of</span> header SHOULD be used for the value of the <span class="code_inline">sword:depositedOnBehalfOf</span> property of the SWORD Statement. See <a href="#statement">Section 11: The SWORD Statement</a> for details of the serialisation.
</p>
<h2><a name="continueddeposit">9. Continued Deposit</a></h2>
<p>
As scholarly systems may wish to give the client more control over the publishing process, SWORD uses the <span class="code_inline">In-Progress</span> HTTP header [<a href="#sword001">SWORD001</a>] to allow the client to indicate that a deposit should not yet be injected into any post-submission or pre-publication workflow. The <span class="code_inline">In-Progress</span> header MUST take the value <span class="code_inline">true</span> or <span class="code_inline">false</span>, and if it is not present the server MUST assume that it is <span class="code_inline">false</span> and behave as described below.
</p>
<p>
An example use case for this is that the client may be embedded into a system which uses the SWORD server as a storage layer, but which cannot acquire all of the content for a "finished" item in one deposit operation. Consider a user-facing system which encourages users to upload files one at a time through some web interface, which causes each file to be directly deposited onto the SWORD server. At the start of the deposit the client asserts that deposit is <span class="code_inline">In-Progress</span>, and then proceeds to upload files. If uploading them to the <strong>SE-IRI</strong> the client continues to assert <span class="code_inline">In-Progress: true</span> on each request (if depositing to <strong>EM-IRI</strong> this is not necessary). This goes on until the user confirms that they have uploaded all the relevant files, or navigates away from the page. At that stage, the client can issue a blank HTTP POST request to the SWORD server, with <span class="code_inline">In-Progress: false</span> to complete the deposit.
</p>
<p>
Note that the <span class="code_inline">In-Progress</span> header is intended to indicate to the server that further content will be coming in which is associated with the existing content, before it can be considered "complete". It is not intended to provide workflow control, and clients MUST NOT assume that asserting <span class="code_inline">In-Progress: true</span> will have any specific effect on the state of the item.
</p>
<h3><a name="continueddeposit_complete">9.1. Deposit Complete</a></h3>
<p>
If <span class="code_inline">In-Progress</span> is <span class="code_inline">false</span>, the server MUST assume that it can carry on processing the deposit or deletion as it sees fit.
</p>
<h3><a name="continueddeposit_incomplete">9.2. Deposit Incomplete</a></h3>
<p>
If <span class="code_inline">In-Progress</span> is <span class="code_inline">true</span>, the server SHOULD expect the client to provide further updates to the item some undetermined time in the future. Details of how this is implemented is dependent on the server's purpose. For example, a repository system may hold items which are marked <span class="code_inline">In-Progress</span> in a workspace until such time as a client request indicates that the deposit is complete.
</p>
<h3><a name="continueddeposit_complete">9.3. Completing a Previously Incomplete Deposit</a></h3>
<p>
The client can assert that a deposit process has completed by issuing an HTTP POST to the <strong>SE-IRI</strong> with a blank message body and with the <span class="code_inline">In-Progress</span> header set to false (it may simply omit the header altogether too, as this is treated as <span class="code_inline">In-Progress: false</span> by the server). The client SHOULD specify a <span class="code_inline">Content-Length: 0</span> HTTP header.
</p>
<p>
This operation is effectively equivalent to <a href="#protocoloperations_addingcontent_binary">Section 6.7.2. Adding New Packages or Files to a Container</a>, but with an empty POST body, and the client must fulfill the following requirements:
</p>
<ul>
<li>The client MAY provide an <span class="code_inline">In-Progress</span> header with a value of <span class="code_inline">true</span> or <span class="code_inline">false</span> [<a href="#sword001">SWORD001</a>]</li>
<li>The client MAY provide an <span class="code_inline">On-Behalf-Of</span> header [<a href="#sword001">SWORD001</a>]</li>
</ul>
<div class="code">
<pre>
POST SE-IRI HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
<strong>Content-Length: 0</strong>
User-Agent: MyJavaClient/0.1 Restlet/2.0
<strong>In-Progress: false</strong>
</pre>
</div>
<p>
If <span class="code_inline">In-Progress</span> is <span class="code_inline">false</span>, the server MUST assume that it can carry on processing the deposit or deletion as it sees fit. The server SHOULD NOT modify the existing content.
</p>
<p>
Once the server has processed the request it SHOULD return a Deposit Receipt as described in <a href="#depositreceipt">Section 10: Deposit Receipt</a> with the HTTP status code <span class="code_inline">200 (OK)</span>. The Deposit Receipt MUST be available under the <strong>Edit-IRI</strong> (Member Entry IRI), which the server MAY supply in the <span class="code_inline">Location</span> header.
</p>
<p>
For example:
</p>
<div class="code">
<pre>
200 OK
Location: [Edit-IRI]
[optional Deposit Receipt]
</pre>
</div>
<h2><a name="depositreceipt">10. Deposit Receipt</a></h2>
<p>
On successfully accepting a POST (deposit), implementers SHOULD return an Atom Entry Document with the HTTP response. The Atom Entry Document is known in SWORD as the Deposit Receipt must conform to the following conditions:
</p>
<ul>
<li>It MAY contain information about the metadata associated with the deposit as it is stored on the server. If it does, it SHOULD provide this metadata in extended Dublin Core [<a href="#dublincore">DublinCore</a>], although it MAY also provide it in other formats. Any Dublin Core markup should be in Dublin Core XML and embedded directly in the <span class="code_inline">atom:entry</span> element, not in a <span class="code_inline">dcterms:metadata</span> element.</li>
<li>It MUST contain a Media Entry IRI (<strong>Edit-IRI</strong>), defined by <span class="code_inline">atom:link@rel="edit"</span></li>
<li>It MUST contain a Media Resource IRI (<strong>EM-IRI</strong>), defined by <span class="code_inline">atom:link@rel="edit-media"</span></li>
<li>It MUST contain a SWORD Edit IRI (<strong>SE-IRI</strong>), defined by <span class="code_inline">atom:link@rel="http://purl.org/net/sword/terms/add"</span> which MAY be the same as the <strong>Edit-IRI</strong></li>
<li>It MAY contain an arbitrary number of <span class="code_inline">sword:packaging</span> elements declaring the formats that the Media Resource can be retrieved in</li>
<li>It MUST contain a single <span class="code_inline">sword:treatment</span> element [<a href="#sword003">SWORD003</a>] which contains either a human-readable statement describing treatment the deposited resource has received or a IRI that dereferences to such a description.</li>
<li>It MAY contain a single <span class="code_inline">sword:verboseDescription</span> element [<a href="#sword003">SWORD003</a>] which should contain a verbose description of the deposit process. This MUST only be used for debugging and development purposes, and clients MUST NOT rely on this field to contain anything in particular.</li>
<li>It MAY contain one or more <span class="code_inline">atom:link</span> element with the <span class="code_inline">rel</span> attribute of <span class="code_inline">http://purl.org/net/sword/terms/statement</span>, and the href to a IRI where the statement can be retrieved. The <span class="code_inline">atom:link</span> element MUST contain a type attribute which indicates the mime-type of the statement (for example <span class="code_inline">application/atom+xml;type=feed</span> or <span class="code_inline">application/rdf+xml</span>)</li>
<li>It MAY contain an <span class="code_inline">atom:link@rel="alternate"</span> element with an <span class="code_inline">href</span> attribute which points to the splash page of the item on the server</li>
<li>It SHOULD contain a single <span class="code_inlin">atom:link</span> element with the <span class="code_inline">rel</span> attribute of <span class="code_inline">http://purl.org/net/sword/terms/originalDeposit</span> which provides the IRI identifying the package or file deposited in the current request. This information is transient and will only be present when responding to a deposit, it is not required that it be available in the Entry Document retreived from the <stong>EM-IRI</strong>.</li>
<li>It SHOULD, if relevant, contain zero or more <span class="code_inline">atom:link</span> elements with the <span class="code_inline">rel</span> attribute of <span class="code_inline">http://purl.org.net/sword/terms/derivedResource</span> which provides the IRIs identifying any content resources which were derived or extracted from the originally deposited resource (e.g. the files unpacked from a zip file). These IRIs SHOULD be actionable as per <a href="#protocoloperations_swordactionableiris">Section 6.10: SWORD Actionable IRIs</a>.</li>
</ul>
<p>
For example:
</p>
<div class="code">
<pre>
&lt;entry xmlns="http://www.w3.org/2005/Atom"
xmlns:sword="http://purl.org/net/sword/"
xmlns:dcterms="http://purl.org/dc/terms/"&gt;
&lt;title&gt;My Deposit&lt;/title&gt;
&lt;id&gt;info:something:1&lt;/id&gt;
&lt;updated&gt;2008-08-18T14:27:08Z&lt;/updated&gt;
&lt;summary type="text"&gt;A summary&lt;/summary&gt;
&lt;generator uri="http://www.myrepository.ac.uk/sword-plugin" version="1.0"/&gt;
<strong>
&lt;!-- the item's metadata --&gt;
&lt;dcterms:abstract&gt;The abstract&lt;/dcterms:abstract&gt;
&lt;dcterms:accessRights&gt;Access Rights&lt;/dcterms:accessRights&gt;
&lt;dcterms:alternative&gt;Alternative Title&lt;/dcterms:alternative&gt;
&lt;dcterms:available&gt;Date Available&lt;/dcterms:available&gt;
&lt;dcterms:bibliographicCitation&gt;Bibliographic Citation&lt;/dcterms:bibliographicCitation&gt;
&lt;dcterms:contributor&gt;Contributor&lt;/dcterms:contributor&gt;
&lt;dcterms:description&gt;Description&lt;/dcterms:description&gt;
&lt;dcterms:hasPart&gt;Has Part&lt;/dcterms:hasPart&gt;
&lt;dcterms:hasVersion&gt;Has Version&lt;/dcterms:hasVersion&gt;
&lt;dcterms:identifier&gt;Identifier&lt;/dcterms:identifier&gt;
&lt;dcterms:isPartOf&gt;Is Part Of&lt;/dcterms:isPartOf&gt;
&lt;dcterms:publisher&gt;Publisher&lt;/dcterms:publisher&gt;
&lt;dcterms:references&gt;References&lt;/dcterms:references&gt;
&lt;dcterms:rightsHolder&gt;Rights Holder&lt;/dcterms:rightsHolder&gt;
&lt;dcterms:source&gt;Source&lt;/dcterms:source&gt;
&lt;dcterms:title&gt;Title&lt;/dcterms:title&gt;
&lt;dcterms:type&gt;Type&lt;/dcterms:type&gt;
</strong>
<strong> &lt;sword:verboseDescription&gt;Verbose description&lt;/sword:verboseDescription&gt;</strong>
<strong> &lt;sword:treatment&gt;Unpacked. JPEG contents converted to JPEG2000.&lt;/sword:treatment&gt;</strong>
<strong> &lt;link rel="alternate" href="http://www.swordserver.ac.uk/col1/mydeposit.html"/&gt;</strong>
&lt;content type="application/zip" src="http://www.swordserver.ac.uk/col1/mydeposit"/&gt;
<strong> &lt;link rel="edit-media" href="http://www.swordserver.ac.uk/col1/mydeposit"/&gt;</strong>
<strong> &lt;link rel="edit" href="http://www.swordserver.ac.uk/col1/mydeposit.atom" /&gt;</strong>
<strong> &lt;link rel="http://purl.org/net/sword/terms/add" href="http://www.swordserver.ac.uk/col1/mydeposit.atom" /&gt;</strong>
<strong> &lt;sword:packaging&gt;http://purl.org/net/sword/package/BagIt&lt;/sword:packaging&gt;</strong>
<strong>
&lt;link rel="http://purl.org/net/sword/terms/originalDeposit"
type="application/zip"
href="http://www.swordserver.ac.uk/col1/mydeposit/package.zip"/&gt;
&lt;link rel="http://purl.org/net/sword/terms/derivedResource"
type="application/pdf"
href="http://www.swordserver.ac.uk/col1/mydeposit/file1.pdf"/&gt;
&lt;link rel="http://purl.org/net/sword/terms/derivedResource"
type="application/pdf"
href="http://www.swordserver.ac.uk/col1/mydeposit/file2.pdf"/&gt;
&lt;link rel="http://purl.org/net/sword/terms/statement"
type="application/atom+xml;type=feed"
href="http://www.swordserver.ac.uk/col1/mydeposit.feed"/&gt;
&lt;link rel="http://purl.org/net/sword/terms/statement"
type="application/rdf+xml"
href="http://www.swordserver.ac.uk/col1/mydeposit.rdf"/&gt;
</strong>
&lt;/entry&gt;
</pre>
</div>
<h2><a name="statement">11. The SWORD Statement</a></h2>
<p>
The Statement is a document which describes two features of the object as it appears on the server:
</p>
<ol>
<li><strong>Structure</strong>. This may include originally uploaded content files, unpackaged content, derived content and any other features of the object</li>
<li><strong>State</strong>. This allows the server to indicate to the client some information with regard to the state of the item on the server, including but not limited, to its ingest workflow position.</li>
</ol>
<h3><a name="statement_predicates">11.1. Predicates used by the Statement</a></h3>
<p>
All predicates used by the statement in any of its serialisations are defined here, and all exist under the sword namespace:
</p>
<div class="code">
http://purl.org/net/sword/terms/
</div>
<h4><a name="statement_predicates_originaldeposit">11.1.1. sword:originalDeposit</a></h4>
<p>
<strong>IRI</strong>: http://purl.org/net/sword/terms/originalDeposit
</p>
<p>
This is used to indicate the IRI of a resource on the server which was an original deposit package. This allows the client to easily identify any packages which form the basis of the original deposit among other parts of the object which may be derived from the original.
</p>
<p>
In XML this may be serialised as:
</p>
<div class="code">
&lt;sword:originalDeposit href="http://location/of/deposit"/&gt;
</div>
<p>
In RDF/XML this can be serialised as as:
</p>
<div class="code">
&lt;sword:originalDepsit rdf:resource="http://location/of/deposit"/&gt;
</div>
<h4><a name="statement_predicates_state">11.1.2. sword:state</a></h4>
<p>
<strong>IRI</strong>: http://purl.org/net/sword/terms/state
</p>
<p>
This is used to supply the IRI representing the state of an item on the server. This can be any IRI, and is not constrained to any ontology. This can be used in combination with <span class="code_inline">sword:stateDescription</span> to provide more details to the client.
</p>
<p>
In XML this may be serialised as:
</p>
<div class="code">
&lt;sword:state href="http://sword/state"/&gt;
</div>
<p>
In RDF/XML this can be serialised as:
</p>
<div class="code">
&lt;sword:state rdf:resource="http://sword/state" /&gt;
</div>
<h4><a name="statement_predicates_packaging">11.1.3. sword:packaging</a></h4>
<p>
<strong>IRI</strong>: http://purl.org/net/sword/terms/packaging
</p>
<p>
This is used to identify the packaging format of a resource. Particularly, if used in conjunction with <span class="code_inline">sword:originalDeposit</span>, this can be used to indicate the package format that an original deposit package used.
</p>
<p>
In XML this may be serialised as:
</p>
<div class="code">
<pre>
&lt;sword:originalDeposit href="http://location/of/deposit"&gt;
&lt;sword:packaging&gt;http://sword/packaging/&lt;/sword:packaging&gt;
&lt;/sword:originalDeposit&gt;
</pre>
</div>
<p>
In RDF/XML this can be serialised as:
</p>
<div class="code">
<pre>
&lt;sword:originalDepsit rdf:resource="http://location/of/deposit"/&gt;
&lt;rdf:Description rdf:about="http://location/of/deposit"&gt;
&lt;sword:packaging rdf:resource="http://sword/packaging/"/&gt;
&lt;/rdf:Description&gt;
</pre>
</div>
<h4><a name="statement_predicates_depositedon">11.1.4. sword:depositedOn</a></h4>
<p>
<strong>IRI</strong>: http://purl.org/net/sword/terms/depositedOn
</p>
<p>
This is used to provide a user who was responsible for depositing an original sword package. The use credentials may just be the username of the depositor, but the server is free to add further details where necessary.
</p>
<p>
In XML this may be serialised as:
</p>
<div class="code">
<pre>
&lt;sword:originalDeposit href="http://location/of/deposit"&gt;
&lt;sword:depositedOn&gt;2011-01-01T00:00:00Z&lt;/sword:depositedOn&gt;
&lt;/sword:originalDeposit&gt;
</pre>
</div>
<p>
In RDF/XML this may be serialised as
</p>
<div class="code">
<pre>
&lt;sword:originalDepsit rdf:resource="http://location/of/deposit"/&gt;
&lt;rdf:Description rdf:about="http://location/of/deposit"&gt;
&lt;sword:depositedOn rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime"&gt;2011-01-01T00:00:00Z&lt;/sword:depositedOn&gt;
&lt;/rdf:Description&gt;
</pre>
</div>
<h4><a name="statement_predicates_depositedby">11.1.5. sword:depositedBy</a></h4>
<p>
<strong>IRI</strong>: http://purl.org/net/sword/terms/depositedBy
</p>
<p>
This is used to provide a user who was responsible for depositing an original sword package. The use credentials may just be the username of the depositor, but the server is free to add further details where necessary.
</p>
<p>
In XML this may be serialised as:
</p>
<div class="code">
<pre>
&lt;sword:originalDeposit href="http://location/of/deposit"&gt;
&lt;sword:depositedBy&gt;jbloggs&lt;/sword:depositedBy&gt;
&lt;/sword:originalDeposit&gt;
</pre>
</div>
<p>
In RDF/XML this may be serialised as
</p>
<div class="code">
<pre>
&lt;sword:originalDepsit rdf:resource="http://location/of/deposit"/&gt;
&lt;rdf:Description rdf:about="http://location/of/deposit"&gt;
&lt;sword:depositedBy&gt;jbloggs&lt;/sword:depositedBy&gt;
&lt;/rdf:Description&gt;
</pre>
</div>
<h4><a name="statement_predicates_obo">11.1.6. sword:depositedOnBehalfOf</a></h4>
<p>
<strong>IRI</strong>: http://purl.org/net/sword/terms/depositedOnBehalfOf
</p>
<p>
This is used to provide the user for whom the original sword package was deposited on behalf of. The use credentials may just be the username of the depositor, but the server is free to add further details where necessary.
</p>
<p>
In XML this may be serialised as:
</p>
<div class="code">
<pre>
&lt;sword:originalDeposit href="http://location/of/deposit"&gt;
&lt;sword:depositedOnBehalfOf&gt;jbloggs&lt;/sword:depositedOnBehalfOf&gt;
&lt;/sword:originalDeposit&gt;
</pre>
</div>
<p>
In RDF/XML this may be serialised as
</p>
<div class="code">
<pre>
&lt;sword:originalDepsit rdf:resource="http://location/of/deposit"/&gt;
&lt;rdf:Description rdf:about="http://location/of/deposit"&gt;
&lt;sword:depositedOnBehalfOf&gt;jbloggs&lt;/sword:depositedOnBehalfOf&gt;
&lt;/rdf:Description&gt;
</pre>
</div>
<h4><a name="statement_predicates_description">11.1.7. sword:stateDescription</a></h4>
<p>
<strong>IRI</strong>: http://purl.org/net/sword/terms/stateDescription
</p>
<p>
This is used to provide a human readable description of the state that the item is in on the server. This is used in conjunction with the <span class="code_inline">sword:state</span> to provide additional details for the client to use in its interface with the end user.
</p>
<p>
In XML this may be serialised as:
</p>
<div class="code">
<pre>
&lt;sword:state href="http://sword/state"&gt;
&lt;sword:stateDescription&gt;The item has passed through the workflow and is now archived&lt;/sword:stateDescription&gt;
&lt;/sword:state&gt;
</pre>
</div>
<p>
In RDF/XML this may be serialised as
</p>
<div class="code">
<pre>
&lt;sword:state rdf:resource="http://sword/state"/&gt;
&lt;rdf:Description rdf:about="http://sword/state"&gt;
&lt;sword:stateDescription&gt;The item has passed through the workflow and is now archived&lt;/sword:stateDescription&gt;
&lt;/rdf:Description&gt;
</pre>
</div>
<h3><a name="statement_requirements">11.2. Statement Requirements</a></h3>
<p>
This section details the requirements of a Statement document. For specific details
as to how to implement these in the various serialisations, see later sections.
</p>
<ul>
<li>The Statement SHOULD identify any original deposit packages with the <span class="code_inline">sword:originalDeposit</span> term</li>
<li>The Statement MAY specify one or more states for the item on the server with the <span class="code_inline">sword:state</span> term</li>
<li>If present, the <span class="code_inline">sword:state</span> term SHOULD include a human readable description in the <span class="code_inline">sword:stateDescription</span> term</li>
<li>If present, the <span class="code_inline">sword:originalDeposit</span> term MAY include one or more <span class="code_inline">sword:packaging</span> terms</li>
<li>If present, the <span class="code_inline">sword:originalDeposit</span> term MAY include the date the package was originally deposited in the <span class="code_inline">sword:depositedOn</span> term</li>
<li>If present, the <span class="code_inline">sword:originalDeposit</span> term MAY include the depositor of the package in the <span class="code_inline">sword:depositedBy</span> term</li>
<li>If present, the <span class="code_inline">sword:originalDeposit</span> term MAY include the user on whose behalf the deposit was made in the <span class="code_inline">sword:depositedOnBehalfOf</span> term</li>
</ul>
<p>
The client's responsibilities are:
</p>
<ul>
<li>If no <span class="code_inline">sword:packaging</span> term is provided on <span class="code_inline">sword:originalDeposit</span>, the client MUST assume only a simple zip packaging format (See <a href="#iris">Section 5: IRIs</a>).</li>
</ul>
<h3><a name="statement_oaiore">11.3. OAI-ORE Serialisation</a></h3>
<p>
The SWORD statement can be provided as an OAI-ORE Resource [<a href="#oaiore">OAIORE</a>] Map with SWORD extensions. For an RDF document to comply with the requirements of the SWORD statement it needs to meet the following requirements but is not constrained in any way as to what additional data is provided alongside. As such, it is expected that the SWORD statement may be included with existing RDF serialisations of objects provided by the server.
</p>
<p>
The responsibilities of the server are (as serialisation-specific versions of the requirements listed in <a href="#statement_requirements">11.2. Statement Requirements)</a>:
</p>
<ul>
<li>The aggregation SHOULD identify any original deposit packages with the <span class="code_inline">sword:originalDeposit</span> term</li>
<li>The aggregation MAY specify one or more states for the item on the server with the <span class="code_inline">sword:state</span> term</li>
<li>If present, the <span class="code_inline">sword:state</span> term SHOULD include a human readable description in the <span class="code_inline">sword:stateDescription</span> term</li>
<li>If present, the <span class="code_inline">sword:originalDeposit</span> term MAY include one or more <span class="code_inline">sword:packaging</span> terms</li>
<li>If present, the <span class="code_inline">sword:originalDeposit</span> term MAY include the date the package was originally deposited in the <span class="code_inline">sword:depositedOn</span> term</li>
<li>If present, the <span class="code_inline">sword:originalDeposit</span> term MAY include the depositor of the package in the <span class="code_inline">sword:depositedBy</span> term</li>
<li>If present, the <span class="code_inline">sword:originalDeposit</span> term MAY include the user on whose behalf the deposit was made in the <span class="code_inline">sword:depositedOnBehalfOf</span> term</li>
<li>The statement MAY include any other ORE terms, and any other terms from other ontologies</li>
<li>All individual files which are listed as <span class="code_inline">ore:aggregation</span> elements SHOULD be actionable as per <a href="#protocoloperations_swordactionableiris">Section 6.10: SWORD Actionable IRIs</a>.</li>
</ul>
<p>
For example:
</p>
<div class="code">
<pre>
&lt;rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ore="http://www.openarchives.org/ore/terms/"&gt;
&lt;rdf:Description rdf:about="http://localhost:8080/edit-IRI/43/my_deposit"&gt;
&lt;ore:describes rdf:resource="http://localhost:8080/agg-IRI/43/my_deposit"/&gt;
&lt;/rdf:Description&gt;
&lt;rdf:Description rdf:about="http://localhost:8080/agg-IRI/43/my_deposit"&gt;
&lt;ore:isDescribedBy rdf:resource="http://localhost:8080/edit-IRI/43/my_deposit"/&gt;
&lt;ore:aggregates rdf:resource="http://localhost:8080/part-IRI/43/my_deposit/example.zip"/&gt;
&lt;sword:originalDeposit rdf:resource="http://localhost:8080/part-IRI/43/my_deposit/example.zip"/&gt;
&lt;sword:state rdf:resource="http://purl.org/net/sword/state/archived"/&gt;
&lt;/rdf:Description&gt;
&lt;rdf:Description rdf:about="http://localhost:8080/part-IRI/43/my_deposit/example.zip"&gt;
&lt;sword:packaging rdf:resource="http://purl.org/net/sword/package/SimpleZip"/&gt;
&lt;sword:depositedOn rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime"&gt;
2011-02-25T14:40:09Z
&lt;/sword:depositedOn&gt;
&lt;sword:depositedBy rdf:datatype="http://www.w3.org/2001/XMLSchema#string"&gt;
sword
&lt;/sword:depositedBy&gt;
&lt;/rdf:Description&gt;
&lt;rdf:Description rdf:about="http://purl.org/net/sword/state/archived"&gt;
&lt;sword:stateDescription&gt;
The work has passed through review and is now in the archive
&lt;/sword:stateDescription&gt;
&lt;/rdf:Description&gt;
&lt;/rdf:RDF&gt;
</pre>
</div>
<p>
The client's responsibilities are (in addition to those specified in <a href="#statement_requirements">11.2. Statement Requirements</a>):
</p>
<ul>
<li>The client MUST ignore without error any terms in the document that it does not understand</li>
<li>The client SHOULD recognise parts of the resource map which are not identified with <span class="code_inline">sword:originalDeposit</span> terms as content of the item, and represent them appropriately</li>
</ul>
<h3><a name="statement_atom">11.4. Atom Serialisation</a></h3>
<p>
The SWORD statement can be provided as an Atom Feed [<a href="#atom">Atom</a>] with sword extensions. For an Atom Feed document to comply with the requirements of the SWORD statement it needs to meet the following requirements but is not constrained in any way as to what additional data is provided alongside. As such, it is expected that the SWORD statement may be included with existing serialisations provided by the server, such as with any GData [<a href="#gdata">GData</a>] extensions.
</p>
<p>
The responsibilities of the server are (as serialisation-specific versions of the requirements listed in <a href="#statement_requirements">11.2. Statement Requirements)</a>:
</p>
<ul>
<li>The Feed MUST represent files contained in the item as an <span class="code_inline">atom:entry</span> element (this does not mandate that all files in the item are listed, though)</li>
<li>Each <span class="code_inline">atom:entry</span> which is an original deposit file MUST have an <span class="code_inline">atom:category</span> element with the term <span class="code_inline">sword:originalDeposit</span> (this does not mandate that all original deposits are listed as entries)</li>
<li>The Feed MAY specify one more more states for the item on the server with an <span class="code_inline">atom:category</span> element with the term <span class="code_inline">http://purl.org/net/sword/terms/state</span> root <span class="code_inline">atom:feed</span> element</li>
<li>If present, the <span class="code_inline">sword:state</span> category term SHOULD include a human readable description in the body of the <span class="code_inline">atom:category</span> element.</li>
<li>Each <span class="code_inline">atom:entry</span> which is an original deposit MAY include one or more <span class="code_inline">sword:packaging</span> terms as foreign markup in the <span class="code_inline">atom:entry</span></li>
<li>Each <span class="code_inline">atom:entry</span> which is an original deposit MAY include the date the package was originally deposited in the <span class="code_inline">sword:depositedOn</span> term as foreign markup in the <span class="code_inline">atom:entry</span></li>
<li>Each <span class="code_inline">atom:entry</span> which is an original deposit MAY include the depositor of the package in the <span class="code_inline">sword:depositedBy</span> term as foreign markup in the <span class="code_inline">atom:entry</span></li>
<li>Each <span class="code_inline">atom:entry</span> which is an original deposit MAY include the user on whose behalf the deposit was made in the <span class="code_inline">sword:depositedOnBehalfOf</span> term as foreign markup in the <span class="code_inline">atom:entry</span></li>
<li>The statement MAY include any other foreign markup and legitimate atom extensions</li>
</ul>
<p>
For example:
</p>
<div class="code">
<pre>
&lt;atom:feed xmlns:sword="http://purl.org/net/sword/terms/"
xmlns:atom="http://www.w3.org/2005/Atom"&gt;
&lt;atom:category scheme="http://purl.org/net/sword/terms/state"
term="[state identifier]"
label="State"&gt;
The work has passed through review and is now in the archive
&lt;/atom:category&gt;
&lt;atom:entry&gt;
&lt;atom:category scheme="http://purl.org/net/sword/terms/"
term="http://purl.org/net/sword/terms/originalDeposit"
label="Orignal Deposit"/&gt;
&lt;atom:content type="application/zip"
src="http://localhost:8080/part-IRI/43/my_deposit/example.zip"/&gt;
&lt;sword:packaging&gt;http://purl.org/net/sword/package/SimpleZip&lt;/sword:packaging&gt;
&lt;sword:depositedOn&gt;2011-03-02T20:50:06Z&lt;/sword:depositedOn&gt;
&lt;sword:depositedBy&gt;sword&lt;/sword:depositedBy&gt;
&lt;sword:depositedOnBehalfOf&gt;jbloggs&lt;/sword:depositedBy&gt;
&lt;/atom:entry&gt;
&lt;/atom:feed&gt;
</pre>
</div>
<p>
The client's responsibilities are (in addition to those specified in <a href="#statement_requirements">11.2. Statement Requirements</a>):
</p>
<ul>
<li>The client MUST ignore without error any terms in the document that it does not understand</li>
</ul>
<h2><a name="errordocuments">12. Error Documents</a></h2>
<p>
SWORD adds a new class of document to [<a href="#atompub">AtomPub</a>] that gives server implementations the ability to describe error conditions more fully than HTTP response codes allow, as per [<a href="#sword003">SWORD003</a>]. If a server is reporting an error condition in response to a resource POST, it SHOULD also return a document with a root element of sword:error. The sword:error element SHOULD have an href attribute containing a IRI that identifies the error. Errors in the SWORD namespace are reserved and legal values are enumerated below. Implementations MAY define their own errors, but MUST use a different namespace to do so.
</p>
<p>
The <span class="code_inline">sword:error</span> element MAY contain any of the elements normally used in the Deposit Receipt, but all fields are OPTIONAL.
</p>
<p>
The error document SHOULD contain an <span class="code_inline">atom:summary</span> element with a short description of the error.
</p>
<p>
The error document MAY contain a <span class="code_inline">sword:verboseDescription</span> element with a long description of the problem or any other appropriate software-level debugging output (e.g. a stack trace). Server implementations may wish to provide this for client developers' convenience, but may wish to disable such output in any production systems.
</p>
<p>The server SHOULD specify that the <span class="code_inline">Content-Type</span> of the is <span class="code_inline">text/xml</span> or <span class="code_inline">application/xml</span>.
<h3><a name="errordocuments_uris">12.1. Error URIs</a></h3>
<h4><a name="errordocuments_uris_content">12.1.1. sword:ErrorContent</a></h4>
<p>
<strong>IRI</strong>: http://purl.org/net/sword/error/ErrorContent
</p>
<p>
The supplied format is not the same as that identified in the <span class="code_inline">Packaging</span> header and/or that supported by the server
</p>
<p><strong>Associated HTTP Status</strong>: 415 (Unsupported Media Type) or 406 (Not Acceptable)</p>
<h4><a name="errordocuments_uris_checksum">12.1.2. sword:ErrorChecksumMismatch</a></h4>
<p>
<strong>IRI</strong>: http://purl.org/net/sword/error/ErrorChecksumMismatch
</p>
<p>
Checksum sent does not match the calculated checksum. The server MUST also return a status code of <span class="code_inline">412 Precondition Failed</span>
</p>
<h4><a name="errordocuments_uris_badrequest">12.1.3. sword:ErrorBadRequest</a></h4>
<p>
<strong>IRI</strong>: http://purl.org/net/sword/error/ErrorBadRequest
</p>
<p>
Some parameters sent with the POST were not understood. The server MUST also return a status code of <span class="code_inline">400 Bad Request</span>.
</p>
<h4><a name="errordocuments_uris_unknown">12.1.4. sword:TargetOwnerUnknown</a></h4>
<p>
<strong>IRI</strong>: http://purl.org/net/sword/error/TargetOwnerUnknown
</p>
<p>
Used in mediated deposit when the server does not know the identity of the <span class="code_inline">On-Behalf-Of</span> user.
</p>
<p><strong>Associated HTTP Status</strong>: 403 (Forbidden)</p>
<h4><a name="errordocuments_uris_mediation">12.1.5. sword:MediationNotAllowed</a></h4>
<p>
<strong>IRI</strong>: http://purl.org/net/sword/error/MediationNotAllowed
</p>
<p>
Used where a client has attempted a mediated deposit, but this is not supported by the server. The server MUST also return a status code of <span class="code_inline">412 Precondition Failed</span>.
</p>
<h4><a name="errordocuments_uris_notallowed">12.1.6. sword:MethodNotAllowed</a></h4>
<p>
<strong>IRI</strong>: http://purl.org/net/sword/error/MethodNotAllowed
</p>
<p>
Used when the client has attempted one of the HTTP update verbs (POST, PUT, DELETE) but the server has decided not to respond to such requests on the specified resource at that time. The server MUST also return a status code of <span class="code_inline">405 Method Not Allowed</span>
</p>
<h4><a name="errordocuments_uris_maxupload">12.1.7. sword:MaxUploadSizeExceeded</a></h4>
<p><strong>IRI</strong>: http://purl.org/net/sword/error/MaxUploadSizeExceeded</p>
<p>
Used when the client has attempted to supply to the server a file which exceeds the server's maximum upload size limit
</p>
<p><strong>Associated HTTP Status</strong>: 413 (Request Entity Too Large)</p>
<h3><a name="errordocuments_example">12.2. Error Document Example</a></h3>
<div class="code">
<pre>
HTTP 1.1 400 Bad Request
&lt;?xml version="1.0" encoding="utf-8"?&gt;
&lt;sword:error xmlns="http://www.w3.org/2005/Atom"
xmlns:sword="http://purl.org/net/sword/"
xmlns:arxiv="http://arxiv.org/schemas/atom"
href="http://example.org/errors/BadManifest"&gt;
&lt;author&gt;
&lt;name&gt;Example repository&lt;/name&gt;
&lt;/author&gt;
&lt;title&gt;ERROR&lt;/title&gt;
&lt;updated&gt;2008-02-19T09:34:27Z&lt;/updated&gt;
&lt;generator uri="https://example.org/sword-app/"
version="0.9"&gt;sword@example.org&lt;/generator&gt;
&lt;summary&gt;The manifest could be parsed, but was not valid -
no technical metadata was provided.&lt;/summary&gt;
&lt;sword:treatment&gt;processing failed&lt;/sword:treatment&gt;
&lt;sword:verboseDescription&gt;
Exception at [ ... ]
&lt;/sword:verboseDescription&gt;
&lt;link rel="alternate" href="https://arxiv.org/help" type="text/html"/&gt;
&lt;/sword:error&gt;
</pre>
</div>
<h2><a name="autodiscovery">13. Auto-Discovery</a></h2>
<p>
AtomPub makes no recommendations on the discovery of Service Documents or other resources. SWORD RECOMMENDS that server implementations use the following conventions
</p>
<h3><a name="autodiscovery_servicedocuments">13.1. For Service Documents</a></h3>
<p>
Embed an html link with a rel value of <span class="code_inline">sword</span> (for backwards compatibility with
SWORD 1.3 recommendations), or a rel value of <span class="code_inline">http://purl.org/net/sword/terms/service-document</span>
</p>
<div class="code">
<pre>
&lt;html:link rel="sword" href="[Service Document URL]"/&gt;
</pre>
</div>
<p>or</p>
<div class="code">
<pre>
&lt;html:link rel="http://purl.org/net/sword/discovery/service-document" href="[Service Document URL]"/&gt;
</pre>
</div>
<h3><a name="autodiscovery_deposit">13.2. For Deposit Endpoints</a></h3>
<p>
Embed an html link with a rel value of <span class="code_inline">http://purl.org/net/sword/terms/deposit</span> in
any page which represents a deposit endpoint (for example, the splash page for a Collection)
</p>
<div class="code">
<pre>
&lt;html:link rel="http://purl.org/net/sword/terms/deposit" href="[Deposit URL]"/&gt;
</pre>
</div>
<h3><a name="autodiscovery_resources">13.3. For Resources</a></h3>
<p>
Embed an html link with a rel value of <span class="code_inline">http://purl.org/net/sword/terms/edit</span> in
any page which represents a deposited resource, and optionally include a <span class="code_inline">http://purl.org/net/sword/terms/statement</span>
link as well.
</p>
<div class="code">
<pre>
&lt;html:link rel="http://purl.org/net/sword/terms/edit" href="[Edit-IRI]"/&gt;
&lt;html:link rel="http://purl.org/net/sword/terms/statement" href="[State-IRI]"/&gt;
</pre>
</div>
<h2><a name="references">14. References</a></h2>
<p>
<a name="atom"><strong>[Atom]</strong></a> Nottingham, M. and R. Sayre, "The Atom Syndication Format", RFC 4287, December 2005. <a href="http://www.ietf.org/rfc/rfc4287.txt">http://www.ietf.org/rfc/rfc4287.txt</a>
</p>
<p>
<a name="atommultipart"><strong>[AtomMultipart]</strong></a> Gregario, J, et al "AtomPub Multipart Media Resource Creation", September 2008. <a href="http://tools.ietf.org/html/draft-gregorio-atompub-multipart-04">http://tools.ietf.org/html/draft-gregorio-atompub-multipart-04</a>
</p>
<p>
<a name="atompub"><strong>[AtomPub]</strong></a> Gregario, J. and B. de hOra, "The Atom Publishing Protocol", RFC 5023, October 2007. <a href="http://www.ietf.org/rfc/rfc5023.txt">http://www.ietf.org/rfc/rfc5023.txt</a> (see also non-normative html version at <a href="http://bitworking.org/projects/atom/rfc5023.html">http://bitworking.org/projects/atom/rfc5023.html</a>)
</p>
<p>
<a name="cmis"><strong>[CMIS]</strong></a> Content Management Interoperability Services (CMIS) Version 1.0. <a href="http://docs.oasis-open.org/cmis/CMIS/v1.0/cs01/cmis-spec-v1.0.html">http://docs.oasis-open.org/cmis/CMIS/v1.0/cs01/cmis-spec-v1.0.html</a>
</p>
<p>
<a name="dublincore"><strong>[DublinCore]</strong></a> DCMI Metadata Terms. <a href="http://www.dublincore.org/documents/dcmi-terms/">http://www.dublincore.org/documents/dcmi-terms/</a>
</p>
<p>
<a name="gdata"><strong>[GData]</strong></a> Google Documents List API. <a href="http://code.google.com/apis/documents/docs/developers_guide.html">http://code.google.com/apis/documents/docs/developers_guide.html</a>
</p>
<p>
<a name="oauth"><strong>[OAUTH]</strong></a> Atwood, A., Conlan, R. et al OAuth Core 1.0 <a href="http://oauth.net/core/1.0/">http://oauth.net/core/1.0/</a>, December 2007
</p>
<p>
<a name="oaiore"><strong>[OAIORE]</strong></a> Lagoze, C., Van de Sompel, H et al, Open Archives Initiative Object Reuse and Exchange, <a href="http://www.openarchives.org/ore/">http://www.openarchives.org/ore/</a>, June 2008
</p>
<p>
<a name="rdf"><strong>[RDF]</strong></a> Resource Description Framework. <a href="http://www.w3.org/RDF/">http://www.w3.org/RDF/</a>
</p>
<p>
<a name="rfc2119"><strong>[RFC2119]</strong></a> Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels". <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>, March 1997.
</p>
<p>
<a name="rfc2183"><strong>[RFC2183]</strong></a> Troost, R., Dorner, S. and Moore, K., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997 <a href="http://www.ietf.org/rfc/rfc2183.txt">http://www.ietf.org/rfc/rfc2183.txt</a>
</p>
<p>
<a name="rfc2616"><strong>[RFC2616]</strong></a> Fielding et al, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999 <a href="http://www.w3.org/Protocols/rfc2616/rfc2616.html">http://www.w3.org/Protocols/rfc2616/rfc2616.html</a>
</p>
<p>
<a name="rfc2617"><strong>[RFC2617]</strong></a> Franks, J. et al, "HTTP Authentication: Basic and Digest Access Authentication". <a href="http://www.ietf.org/rfc/rfc2617.txt">http://www.ietf.org/rfc/rfc2617.txt</a>, June 1999
</p>
<p>
<a name="rfc2818"><strong>[RFC2818]</strong></a> Rescorla, E. "HTTP over TLS". <a href="http://www.ietf.org/rfc/rfc2818.txt">http://www.ietf.org/rfc/rfc2818.txt</a>, May 2000.
</p>
<p>
<a name="sword13"><strong>[SWORD 1.3]</strong></a> Downing, J. "SWORD AtomPub Profile version 1.3", 2008. <a href="http://www.swordapp.org/docs/sword-profile-1.3.html">http://www.swordapp.org/docs/sword-profile-1.3.html</a>
</p>
<p>
<a name="sword001"><strong>[SWORD001]</strong></a> Jones, R. "Packaged Content Delivery over HTTP", February 2011
</p>
<p>
<a name="sword002"><strong>[SWORD002]</strong></a> Jones, R. "AtomPub Extensions for Packaged Content", February 2011
</p>
<p>
<a name="sword003"><strong>[SWORD003]</strong></a> Jones, R. "AtomPub Extensions for Scholarly Systems", February 2011
</p>
<p>
<a name="sword004"><strong>[SWORD004]</strong></a> Jones, R. "Atom Multipart Extensions for Packaged Content", February 2011
</p>
</body>
</html>
Jump to Line
Something went wrong with that request. Please try again.