PID Module: Basic Framework & API Connector

[matthewjmckinley]

• Connect to API, mint PID, assign PID to Omeka item
• Store PID as (internal/public?) item metadata
• Generic enough to swap in other PID APIs in future
• Start with either DOI or ARK

[matthewjmckinley]

@zerocrates @jimsafley Initial commit should perform all the tasks outlined above (with ARK PIDs, DOI will come next). Still some TODOs scattered throughout. Sorry I didn't have time to do a walkthrough of the code, but I would appreciate any issues, redundancies, feedback etc. etc. that you might see upon initial review!

[jimsafley]

I made a few comments on your first commit. I'd say you're on the right track.

One concern I have is that you only allow one PID per item. That's fine if you think users will use no more than one PID service at a time. Maybe add the ability to mint more than one PID per item? I just don't have a sense whether it's something to explore.

Generally speaking, I'm interested in how you plan to add PID services. Your code suggests that they'll be baked into the code. Instead, I recommend abstracting them out as Laminas services. For example, you could create your own PID service manager which will be responsible for getting PID services (EZID, DataCite, etc.), which, in turn, will be responsible for rendering service-specific elements and minting PIDs. This would make it easier to implement services and enable other modules to add their own. It's a common pattern I've used in many modules.

[matthewjmckinley]

These are great notes, Jim, thanks! I can certainly start implementing the more detailed technical suggestions, and I will look in to setting up the PID services as Laminas services that can be swapped out.

As far as one PID per item: I suppose this is just the way I've always seen PIDs utilized--institutions seem to pick a service and stick with it, at least in regard to a specific body of items. Indeed, one single unambiguous persistent identifier per object seems baked in to the premise and utility of PIDs. I realize now that this might be an assumption on my part, and that there might be a use case for multiple PIDs pointing to a single object URI, but I also question whether institutions are using PIDs this way in the real world. I honestly don't know! Perhaps it's something I could ask in the forums, or somewhere like a digital-curation/code4lib/etc. list serv.

It seems like this would be a difficult feature to reverse-engineer after release, so if there is any interest I should probably include it in the initial release.