As a scientist/user, I want to mint a PID from different providers

[poikilotherm]

Dear all,

currently, only one persistant identifier can be stored per DvObject. Protocol, authority and identifiert are stored within the database and together form the GlobalId.

Besides that we need support for different providers than already present (currently only Handle and DOI via providers for EZID, DataCite and Handle.net), described in #4106, there is a need to have multiple persistant identifiers.

Use case:
A scientist creates a dataset from some of them research data. Them does not want to publish the set, but for referencing it in some other database or application, it should get a PID. (Using a dataverse URL does not seem appropriate for this!). This is especially true for data which is piped into Dataverse from automated processes / analysis, etc.

As it is quite expensive to mint a DOI at DataCite and others, the admins decide to offer some other PID service, e. g. ePIC (see #4833).

After some time, a dataset has proven valuable. Now the scientist wants to mint a real DOI for it, but of course the existing PIDs shall not break, as they were already used as references.

Willing to act on this, if you agree with the use case. Will most certainly make data migrations necessary (ah, NoSQL for the win...).

[pdurbin]

@poikilotherm thanks for opening this issue. Can you please take a look at pull request #5064 for issue #4832 which solves a specific but related issue some installations of Dataverse have where they ran with Handles for a while and want to mint DOIs for those datasets but still have the old Handles work. Thanks.

[pameyer]

@poikilotherm any specific PIDs you're thinking of? minid came across my radar for what might be a similar use case, but there may be better alternatives.

[poikilotherm]

@pameyer definitly ePIC. E. g. big EU player B2SHARE is using it and they provide a mechanism to add a DOI to a dataset with an ePIC PID when it gets published. (Clever trick: the ePIC is built almost the same as the DOI, but a bit longer. Thus the IDs part looks very similar afterwards, as the DOI is actually a shortened ePIC ID...)

@pdurbin: will look into that :-) Sounds definitly related, maybe a good start. :-)
@pdurbin that looks definitly like a 75% of what I outlined above. There is already support for multiple alternative IDs builtin, which was definetly one big point. What would be missing from my point of view is some configurable trigger on publishing the dataset, that does exactly what the curl call from an admin does now.

@scolapasta, @TaniaSchlatter, @djbrooke and @landreev, what do you think - is this a valid extension of #4832?

[poikilotherm]

This is no longer of interest for us. Will close for now and might reopen if this issue rises again in the future.