Handling DOIs for restricted records

[ppanero]

A record might get a DOI reserved when creating a draft. However, then the access rules might change. The use cases are the following:

• [ ] A draft gets a reserved DOI, but then it changes access to embargoed.
• [ ] A record gets a reserved DOI, but then it changes access to embargoed. Can this happen, the record access cannot changed, when published?
• [ ] A drafts gets a reserved DOI, but then it changes to access to restricted
• [ ] Once the embargo is lifted how does the DOI gets registered?

Related issues:

• [ ] https://github.com/inveniosoftware/invenio-app-rdm/issues/2129
• [ ] Ensure that we can easily add Crossref provider

[tmorrell]

I think we want embargoed records to have published DOIs. Embargoed record metadata is public so there is no risk in sending metadata to DataCite. For our common embargo use case (files under review for a publication) you need the DOI to be registered so editors and reviewers can see that the DOI works.

For records where access is "restricted", I think there is very limited risk in having a reserved DOI. Reserved DOIs don't show up in any public system and aren't even in the handle system. I guess it depends on your level of concern about restricting access to the metadata, since you are putting information on another system. But the access levels do match between restricted and draft.

The only state change I think we have to worry about is:

• [ ] Record is published, then user changes access to restricted. In this case we'd want to use the private_doi call to make sure metadata doesn't appear in the DataCite public interface.

[ppanero]

@tmorrell I see your point about embargoed, thanks. In terms of restricted... I think I would still not send the metadata out... For Zenodo/similar use cases is Ok I guess. But for medical or more "confidential" repositories it might not be a good idea to shit metadata out... In that case I guess the question is "why have a DOI provider?"... Maybe @lnielsen can clarify on this use case.

[ppanero]

Add this test:

@pytest.mark.skip("PIDS-FIXME: re-enable when tackling permissions")
def test_reserve_pid_without_login(
    app, location, es_clear, headers, client, minimal_record
):
    """Test the reserve function" without client log in."""
    # Create the draft
    response = client.post(
        "/records", data=json.dumps(minimal_record), headers=headers)

    assert response.status_code == 201
    recid = response.json['id']

    response = client.get(
        f"/records/{recid}/draft/pids/doi", headers=headers)
    assert response.status_code == 403

Among others, just not in the test suite at the moment...

[github-actions[bot]]

This issue was automatically marked as stale.

[Herrner]

But for medical or more "confidential" repositories it might not be a good idea to shit metadata out... In that case I guess the question is "why have a DOI provider?"... Maybe @lnielsen can clarify on this use case.

People who want a DOI should be aware that the metadata is always public (even CC0?), so if you want your metadata to be hidden, don't get a DOI.

[github-actions[bot]]

This issue was automatically marked as stale.

[chriz-uniba]

People who want a DOI should be aware that the metadata is always public (even CC0?), so if you want your metadata to be hidden, don't get a DOI.

• we might would like to see a "I do not want a DOI" button. Since currently in a repo that creates DOIs, you cannot have a published record without a DOI.

Going the other way round:

• If there's a DOI then the DOI needs to be resolvable and therefore at least the metadata of the record needs to be public.
• Therefore, creating a "fully restricted record" would be forced to be a record without a DOI.
• When a record is published with a DOI, fully restricting the record should be prevented.
  • admin magic (deleting a record from invenio) for horrible exceptions

Said that... I'm sure I didn't thought through all corner cases.

Additional notes:

• We had internal discussions wrt. to fully restricted records and embargos and whether it would be okay to have a DOI given an embargo-date.
• Our conclusion is: no - an embargo (1 day, 10 days, 100 days 1000 days, 10 000 days) is not enough to create a DOI for a fully restricted record.

[github-actions[bot]]

This issue was automatically marked as stale.

[github-actions[bot]]

This issue was automatically marked as stale.

[wgresshoff]

We don't want fully restricted records to register a DOI. If it is only a reserved DOI which is not findable it might be ok.

[lnielsen]

Discussion from the coffee break at the InvenioRDM workshop with Werner, Nico, Martin, Karolina and Christoph.

Proposed solution:

• Restricted records: DOIs are not created, and hence also not registered.
• Restricted records with embargo: DOIs are not created, and hence also not registered.
• Public with restricted files (w/wo embargo): DOIs are created and registered when published.
• Public: DOIs are created and registered when published.

State changes:

• Restricted -> Public (e.g. user changes the setting or embargo expire): No DOI is created automatically.
• Public -> Restricted (e.g. user changes visibility setting): A general warning is displayed to the user that they should be aware that a DOI is registered and metadata may have been harvested by several systems and there's no control of what happens.

[chriz-uniba]

Can someone shortly explain:

• "Restricted -> Public (e.g. user changes the setting or embargo expire): No DOI is created automatically."

• Why did you decide to not create a DOI in this case?

• Will there be a way to create it manually?

[fenekku]

+1 on @chriz-uniba comments. Apart from that the rest of the approach seems good and we would like to see that happen at NU. We are willing to lend a hand.

[chokribr]

Datacite identify three states for registered metadata:

publish | Triggers a state move from draft or registered to findable register | Triggers a state move from draft to registered hide | Triggers a state move from findable to registered

to Move from published to restricted we can use the "hide" state this will make metadata no longer available and findable via the Public API but they will stay viewable by members! https://support.datacite.org/docs/doi-states