...

As with every code there is always something left that could be improved. But we think our code is ready to get tested and included in DSpace. We would be glad to here about your ideas and everything you think we should change. All discussions should happen in the JIRA ticket (

Design Decisions

There are two design decisions we want to document here:

We safe the DOIs in the database using a column type VARCHAR(256). As far as I know there is no limit for the length of a DOI. We decided to use a VARCHAR(256) column as it provide quite a good length and is fully indexed. This is important as DOIs must be unique and we want to use support by the database to find a DspaceObject by its DOI really fast.

When we mint a new DOI it is generated by the database. We do not check if it already exists as the database should generate one DOI after the other without any conflict. If one adds DOIs manually to the database it's on his or her own risk. Nobody should insert DOIs without updating the database seqeunece doi_seq. Nevertheless it is possible to use a different name space separator when one adds DOIs manually. Almost the same applies to the registration agency: We check if a DOI is reserved or registered online but we don't have any strategy to handle conflicts. So please use a unique name space separator that only one DSpace installation use. In other words: If you want to avoid trouble, DSpace needs a space where only it reserves and register DOIs.

Thanks

I want to thank Mark H. Wood who made the 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 also wrote a test class for it. I took the liberty to use some of his code.

...