on our Vetmeduni Phaidra instance, the object landing pages include a “Request DOI” button that allows object owners after a login to mint a DOI for the object. Since a recent minor update, this button is now visible even when the object’s metadata already contains a DOI (= object already has a DOI assigned). Previously, the button was hidden in this case.
My understanding has always been that each object should have exactly one DOI.
Are there scenarios where assigning two DOIs to one and the same object (not a new version or derivative) is actually desirable or standards-compliant? If there is no compelling use case, I would suggest hiding (or at least disabling) the button when a DOI is already present.
Agree: 1 DOI can have 1 or even mor URLs but 2 DOIs mean two different object, e.g. a pre-print for a published article might have the publisher’s DOI, but the pre-print might have it’s own DOI while the metadata also points to the published article. The pre-print is it’s own independent object, but a bit-by-bit copy of the published article is not.
A preprint, an accepted manuscript (also known as a “postprint”), and the version of record each represent different stages of the publication process. These are typically made available in different systems (e.g., preprint servers, institutional repositories, and journal publishing platforms) with separate DOIs.
When a version of record is available, connect preprints and accepted manuscripts to the version of record using the relationType IsVersionOf. Connect the version of record to any associated preprints or accepted manuscripts using the reciprocal relationType HasVersion.
But it then depends on platform supporting and understanding this kind of relations. Phaidra has various relation types, one of them is “isAlternativeVersionOf”: