Support Archival Resource Key (ARK) as Persistent Identifier

[pallinger]

Currently, dataverse supports DOIs and Handles as persistent identifiers, but ARK is a viable alternative, that can be very enticing, especially due to the price (it's free).

Details about ARK: https://n2t.net/e/ark_ids.html

To provide ARKs, one must either have an access to an ARK provider like EZID (https://ezid.cdlib.org/) or register your organization as a Name Assigning Authority (NAA) and be an ARK provider, possibly using the dataverse.

As different dataverses inside a Dataverse installation may belong to different organizations, it may be a requirement for each (at least top-level) dataverse to have a NAA assigned.

I will try to look at the Handle and DOI implementation and try to come up with a way to implement ARK support with minimal intrusion.

[djbrooke]

Hey @pallinger - thanks for being willing to work on this. We're definitely interested in decreasing the cost of running a Dataverse installation where we can. Once you've done some research and have an idea about what it would take to implement, we're happy to discuss.

It seems that there are two use cases that you've outlined. One is to allow ARKs to be used in place of Handles and DOIs, the other is to allow a sub-collection to have their own NAAs. I feel the second use case would be more work, as we'd have to set up some workflow to create/assign these NAAs.

[qqmyers]

FWIW: I think there are several use cases for allowing Dataverse to support multiple PID providers at once - sub-collections managed by different orgs, but also migration of data from other repositories (keeping their original DOIs but allowing Dataverse to update the DOI landing page/metadata). So - it would be nice to have a general capability here.

As for ARKs, I don't think it would be too hard to treat them as a generic new form of PID - Dataverse already has an AbstractGlobalIdServiceBean class and can retrieve the right one given what you configure for the protocol. That said, ARKs are more powerful that DOIs/Handles in that they have two parts - two ARKs can refer to the same object 'as managed by' two different organizations - and they can serve metadata about the repository as well as the specific object. (If ARKs were already in use, migrating old data would potentially be much easier!) It's possible that these features might require additional functionality (or perhaps just make some new things possible - without requiring any changes just to start using them.) It would be good to have at least a check to make sure there are no gotchas w.r.t. the way Dataverse currently manages PIDs.

Lastly - I'll note that EZID used to mint shadow ARKs - now deprecated I think. I don't know that anything would need to be done for existing DOIs (some in Dataverse started at EZID), but if there are still systems that create multiple identifiers, supporting ARKs fully might involve the alternate identifier filed in Dataverse or some update of that.

[poikilotherm]

Let me link to some older issues on the topic:

• Feature: use ePIC PIDs in addition to DOI and EZID #4833 about adding ePIC
• Plugin mechanism to support further PID providers #4106 about making providers pluggable (GESIS wanted to use DARA PIDs)

This sounds like a perfect use case to talk about refactoring this part of the code with the ideas I proposed in #7050

Let me also add that ARK might be very useful for the Software, Workflows and Containers use case (ping @atrisovic), as ARKs allow for much more detailed references than DOIs. See also FORCE11 SCID WG output 1.1

[qqmyers]

The “suffix passthrough” mechanism mentioned in the FORCE 11 doc above could also affect how file identifiers need to be/should be created when using ARKs.

[atrisovic]

This looks very interesting and I'll add it to our agenda for the SWC working group. @pallinger would you like to join the working group discussions?

[pallinger]

If the working group discussions are still ongoing, then sure! :)

[atrisovic]

Hey @pallinger, yeah! Check out our website: https://swc.wgs.gdcc.io
Can you send me your email at [email protected] and I'll add you to the next meeting :)

[metasj]

Echoing the original request -- ARKs and their philosophy are top notch, I'd love to see them be a first-class option / recommendation for an ID, as noted below.

ARKs are more powerful that DOIs/Handles in that they have two parts - two ARKs can refer to the same object 'as managed by' two different organizations - and they can serve metadata about the repository as well as the specific object.