...

Knowing this situation we developed a DOIIdentifierProvider that should perform everything on the side of DSpace that is necessary to support DOIs. For example after minting and registering a DOI it safes the DOI as a metadata value of an Item. To be able to extend our DOIIdentifierProvider we put a DOIConnector between our DOIIdentifierProvider and the API for the registration agency. The DOIConnector has to support seven methods and should be quite easy to implement for any API of a DOI registration agency. The seven methods are:

...

DataCite wants to get metadata of the objects the DOIs addresses. The DataCite Schema (http://schema.datacite.org) defines a XML structure to describe the metadata of an object. We developed a DIM2DataCite crosswalk that takes the metadata of a DSpace Item and transforms it into a XML using DataCite Schema 2.2. As far as I know, EZID does not use this XML so that probably another crosswalk is needed. It should be discussed (see below or in the JIRA ticket) how we want to deal with metadata updates as the API for external identifiers does not define a mechanism to update metadata for external identifer yet.

Status

What's done already?

The DSpace wiki tells as to get in touch with the developer community early. A first version of a DOIIdentivierProvider is complete. A An interface for a DOIConnector is defined. The reserveration, registration and deletion of a DOI had been tested here We were able to reserve, register and delete DOIs at the test API of DataCite. All the code can be found in our DSpace repository on github, in the branch DOI: https://github.com/tuub/DSpace/tree/DOI

What's still to do?

Of cause documentation for the DSpace manual would be necessary if this contribution gets accepted. Although javadoc documentation could be enhanced. I should (but did not yet) write here something about several design decisions I made while implementing the DOIIdentifierProvider.

A lot of testing and possibly some debugging. It would be great if someone could implement a DOIConnector for EZID. We did not write any test classes yet (knowing that this is not good and should be changed). We currently break some tests because DataCite defines five mandatory metadata fields (the DOI, a creator, a title, a publisher and the publication year) and not all TestItems contains all of these.

We did not care for the frontends yet. Currently we can register DOIs but we did not care if they will be presented in any UI.

...

• Currently the API for external identifiers does not inform a IdentifierProvider about updated metadata. Should the DOIIdentifierProvider API be extended to take care for metadata API or does another mechanism already exists in DSpace?
• The IdentifierProvider API allows most of the methods to throw an IdentifierException. But in our first test it seems that a thrown IdentifierException won't be caught. If the API of the DOI registration agency is down or produces errors it is impossible to publish any Items in DSpace.

Thanks

I want to thank Mark H. Wood who mad a first steps for a DOIIdentifier. His code helped me to understand how DSpace handles metadata and what should be done to support DOIs within DSpace. He started to implement a DOIIdentifierProvider using EZID and although wrote a test class for it. I allowed my self to use some of his code.

The other person helping me was Fabian Fürste a collegue here at TU Berlin. Thanks goes to him as well.