Assess pivot to DataCite API

[bryanmgee]

Instability and unpredictability of the TDR servers is hindering scripted work that uses the Dataverse API. Quite a lot of the relevant metadata can be obtained from the DataCite API, though with less granularity (e.g., no versions) and lack of certain fields (e.g., parent dataverse). Build list of 'can' and 'cannot':

Can retrieve from DataCite:

• Author name, identifier, affiliation (and affiliation identifier)
• Dataset contact name and affiliation
• Subject (sort of, is mixed in with keywords but could be pulled out via CVOC)
• Keywords
• MDC metrics (not directly equivalent to DV metrics)
• Individual file sizes
• Individual file mimetypes
• Manual and automated timestamps (e.g., published, created, deposited)
• License

Cannot retrieve from DataCite:

• Parent institution's dataverse
• Dataset ID
• Version ID
• Dataverse information
• Dataset contact email
• Data depositor information
• Assorted restrictions fields

[bryanmgee]

Secondary question is what API needs to be used to get the metadata that DataCite doesn't contain.

• [Search] Parent institution's dataverse
• [Native] Dataset ID
• [Search] Version ID
• [Search] Dataverse information
• [Native] Dataset contact email
• [Native] Data depositor information
• [Native] Assorted restrictions fields

Current analysis would suggest that combo of DC + Search API is not sufficient; if we still have to hit the Native API for each dataset (which we do) and each dataverse (which we do), not a clear benefit to using DC API as a means of reducing usage.