Digital Object Identifier (DOI)

[carrascomj]

trafficstars

A Digital Object Identifier provides a persistent interoperable identifier to reference.

Having a DOI for bevy releases would make it easier to cite in academic publications and give correct attribution. Pandas (a ubiquitous python data wrangling library) does this using Zenodo, and refers to it in its documentation in the citing section.

[alice-i-cecile]

I'm in favor. Bevy is an excellent scientific simulation and modeling toolkit, and this really does make life easier for academics.

What's the best way to generate these ATM? We could add this to our CI.

[carrascomj]

I have looked into it and github has documentation about it. Summary: you can link a github repository in zenodo and they will take care of generating a DOI for each github release.

[mockersf]

The oauth app requires web hook admin permissions to add a web hook on release to zenodo

@cart would you be ok with that?

[cart]

I've never worked with DOIs before. What value does a DOI provide that a link to a release on github does not? Ex:

// Canonical link to the 0.9.0 release tag
https://github.com/bevyengine/bevy/releases/tag/v0.9.0

// DOI, which will internally link to our release on github
https://doi.org/10.5281/zenodo.3509134

The former is clearer + direct. The latter is an arbitrary id whose provenance and purpose is not directly clear.

[carrascomj]

TLDR: DOIs are better for academic citations.

Different fields of science are now converging to a particular care in reproducibility of software (see FAIR principles).

I agree the github release URL is more clear, since modern web rooting is designed to be intuitive. Now, a github release has two aspects that makes it worse for publications: persistency and interoperability.

The reason why it is less persistent is that at any point, github could change their rooting system. Another situation would be the removal of the release or the change of the name of the repository, for instance. The broken link would make more difficult to reproduce an article that cited the library. In contrast, DOIs are persistent and unique.

Interoperability is about integration with different tools. Githubs releases are fairly interoperable (and accessible), but a DOI has the advantage of being more general than only software (it could be a dataset, an article or any other document). A practical example of the improvement in interoperability is also citations: it is easier to cite DOIs since citation tools know how to access and process their information.

I hope I could explain myself :). If this is still not desired (I know the request is pretty niche), it would be nice to provide a "how to cite" piece of bibtex in the FAQ or something to give correct attribution.

[alice-i-cecile]

My background is in academic science: that explanation is good, and providing a DOI is standard for scientific software as of about a decade ago.

[cart]

Hmmm ping me again after the 0.10 release :)

I'm hesitant to add something like this to our infrastructure for what feels like pretty marginal gains. Do any of the other big engines do this? Couldn't find one for unreal, but I did find this: http://citebay.com/how-to-cite/unreal-engine/. Letting an arbitrary data host like Zenodo be the owner of our "canonical release ids" (forever ... given that these are intended to be canonical) that have no direct coupling to our versioning, urls, branding, etc seems odd. And being in the business of keeping that reference up to date in perpetuity also feels suboptimal to me.

I'd be more comfortable treating "Bevy Engine" + "v0.9.1" as the "canonical way to cite bevy". That feels way more natural and logical to me and doesn't rely on a random 3rd party service existing forever.

Obviously I'm brand new to this space and theres a very good chance I'm wrong here :)

[carrascomj]

Hi @cart!

How do we feel about this piece of bibtex?

@software{thebevyorganizationBevyReleaseV02023,
  title = {Bevy {{Release}} v0.10.1},
  author = {The Bevy Organization},
  year = {2023},
  month = march,
  journal = {GitHub},
  abstract = {A refreshingly simple data-driven game engine built in Rust - Release v0.10.0 {$\cdot$} bevyengine/bevy},
  howpublished = {https://github.com/bevyengine/bevy/releases/tag/v0.10.0},
  langid = {english},
}

Not super sure about "the Bevy organization" part.

[cart]

Not super sure about "the Bevy organization" part.

I would prefer "Bevy Contributors". "The Bevy Organization" is a subset of the people authoring Bevy.

thebevyorganizationBevyReleaseV02023

This seems like a mouthful. Can we just do bevyengine like unreal does with unrealengine here? http://citebay.com/how-to-cite/unreal-engine/. What is the purpose of this name?

year = {2023}, month = march,

Can we replace this with the single date field? Seems more concise and more accurate.

journal = {GitHub},

Is this common place? I wouldn't consider Github to be a journal personally.

abstract = {A refreshingly simple data-driven game engine built in Rust - Release v0.10.0 {$\cdot$} bevyengine/bevy},

Do we need anything after the -? Seems like we're already covering that other stuff elsewhere

title = {Bevy {{Release}} v0.10.1},

Hmm I rather like the unreal link' approach to this. title = "Bevy Engine", version = "0.10.1"

[carrascomj]

What you said makes sense, definitely. I generated most of it automatically using zotero, which is an open-source bibliography app, so some of it was off.

Regarding the thebevyorganizationBevyReleaseV02023, that's an ID for the consumer of the bib reference to cite it in a manuscript (some more sophisticated generation involves hashing it to avoid collisions). For the purpose of recommendations, simply writing bevyengine is perfectly valid.

Thanks for the input, that was very helpful!

[cart]

I created an FAQ entry with the results of this conversation, so I consider this closed: https://github.com/bevyengine/bevy/discussions/8098