...
A first version of a DOIIdentivierProvider is complete. A interface for a DOIConnector is defined. The reserveration, registration and deletion of a DOI had been tested here. 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?
...
A lot of testing and possibly some debugging. It would be great if someone could implement a DOIConnector for EZID.
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.
We just implemented a DOIIdentifierProvider that can be compared to the HandleIdentifierProvider. We did neither care for or tested our implementation with versioning switched on. We want to support versioning but we wanted to get a first implementation done before taking care for versioning. Is a special IdentifierProvider needed for versioning as it exists with the VersionedHandleIdentifierProvider or does every IdentifierProvide can be used when versioning is switched on?
We currently support DSpace Items only. We would like to extend this, so that a DOI can be registered for a community and a collection as well. The main problem is to look how we deal with the metadata that DataCite wants to get for an object thats addressed by a DOI. In a first lose discussion our DOI registration agency seems to be quite open to support us with DOIs for communities and collections but this may differ from registration agency to registration agency so that it should be configurable if a DOI gets registered for a Item only or for communities and collections as well.
There are several things that should be discussed within the DSpace developer community:
- 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?