Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

If you want to know more about the DataCite Schema, have a look at the the documentation. If you change this file in a way that is not compatible with the DataCite schema, you won't be able to reserve and register DOIs anymore. Do not change anything if you're not sure what you're doing.

Identifier Service

...

To get the XML on which the XSLT processor will start, use the following command:

Code Block
languagebash
[dspace]/

...

After removing the comment signs the file should look something like this (I removed the comments to make the listing shorter):

...

bin/dspace dsrun org.dspace.content.crosswalk.XSLTDisseminationCrosswalk dim 123456789/3

To get the XML that will be send to DataCite replace 'dim' with 'DataCite'. If the DOI is not stored in the metadata, DSpace will add it automatically as identifier. So don't worry if the XML produced by this command does not contain the DOI. Once the DOI is stored in the metadata, it should also be contained in the XML.

Identifier Service

The Identifier Service manages the generation, reservation and registration of identifiers within DSpace. You can configure it using the config file located in [dspace

...

]/config/spring/api/identifier-service.xml. In the file you should already find the code to configure DSpace to register DOIs. Just read the comments and remove the comment signs around the two appropriate beans.

After removing the comment signs the file should look something like this (I removed the comments to make the listing shorter):

Code Block
title\[dspace\]/config/spring/api/identifier-service.xml
<!--
    Copyright (c) 2002-2010, DuraSpace.  All rights reserved
    Licensed under the DuraSpace License.

    
<!--
    Copyright (c) 2002-2010, DuraSpace.  All rights reserved
    Licensed under the DuraSpace License.

    A copy of the DuraSpace License has been included in this
    distribution and is available at: http://www.dspace.org/license
-->

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

    <bean id="org.dspace.identifier.service.IdentifierService"
          class="org.dspace.identifier.IdentifierServiceImpl"
          autowire="byType"
          scope="singleton"/>

    <bean id="org.dspace.identifier.DOIIdentifierProvider"
        class="org.dspace.identifier.DOIIdentifierProvider"
        scope="singleton">
        <property name="configurationService"
            ref="org.dspace.services.ConfigurationService" />
        <property name="DOIConnector"
            ref="org.dspace.identifier.doi.DOIConnector" />
    </bean>

    <bean id="org.dspace.identifier.doi.DOIConnector"
        class="org.dspace.identifier.doi.DataCiteConnector"
        scope="singleton">
        <property name='DATACITE_SCHEME' value='https'/>
        <property name='DATACITE_HOST' value='mds.test.datacite.org'/>
        <property name='DATACITE_DOI_PATH' value='/doi/' />
        <property name='DATACITE_METADATA_PATH' value='/metadata/' />
        <property name='disseminationCrosswalkName' value="DataCite" />
    </bean>
</beans>

...

In DSpace, a DOI can have different states (see the following table). After updating an item's metadata the state of its assigned DOI is set back to the state "registered", "reserved", "to be reserved", "to be registered", "needs update", "to be deleted", or "deleted". After updating an item's metadata the state of its assigned DOI is set back to the last state it had before. So, e.g., last state it had before. So, e.g., if a DOI has the state "to be registered" and the metadata of its item changes, it will be set to the state "needs update". After the update is performed its state is set to "to be registered" again. Because of this behavior the order of the commands above matters: the update command must be executed before all of the other commands above.

State #


State Name


DSpace State Description


DataCite State Name


0UNKNOWN???N/A*
1TO_BE_REGISTEREDThe submission has been approved and the DOI has been registered in DSpace. The registration has not yet been published to DataCite.Draft
2TO_BE_RESERVEDThe minted DOI has been associated with an item. However, the reservation has not yet been published to DataCite.N/A*
3IS_REGISTEREDThe registration has been published to DataCite and a url back to DSpace has been associated with the DOI. Findable
4IS_RESERVEDThe reservation has been published to DataCite. Draft
5UPDATE_RESERVEDA "Reserved" DOI's metadata has been modified in DSpace, but its modification has not yet been communicated to DataCite. Draft
6UPDATE_REGISTEREDA "Registered" DOI's metadata has been modified in DSpace, but its modification has not yet been communicated to DataCite. Findable
7UPDATE_BEFORE_REGISTRATIONA "To be registered" DOI's metadata has been modified in DSpace, but its modification has not yet been communicated to DataCite. N/A*
8TO_BE_DELETEDAn item with a registered DOI has been deleted in DSpace. However, the DOI still exists in DataCite. 
9DELETEDThe DOI has been deleted in both DSpace and DataCite. Tombstone? or nothing visible anymore?
10PENDING

The DOI was minted during submission. It was shown to a user that the submitted item would get this DOI if it ever gets any. The DOI is pending until it is archived and passes any filter by the DOIIdentifierProvider or is assigned to the item manually by an admin.


11MINTEDA DOI was created during the submission and a user was informed that the submission will get this DOI if any. Then the user changed the submission in a way that ceased to satisfy the DOI filter. In case the item passes the filter again, we want to re-apply the same DOI again (without creating new database rows), so we store it as being minted. DataCite was not informed about this DOI.

* An item in this state is not visible in DataCite

The cron job should perform the following commands with the rights of the user your DSpace installation runs as:

...

Property:

identifiers.submission.register

Example Value:

true

Informational Note:

Enable this feature. Default: false.

Handles will be registered at time of submission.

DOIs (if item filters evaluate to true) will be minted in a "pending" state for items, to be registered or queued for registration at archival.

Property:

identifiers.submission.filter.install

Example Value:

doi-filter

Informational Note:

Bean ID of a logical item filter (see config/modules/spring/api/item-filters.xml ) that will be used to evaluate whether a DOI should be queued  for registration when this item is installed (archived) in DSpace. This filter will be applied whether or not a "pending" DOI is already minted for the item.

(If a filter is absent or null, an item will always be evaluated as 'true')

Property:

identifiers.submission.filter.workspace

Example Value:

always_true_filter

Informational note

Bean ID of a logical item filter (see config/modules/spring/api/item-filters.xml ) that will be used to evaluate whether a DOI should be minted as "pending" for registration when this item is first submitted as a workspace item in DSpace.

Depending on the value of identifiers.submission.strip_pending_during_submission this filter will be checked whenever the workspace item changes, to see if it now qualifies for a DOI.

Default: always_true_filter

(If a filter is absent or null, an item will always be evaluated as 'true')

Property:

identifiers.submission.strip_pending_during_submission

Example Value:

true

Informational Note:

If, during workspace item changes, the workspace filter no longer evaluates to true, should any DOIs be stripped? (moved to MINTED or DELETED status)

This is useful in situations where the submitter needs real-time feedback as to whether their item qualifies for a DOI.

Property:

identifiers.item-status.register-doi

Example Value:

false

Informational Note:

Allow administrators to queue DOIs for registration in the Item Status page.

Default: false.

Important: This configuration property must  be set, even if it matches the default, as it is exposed as a REST configuration property to the frontend.

...