DOIs for CF Convention releases?

[rsignell-usgs]

Seems like getting a new DOI for each release of CF would be a good idea.

And getting a DOI is pretty easy for GitHub releases:
https://guides.github.com/activities/citable-code/

What do folks think?

---

In March 2023 the CF governance panel decided to use Zenodo fo CF DOIs, as reported by Ethan @ethanrd. After the annual meeting in September 2023, Gui @castelao prepared pull request 443 to support CF's adoption of GitHub/Zenodo integration.

[davidhassell]

An excellent idea, I think.

[cf-metadata-list]

Makes a lot of sense to me. Cheers, Roy. Please note that I partially retired on 01/11/2015. I am now only working 7.5 hours a week and can only guarantee e-mail response on Wednesdays, my day in the office. All vocabulary queries should be sent to enquiries@bodc.ac.uk. Please also use this e-mail if your requirement is urgent.

…

________________________________ From: owner-cf-metadata@listserv.llnl.gov <owner-cf-metadata@listserv.llnl.gov> on behalf of David Hassell <notifications@github.com> Sent: 18 January 2018 19:28 To: cf-convention/cf-conventions Cc: Subscribed Subject: Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127) An excellent idea, I think. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#127 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AfI2geMh29WgZpi4h9niedoqGHr574-yks5tL5mcgaJpZM4RjadX>.

________________________________ This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.

________________________________

[ethanrd]

Another option is to have a single DOI and recommend that users include the version number when citing CF.

What URL should result when dereferencing a CF DOI? I would think either the main CF web page or the current CF specification document.

[neumannd]

It sounds like a good idea to assign DOIs for the cv convention documents. The content, to which a DOI points, has to be invariable. Therefore, a DOI can only be assigned to a particular version of the cf convention document and not to the cf conventions in general.

[davidhassell]

I know that on some DOI services (e.g. https://zenodo.org/) you can have a unique DOI for each release, but also generic DOI that always resolves to the latest version. I don't know if this feature is ubiquitous, though.

For instance, https://doi.org/10.5281/zenodo.832255 resolves to the latest version of cf-python, whatever it may be. Right now it's v2.1, and v2.1 has it's own DOI https://zenodo.org/record/1039367

[ethanrd]

The DOI itself is permanent, the URL that results from dereferencing the DOI can be changed. The object/concept the DOI identifies should be permanent. What that object/concept actually represents and the possible versioning of that object, I believe, is up to those stewarding that object.

DataCite [1] is the DOI minting service I've used. Their metadata schema [2] includes a field for version information. There are some notes on versioning on page 28 of the "DataCite Metadata Schema Documentation for the Publication and Citation of Research Data" [3] including:

Suggested practice: track major_version.minor_version.

Register a new identifier for a major version change. Individual stewards need to determine which are major vs. minor versions2

Not sure what other DOI minting services recommend or how this might work if using the GitHub DOI minting tie-in with FigShare.

[1] https://www.datacite.org

[2] http://doi.org/10.5438/0014

[3] https://schema.datacite.org/meta/kernel-4.1/doc/DataCite-MetadataKernel_v4.1.pdf

[ethanrd]

Yes, I kind of like the idea of having a top-level DOI and one for each version. Though, more DOIs means more things to maintain and more DOIs to include when tracking citations.

With a top-level DOI and individual version DOIs, what would be the recommended citation? Including the version information in the citation is more transparent (at least to the human eye).

The DataCite metadata schema includes a relationType property that can be used to give a relationship with another DOI-ed resource. It has a controlled list of values that includes HasVersion and IsVersionOf. So, perhaps defining these relationships will help ameliorate some of the issues around multiple DOIs.

[neumannd]

OK, thanks for the clarification. I wasn't aware of that possibiliy.

[rsignell-usgs]

@davidhassell would you be willing to make this happen?

[graybeal]

OK, looks like I'll be the odd one out here. Let me ask a few questions:

• What will the DOI(s) be used for that the canonical URLs can not?
• What capability do the DOIs have that the canonical URLs do not?
• How will you resolve the duality of two canonical references, one being the DOI and the other being the canonical URL?
• How will the DOIs representing different versions be recognizably different versions of the same entity/publication?
• How will the DOIs be recognizably associated with the CF conventions, without having to actually resolve them? (This, at least, there is a known answer to, just want to be sure we are leveraging it.)

I know the community likes DOIs, but I'm not convinced there is any analytical advantage to the function provided by the DOIs.

[dopplershift]

I completely reject the idea that a URL on the internet is a suitable fixed point of reference. The "canonical URL" for the CF-conventions has changed over time, rendering unusable any publication citation that relied upon that.

DOIs provide a fixed record suitable for citation that is capable of being updated to point to new "landing pages" for the same content.

[dblodgett-usgs]

Assuming someone maintains the mapping between DOI and the intended digital object's current URL. Otherwise, DOIs become stale unique strings the same as URLs do. I said I'd stay out of the persistent identifier flame war, but I failed. Maybe we should use blockchain.

…

On Jan 19, 2018, at 11:58 AM, Ryan May ***@***.***> wrote: I completely reject the idea that a URL on the internet is a suitable fixed point of reference. The "canonical URL" for the CF-conventions has changed over time, rendering unusable any publication citation that relied upon that. DOIs provide a fixed record suitable for citation that is capable of being updated to point to new "landing pages" for the same content. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#127 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABbHQxMdhPyMjQpwEsqD-hfJECeDFzirks5tMNfGgaJpZM4RjadX>.

[dopplershift]

Sure, everything digital needs upkeep--that's the blessing and the curse.

It's not my area of expertise, so I'm not really qualified to debate this with an informed point of view. therefore when it comes to best practice for long term reference and archival, I'll trust what the experts (i.e. digital library people) tell me to do: DOIs.

[graybeal]

The only reason canonical UIs have to change is that they have been chosen and managed without regard to their final purpose. (Something that DOIs are also vulnerable to, though I agree not as commonly.) Put me in the Cool URIs Don't Change camp.