Module for Managing Persistent Identifiers (Handle, EZID, etc...)

[elizoller]

We have a use case where we need to mint handles on a locally running handle server for handle.net http://handle.net/
The idea was briefly mentioned here: #1042

The idea would be that

• when a repository node is created, it would mint a handle (via REST API) (this could be controlled via context)
• the handle would be returned and stored as part of the node
• the handle would be displayed to the users
• the handle would be mapped to RDF in Fedora (maybe schema:sameAs?)
• the handle would be redirected to a tombstone message when the repository node is deleted

I have started developing this and am wondering if this is something that would be applicable for other institutions. If so, I will try to develop in a way that would allow it to be contributed.

[pautri]

We are running a local Handle server currently with an Islandora 7.x instance, but we have a custom ingest pipeline that also takes care of the Handle issuing. We may want to stick to such a setup when migrating to Islandora 8, I'm not sure yet, we do not have any concrete plans for migrating.

Regarding destroying Handles when nodes are deleted, I think a better option would be to keep the Handle but direct it to some kind of "tombstone", after all they're meant to be "Persistent Identifiers". Fedora 4/5 has this tombstone concept.

[elizoller]

@pautri good thinking on the tombstoning - i have updated the issue

[seth-shaw-unlv]

This is on my (very long) task list; with the exception that we use the EZID service (their API) to mint ARKs.

I'm thinking we could make a stand-alone module that builds the framework (the necessary hooks) for minting and updating persistent identifiers but make the actual minting/updating logic plugin-based. We would have an IdentifierManagerPluginBase that could be extended by HandleManager, EzidManager, etcetera, plugins.

Note: our semi-automated process here is suitable for now, and I have enough on my plate at the moment, but I am happy to contribute once I check off some higher-priority issues. Possibly in December/January?

[mjordan]

👍 to @seth-shaw-unlv 's suggestion. The identifier-specific minting could be handled by submodules that could have their own configuration for DOIs (and there are multiple DOI providers), Handles, ARKs, etc.

[elizoller]

Thanks @seth-shaw-unlv and @mjordan. This sounds like a great approach! I'll see if I can get something started and then we can work more on it together later on. 👍

[mjordan]

We'll definitely want to be able to mint DOIs, so count me in.

[mjordan]

Tagging @bryjbrown and @DonRichards since this will be of interest to the IR Interest Group.

[mjordan]

Picking up conversation on this again... is the goal of such a service simply to mint an identifier on object ingest (or in addition, on demand from within the user interface by a suitably privileged user, which is what we do now with Datacite DOIs) and insert the new identifier into a specific field on the object? If so, a couple of functional requirements would be:

1. "mint an identifier" can be done in a variety of ways (e.g., get a DOI from DataCite, get a DOI from Crossref, get an ARK from a service, etc.).
2. allow implementors to choose a minting method, a target field, and a workflow (e.g. auto / manual)

[elizoller]

Yes, that aligns with my thinking as well.

[mjordan]

I've started an implementation of some ideas around how we might have pluggable minters (and persisters) at https://github.com/mjordan/persistent_identifier_framework, e.g.:

• minter a persistent identifier, and saving it to a node's field, are done via services
• third-party, or submodules, can invoke these services
• three possible workflows:
  • GUI, as illustrated in the README
  • Drush command, as documented in the GUI
  • a Context Reaction for automated assignment of PIDs on add/update nodes

Nothing in this module is sacrosanct, I'm just playing around at this point trying to figure out how to do stuff in Drupal 8.

On a related topic, our current use of the Islandora 7 module to mint DOIs from DataCite is illustrated in this screenshot:

We do not have end users assign DOIs, but instead have one of our research data management curators do that after the object has been created. We'd be looking for something similar in Islandora 8.

[seth-shaw-unlv]

Interesting. I was thinking we would use a plugin model, but it looks like the services model could work just as well. Either way we probably want to include a Minter Interface class that our minters can implement. We may also want an update function in case we need to update a PIDs record. (E.g. telling EZID that the URL of a node changed because the path was updated.)

[mjordan]

Yes, I called the updating the "persister" service above but now don't like that lingo since it competes with "persistent" identifier. "Updater" is better. One reason that service should be swappable is that some instances would want to store the DOI, etc. in a text field, others in a typed relation field, etc.

[seth-shaw-unlv]

Also, you can probably drop "_framework" from the module name; or you can swap it with "_api" to mirror the search_api module.

[mjordan]

I'm not attached to "_framework", I was emulating the 7.x version. I haven't had a chance to look at any work that @elizoller has done and don't want to duplicate it. I suggest we all get together early in the new year and maybe have a call to decide how to move forward. Or, join the IR Interest Group call to get wider use cases.

[elizoller]

I started a plugin style approach, but it's hard-coded to ASU things right now while I try to get it working. I would definitely be keen to join a combined effort for this. We can ping @DonRichards about getting it an IR Interest Group call.

[mjordan]

I've moved my repo to https://github.com/mjordan/persistent_identifiers, reflecting @seth-shaw-unlv 's suggestion to remove _framework from the name.

[elizoller]

I submitted a PR to @mjordan 's persistent_identifiers to add a Handle minter: mjordan/persistent_identifiers#2

[seth-shaw-unlv]

I'll eventually get an EZID one going, but I need to get the Islandora Workbench Desktop to a distributable beta first.

[mjordan]

@elizoller thanks! Your Handle minter has been merged into the master branch. It works as expected in the config and user UIs, but I don't have an account on a Handle minting service, so couldn't test that part.

[simonhm]

Hi all,
@elizoller Any updates for this ???
"the handle would be redirected to a tombstone message when the repository node is deleted"
<<< We're interested in this as well.
Thanks!
Simon.

[mjordan]

@simonhm PRs welcome if you can put some time on this.

[simonhm]

@mjordan
I'm thinking about creating a rule action (Minting Handle, for example). Then using rules to apply the "tombstone message" for the node getting deleted. Basically we will not delete the handle link. Instead, we will update the URL record of the handle link into somewhere having "tombstone message".
What do you think?
Simon.

[jordandukart]

@simonhm you could look into using https://github.com/discoverygarden/dgi_actions if you'd like!

[mjordan]

Thanks @jordandukart. I'm going to put a call out to the community to see if anyone wants to take on ownership of the Persistent Identifiers module. It's not fair to the community that I am ghosting people on it.

Edit: here's that call.