[GRASS-dev] [release planning] Enable Zenodo before 7.8.6 and 8.0.0

GRASS GRASS developer
1

Hi all,

Let’s enable the Zenodo link before 7.8.6 and 8.0(.0?) releases to get DOIs and Zenodo records.

Solving the whole DOI linking and Zenodo archiving for the old versions may be complex [1], but enabling the link between GitHub and Zenodo is trivial (one click) and every newly created GitHub release (we do those) will be automatically registered and receive DOI.

Zenodo uses a system of DOI versions and a main DOI (Concept DOI). Whether it is an ideal system, that’s a question, but it is currently the expected one since it is the same for everything on Zenodo. It is used automatically when using the GitHub-Zenodo integration.

It seems I have the permissions to enable it for GRASS GIS. The one who enables that becomes a maintainer of it. I’m fine with that, but I won’t be uploading any older versions. The maintainer can be changed later by contacting Zenodo support [2].

Although there are things to figure out in terms of next steps, I don’t see much risk in enabling it. There are no choices available in the setup or in terms of alternatives. DOI and some kind of registration are expected more and more.

Thoughts?

Vaclav

[1] https://grasswiki.osgeo.org/wiki/GitHub-Zenodo_linkage
[2] https://github.com/zenodo/zenodo/issues/826

2

Clear +1 from me.

Moritz

Le 24 mai 2021 03:08:06 GMT+01:00, Vaclav Petras wenzeslaus@gmail.com a écrit :

Hi all,

Let’s enable the Zenodo link before 7.8.6 and 8.0(.0?) releases to get DOIs and Zenodo records.

Solving the whole DOI linking and Zenodo archiving for the old versions may be complex [1], but enabling the link between GitHub and Zenodo is trivial (one click) and every newly created GitHub release (we do those) will be automatically registered and receive DOI.

Zenodo uses a system of DOI versions and a main DOI (Concept DOI). Whether it is an ideal system, that’s a question, but it is currently the expected one since it is the same for everything on Zenodo. It is used automatically when using the GitHub-Zenodo integration.

It seems I have the permissions to enable it for GRASS GIS. The one who enables that becomes a maintainer of it. I’m fine with that, but I won’t be uploading any older versions. The maintainer can be changed later by contacting Zenodo support [2].

Although there are things to figure out in terms of next steps, I don’t see much risk in enabling it. There are no choices available in the setup or in terms of alternatives. DOI and some kind of registration are expected more and more.

Thoughts?

Vaclav

[1] https://grasswiki.osgeo.org/wiki/GitHub-Zenodo_linkage
[2] https://github.com/zenodo/zenodo/issues/826

3

+1 from my side too

El lun., 24 may. 2021 03:23, Moritz Lennert <mlennert@club.worldonline.be> escribió:

Clear +1 from me.

Moritz

Le 24 mai 2021 03:08:06 GMT+01:00, Vaclav Petras <wenzeslaus@gmail.com> a écrit :

Hi all,

Let’s enable the Zenodo link before 7.8.6 and 8.0(.0?) releases to get DOIs and Zenodo records.

Solving the whole DOI linking and Zenodo archiving for the old versions may be complex [1], but enabling the link between GitHub and Zenodo is trivial (one click) and every newly created GitHub release (we do those) will be automatically registered and receive DOI.

Zenodo uses a system of DOI versions and a main DOI (Concept DOI). Whether it is an ideal system, that’s a question, but it is currently the expected one since it is the same for everything on Zenodo. It is used automatically when using the GitHub-Zenodo integration.

It seems I have the permissions to enable it for GRASS GIS. The one who enables that becomes a maintainer of it. I’m fine with that, but I won’t be uploading any older versions. The maintainer can be changed later by contacting Zenodo support [2].

Although there are things to figure out in terms of next steps, I don’t see much risk in enabling it. There are no choices available in the setup or in terms of alternatives. DOI and some kind of registration are expected more and more.

Thoughts?

Vaclav

[1] https://grasswiki.osgeo.org/wiki/GitHub-Zenodo_linkage
[2] https://github.com/zenodo/zenodo/issues/826

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

4

Sonds like a very good plan. Appreciate the effort.

There is already a GRASS GIS community on Zenodo, managed by Pietro.

There are way more GRASS related records in zenodo than registered in that community. Wound probably be useful to register relevant entries in a GRASS community…

Would it be an option to develop the community in that direction, Pietro? If others too think that’s useful …

Cheers
Stefan

···

From: grass-dev grass-dev-bounces@lists.osgeo.org on behalf of Veronica Andreo veroandreo@gmail.com
Sent: Monday, May 24, 2021 1:48:21 PM
To: Moritz Lennert mlennert@club.worldonline.be
Cc: grass-dev grass-dev@lists.osgeo.org; Peter Löwe peter.loewe@gmx.de
Subject: Re: [GRASS-dev] [release planning] Enable Zenodo before 7.8.6 and 8.0.0

+1 from my side too

El lun., 24 may. 2021 03:23, Moritz Lennert <mlennert@club.worldonline.be> escribió:

Clear +1 from me.

Moritz

Le 24 mai 2021 03:08:06 GMT+01:00, Vaclav Petras <wenzeslaus@gmail.com> a écrit :

Hi all,

Let’s enable the Zenodo link before 7.8.6 and 8.0(.0?) releases to get DOIs and Zenodo records.

Solving the whole DOI linking and Zenodo archiving for the old versions may be complex [1], but enabling the link between GitHub and Zenodo is trivial (one click) and every newly created GitHub release (we do those) will be automatically registered and receive DOI.

Zenodo uses a system of DOI versions and a main DOI (Concept DOI). Whether it is an ideal system, that’s a question, but it is currently the expected one since it is the same for everything on Zenodo. It is used automatically when using the GitHub-Zenodo integration.

It seems I have the permissions to enable it for GRASS GIS. The one who enables that becomes a maintainer of it. I’m fine with that, but I won’t be uploading any older versions. The maintainer can be changed later by contacting Zenodo support [2].

Although there are things to figure out in terms of next steps, I don’t see much risk in enabling it. There are no choices available in the setup or in terms of alternatives. DOI and some kind of registration are expected more and more.

Thoughts?

Vaclav

[1] https://grasswiki.osgeo.org/wiki/GitHub-Zenodo_linkage
[2] https://github.com/zenodo/zenodo/issues/826

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

5

Thanks everyone for the support.

I was able to identify some potential issues. Namely, the auto-generated metadata on Zenodo does not seem to be that great and that includes basic things like title and license. How an author list will look is hard to say without trying, but it is promised to be sensible. It seems that a lot of projects just solve this using a .zenodo.json configuration file which includes this info, e.g. a full author list.

Although these metadata issues are certainly visible, a DOI will be generated and usable by itself in any case. Additionally, metadata can be edited manually after the publishing/release. Finally, having .zenodo.json is doable (probably through CITATION.cff which would be good to have anyway). Thus, I don’t see this as a blocker, just as something to resolve on the way.

On Mon, May 24, 2021 at 1:27 PM Stefan Blumentrath <Stefan.Blumentrath@nina.no> wrote:

There is already a GRASS GIS community on Zenodo, managed by Pietro.

There are way more GRASS related records in zenodo than registered in that community. Wound probably be useful to register relevant entries in a GRASS community…

There seems to be exactly n-1 GRASS-related records not in the community (where n is all the GRASS-related records). Are we looking at the same one?

https://zenodo.org/communities/grass/

Would it be an option to develop the community in that direction, Pietro? If others too think that’s useful …

Cheers
Stefan

From: grass-dev <grass-dev-bounces@lists.osgeo.org> on behalf of Veronica Andreo <veroandreo@gmail.com>
Sent: Monday, May 24, 2021 1:48:21 PM
To: Moritz Lennert <mlennert@club.worldonline.be>
Cc: grass-dev <grass-dev@lists.osgeo.org>; Peter Löwe <peter.loewe@gmx.de>
Subject: Re: [GRASS-dev] [release planning] Enable Zenodo before 7.8.6 and 8.0.0

+1 from my side too

El lun., 24 may. 2021 03:23, Moritz Lennert <mlennert@club.worldonline.be> escribió:

Clear +1 from me.

Moritz

Le 24 mai 2021 03:08:06 GMT+01:00, Vaclav Petras <wenzeslaus@gmail.com> a écrit :

Hi all,

Let’s enable the Zenodo link before 7.8.6 and 8.0(.0?) releases to get DOIs and Zenodo records.

Solving the whole DOI linking and Zenodo archiving for the old versions may be complex [1], but enabling the link between GitHub and Zenodo is trivial (one click) and every newly created GitHub release (we do those) will be automatically registered and receive DOI.

Zenodo uses a system of DOI versions and a main DOI (Concept DOI). Whether it is an ideal system, that’s a question, but it is currently the expected one since it is the same for everything on Zenodo. It is used automatically when using the GitHub-Zenodo integration.

It seems I have the permissions to enable it for GRASS GIS. The one who enables that becomes a maintainer of it. I’m fine with that, but I won’t be uploading any older versions. The maintainer can be changed later by contacting Zenodo support [2].

Although there are things to figure out in terms of next steps, I don’t see much risk in enabling it. There are no choices available in the setup or in terms of alternatives. DOI and some kind of registration are expected more and more.

Thoughts?

Vaclav

[1] https://grasswiki.osgeo.org/wiki/GitHub-Zenodo_linkage
[2] https://github.com/zenodo/zenodo/issues/826

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

6

Hi Vaclav, all,

it’s great to hear that the GRASS project is about to embrace DOI and long term archiving by Zenodo.

The MOSS project minted its first DOI as a proof concept in the process of becoming a OSGeo heritage project (https://zenodo.org/record/4719685#.YKzpGKgzaUk). For this, we used stakeholders roles according to MARC21 like the R project does: https://journal.r-project.org/archive/2012-1/RJournal_2012-1_Hornik~et~al.pdf

BTW, ways to retro-provide DOI versioning for previous GRASS releases would be an rewarding topic to discuss with Data Cite (the DOI infrastructure community). DOI for software versioning is is still a developing topic. Feedback from the GRASS community would be valuable to push this forward.

Best,
Peter

peter.loewe@gmx.de

Gesendet: Montag, 24. Mai 2021 um 04:08 Uhr
Von: “Vaclav Petras” wenzeslaus@gmail.com
An: “grass-dev@lists.osgeo.org” grass-dev@lists.osgeo.org
Cc: “Peter Löwe” peter.loewe@gmx.de
Betreff: [release planning] Enable Zenodo before 7.8.6 and 8.0.0

Hi all,

Let’s enable the Zenodo link before 7.8.6 and 8.0(.0?) releases to get DOIs and Zenodo records.

Solving the whole DOI linking and Zenodo archiving for the old versions may be complex [1], but enabling the link between GitHub and Zenodo is trivial (one click) and every newly created GitHub release (we do those) will be automatically registered and receive DOI.

Zenodo uses a system of DOI versions and a main DOI (Concept DOI). Whether it is an ideal system, that’s a question, but it is currently the expected one since it is the same for everything on Zenodo. It is used automatically when using the GitHub-Zenodo integration.

It seems I have the permissions to enable it for GRASS GIS. The one who enables that becomes a maintainer of it. I’m fine with that, but I won’t be uploading any older versions. The maintainer can be changed later by contacting Zenodo support [2].

Although there are things to figure out in terms of next steps, I don’t see much risk in enabling it. There are no choices available in the setup or in terms of alternatives. DOI and some kind of registration are expected more and more.

Thoughts?

Vaclav

[1] https://grasswiki.osgeo.org/wiki/GitHub-Zenodo_linkage
[2] https://github.com/zenodo/zenodo/issues/826

7

Yes, this is the community I was talking about.

https://zenodo.org/communities/grass/

Even if it has just one entry, the title is still GRASS GIS.

Maybe we could add a second one for the dev group / PSC. However, avoiding confusion by just having one real GRASS GIS community on Zenodo would be better also for user experience…

Pietro, any thought about the future of that Zenodo community?

Cheers

Stefan

···

From: Vaclav Petras wenzeslaus@gmail.com
Sent: tirsdag 25. mai 2021 03:07
To: Stefan Blumentrath Stefan.Blumentrath@nina.no
Cc: Veronica Andreo veroandreo@gmail.com; Moritz Lennert mlennert@club.worldonline.be; grass-dev grass-dev@lists.osgeo.org; Peter Löwe peter.loewe@gmx.de; Zambelli Pietro peter.zamb@gmail.com
Subject: Re: [GRASS-dev] [release planning] Enable Zenodo before 7.8.6 and 8.0.0

Thanks everyone for the support.

I was able to identify some potential issues. Namely, the auto-generated metadata on Zenodo does not seem to be that great and that includes basic things like title and license. How an author list will look is hard to say without trying, but it is promised to be sensible. It seems that a lot of projects just solve this using a .zenodo.json configuration file which includes this info, e.g. a full author list.

Although these metadata issues are certainly visible, a DOI will be generated and usable by itself in any case. Additionally, metadata can be edited manually after the publishing/release. Finally, having .zenodo.json is doable (probably through CITATION.cff which would be good to have anyway). Thus, I don’t see this as a blocker, just as something to resolve on the way.

On Mon, May 24, 2021 at 1:27 PM Stefan Blumentrath <Stefan.Blumentrath@nina.no> wrote:

There is already a GRASS GIS community on Zenodo, managed by Pietro.

There are way more GRASS related records in zenodo than registered in that community. Wound probably be useful to register relevant entries in a GRASS community…

There seems to be exactly n-1 GRASS-related records not in the community (where n is all the GRASS-related records). Are we looking at the same one?

https://zenodo.org/communities/grass/

Would it be an option to develop the community in that direction, Pietro? If others too think that’s useful …

Cheers

Stefan

From: grass-dev <grass-dev-bounces@lists.osgeo.org> on behalf of Veronica Andreo <veroandreo@gmail.com>
Sent: Monday, May 24, 2021 1:48:21 PM
To: Moritz Lennert <mlennert@club.worldonline.be>
Cc: grass-dev <grass-dev@lists.osgeo.org>; Peter Löwe <peter.loewe@gmx.de>
Subject: Re: [GRASS-dev] [release planning] Enable Zenodo before 7.8.6 and 8.0.0

+1 from my side too

El lun., 24 may. 2021 03:23, Moritz Lennert <mlennert@club.worldonline.be> escribió:

Clear +1 from me.

Moritz

Le 24 mai 2021 03:08:06 GMT+01:00, Vaclav Petras <wenzeslaus@gmail.com> a écrit :

Hi all,

Let’s enable the Zenodo link before 7.8.6 and 8.0(.0?) releases to get DOIs and Zenodo records.

Solving the whole DOI linking and Zenodo archiving for the old versions may be complex [1], but enabling the link between GitHub and Zenodo is trivial (one click) and every newly created GitHub release (we do those) will be automatically registered and receive DOI.

Zenodo uses a system of DOI versions and a main DOI (Concept DOI). Whether it is an ideal system, that’s a question, but it is currently the expected one since it is the same for everything on Zenodo. It is used automatically when using the GitHub-Zenodo integration.

It seems I have the permissions to enable it for GRASS GIS. The one who enables that becomes a maintainer of it. I’m fine with that, but I won’t be uploading any older versions. The maintainer can be changed later by contacting Zenodo support [2].

Although there are things to figure out in terms of next steps, I don’t see much risk in enabling it. There are no choices available in the setup or in terms of alternatives. DOI and some kind of registration are expected more and more.

Thoughts?

Vaclav

[1] https://grasswiki.osgeo.org/wiki/GitHub-Zenodo_linkage

[2] https://github.com/zenodo/zenodo/issues/826

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

8

Peter,

On Tue, May 25, 2021 at 8:30 AM Peter Löwe <peter.loewe@gmx.de> wrote:

The MOSS project minted its first DOI as a proof concept in the process of becoming a OSGeo heritage project (https://zenodo.org/record/4719685#.YKzpGKgzaUk). For this, we used stakeholders roles according to MARC21 like the R project does: https://journal.r-project.org/archive/2012-1/RJournal_2012-1_Hornik~et~al.pdf

Are there any good alternatives or more recent documents for that?

BTW, ways to retro-provide DOI versioning for previous GRASS releases would be an rewarding topic to discuss with Data Cite (the DOI infrastructure community).

Any opinions on how useful this is? We want a good archive of old versions, but does someone need DOIs for old releases?

DOI for software versioning is is still a developing topic. Feedback from the GRASS community would be valuable to push this forward.

Right. Any suggestions on includings DOI into source code? It seems to me that you can only use the generic/concept one and tell people to get the recent one. I didn’t figure out the DOI reservation for GitHub repos.

Vaclav

9

Dear all,

Zenodo-GitHub link is enabled. There is nothing to see or customize on Zenodo.org until a release happens. It is important that every release is a GitHub release rather than just a tag, but other than that, it will work automatically.

I won’t be creating .zenodo.json right away, but will probably wait until 7.8.6 or 8.0.alpha happens to see how good or bad the metadata is. Then we will see what priority to assign to creating .zenodo.json.

Best,

Vaclav

On Mon, May 24, 2021 at 9:06 PM Vaclav Petras <wenzeslaus@gmail.com> wrote:

Thanks everyone for the support.

I was able to identify some potential issues. Namely, the auto-generated metadata on Zenodo does not seem to be that great and that includes basic things like title and license. How an author list will look is hard to say without trying, but it is promised to be sensible. It seems that a lot of projects just solve this using a .zenodo.json configuration file which includes this info, e.g. a full author list.

Although these metadata issues are certainly visible, a DOI will be generated and usable by itself in any case. Additionally, metadata can be edited manually after the publishing/release. Finally, having .zenodo.json is doable (probably through CITATION.cff which would be good to have anyway). Thus, I don’t see this as a blocker, just as something to resolve on the way.

On Mon, May 24, 2021 at 1:27 PM Stefan Blumentrath <Stefan.Blumentrath@nina.no> wrote:

There is already a GRASS GIS community on Zenodo, managed by Pietro.

There are way more GRASS related records in zenodo than registered in that community. Wound probably be useful to register relevant entries in a GRASS community…

There seems to be exactly n-1 GRASS-related records not in the community (where n is all the GRASS-related records). Are we looking at the same one?

https://zenodo.org/communities/grass/

Would it be an option to develop the community in that direction, Pietro? If others too think that’s useful …

Cheers
Stefan

From: grass-dev <grass-dev-bounces@lists.osgeo.org> on behalf of Veronica Andreo <veroandreo@gmail.com>
Sent: Monday, May 24, 2021 1:48:21 PM
To: Moritz Lennert <mlennert@club.worldonline.be>
Cc: grass-dev <grass-dev@lists.osgeo.org>; Peter Löwe <peter.loewe@gmx.de>
Subject: Re: [GRASS-dev] [release planning] Enable Zenodo before 7.8.6 and 8.0.0

+1 from my side too

El lun., 24 may. 2021 03:23, Moritz Lennert <mlennert@club.worldonline.be> escribió:

Clear +1 from me.

Moritz

Le 24 mai 2021 03:08:06 GMT+01:00, Vaclav Petras <wenzeslaus@gmail.com> a écrit :

Hi all,

Let’s enable the Zenodo link before 7.8.6 and 8.0(.0?) releases to get DOIs and Zenodo records.

Solving the whole DOI linking and Zenodo archiving for the old versions may be complex [1], but enabling the link between GitHub and Zenodo is trivial (one click) and every newly created GitHub release (we do those) will be automatically registered and receive DOI.

Zenodo uses a system of DOI versions and a main DOI (Concept DOI). Whether it is an ideal system, that’s a question, but it is currently the expected one since it is the same for everything on Zenodo. It is used automatically when using the GitHub-Zenodo integration.

It seems I have the permissions to enable it for GRASS GIS. The one who enables that becomes a maintainer of it. I’m fine with that, but I won’t be uploading any older versions. The maintainer can be changed later by contacting Zenodo support [2].

Although there are things to figure out in terms of next steps, I don’t see much risk in enabling it. There are no choices available in the setup or in terms of alternatives. DOI and some kind of registration are expected more and more.

Thoughts?

Vaclav

[1] https://grasswiki.osgeo.org/wiki/GitHub-Zenodo_linkage
[2] https://github.com/zenodo/zenodo/issues/826

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

10

Hi Vaclav, all,

answers are included below.

Best,
Peter

Gesendet: Montag, 31. Mai 2021 um 21:23 Uhr
Von: “Vaclav Petras” wenzeslaus@gmail.com
An: “grass-dev@lists.osgeo.org” grass-dev@lists.osgeo.org, “Peter Löwe” peter.loewe@gmx.de
Betreff: Re: [release planning] Enable Zenodo before 7.8.6 and 8.0.0

Peter,

On Tue, May 25, 2021 at 8:30 AM Peter Löwe <peter.loewe@gmx.de> wrote:

The MOSS project minted its first DOI as a proof concept in the process of becoming a OSGeo heritage project (https://zenodo.org/record/4719685#.YKzpGKgzaUk). For this, we used stakeholders roles according to MARC21 like the R project does: https://journal.r-project.org/archive/2012-1/RJournal_2012-1_Hornik~et~al.pdf

Are there any good alternatives or more recent documents for that?

==> the CodeMeta-Project is currenlty pushing software citation standards: https://codemeta.github.io/

BTW, ways to retro-provide DOI versioning for previous GRASS releases would be an rewarding topic to discuss with Data Cite (the DOI infrastructure community).

Any opinions on how useful this is? We want a good archive of old versions, but does someone need DOIs for old releases?

==> This depends on wether the community wants to give due credit by citation to the persons which were involved in the previous releases.

DOI for software versioning is is still a developing topic. Feedback from the GRASS community would be valuable to push this forward.

Right. Any suggestions on includings DOI into source code? It seems to me that you can only use the generic/concept one and tell people to get the recent one. I didn’t figure out the DOI reservation for GitHub repos.

==> A JSON file could be included. This way, the information is both readable for humans and automated access: https://codemeta.github.io/codemeta-generator/

Vaclav

11

Hi Peter, all, thanks for the answers. I have more questions assuming that’s okay.

On Fri, Jun 4, 2021 at 2:57 AM Peter Löwe <peter.loewe@gmx.de> wrote:

==> the CodeMeta-Project is currenlty pushing software citation standards: https://codemeta.github.io/

Thanks. The roles there seem to be more clear. Any opinion on CodeMata versus CFF (see also below)?

BTW, ways to retro-provide DOI versioning for previous GRASS releases would be an rewarding topic to discuss with Data Cite (the DOI infrastructure community).

Any opinions on how useful this is? We want a good archive of old versions, but does someone need DOIs for old releases?

==> This depends on wether the community wants to give due credit by citation to the persons which were involved in the previous releases.

Currently, the author list maintained in the source code is cumulative as far as I know, so old authors are still included as authors, so only use cases for that would be citing old releases in paper or by the new versions of software software. None seem likely to me. What do you think?

Any suggestions on includings DOI into source code? It seems to me that you can only use the generic/concept one and tell people to get the recent one. I didn’t figure out the DOI reservation for GitHub repos.

Rather than where to put it - although that’s important, too - my question is about which DOI? The main one everywhere or somehow try to put there the version specific one if that’s even possible. It seems to me that the main DOI is the only feasible option.

==> A JSON file could be included. This way, the information is both readable for humans and automated access: https://codemeta.github.io/codemeta-generator/

I was thinking about the Citation File Format as I have seen it used quite a bit. Any opinions on that?

12

Hi Vaclav, all,

I would advise to include both a CFF and a Codemeta linked data json file.

Reason: CFF is a front-end format, while codemeta-json is a back-end format. The linked data file can be automatically created from the initial CFF.

CFF is the right format for the initial provision of the software citation metadata. In a follow up-step its content should be included as a codemeta.json file as linked data into the machine-actioned downstream citation workflow. This allows to translate the metadata into multiple software metadata dialects (https://codemeta.github.io/crosswalk/).
The codemeta.json will also be recognized and used by the Zenodo hooks as part of the DOI-publication process.

The CFF should be created first (generator here: https://citation-file-format.github.io/cff-initializer-javascript/).
A codemeta.json file can be derived from the CCF by a converter: https://github.com/citation-file-format/cff-converter-python or https://pypi.org/project/cffconvert/

For the DOI, I believe there should be (at least) one central DOI for the “general concept” of GRASS GIS. There can be additional GRASS-GIS-releated DOIs (later) for specific releases/versions.

Best,
peter

peter.loewe@gmx.de

Gesendet: Sonntag, 06. Juni 2021 um 05:33 Uhr
Von: “Vaclav Petras” wenzeslaus@gmail.com
An: “Peter Löwe” peter.loewe@gmx.de
Cc: “grass-dev@lists.osgeo.org” grass-dev@lists.osgeo.org
Betreff: Re: Re: [release planning] Enable Zenodo before 7.8.6 and 8.0.0

Hi Peter, all, thanks for the answers. I have more questions assuming that’s okay.

On Fri, Jun 4, 2021 at 2:57 AM Peter Löwe <peter.loewe@gmx.de> wrote:

==> the CodeMeta-Project is currenlty pushing software citation standards: https://codemeta.github.io/

Thanks. The roles there seem to be more clear. Any opinion on CodeMata versus CFF (see also below)?

BTW, ways to retro-provide DOI versioning for previous GRASS releases would be an rewarding topic to discuss with Data Cite (the DOI infrastructure community).

Any opinions on how useful this is? We want a good archive of old versions, but does someone need DOIs for old releases?

==> This depends on wether the community wants to give due credit by citation to the persons which were involved in the previous releases.

Currently, the author list maintained in the source code is cumulative as far as I know, so old authors are still included as authors, so only use cases for that would be citing old releases in paper or by the new versions of software software. None seem likely to me. What do you think?

Any suggestions on includings DOI into source code? It seems to me that you can only use the generic/concept one and tell people to get the recent one. I didn’t figure out the DOI reservation for GitHub repos.

Rather than where to put it - although that’s important, too - my question is about which DOI? The main one everywhere or somehow try to put there the version specific one if that’s even possible. It seems to me that the main DOI is the only feasible option.

==> A JSON file could be included. This way, the information is both readable for humans and automated access: https://codemeta.github.io/codemeta-generator/

I was thinking about the Citation File Format as I have seen it used quite a bit. Any opinions on that?

13

Hi Vaclav, all,

maybe helpful:

The transient MOSS repo has been updated for CFF and codemeta.json:

https://github.com/ploewe/MOSS

The online CFF-generator didn’t accept some of the attributes. Doublechecking of the output is recommended.
Further, we hijacked the CFF affiliation tag to include MARC relator/ role terms (https://www.loc.gov/marc/relators/relaterm.html), like the R community has done:

https://r-pkgs.org/description.html

"… A three letter code specifying the role. There are four important roles:

  • cre: the creator or maintainer, the person you should bother if you have problems.

  • aut: authors, those who have made significant contributions to the package.

  • ctb: contributors, those who have made smaller contributions, like patches.

  • cph: copyright holder. This is used if the copyright is held by someone other than the author, typically a company (i.e. the author’s employer).

…"

I will talk to the software citation folks to see how this is perceived.

Best,
Peter

peter.loewe@gmx.de

Gesendet: Sonntag, 06. Juni 2021 um 05:33 Uhr
Von: “Vaclav Petras” wenzeslaus@gmail.com
An: “Peter Löwe” peter.loewe@gmx.de
Cc: “grass-dev@lists.osgeo.org” grass-dev@lists.osgeo.org
Betreff: Re: Re: [release planning] Enable Zenodo before 7.8.6 and 8.0.0

Hi Peter, all, thanks for the answers. I have more questions assuming that’s okay.

On Fri, Jun 4, 2021 at 2:57 AM Peter Löwe <peter.loewe@gmx.de> wrote:

==> the CodeMeta-Project is currenlty pushing software citation standards: https://codemeta.github.io/

Thanks. The roles there seem to be more clear. Any opinion on CodeMata versus CFF (see also below)?

BTW, ways to retro-provide DOI versioning for previous GRASS releases would be an rewarding topic to discuss with Data Cite (the DOI infrastructure community).

Any opinions on how useful this is? We want a good archive of old versions, but does someone need DOIs for old releases?

==> This depends on wether the community wants to give due credit by citation to the persons which were involved in the previous releases.

Currently, the author list maintained in the source code is cumulative as far as I know, so old authors are still included as authors, so only use cases for that would be citing old releases in paper or by the new versions of software software. None seem likely to me. What do you think?

Any suggestions on includings DOI into source code? It seems to me that you can only use the generic/concept one and tell people to get the recent one. I didn’t figure out the DOI reservation for GitHub repos.

Rather than where to put it - although that’s important, too - my question is about which DOI? The main one everywhere or somehow try to put there the version specific one if that’s even possible. It seems to me that the main DOI is the only feasible option.

==> A JSON file could be included. This way, the information is both readable for humans and automated access: https://codemeta.github.io/codemeta-generator/

I was thinking about the Citation File Format as I have seen it used quite a bit. Any opinions on that?

14

Hi Vaclav, GRASS devs,

the MOSS project has successfully adopted a new Zenodo-related feature, which might simplify also the open access publishing of GRASS 7.8.6 and 8.0.0 via Zenodo.

Best,
Peter

peter.loewe@gmx.de

Gesendet: Sonntag, 06. Juni 2021 um 05:33 Uhr
Von: “Vaclav Petras” wenzeslaus@gmail.com
An: “Peter Löwe” peter.loewe@gmx.de
Cc: “grass-dev@lists.osgeo.org” grass-dev@lists.osgeo.org
Betreff: Re: Re: [release planning] Enable Zenodo before 7.8.6 and 8.0.0

Hi Peter, all, thanks for the answers. I have more questions assuming that’s okay.

On Fri, Jun 4, 2021 at 2:57 AM Peter Löwe <peter.loewe@gmx.de> wrote:

==> the CodeMeta-Project is currenlty pushing software citation standards: https://codemeta.github.io/

Thanks. The roles there seem to be more clear. Any opinion on CodeMata versus CFF (see also below)?

BTW, ways to retro-provide DOI versioning for previous GRASS releases would be an rewarding topic to discuss with Data Cite (the DOI infrastructure community).

Any opinions on how useful this is? We want a good archive of old versions, but does someone need DOIs for old releases?

==> This depends on wether the community wants to give due credit by citation to the persons which were involved in the previous releases.

Currently, the author list maintained in the source code is cumulative as far as I know, so old authors are still included as authors, so only use cases for that would be citing old releases in paper or by the new versions of software software. None seem likely to me. What do you think?

Any suggestions on includings DOI into source code? It seems to me that you can only use the generic/concept one and tell people to get the recent one. I didn’t figure out the DOI reservation for GitHub repos.

Rather than where to put it - although that’s important, too - my question is about which DOI? The main one everywhere or somehow try to put there the version specific one if that’s even possible. It seems to me that the main DOI is the only feasible option.

==> A JSON file could be included. This way, the information is both readable for humans and automated access: https://codemeta.github.io/codemeta-generator/

I was thinking about the Citation File Format as I have seen it used quite a bit. Any opinions on that?