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
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
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.
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
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
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.
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
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
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
@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
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
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
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
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:
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.
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
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
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.
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
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.
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
21 matches
Mail list logo
