Page History
...
Configuration File: | [dspace]/config/dspace.cfg | |
---|---|---|
Property: | identifier.doi.user | |
Example Value: | Code Block | identifier.doi.user = user123 |
Informational Note: | Username to login into the API of the DOI registration agency. You'll get it from your DOI registration agency. | |
Property: | identifier.doi.password | |
Example Value: | Code Block | identifier.doi.password = top-secret |
Informational Note: | Password to login into the API of the DOI registration agency. You'll get it from your DOI registration agency. | |
Property: | identifier.doi.prefix | |
Example Value:code | identifier.doi.prefix = 10.5072 | |
Informational Note: | The prefix you got from the DOI registration agency. All your DOIs start with this prefix, followed by a slash and a suffix generated from DSpace. The prefix can be compared with a namespace within the DOI system. | |
Property: | identifier.doi.namespaceseparator | |
Example Value: | Code Block | identifier.doi.namespaceseparator = dspace- |
Informational Note: | This property is optional. If you want to use the same DOI prefix in several DSpace installations or with other tools that generate and register DOIs it is necessary to use a namespace separator. All the DOIs that DSpace generates will start with the DOI prefix, followed by a slash, the namespace separator and some number generated by DSpace. For example, if your prefix is 10.5072 and you want all DOIs generated by DSpace to look like 10.5072/dspace-1023 you have to set this as in the example value above. |
Metadata conversion
To reserve or register a DOI, DataCite requires that metadata be supplied which describe the object that the DOI addresses. The file [dspace]/config/crosswalks/DIM2DataCite.xsl controls the conversion of metadata from the DSpace internal format into the DataCite format. You have to add the name of your institution to this file:
Info |
---|
Please don't use the test prefix 10.5072 with DSpace. The test prefix 10.5072 differs from other prefixes: It answers GET requests for all DOIs even for DOIs that are unregistered. DSpace checks that it mint only unused DOIs and will create an Error: "Register DOI ... failed: DOI_ALREADY_EXISTS". Your registration agency can provide you an individual test prefix, that you can use for tests. |
Metadata conversion
To reserve or register a DOI, DataCite requires that metadata be supplied which describe the object that the DOI addresses. The file [dspace]/config/crosswalks/DIM2DataCite.xsl controls the conversion of metadata from the DSpace internal format into the DataCite format. You have to add the name of your institution to this file:
Code Block | ||
---|---|---|
| ||
<!--
Document : DIM2DataCite.xsl
Created on : January 23, 2013, 1:26 PM
Author : pbecker | ||
Code Block | ||
| ||
<!--
Document : DIM2DataCite.xsl
Created on : January 23, 2013, 1:26 PM
Author : pbecker, ffuerste
Description: Converts metadata from DSpace Intermediat Format (DIM) into
metadata following the DataCite Schema for the Publication and
Citation of Research Data, Version 2.2
-->
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:dspace="http://www.dspace.org/xmlns/dspace/dim"
xmlns="http://datacite.org/schema/kernel-2.2"
version="1.0">
<!-- CONFIGURATION -->
<!-- The content of the following variable will be used as element publisher. -->
<xsl:variable name="publisher">My University</xsl:variable>
<!-- The content of the following variable will be used as element contributor with contributorType datamanager. -->
<xsl:variable name="datamanager"><xsl:value-of select="$publisher" /></xsl:variable>
<!-- The content of the following variable will be used as element contributor with contributorType hostingInstitution. -->
<xsl:variable name="hostinginstitution"><xsl:value-of select="$publisher" /></xsl:variable>
<!-- Please take a look into the DataCite schema documentation if you want to know how to use these elements.
http://schema.datacite.org -->
<!-- DO NOT CHANGE ANYTHING BELOW THIS LINE EXCEPT YOU REALLY KNOW WHAT YOU ARE DOING! -->
... |
...
Code Block | ||
---|---|---|
| ||
<!--
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.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> |
...
Please pay attention to configure the property DATACITE_HOST. Per default it is set to the DataCite test server. To reserve real DOIs you will probably have to change it to mds.datacite.org. Ask your registration agency if you're not sure about the correct address. Unfortunately
Info |
---|
For sometime unfortunately the test and the production server |
...
of Datacite had different paths to the API. Those paths has changed after the release of DSpace 5.4. Please use the properties DATACITE_HOST, DATACITE_DOI_PATH and DATACITE_METADATA_PATH as mentioned above to connect to the test server and change the DATACITE_HOST to mds.datacite.org when you want to to switch to the production server of DataCite (registering real DOIs). |
For the test server you have to set the DATACITE_DOI_PATH to "/mds/doi/" and the DATACITE_METADATA_PATH to "/mds/doi/", for the production server you have to remove the leading /mds from both properties.
DSpace should send updates to DataCite whenever the metadata of an item changes. To do so you have to change the dspace.cfg again. You should remove the comments in front of the two following properties or add them to the dspace.cfg:
...
The command line interface in general is documented here: Command Line Operations.
The command used for DOIs is 'doi-organiser
'. You can use the following options:
...
Code Block | ||
---|---|---|
| ||
# Send information about new and changed DOIs to the DOI registration agency: 0 1,13 * * * [dspace]/bin/dspace doi-organiser -u -q ; [dspace]/bin/dspace doi-organiser -s -q ; [dspace]/bin/dspace doi-organiser -r -q ; [dspace]/bin/dspace doi-organiser -d -q |
Limitations of DataCite DOI support
Warning |
---|
Every DSpace installation expects to be the only application that generates DOIs which start with the prefix and the namespace separator you configured. DSpace does not check whether a DOI it generates is reserved or registered already. |
That means if you want to use other applications or even more than one DSpace installation to register DOIs with the same prefix, you'll have to use a unique namespace separator for each of them. Also you should not generate DOIs manually with the same prefix and namespace separator you configured within DSpace. For example, if your prefix is 10.5072 you can configure one DSpace installation to generate DOIs starting with 10.5072/papers-, a second installation to generate DOIs starting with 10.5072/data- and another application to generate DOIs starting with 10.5072/results-.
DOIs will be used in addtion addition to Handles. This implementation does not replace Handles with DOIs in DSpace. That means that DSpace will still continue to generate Handles for every item, every collection and every community, and will use those Handles as part of the URL of items, collections and communities.
DSpace currently generates DOIs for items only. There is no support to generate DOIs for Communities and collections yet.
When using DSpaces DSpace's support for the DataCite API probably not all infomration information would be restored when using the AIP Backup and Restore (see
Jira | ||||||||
---|---|---|---|---|---|---|---|---|
|
Configure DSpace to use EZID service for registration of DOIs
DS-1836). The DOIs included in metadata of Items will be restored, but DSpace won't update the metadata of those items at DataCite anymore. You can even get problems when minting new DOIs after you restored older once using AIP.
Configure DSpace to use EZID service for registration of DOIs
The EZID IdentifierProvider operates synchronously, so there is much less to configure. You will need to un-comment the org.dspace.identifier.EZIDIdentifierProvider
bean in config/spring/api/identifier-service.xml
to enable DOI registration through EZID.
In config/dspace.cfg
you will find a small block of settings whose names begin with identifier.doi.ezid
. You should uncomment these properties and give them appropriate values. Sample values for a test account are supplied.
name | meaning |
---|---|
identifier.doi.ezid.shoulder | The "shoulder" is the DOI prefix issued to you by the EZID service. DOIs minted by this instance of DSpace will be the concatenation of the "shoulder" and a locally unique token. |
identifier.doi.ezid.user identifier.doi.ezid.password | The username and password by which you authenticate to EZID. |
identifier.doi.ezid.publisher | You may specify a default value for the required datacite.publisher metadatum, for use when the Item has no publisher. |
Back The EZID IdentifierProvider operates synchronously, so there is much less to configure. You will need to un-comment the EZIDIdentifierProvider
bean in config/spring/api/identifier-service.xml
to enable DOI registration through EZID.
In config/dspace.cfg
you will find a small block of settings whose names begin with identifier.doi.ezid
. You should uncomment these properties and give them appropriate values. Sample values for a test account are supplied.
name | meaning |
---|---|
identifier.doi.ezid.shoulder | The "shoulder" is the DOI prefix issued to you by the EZID service. DOIs minted by this instance of DSpace will be the concatenation of the "shoulder" and a locally unique token. |
identifier.doi.ezid.user identifier.doi.ezid.password | The username and password by which you authenticate to EZID. |
identifier.doi.ezid.publisher | You may specify a default value for the required datacite.publisher metadatum, for use when the Item has no publisher. |
...
you will see some other configuration of the EZIDIdentiferProvider
bean. In most situations, the default settings should work well. But, here's an explanation of options available:
- EZID Provider / Registrar settings: By default, the EZIDIdentifierProvider is configured to use the CDLib provider (ezid.cdlib.org) in the
EZID_SCHEME
,EZID_HOST
andEZID_PATH
settings. In most situations, the default values should work for you. However, you may need to modify these values (especially theEZID_HOST
) if you are registered with a different EZID provider. In that situation, please check with your provider for valid "host" and "path" settings. If your provider provides EZID service at a particular path on its host, you may set that inEZID_PATH
.- NOTE: As of the writing of this documentation, the default CDLib provider settings should also work for institutions that use Purdue (ezid.lib.purdue.edu) as a provider. Currently, Purdue and CDLib currently share the same infrastructure, and both
ezid.cdlib.org
andezid.lib.purdue.edu
point to the same location.
- NOTE: As of the writing of this documentation, the default CDLib provider settings should also work for institutions that use Purdue (ezid.lib.purdue.edu) as a provider. Currently, Purdue and CDLib currently share the same infrastructure, and both
- Metadata mappings: You can alter the mapping between DSpace and EZID metadata, should you choose. The
crosswalk
property is a map from DSpace metadata fields to EZID fields, and can be extended or changed. Thekey
of eachentry
is the name of an EZID metadata field; thevalue
is the name of the corresponding DSpace field, from which the EZID metadata will be populated. - Crosswalking / Transforms: You can also supply transformations to be applied to field values using the
crosswalkTransform
property. Eachkey
is the name of an EZID metadata field, and itsvalue
is the name of a Java class which will convert the value of the corresponding DSpace field to its EZID form.
...
- The only transformation currently provided is one which converts a date to the year of that date, named
org.dspace.identifier.ezid.DateToYear
. In the configuration as delivered, it is used to convert the date of issue to the year of publication. You may create new Java classes with which to supply other transformations, and map them to metadata fields here. If an EZID metadatum is not named in this map, the default mapping is applied: the string value of the DSpace field is copied verbatim.
Limitations of EZID DOI support
DOIs will be used in addition to Handles. This implementation does not replace Handles with DOIs in DSpace. That means that DSpace will continue to generate Handles for every item, every collection and every community, and will use those Handles as part of the URL of items, collections and communities.
Currently, the EZIDIdentifierProvider has a known issue where it stores its DOIs in the dc.identifier
field, instead of using the dc.identifier.uri
field (which is the one used by DataCite DOIs and Handles). See DS-2199 for more details. This will be corrected in a future version of DSpace.
DSpace currently generates DOIs for items only. There is no support to generate DOIs for Communities and Collections yetNormally, you should not change the value of the EZID_SCHEME
property of the EZIDRequestFactory
bean. If you registered with the CDLib provider, you should not change the value of EZID_HOST; if you registered with another provider, such as Purdue, you should set the EZID_HOST appropriately (for example, https://ezid.lib.purdue.edu).
If your provider provides EZID service at a particular path on its host, you may set that in EZID_PATH.
Adding support for other Registration Agencies
...