Ability to mint DOIs for completed DMPs

[mariapraetzellis]

Our initial work on minting DOIs via DataCite for completed DMPs via the DMPHub/DMPTool was tracked here.

We now need to take this existing work and transfer it into Roadmap. Some outstanding questions remain:

• Workflow for dealing with DOI mint failures. For example, do we still capture the DMP metadata and allow a DMPHub admin to correct any issues and then re-try the minting process? If so how does the origin of the DMP metadata (e.g. DMPTool) get notified of the DOI afterward.
• Where are we tracking versioning?
• Where does the user request that a DOI is minted? We had thought this could be within the Share tab, but should be discussed with the group.
• What DataCite account is minting the DOI? Should this go through CDL?
• Need to determine if assertions against the DMP DOI will be handled via the DMPHub, DMPTool or something else.

[mariapraetzellis]

We will need to require ORCID authentication before minting a DOI.

[briri]

We need to discuss workflows for this. We are trying to do the following for the DMPTool:

• An external system or individual researcher creates a new plan in the DMPTool
• Researcher(s) write the DMP
• Researcher clicks a button indicating that they are done and ready for funder review
• Funder (template owner) reviews and approves the plan which triggers the following:
  • DMPTool sends a request (as RDA common standard metadata as JSON) to a new system (aka DMPHub) that mints a DOI through Datacite
  • That new system returns the DOI to the DMPTool. The DOI resolves to the DMP download URL which dynamically creates the DMP PDF based on the current data.
• Researchers now see a link on the Project Details page to the plan's landing page (hosted by the new system)
• Researchers make changes to the plan which triggers (need to define what constitutes a 'change'):
  • Generation of a PDF copy of the plan prior to the changes.
  • Store the PDF somewhere (Zenodo, Dryad, local disk or S3, etc.).
  • Add a reference to this old 'version' in a new related_identifier or plan_versions DB table.
  • DMPTool sends the updated metadata to the new system (aka DMPPHub) including the link to the older version

Not every installation of the DMPRoadmap codebase will mint DOIs though, and those that do may not agree on a minting authority (e.g. Datacite, Crossref, EZID, etc.). This is why we are opting to leave the minting of identifiers to an external system.

How can we handle this for those installations that do not want to mint DOIs? Can we simply just make this functionality configurable? Which would:

• Disable the entire funder review and plan 'completion' workflow
• Disable the versioning of plans as PDF copies
• Always use the plan's PDF download URL as the dmp_id in the API

questions:

• should minting be enable-able on a per template level (Where it is disabled by default)?
• Is generating and storing PDF copies of a plan enough for versioning? Or do we need to implement versioning like we do for templates?

[mariapraetzellis]

@mariapraetzellis @magdalenadrafiova @sjDCC Things to discuss:

1. Where does button live that mints a DOI
2. Where do we display the DOI once it has been minted

[mariapraetzellis]

Adding two screenshots of where we put the button to mint the DOI in our prototype:

1. Register your plan
   

2. Confirmation that the DOI was minted and a link to the landing page:
   

[sjDCC]

I think this might sit better on the download page as getting a DOI is more like publishing? Or we create a publish tab? We discussed some ideas on a DMP product manager call which I've tried to visualise below so we can discuss with UX

[briri]

removed 'Enable SSO' ticket from this epic. We are going to hold off on that for now