Write prereserved DOIs into files before depositing them to Zenodo

[zyzzyxdonta]

When metadata is uploaded to Zenodo, we prereserve a DOI. It might be necessary to use this DOI to update files (CITATION.CFF, codemeta.json, README.md, ...) before uploading them. The deposit resource returned by the API after metadata was posted to the deposit_url has a metadata field that can be used for this.

deposit["metadata"] contains a prereserve_doi field which looks like this: {'doi': '10.5072/zenodo.1234567', 'recid': 1234567}. The recid can be used to construct the URL to the record when published: f"https://sandbox.zenodo.org/record/{recid}".

[schlauch]

This would be an awesome feature :)

[FObersteiner]

related ? #63

[zyzzyxdonta]

related ? #63

Definitely related. I don't know if this is as generalizable to other deposit platforms as #63 is, though. E.g. can we prereserve DOIs on Dataverse? I don't know. Also #63 can be applied to other metadata that can only be known after a publication (I don't have a good example though).

[FObersteiner]

right, PID is more general.

Specifically for DOIs on zenodo, I think it should be possible - but to be honest I have no idea though how well this would fit into hermes or a hermes plugin...
To my understanding, once you draft a publication (or an update to an existing one), you get a temporary ID, which then later becomes the DOI suffix once published. At least in my experiments with the zenodo API + zenodo sandbox that worked. Basically, after making the post-request to create / update a publication, you'd have to process the response and use that info for updating local metadata (codemeta.json etc.), then push the updated data to zenodo and call the publish action.

[zyzzyxdonta]

Yes, this is absolutely doable in Zenodo and other Invenio instances. There is no notion of this workflow in Hermes though. Prereserving a DOI in the InvenioDepositPlugin is easy. But writing it back to the files before making the deposition is not. At least not in the general case if we want to support different targets (CITATION.cff, codemeta.json, pyproject.toml, ...) for the DOI.

[FObersteiner]

I see. So, if I understand the hermes workflow correctly, this "insert-DOI" step should be part of the "curate" step? In my naive approach, I wouldn't see huge obstacles in writing to different output files, however wouldn't this break the separation of the "curate" and the "deposit" step, by introducing this kind of statefulness ("pending publication")?

[zyzzyxdonta]

I have some issues with this:

1. It doesn't feel like curation would be the right step to do this
2. Curation happens before deposit but prereserving a DOI feels like part of the deposition process but I could be wrong with this...
3. On the other hand, I think I might want to check again whether every piece of metadata was put in the correct place, so it should happen before the curation even...

Maybe the "pipeline" idea starts to fall apart at this point. Or maybe the postprocess step at the end of the pipeline was the wrong approach and any step of the pipeline should be able to change the files at any time. 🤷‍♂

This feels like something we should discuss in the bi-weekly meeting. But I can't promise that we will actually tackle this problem any time soon 😅

[FObersteiner]

Yep, feels a bit difficult to find a good spot in the existing pipeline (of which I like the idea, especially the CI merge requests !). Anyways, thanks for the discussion. I'll be exploring this topic further, with some custom / specific prototype for my data/software I guess. You could give me a ping once this topic gets on the agenda. Maybe I can contribute some experience by then ;-)