Page History
...
| Configuration File: | [dspace]/config/dspace.cfg | ||
|---|---|---|---|
| Property: | identifier.doi.user | ||
| Example Value: |
| ||
| Informational Note: | Username to login into the API of the DOI registration agency. You can get it from you DOI registration agency. | ||
| Property: | identifier.doi.password | ||
| Example Value: |
| ||
| Informational Note: | Password to login into the API of the DOI registration agency. You can get it from you DOI registration agency. | ||
| Property: | identifier.doi.prefix | ||
| Example Value: |
| ||
| Informational Note: | The prefix that you got from the DOI registration agency. All your DOIs start with the prefix, followed by a slash and a suffix generated from DSpace. The prefix can be compared with a name space within the DOI system. | ||
| Property: | identifier.doi.namespaceseparator | ||
| Example Value: |
| ||
| Informational Note: | The value can remain empty. 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 name space separator. All the DOIs that DSpace generates will start with the DOI prefix, followed by a slash, the name space separator and some number generated by DSpace. If for example 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. |
Meta data Metadata conversion
To reserve a DOI DataCite requests metadata from the object the DOI addresses. It is mandatory to send those metadata to reserve and register a DOI. The file [dspace]/config/crosswalks/DIM2DataCite.xsl controls the conversion of meta data metadata from the DSpace internal format into the DataCite format. You have to add the name of you institution into this file:
...
DSpace should send updates to DataCite whenever meta data metadata of an item changes. To do so you have to change the dspace.cfg again. You should remove them comments in front of the two following properties or add them to the dspace.cfg:
...
| Option (short) | Option (long) | Parameter | Description |
|---|---|---|---|
| -d | --delete-all | Transmit information to the DOI registration agency about all DOIs that were deleted. | |
| --delete-doi | DOI | Transmit information to the DOI registration agency that the specified DOI was deleted. The DOI must be marked for deletion before, you cannot use this command to delete a DOI for an exisiting item. | |
| -h | --help | Print online help. | |
| -l | --list | List all DOIs those changes were not commited to the registration agency yet. | |
| -q | --quiet | The doi-organiser send error reports to the mail address configured in the property alert.recipient in dspace.cfg. If you use this option no output should be given to stdout. If you do not use this option the DOI-Organiser put informations about successful and unsuccessful operations to stdout and stderr. | |
| -r | --register-all | Transmit information about all DOIs that should be registered. | |
| --register-doi | DOI | ItemID | handle | If a DOI is marked for registration you can trigger the registration at the DOI registration agency by this command. Specify either the DOI, the ID of the item or its handle. | |
| -s | --reserve-all | Transmit information about all DOIs that should be reserved to the DOI registration agency. | |
| --reserve-doi | DOI | ItemID | handle | If a DOI is marked for registration you can trigger the registration at the DOI registration agency by this command. Specify either the DOI, the ID of the item or its handle. | |
| -u | --update-all | If a DOI is reserved for an item, the meta data metadata of the item will be send to DataCite. This command transmit new meta data metadata for items those meta data metadata were changed since the DOI was reserved. | |
| --update-doi | DOI | ItemID | handle | If a DOI needs an update of the meta data metadata of the item it belongs to, you can trigger this update with this command. Specify either the DOI, the ID of the item or its handle. |
...
'cron' job for asynchronous reservation/registration
Limitations of DOI support
DSpace currently generate DOIs for Items only. There is no support to generate DOIs for Communities and collections yet.
...
When a DOI should be reserved, registered, delete or the metadata need to be updated, DSpace just write this information into its local database. A command line interface is supplied to send the necessary information to the registration agency. This behaviour makes it easier to react on outages or errors while using the API from the registration agency. As these information should be send regularly it is a good idea to let this done by a cron job instead of doing it manually.
There are for commands that should be run regularly:
- Update the mata data of all items that changed since their DOI was reserved.
- Reserve all DOIs marked for reservation
- Register all DOIs marked for registration
- Delete all DOIs marked for deletion
In DSpace a DOI can has the state registered, reserved, to be reserved, to be registered, needs update, to be deleted or deleted. After an update of the metadata of an item the state of an assigned DOI is set back to the last state it had. So f.e. 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 performed its state is to be registered again. In cause of this behaviour the order of the commands above matters, the update command should be performed before every other of the commands above.
The cron job should perform the following command with the rights of the user your DSpace installation runs as:
| Code Block | ||
|---|---|---|
| ||
[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 |
The doi-organiser command sends error messages as email and logs some messages. The option -q tells DSpace to be quiet. That means it does not give information about the command line. If you don't use this option the doi-organiser will print messages to stdout about every DOI it successfully reserved, registered, updated, deleted. Using a cron job these messages will be send as E-Mail to you.
In case of an error take a look in the log messages what happened. If there is an outage of the API of your registration agency, DSpace will not change the state of the DOIs so that it will do everything necessary when the cron job starts the next time and the API is reachable again.
The frequency the cron job runs depend on your needs and your hardware. The more often you run the cron job the shorter is the delay between the moment a DOI is marked for registration in DSpace and the moment it is registered online. If you have a lot of submissions and want the DOIs to be available really quickly, you probably should run the cron job every fifteen minutes. If there are just one or two submissions per day it should be enough to let the cron job run twice per day.
Limitations of DOI support
| Warning |
|---|
| Every DSpace installation expects to be the only application that generate DOIs that starts with the prefix and name space separator you configured. DSpace does not check whether a DOI it generates is reserved or registered already. |
That means if you want to use multiple software or even more then one DSpace installation to register DOIs with the same prefix, you'll have to use a unique name space separator. 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 software to generate DOIs starting with 10.5072/results-.
DSpace currently generate DOIs for Items only. There is no support to generate DOIs for Communities and collections yet.
Configure DSpace to use EZID service for registration of DOIs
...
Overview
Content Tools