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

Generate DOIs for templates using DataCite #1173

Open
martinjoconnor opened this issue Aug 12, 2022 · 3 comments
Open

Generate DOIs for templates using DataCite #1173

martinjoconnor opened this issue Aug 12, 2022 · 3 comments
Assignees
Labels

Comments

@martinjoconnor
Copy link
Member

martinjoconnor commented Aug 12, 2022

Generate DOIs for templates using DataCite

Driven by the FAIRworkflow project, support the generation of DOIs for CEDAR templates.

Possible implementation scenario:

Give users the option of generating a DOI using DataCite when making public a version of a template (see here for documentation on the process of making a template public).

When made public in this way, a version of the template will be available at a newly generated URI. (This URI looks something like: https://openview.metadatacenter.org/templates/https:%2F%2Frepo.metadatacenter.org%2Ftemplates%2Ff52a9a21-c593-4ea3-958a-df6cf01e080a, which is not ideal. Perhaps allow redirects from https://repo.metadatacenter.org/templates to directly go to the OpenView view of public artifacts.)

We will need information from users (e.g., name, institution) to supply DataCite with sufficient information to generate a DOI. One option is to ask users to link their CEDAR account with their ORCID account (using the current ORCID SSO capabilities in CEDAR) and the retrieve that information and submit it to DataCite along with the public URI of the template.

Currently, there is no UI dialog for making a template public so we would need to implement dialog to acquire any necessary information for the user.

We will need to decide where we store the generated DOI in the source template, possibly along with other metadata.

@graybeal
Copy link
Member

Waaait. your visual is the Publish action, but the thing that makes CEDAR artifacts publicly visible is Enable OpenView. Currently, there is no dialog when that option is selected.

@martinjoconnor
Copy link
Member Author

Ooops - you are right. Will correct.

@graybeal
Copy link
Member

Note that typically people who generate DOIs think of the DOI as the primary identifier of the Digital Object (DO). (That was more or less the stated purpose of DOIs.) So in some sense, it competes with the CEDAR identifier as the primary identifier of the CEDAR artifact. I don't think this is a major issue, most people/projects will pick one and not the other consistently, and DOI doesn't enforce/expect that interpretation.

Nonetheless, it's worth being aware that the CEDAR identifier will resolve (should resolve?) to an actual entity inside CEDAR, if the user has permission. Whereas the DOI will resolve to the CEDAR OpenView of the entity, which in turn lets you access the CEDAR entity (again, if you have permission).

Do we need to question our assumption that the DOI should resolve to the public view of the CEDAR artifact? The DOI documentation says a DOI "takes you to one or more current URLs or other services related to a single resource", whereas Wikipedia says it should resolve to "the information object to which the DOI refers.", and in CrossRef they resolve DOIs to "a response page containing no less than complete bibliographic information about the target content". So I guess we get to decide what these DOIs that we create will resolve to.

One option would be for CEDAR to be smart enough to test a CEDAR identifier to see if the user has access to it; and if they do not, send them to a publicly viewable page, assuming it exists. Then if we require all DOI'd CEDAR entities have OpenView enabled, all DOIs would resolve to the internal CEDAR view for people with access, and the public view for others.

In the end that may be more confusing than good—it's making the resolution target consistent, but creating slightly inconsistent behavior for some cases for a CEDAR user.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants