Which Dspace versions do we support?

Following the update of our Long-Term Preservation connector to Dspace version 7, we announced that we would discontinue support for previous versions of Dspace (v4-v6).

We will continue supporting previous versions of Dspace for 5.30 (June 2024) releases. However, starting from Pure 5.31 (October 2024), support for versions of Dspace prior to v7 will cease.

License

Pure is able to display licenses from DSpace collections when users adds files to content. A license collection can be defined and the license from that collection will be displayed. If the license collection is left blank, the license from the home collection and any matching linked collections (if any) will be displayed.

MODS transformation

If the repository installation requires changes to the MODS data, a style sheet can be defined to modify the data sent. A preview function is available to help preview transformed content.

Adjust the MODS-2-DIM crosswalk XSL

For ingestion into DSpace PURE creates a METS package containing MODS metadata. The MODS metadata is transformed by Dspace to its internal metadata format by the MODS-2-DIM crosswalk. This crosswalk is basicly an XML stylesheet (XSL).

PURE aims to create as complete and correct MODS metadata as possible, and for DSpace to ingest this correctly the included default crosswalk XSL must be modified. Atira provides a modified crosswalk that can be used as a starting point for local customizations. The crosswalk XSL is available at: http://github.com/bogundersen/Ingest-xsl (This file might not work with Pure after 5.28.0 as Pure have been upgraded to MODS 3.8)

(the initial modified version of the crosswalk is courtesy of Timo Aalto <timo.j.aalto@helsinki.fi> of the University of Helsinki) 
To enable this new extended crosswalk and PURE integration, the following tasks have to be made to your DSpace:

1. Download the new mods-submission.xsl from GitHub
2. Modify it with any local requirements
3. Deploy it to your DSpace (in the config/crosswalks folder)

To use the modified crosswalk, the following dc metadata fields have to be added to DSpace:

• dc.contributor.institution
• dc.contributor.pbl
• dc.identifier.doi
• dc.author.editor
• dc.author.illustrator
• dc.author.translator
• dc.author.publisher
• dc.author.inventor
• dc.author.producer
• dc.author.performer
• dc.author.photographer
• dc.author.composer
• dc.author.designer
• dc.description.version
• dc.description.status
• dc.date.embargoedUntil

Disable workflow for DSpace

There should be no workflows defined for the collection where PURE submits its items too otherwise the submissions will not be created.

3.2, 4.1 & 4.2 LNI API

LNI API

The Lightweight Network Interface for supported DSpace server versions 3.2, 4.1, 4.2

DSpace server setup

Prior to setting up the storage communication in the administration interface in Pure, setup a home collection and check the sections below to ensure the DSpace server is setup accordingly.

PURE communicates with DSpace via the LNI interface. Unfortunately the default LNI implementation in DSpace does not contain the functionality nessesary for a good integration.

Because of this, it is necessary to make some adjustments to your DSpace installation before you start using it with PURE, the following sections describe the necessary adjustments.

Patch the LNI interface

The default LNI interface are missing vital operations, such as update an item and delete a bitstream, so Atira provides a patched version that contains the following changes:

• Changed DAVItem.put() to update the item (new functionality)
• Changed DAVBitstream.deleteInternal to delete the bitstream (new functionality)
• Changed DAVItem.delete() to delete the item instead of withdrawing it
• Changed PackageUtils.addDepositLicense() so that it doesnt add the default collection license if the ingested item already has a license

Patch files can be downloaded here:

dspace-4.2_lni_atira.diffdspace-3.2_lni_atira.diffdspace-4.1_lni_atira.diff

Appropriate versions of dspace can be downloaded from https://github.com/DSpace/DSpace/releases

To use the patch : 

Clone

git clone https://github.com/DSpace/DSpace.git

Go to directory

cd DSpace

Checkout

git checkout dspace-4.1

Make sure the downloaded patch (.diff) version follows the checkout version, then patch

patch -p0 -i ~/dspace-4.1_lni_atira.diff
 
//output should look like this:
patching file ./dspace-api/src/main/java/org/dspace/content/packager/AbstractMETSIngester.java
patching file ./dspace-api/src/main/java/org/dspace/content/packager/PackageUtils.java
patching file ./dspace-lni/src/main/java/org/dspace/app/dav/DAVBitstream.java
patching file ./dspace-lni/src/main/java/org/dspace/app/dav/DAVItem.java

1. Build and deploy lni as pr. normal

Note: For version 3.2, due to an issue (https://jira.duraspace.org/browse/DS-1625) in the LNI server, a patch for the "dspace-lni/src/main/webapp/WEB-INF/web.xml" has been added as well.

Adjust the MODS-2-DIM crosswalk XSL

For ingestion into DSpace PURE creates a METS package containing MODS metadata. The MODS metadata is transformed by Dspace to its internal metadata format by the MODS-2-DIM crosswalk. This crosswalk is basicly an XML stylesheet (XSL).

PURE aims to create as complete and correct MODS metadata as possible, and for DSpace to ingest this correctly the included default crosswalk XSL must be modified. Atira provides a modified crosswalk that can be used as a starting point for local customizations. The crosswalk XSL is available at: http://github.com/bogundersen/Ingest-xsl

(the initial modified version of the crosswalk is courtesy of Timo Aalto <timo.j.aalto@helsinki.fi> of the University of Helsinki) 
To enable this new extended crosswalk and PURE integration, the following tasks have to be made to your DSpace:

1. Download the new mods-submission.xsl from githup
2. Modify it with any local requirements
3. Deploy it to your DSpace (in the config/crosswalks folder)

To use the modified crosswalk, the following dc metadata fields have to be added to DSpace:

• dc.contributor.institution
• dc.contributor.pbl
• dc.identifier.doi
• dc.author.editor
• dc.author.illustrator
• dc.author.translator
• dc.author.publisher
• dc.author.inventor
• dc.author.producer
• dc.author.performer
• dc.author.photographer
• dc.author.composer
• dc.author.designer
• dc.description.version
• dc.description.status

Disable workflow

There should be no workflows defined for the collection where Pure submits it's items to, otherwise the submissions will not be created.

Licenses

Pure is able to display licenses from DSpace collections when users adds files to content.

a) A license collection can be defined and the license from that collection will be displayed.

b) If the license collection is left blank, the license from the home collection and any matching linked collections (if any) will be displayed.

Collection links

Note that content can be linked from the home collection to additional DSpace collections based on organisation id or keyword group classification. A link will be created in the collections for content matching the conditions. This allows content from different organisational units to be visible in separate collections.

5.5 REST API

REST API

The REST API documentation is located at https://wiki.duraspace.org/display/DSDOC5x/REST+API and can be used by Pure 5.6.0+. Be aware that we only support DSpace version is 5.5 and above, (Version DSpace 5.4 is currently unsupported due to a bug in 'handle' API call, used heavily by Pure to translate handles).

DSpace server setup

Prior to setting up the storage communication in the administration interface in Pure, setup a home collection and check the sections below to ensure the DSpace server is setup accordingly.  

Check the <mydspace.domain.org>/rest or to see if the service is deployed. It should show a description of the REST service API.

MODS metadata

Pure aims to create as complete and correct MODS metadata as possible.

You can find a detailed mapping from Pure fields to MODS fields on the MODS Publication field mapping 

MODS serializer (stylesheet/crosswalk)

The initial modified version of the crosswalk is courtesy of Timo Aalto <timo.j.aalto@helsinki.fi> of the University of Helsinki), the crosswalk is used inside Pure prior to submitting items to DSpace REST API.

You can download it for clarification to see the mapping between MODS fields and DC fields used in DSpace, or use it as baseline for your own custom version.

mods-to-dspace.xslt

Metadata Field Registry

Prior to submitting items to DSpace REST API the following dc metadata fields must to be added to DSpace:

• dc.contributor.institution
• dc.contributor.pbl
• dc.identifier.doi
• dc.identifier.url
• dc.description.version
• dc.description.status
• dc.contributor.author
• dc.contributor.illustrator
• dc.contributor.translator
• dc.contributor.publisher
• dc.contributor.inventor
• dc.contributor.producer
• dc.contributor.performer
• dc.contributor.photographer
• dc.contributor.composer
• dc.contributor.designer

The dc.contributor.* fields (not including dc.contributor.institution) are based on the roles classification schemes present for the different research output types. If you add/update the default roles make sure that these roles are also added as dc.contributor.role fields in DSpace.

DSpace system metadata fields

The following fields are DSpace system metadata fields and therefore ignored by the Pure DSpace REST client. The default stylesheet included in Pure does not use this fields, but if you have a custom stylesheet with these fields the data in those fields will be ignored.

• dc.date.available
• dc.date.accessioned
• dc.identifier.uri
• dc.description.provenance

Disable workflow

No workflows should be defined for the collection where Pure submits it's items to, as the REST API will not honour these steps.

Licenses

Pure is able to display licenses from DSpace collections when users adds files to content.

a) A license collection can be defined and the license from that collection will be displayed.

b) If the license collection is left blank, the license from the home collection and any matching linked collections (if any) will be displayed.

Note: The DSpace REST api does not support uploading bitstreams to the license bundle. So the accepted licenses are not added to the DSpace record.

Collection links

Note that collection linking is unsupported in REST API.

Migrating from LNI to REST

Stylesheet

Pure comes with a standard stylesheet based on the stylesheet used in LNI. If you have not made any local changes to your stylesheet you can use that. If you have used a modified stylesheet in LNI you will need to convert it to a new one. You can base it on the standard stylesheet and incorporate you changes into that. Your stylesheet should not contain any of the DSpace system metadata fields mentioned above. Note that only version 1 of XSLT can be used.

The standard stylesheet for REST uses dc.identifier.url instead of dc.identifier.uri used in LNI for other links.

Collection links

Since collection links are unsupported in the REST API, you will need to remove the links from your LNI configuration before converting it to a REST configuration.

7.0+ REST API

Rest API

Official REST documentation is found at: https://wiki.lyrasis.org/display/DSDOC7x/REST+API.

The REST API for DSpace 7.0+ is a completely new API different from the previous versions.

DSpace 7.0 is supported in Pure 5.27.0+.

Mods

Pure Metadata fields

Prior to submitting items to DSpace REST API the following dc metadata fields must to be added to DSpace:

• dc.contributor.author
• dc.contributor.aut
• dc.contributor.composer
• dc.contributor.creator
• dc.contributor.designer
• dc.contributor.edt
• dc.contributor.illustrator
• dc.contributor.institution
• dc.contributor.inventor
• dc.contributor.pbl
• dc.contributor.performer
• dc.contributor.photographer
• dc.contributor.producer
• dc.contributor.publisher
• dc.contributor.translator
• dc.coverage.spatial
• dc.coverage.temporal
• dc.date.available
• dc.date.created
• dc.date.embargoedUntil
• dc.date.issued
• dc.description
• dc.description.abstract
• dc.description.status
• dc.description.version
• dc.format.extent
• dc.identifier.citation
• dc.identifier.doi
• dc.identifier.isbn
• dc.identifier.issn
• dc.identifier.other
• dc.identifier.uri
• dc.identifier.url
• dc.language.iso
• dc.publisher
• dc.relation.ispartofseries
• dc.relation.ispartof
• dc.rights
• dc.subject
• dc.subject.classification
• dc.title
• dc.title.alternative
• dc.type

The dc.contributor.* fields (not including dc.contributor.institution) are based on the roles classification schemes present for the different research output types. If you add/update the default roles make sure that these roles are also added as dc.contributor.role fields in DSpace.

Note: In cases where a field is missing Pure should be able to report what fields are missing in the error presented.

DSpace system metadata fields

The following fields are DSpace system metadata fields and therefore ignored by the Pure DSpace REST client. The default stylesheet included in Pure does not use this fields, but if you have a custom stylesheet with these fields the data in those fields will be ignored.

• dc.date.available
• dc.date.accessioned
• dc.identifier.uri
• dc.description.provenance

License

Pure is able to display licenses from DSpace collections when users adds files to content.

a) A license collection can be defined and the license from that collection will be displayed.

b) If the license collection is left blank, the license from the home collection and any matching linked collections (if any) will be displayed.

Note: The DSpace REST api does not support uploading bitstreams to the license bundle. So the accepted licenses are not added to the DSpace record.

Collection Links

Content is always created in the DSpace server in the configured home collection. In addition to this default mapping it is also possible to map content to other manually created collections. This can be done by creating conditions in the "Collection Links" section of the DSpace configuration page. The sections below contain examples of how filters can be defined.

Organisation ID conditions

There are three types of IDs that can be used. Here is an example of using "Organisation Classified ID".

The organisation ID supplied above corresponds to this classified ID in Pure.

Notice that the type of the ID in Pure is "Organisation ID". The name of the collection that was supplied in the condition above corresponds to a collection in DSpace. You can se the handle in the UI here.

In the DSpace UI interface the mapped collections can be seen and edited under the "Collection Mapper" pane for each item.
 

Example of using the Pure ID of the organisation. Notice that it is possible to type in more than one ID in the "Organisation IDs" input field - when you enter an id then another input box becomes available.

And here we use the ID of the organisation.

Lastly it is also possible to use the source id of the organisation.

Do not use the option "Link Identifiers". It is deprecated and will be removed.

Keyword group conditions

It is also possible to use keywords to map to other collections than the home collection. Here is an example with library keywords.

This condition will map a publication with the library keyword set like this.

It is also possible to create your own keyword groups to use with this feature. The new keyword group should be created using a classification scheme, which could be a new one create for this mapping. After the new keyword group has been created you need to log out of Pure and in again before the keyword group is shown in the drop down menu. Remember to add the keyword group to all the content types that you wish to map, e.g. Research Output, Dataset, Student thesis.