Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[Guilherme Castelão]

My understanding is that this DOI would be used as any other reference, which 
should be included in the list of references at the end. With a single DOI or 
one for each version, the version identification (ex. CF-1.7) would go 
explicitly in the bibliographic references section. In my lab, we explicitly 
write a line suggesting how to cite our DOIs.

About adopting multiple versions or not, it might be useful to distinguish 
between major versions, like someone that wants to refer that followed CF-1.X 
or CF-2. I don't have a strong opinion about adopting a DOI for each version, 
but at least one DOI is crucial to allow any metric of the scientific impact of 
the CF conventions. 

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-433235930

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[Nan Galbraith]

Without wanting to belabor this point, since it's clearly been decided, I'd 
like to point out that the DOI can in no way replace the description of CF in 
the Conventions attribute: 'files that follow these conventions indicate this 
by setting the NUG defined global attribute Conventions to the string value 
"CF-1.7"'.

The Conventions attribute is human-readable, very important for those of us who 
use data at sea or otherwise off-line. This leaves the issue of multiple items 
containing identical (hopefully)  information. To me, it's one more reason to 
use a single DOI for CF, not for each version.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-432704808

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[John Graybeal]

I remember doing a similar exercise several years back. The COARDS-unique 
contribution was a very thin thread indeed, in my opinion. COARDS is very old 
now, and relatively to CF, was pretty primitive at its completion. I would be 
surprised if it is in use at all. At this point, I think "COARDS-inspired" 
might be closer to the truth, and more useful framing.

John


On Oct 23, 2018, at 9:36 AM, Nan Galbraith 
mailto:notificati...@github.com>> wrote:


Thanks, that's great. While I agree that we need to mention standard names, I 
don't think we can say 'precise definition of each variable via specification 
of a standard name' though, because CF allows variables without standard names.

Also, I'm afraid some of the details might be better omitted, like 'describes 
the vertical locations corresponding to dimensionless vertical coordinate 
values' - which may only confuse people. You covered that nicely with 'spatial 
and temporal properties of the data', I think.

Last, in a brief description of CF, could we consider omitting references to 
COARDS? I realize it's good to keep that in the CF docs, but ... is there any 
part of COARDS that's not described in those docs? I'm almost sure the answer 
is no. I went to check, however the link to COARDS from 
unidata.ucar.edu/software/netcdf/conventions.html
 is broken. Hmm, that tells us something, too.

—
You are receiving this because you commented.
Reply to this email directly, view it on 
GitHub,
 or mute the 
thread.


John Graybeal
Technical Program Manager
Center for Expanded Data Annotation and Retrieval /+/ NCBO BioPortal
Stanford Center for Biomedical Informatics Research
650-736-1632




-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-432372842

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[Nan Galbraith]

Thanks, that's great.  While I agree that we need to mention standard names, I 
don't think we can say 'precise definition of each variable via specification 
of a standard name' though, because CF allows variables without standard names. 

Also, I'm afraid some of the details might be better omitted, like 'describes 
the vertical locations corresponding to dimensionless vertical coordinate 
values' - which may only confuse people. You covered that nicely with 'spatial 
and temporal properties of the data', I think.  

Last, in a brief description of CF, could we consider omitting references to 
COARDS? I realize it's good to keep that in the CF docs, but ... is there any 
part of COARDS that's not described in those docs?  I'm almost sure the answer 
is no. I went to check, however the link to COARDS from 
unidata.ucar.edu/software/netcdf/conventions.html is broken. Hmm, that tells us 
something, too.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-432321913

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[Guilherme Castelão]

The required fields to mint a DOI for CF conventions. I used the documentation 
authors as creators, but it still misses most of the ORCIDs. These are only 
suggestions; please let me know if you would like to change any field.

=


- URL: http://cfconventions.org
- Title: NetCDF Climate and Forecast (CF) Metadata Conventions

- Publisher: ??

- Publication Year: 2004 (Since this is the general DOI, should it go with the 
very first version or the latest?)

- Resource Type General: Text

- Description:
  - Descriptive information: This document describes the CF conventions for 
climate and forecast metadata designed to promote the processing and sharing of 
files created with the netCDF Application Programmer Interface [NetCDF]. The 
conventions define metadata that provide a definitive description of what the 
data in each variable represents, and of the spatial and temporal properties of 
the data. This enables users of data from different sources to decide which 
quantities are comparable, and facilitates building applications with powerful 
extraction, regridding, and display capabilities.
The CF conventions generalize and extend the COARDS conventions [COARDS]. The 
extensions include metadata that provides a precise definition of each variable 
via specification of a standard name, describes the vertical locations 
corresponding to dimensionless vertical coordinate values, and provides the 
spatial coordinates of non-rectilinear gridded data. Since climate and forecast 
data are often not simply representative of points in space/time, other 
extensions provide for the description of coordinate intervals, 
multidimensional cells and climatological time coordinates, and indicate how a 
data value is representative of an interval or cell. This standard also relaxes 
the COARDS constraints on dimension order and specifies methods for reducing 
the size of datasets.
  - Type: Abstract
  - Description Language: English

- Funding Reference (May have several items):
  - Funder Name: ??
  - Funder Identifier: ??
  - Identifier Type: ??

- Creators
  - Brian Eaton
- Affiliation: NCAR

  - Jonathan Gregory
- Affiliation: University of Reading and UK Met Office Hadley Centre

  - Bob Drach
- Affiliation: PCMDI, LLNL

  - Karl Taylor
- Affiliation: PCMDI, LLNL

  - Steve Hankin
- Affiliation: PMEL, NOAA

  - Jon Blower
- Affiliation: University of Reading

  - John Caron
- Affiliation: UCAR

  - Rich Signell
- ORCID: -0003-0682-9613
- Affiliation: USGS

  - Phil Bentley
- Affiliation: UK Met Office Hadley Centre

  - Greg Rappa
- Affiliation: MIT

  - Heinke Höck
- ORCID: -0002-0131-1404
- Affiliation: DKRZ

  - Alison Pamment
- Affiliation: BADC

  - Martin Juckes
- Affiliation: BADC

  - Martin Raspaud
- Affiliation: SMHI

  - Randy Horne
- Affiliation: Excalibur Laboratories, Inc., Melbourne Beach Florida USA

- Contributor (May have several items. I suggest to clearly define the criteria 
to be considered a contributor.):
  - Contributor Type: [ Editor | Project Manager | Project Member | Related 
Person | Researcher | Supervisor | Other ]
  - Name:
  - ORCID:
  - Affiliation: 

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-432292340

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[HeinkeH]

My 
https://orcid.org/-0002-0131-1404
Best wishes
Heinke
-- 
Heinke Höck
World Data Center for Climate (WDCC)
Abteilung Datenmanagement

Deutsches Klimarechenzentrum GmbH (DKRZ)
Bundesstraße 45 a • D-20146 Hamburg • Germany

Email:ho...@dkrz.de
URL:  www.dkrz.de

Geschäftsführer: Prof. Dr. Thomas Ludwig
Sitz der Gesellschaft: Hamburg
Amtsgericht Hamburg HRB 39784 

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-415345146

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[Guilherme Castelão]

Great! We need to put some information together to move this forward:

- Are there funding agencies? Which ones?
- Who are the creators? [The list of authors in the main 
document](http://cfconventions.org/cf-conventions/cf-conventions.html#_about_the_authors)?
- There are other categories of contributors that are not creators/authors. Who 
are the contributors and which category? There are [more 
options](https://ezid.cdlib.org/static/locale/en/EZID_ContributorTypes.pdf) if 
the list below is not enough.
  - Editor
  - Data collector
  - Data curator
  - Project leader
  - Project manager
  - Project member
- For everyone that go in this DOI, it would be nice to have their ORCIDs, so 
this DOI is connected directly to each one.

The other fields should be straightforward, but I would print it all here for 
approval before submitting it.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-413746870

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[Rich Signell]

Sounds like a thumbs up, @castelao !

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-412851042

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[David Hassell]

Creating a single DOI pointing to https://cfconventions.org would be great, I 
think, and what was decided at the Reading meeting. We didn't decide to _not_ 
create further DOIs (e.g. for different conventions versions) simply because we 
couldn't decide in the limited time how best to proceed. These will come later 
...

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-412790253

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[Guilherme Castelão]

Sorry for the delay, I'm back.

Thanks for the correction @ethanrd. Yes, I also recall an agreement for a 
single DOI. Although I would recommend using a master DOI with one child DOI 
for each release, it is possible to use a single DOI for the CF concept. Thus 
it would not be associated to a specific version. In that case, I would 
recommend it to point to the general 
[https://cfconventions.org](https://cfconventions.org) website, not the 
repository.

My question is, how to move forward? If nobody says anything against this in 3 
weeks, shall I start implementing such single DOI? 

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-412379681

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[Ethan Davis]

As I recall, the decision at the Reading meeting was to mint a DOI for CF in 
general rather than for any particular version of any particular document. Is 
there a way using Zenodo with GitHub to mint a DOI that isn't associated with a 
particular document/artifact/release?

Or, perhaps the overarching DOI should be tied to the CF web page repo rather 
than the CF conventions document repo. (Seems an appropriate repo since we want 
the DOI to dereference to https://cfconventions.org.)

PS David and I have started on a meeting summary document. We'll share it out 
for comment and such once it isn't quite so rough.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-407912732

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[Guilherme Castelão]

UCSD library could provide that, but they suggested to use Zenodo since it can 
be integrated with GitHub, which I confirm that is nearly zero maintenance. My 
contact in the library also mentioned that they trust Zenodo due to the solid 
institutions that support it.

I canto do the repository setup to connect it with Zenodo automatically if 
there is a consensus to move this forward.



-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-407820951

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[Daniel Lee]

I was really impressed by Zenodo and think it would be a great idea - lots of 
benefits, low workload.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-406333880

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[Rich Signell]

@castelao , thanks for picking this issue up again!

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-405543642

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[Guilherme Castelão]

I believe that there was an agreement in Reading to create a DOI for the CF 
convention documentation. Is that correct? If so, shall we discuss the details 
on how to do it?

We have a few options on how to implement it. One of them is using Zenodo as 
suggested by @rsignell-usgs , which would also archive the document itself as 
mentioned by @davidhassell , and would allow a general DOI grouping all 
releases as suggested by @ethanrd . I use Zenodo in other projects and it is 
minimal work to operate in a GitHub environment.

I'm checking an alternative through UCSD library which offers similar resources 
and I just learned that they operate in a partnership with NCAR. I'll post here 
once I got some news.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-405477018

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[taylor13]

Could we discuss this at the meeting in Reading in June?

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-380216568

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[David Blodgett]

Was there a conclusion to this issue? Is someone going to move it forward?

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-379945238

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[Daniel Neumann]

I just realized that netCDF also has its own DOI as mentioned here:

https://www.unidata.ucar.edu/software/netcdf/docs/faq.html#How-should-I-cite-use-of-netCDF-software

It is written (if the URL does not work at some point in the future):

```
The registered Digital Object Identifier for all versions of netCDF software is 
http://doi.org/10.5065/D6H70CW6.

The following can be used as a citation:

Unidata, (year): Network Common Data Form (netCDF) version nc_version 
[software]. Boulder, CO: UCAR/Unidata. (http://doi.org/10.5065/D6H70CW6)

where year is the year in which the work being described was done and 
nc_version is the version of netCDF used. For example:

Unidata, (2015): Network Common Data Form (netCDF) version 4.3.3.1 [software]. 
Boulder, CO: UCAR/Unidata. (http://doi.org/10.5065/D6H70CW6) 
```

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-364413900

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[John Graybeal]

TLDR version: I will not object further nor complain if you go the DOI path 
(except occasionally with a wink and nudge to close colleagues).  Thanks for 
listening to my input!

I just have a few followups, to fully explain my perspective. 

I am not aware of DOI servers being used to archive content. In fact not sure 
how they would know what to archive, given they just point to another resource, 
which could have arbitrarily many links to its parts (if the document is 
maintained as a set of pages, for example). I'm interested to know more.

I accept the judgment of the library community that DOIs are perfect unique 
identifiers for bibliographic materials, that is their clear community choice. 
On the other hand, the expert librarians I talk to at Stanford are open to the 
possibility that DOIs are not the primary references for certain other kinds of 
digital content. The kind of content where I am most experienced is semantic 
content, where IRIs are the typical (but not universal) identifier of choice, 
because of the W3C semantic standards. So, in short, I think one identifier 
type does not fit all needs.

I accept that DOIs were designed to decouple content; they were poorly designed 
to resolve content, without knowing what to add to them to make them 
resolvable.  That said, you can generally find a DOI with Google, and yes, DOIs 
are easy(ier) to re-point by design.

I also concede that the DOI infrastructure is well-enough funded (and 
consistently-enough-used for this kind of thing) that the DOI infrastructure 
will not cause as many long-term headaches as most IRIs will. So I will not be 
trying to argue further, but I do want to note:
 - updating the DOI requires authority to update the DOI
 - over time, that authority must be passed on to others in an organized way, 
ideally through organizational accounts and permissions
 - if you have not properly prepared your organization for managing the DOIs, 
you will not be able to update the DOIs without at least some pain and 
suffering (the more rigorously DOI servers care about transitioning ownership, 
the more pain and suffering you'll face—since you don't want people stealing 
your DOI maintenance role from you)
 - you remain at the mercy of the company managing the DOI, and the services 
they provide.

These realities seem to map one-to-one with the realities of creating IRIs to 
decouple the content from the particulars of how and where it's served (I 
recommend Tim Berners-Lee's Cool URIs document, it's a short read and a fun bit 
of history).  Either way, to have a successful persistent identifier, you have 
to be thoughtful, you have to invest resources in managing the maintenance and 
succession processes, and you have to understand that this is an indirection 
service that is run by an organization, one which you may or may not have full 
control over for the (eternal!) life of the identifier. If you manage those 
issues, either technology is equally effective, with only minor differences in 
cost-per-identifier and user pain to resolve the identifier.



-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-359139705

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[David Hassell]

I am happy to make something happen!

The DOI server would, I think, keep a copy of the versioned document(s), 
thereby decoupling the need for a stable URL.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-359062048

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[Ryan May]

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. 

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-359045028

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[John 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.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-359045064

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[David Blodgett]

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 
> ,
>  or mute the thread 
> .
> 



-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-359043896

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[Ryan May]

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 commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-359042523

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[John 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.


-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-359039310

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[Rich Signell]

@davidhassell would you be willing to make this happen?

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-358998585

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[Daniel Neumann]

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

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-358969892

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[Ethan Davis]

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.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-358776697

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[Ethan Davis]

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

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-358772030

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[David Hassell]

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]()

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-358770725

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[Daniel Neumann]

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.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-358763844

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[Ethan Davis]

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.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-358760581

Re: [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)

[David Hassell]

An excellent idea, I think.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-358753375