Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial draft of a design document for the Zenodo like DOI per dandiset #2012

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions doc/design/doi-generation-2.md
Original file line number Diff line number Diff line change
Expand Up @@ -33,10 +33,10 @@ DataCite allows for three types of DOIs ([DataCite](https://support.datacite.org
We propose to:

- Instead of a fake DOI, upon creation of a **public** dandiset, mint and use a legit `Draft DOI` `10.48324/dandi.{dandiset.id}` with
- *minimal metadata* entered during creation request (title, description, license)
- DLP URL `https://dandiarchive.org/dandiset/{dandiset.id}`
- For embargoed dandiset, **do not** specify any metadata besides the DLP URL.
- If minting a DOI fails, we need to raise exception to inform developers about the issue but proceed with the creation of the dandiset.
- *minimal metadata* entered during creation request (title, description, license)
- DLP URL `https://dandiarchive.org/dandiset/{dandiset.id}`
- For embargoed dandiset, **do not** specify any metadata besides the DLP URL.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a thought: perhaps the doi generation process can be implemented only when dataset is unembargoed. i.e. embargoed datasets cannot be pointed to by doi (even if we get reviewer view only access). an owner would have to unembargo it.

for implementation, doi generation happens at creation for public and unembargoing for embargoed dandisets.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could. But one of the goals here is to get away from using "fake DOIs" (#1709) which this would "prevent".

In current design (might change) we would make overall dandiset DOI Findable only upon initial publication. As embargoed dataset would never be published, its DOI would remain Draft thus not available to users, and thus IMHO there is no harm. I think we could even keep updating it with metadata etc. That IMHO would simplify the logic and make "embargoed" less special (thus easier to code/troubleshoot etc).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In current design (might change) we would make overall dandiset DOI Findable only upon initial publication.

Given demand from zarr users to get DOIs for dandisets with zarrs, we better make them Findable as soon as possible in the life cycle of those dandisets. ref: dandi/helpdesk#165 (reply in thread) . So I think we should proceed that way -- make them Findable as soon as datacite validation passes. Also inform user about datacite model issues as part of the validation.

- If minting a DOI fails, we need to raise exception to inform developers about the issue but proceed with the creation of the dandiset.
- Upon changes to dandiset metadata record, for public (non-embargoed dandisets), try to update datacite metadata record while keeping the same target URL.
- For `Draft DOI` (dandiset was not published yet), there is no validation.
- **Question to clear up**: what happens to Draft DOI if metadata record is invalid? Does it fail to update altogether? does it update only the fields it knows about?
yarikoptic marked this conversation as resolved.
Show resolved Hide resolved
Expand Down