I spoke with a couple of experts on DOIs, and here is my suggestion.
First, some clarifications:
- The DOI handle that we see, something like 10.21238/S8SPRAY1618, is like a
primary key in a database. Associated with that DOI, there are several fields
stored in a public database, such as creators, license, contributors, funding
agencies, and related DOIs. This last one is how a DOI is linked to other
items. Another field is the URL for the landing page, which is not necessarily
the dataset or the document itself, but a human-readable page explaining what
it is and where to get it;
- DOIs are not URLs and should not replace URLs. We should keep using URLs in
the websites and even documentation, while DOIs would be used on the
bibliography list;
- The DOI handle doesn't change, but the fields of that DOI can be updated;
- Only a few fields are required to register a DOI, while most of the fields
are optional;
My suggestion is to create the following structure of DOIs:
- (A) Top DOI to aggregate the whole CF
- (B) DOI for cf-conventions (isPartOf A)
- (E) DOI for conventions version 1.9 (isVersionOf B)
- (F) DOI for conventions version 1.8 (isVersionOf B)
- DOI for conventions version 1.7 (isVersionOf B)
...
- (C) DOI for standard names (isPartOf A)
- (D) DOI for standard names version 75 (isVersionOf C)
- DOI for standard names version 74 (isVersionOf C)
- DOI for standard names version 73 (isVersionOf C)
...
One top-level DOI for the whole CF-Conventions, as an evolving concept (A).
The conventions manual and the standard names evolve on different time scales,
and one specific convention version could be used with several versions of
standard names. Thus let's keep those separated — one DOI for CF-conventions
(B) and one for standard names(C).
Each version released receives its own DOI. For instance, standard names
version 75 has one DOI (D), as well as CF-Conventions 1.9 has its own DOI.
This structure allows for granularity on how to use it. Someone interested in
reproducibility would be interested in defining one specific version and would
use DOIs such as (D), (E), or (F). If a specific version is not required, one
would use (C) or (B). Finally, to talk about the whole system, one would use
(A). (A) would also be the way to measure the scientific impact (like cited n
times) since it aggregates all components.
All these DOIs would be linked. For instance, E isVersion of B, D isVersion of
C, and C is PartOf A. These links are registered on the creation of the DOI.
Nobody has to worry about this except the person recording the DOI. These links
are meant for machines, not for us.
How to manage all this? DOIs for specific versions could be registered using
Zenodo. That can be set up to be done automatically every time we do a new
release on GitHub. Zenodo takes a snapshot of the repository at the moment of
the release and archives it. The URL (landing page) associated with that DOI is
the archiving place at Zenodo.
The general DOIs for CF-Conventions and standard names (B & C) would be the
overarching DOIs created by Zenodo, which points to the latest version of each
line. For instance, if I'm not concerned with the specific version but just
want to refer to the standard names, I would point to DOI (C), which is
automatically updated to point to the latest version of standard names.
Finally, the top-level DOI (A) would be recorded manually, without using
Zenodo. Some alternative providers are UC Library or UCAR. Note that this
information is not stored at UC Library or UCAR, but they can provide us access
to the system. It requires more work since it is manual, but we don't expect
regular updates, and it allows us the freedom to define each field as we want.
Using Zenodo we don't have access to all the fields related to a DOI. For
instance, we can't choose a landing page. For the top-level DOI, a good landing
page (i.e., the URL associated with that DOI) could be the cf-conventions.org
website.
In summary, using Zenodo we can create a configuration file to be saved in the
repository so every release, everything goes automatically, but we need to
conform to the way Zenodo operates. Registering manually is more work but gives
more freedom.
If this sounds too complex and there is no interest in granularity to cite
specific versions, we can ignore the levels below B & C. If we want a
minimalist version and really don't care about versions and reproducibility, we
can use (A) only.
Please, let me know your questions.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/127*issuecomment-933831094__;Iw!!G2kpM7uM-TzIFchu!hKIH6E6RWQChqiKwqwtrCZEIw_BuHqRNwTT1FSZttL67dmBLrT12Yb_XI5OUPownMY9cqql5cSA$
This list forwards relevant notifications from Github. It is distinct from
[email protected], although if you do nothing, a subscription to the
UCAR list will result in a subscription to this list.
To unsubscribe from this list only, send a message to
[email protected].
