Evaluate existing code for EZID client gem

[gamontoya]

Descriptive summary

The EZID/DataCite Working Group has been formed and will organize and coordinate efforts around Samvera Partners moving from EZID to DataCite for DOI creation. UCSD will continue to use EZID and therefore this working group would like to see if the existing code from Virginia Tech can be the starting point and also build out DataCite support from there.

UCSD developers (and other dev from other institutions) are being asked to review the code.

Note: How does this code differ from Dukes?

Context for EZID Clien Gem Review

Per Rick Johnson:

From EZID support standpoint no specific objectives other than to understand current solutions that exist to date, and which we may want to continue to use and/or adapt for built-in support within Hyrax. We will be doing same for any work that has been done with Datacite (e.g., DCE is working on an implementation in the next couple weeks).

[gamontoya]

@mcritchlow I added Rick's response above.

[mcritchlow]

@gamontoya - I'll take a look at this and report back once I've got something and/or have more questions.

[mcritchlow]

Ok, here are a few initial things:

1. The Virginia Tech application is using Duke's ezid-client gem, so there's nothing really of value there other than a reference implementation we could consult as we build out usage ourselves. They're taking some different directions with their EZID integration that I'm not sure we'll want. For example, they're auto-minting DOI's for every created object.

2. I've created a ticket in the Duke repo to ask the lead developer (David Chandek-Stark) what his thoughts are on ensuring the gem can stay maintained going forward.