mirror of
https://github.com/DSpace/DSpace.git
synced 2025-10-12 12:33:18 +00:00
117 lines
5.0 KiB
Markdown
117 lines
5.0 KiB
Markdown
# DSpace SWORD (v1) README
|
|
|
|
* Author: Richard Jones
|
|
* Last Updated: 18-02-2008
|
|
* SWORD Version: 1.3
|
|
* DSpace-SWORD Version: 1.3.1
|
|
|
|
This document describes the DSpace implementation of the SWORD (v1) deposit standard. This is an extension to the ATOM
|
|
Publishing Protocol (APP), which provides a framework to discover deposit targets, and to deposit packaged content into
|
|
remote repositories.
|
|
|
|
For more information see:
|
|
|
|
http://www.swordapp.org/
|
|
|
|
## Changes
|
|
|
|
### Version 1.3.1
|
|
|
|
Second major version to be compliant with the SWORD 1.3 standard.
|
|
|
|
- Architectural changes to reflect need to support deposit targets other than collections
|
|
- Implementation of hierarchical service documents
|
|
- Add support for keeping and retrieving original deposit package
|
|
- Add support for depositing files into items
|
|
- Move previously hard-coded features out to configuration
|
|
- Re-write/re-architecture of authentication and authorisation system to encompass LDAP, and to support authorisations
|
|
on items
|
|
- Meet request/response requirements of 1.3 specification
|
|
|
|
### Version 1.2.1
|
|
|
|
Initial version to be compliant with the SWORD 1.2 standard.
|
|
|
|
- Support for depositing METS DSpace SIP files into DSpace collections
|
|
- Expose all DSpace Collections as ATOM Collections in SWORD Service Documents
|
|
|
|
## Configuration
|
|
|
|
The SWORD (v1) interface is configured within the `[dspace]/config/modules/sword-server.cfg` file.
|
|
|
|
## Testing
|
|
|
|
Supplied along with the source code is a package which can be used for testing. This consists of a mets.xml file, which
|
|
is a METS document containing a Dublin Core XML section of descriptive metadata which conforms to the SWAP standard.
|
|
There are additionally 3 example PDF files.
|
|
|
|
These files are provided additionally inside a zip file which should form the content of a deposit request
|
|
(example.zip).
|
|
|
|
These files are all available in the directory: `[dspace-sword]/example`
|
|
|
|
Testing can be performed using the separately available SWORD Client, or by invoking the sword deposit web service via a
|
|
command line tool such as `curl`:
|
|
|
|
### Service Documents
|
|
|
|
Authorised by dspace/dspace:
|
|
|
|
`curl -i http://dspace:dspace@localhost:8080/sword/servicedocument`
|
|
|
|
Authorised by dspace/dspace on behalf of admin:
|
|
|
|
`curl -i -H "X-On-Behalf-Of: admin" http://dspace:dspace@localhost:8080/sword/servicedocument`
|
|
|
|
### Deposits
|
|
|
|
Authorised by dspace/dspace on a Collection:
|
|
|
|
`curl -i --data-binary "@dspace-sword/example/example.zip" -H "Content-Disposition: filename=myDSpaceMETSItem.zip"
|
|
-H "Content-Type: application/zip" -H "X-Packaging: http://purl.org/net/sword-types/METSDSpaceSIP"
|
|
-H "X-No-Op: false" -H "X-Verbose: true" http://dspace:dspace@localhost:8080/sword/deposit/123456789/2`
|
|
|
|
Authorised by dspace/dspace on behalf of admin on a Collection:
|
|
|
|
`curl -i --data-binary "@dspace-sword/example/example.zip" -H "Content-Disposition: filename=myDSpaceMETSItem.zip"
|
|
-H "X-On-Behalf-Of: admin" -H "Content-Type: application/zip"
|
|
-H "X-Packaging: http://purl.org/net/sword-types/METSDSpaceSIP" -H "X-No-Op: false" -H "X-Verbose: true"
|
|
http://dspace:dspace@localhost:8080/sword/deposit/123456789/2`
|
|
|
|
Authorised by dspace/dspace on an Item:
|
|
|
|
`curl -i --data-binary "@dspace-sword/example/pdf1.pdf" -H "Content-Disposition: filename=somepdf.pdf"
|
|
-H "Content-Type: application/pdf" -H "X-No-Op: true" -H "X-Verbose: true"
|
|
http://dspace:dspace@localhost:8080/sword/deposit/123456789/21`
|
|
|
|
|
|
## Implementation Notes
|
|
|
|
- The logic of onBehalfOf is as follows: The list of collections which is supplied during a request which is done
|
|
onBehalfOf another user is the intersection of the lists of collections that the authenticated user can submit to and
|
|
the list that the onBehalfOf user can submit to.
|
|
|
|
- When items are deposited and pass into the DSpace workflow system, they cannot be assigned external identifiers
|
|
immediately. Therefore the returned id on "Accepted" items will be the front page of the repository on which the
|
|
deposit happened. Alternatives to this mechanism are being sought, but may require core DSpace modifications.
|
|
|
|
- If a request is made with an onBehalfOf user supplied, the authentication process requires that the username/password
|
|
pair successfully authenticate a user, and that the onBehalfOf user simply exists in the user database. If any of
|
|
these conditions fail, authentication fails.
|
|
|
|
- The ingest stylesheet used by default is available in the file:
|
|
|
|
[dspace-source]/config/crosswalks/sword-swap-ingest.xsl
|
|
|
|
but does not cover the complete SWAP profile yet.
|
|
|
|
- The scope of the dspace-sword module does not include the discoverability of deposit targets through the normal
|
|
user interface.
|
|
|
|
- If Items are enabled as SWORD deposit targets, then all the bitstream formats in the bitstream format registry will
|
|
be used to populate the atom:accepts field in the service document.
|
|
|
|
- If Communities are enabled for exposure in service documents, they will not specify an atom:accepts field, in
|
|
contravention to the standard, as they do not take deposits. Instead they are just gateways to the Collections
|
|
and Items which they contain.
|