Check out ZENODO.org for making tools citeable without removing from GitHub and without a peer-reviewed publication

[joewheaton]

So Samuel (@sdunesme) turned me on to this Zenodo.org. You can login with your GitHub credentials or an ORC-ID credentials, which is nice. Zenodo consists of a) uploads (primary feature), that mint DOIs for that (so it is citable) and has the nice feature that it can be easily citable and b) communities.

Upload Code

So as an example, @sdunesme uploaded his repository for the Fluvial Corridor Toolbox Q Plugin to Zenodo at https://zenodo.org/record/4317225#.YySLpXbP3MY, which minted him the following DOI: 10.5281/zeondo.4317225 and indexed it in OpenAIRE. It tracks, automatically views, downloads and citations! It also creates this lovely suggested citation:

ROUSSON Christophe, & DUNESME Samuel. (2020). Fluvial Corridor Toolbox QGis Plugin (1.0.6). Zenodo. https://doi.org/10.5281/zenodo.4317225

Uploads also seem to allow publications, posters, presentations (not sure if this is better than ResearchGate), datasets, images, video/audio, software, lessons, physical objects, and workflows. So pretty flexible. What is pretty cool is that it also allows "Access Right"to be open access, emargoed access, restricted access, and or closed access. When you upload, if you don't have a DOI already, you can "reserve DOI", which is handy.

I went through process with BRAT here: https://zenodo.org/record/7086388#.YySbtXbP1D8, which gave me:

Jordan Gilbert, Joe Wheaton, Wally Macfarlane, & Margaret Hallerud. (2019). pyBRAT - Beaver Restoration Assessment Tool (Python) (3.1.0). Zenodo. https://doi.org/10.5281/zenodo.7086388

Communities

So I made myself a Riverscapes Consortium community here. It looks like it allows having community collections, uploads, curation and automatic harvesting of METADATA through OAI-HM feed.

Discussion Please

@MattReimer, @jtgilbert and @philipbaileynar I think we should be doing this for all our production grade and professional grade tools when we release them and we should include them in the Report Cards. @MattReimer I'm thinking this might give us a niceway to not have to do our own tracking and indexing and minting at least for Tools and code. Hence making the tools partially FAIR #589. Thoughts? Actions?

[joewheaton]

@MattReimer for you: https://developers.zenodo.org/ happens to be an API for this.

[philipbaileynar]

I have no problem releasing DOI for our software.

I also have no problem issuing DOI for model runs providing that it is done judiciously.

We need to collectively develop a set of cirteria for when to issue a DOI for a project. If that turns out to be centered around a project being cited in a publication then this probably means assigning the DOI at a point in time well after the project has been created. (Separate CLI command for this specific task?)

The biggest impact in all of this is refactoring the warehouse API to restrict changes on projects that have DOI.

[MattReimer]

@philipbaileynar I've created a new discussion to talk about how DOIs for projects since that is a very different (but related) conversation:
https://github.com/Riverscapes/rs-web-monorepo/discussions/286

Minting a DOI for a tool is a really good fit because they are both versionable. Also we might be able to automated the releases and tags so that it gets archived by Zenodo.

For now I think we should experiment with DOIs for tools like riverscapes-tools, our python plugins, maybe even our businesslogic and XSD specs (just ideas, discussions to follow).

[joewheaton]

Thanks @MattReimer and @philipbaileynar. Yes, @MattReimer lets keep the DOI minting of projects separate from minting DOIs for versions of models. As you say @MattReimer, the code stuff is a really good fit. I also like your suggestions about seeing how this works for riverscapes-tools, python plugins, and potentially business logic and XSD. It does potentially solve a project metadata issue you and I have discussed about being very clear what version of models, business logic etc. are appropriate. I would say that we might not need to "mint" DOIs for things like business logic and XSD (they are not really going to be cited), but we may still want to use Zenodo for tracking. At some point, we should be careful not to duplicate functionality and utility already present in GitHub. But I like your idea of playing with it, seeing what we can do, and then making some decisions.

I would like to propose we update our Tool Documentation Standards to reflect:

• When is a good time to mint a DOI (e.g. for CyberCastor RiverscapesTools anytime we are doing deliverable runs from an official release, or anytime we decide to issue an official release)?
• More guidance on versioning
• Maybe we should not advocate minting a DOI until a Report Card has been completed for that release?

This requires further discussion, but is looking promising.

[MattReimer]

This is good guidance I think. I like the "only citable stuff" guideline.