Currently there are no DOIs for Stan case studies but I was asked about this and it seems like something we could do (e.g., via Zenodo). Does anyone have any thoughts about whether we should do this?
16 Likes
Without knowing too much about it, seems like that’s a great way to easily cite the case studies.
4 Likes
Yes please! I’d also love to give certain threads DOI’s but that’s harder.
1 Like
Judging from the “likes” and comments it seems that there’s support for this, which is great.
Before we go further down this path, does anyone oppose this for any reason? It’s going to take some effort to get all the existing case studies entered into Zenodo’s system in order to get DOIs (nothing difficult but it seems like it could take hours) so I think we should wait to get started on that until there’s been a chance for more people to comment on this if they want.
If we do end up doing this I will volunteer to register the case studies with Zenodo but I may ask for other volunteers to help out if anyone has time.
Never done this, but if it’s just a matter of spending some time I volunteer.
2 Likes
I’m happy to do some as well!
1 Like
I’d be glad to help too. I use zendo for most of our data DOI stuff. github and zendo have a nice way to talk to each other.
1 Like
I’m not opposed per se but if the Stan organization is providing DOIs for case studies then I think that there should be official, clear, and well-documented requirements for anyone to submit a case study and have it accepted so that they too can have a DOI.
4 Likes
If the case studies are on Github it’s super easy to clone a github to Zenodo - literally just a few clicks, complete a few fields as I recall. Here’s a Zenodo archive I made of Github for R code for one of our papers for example: jpkrooney/ALS_C9orf72_Resp_function_Paper: Original submission. Bascially the Git repo is stored as a zip file and you download it. It gives you a DOI which can be versioned. You can later change your git repo but that won’t be reflected on Zenodo unless you submit a new version to Zenodo. (Edit: this is just how I use Zenodo beause its super easy and fast - there are other ways to use it and maybe those are not so quick!)
Another option is OSF which allows you to have Project with subdirectories. OSF also gives dois but doens’t support doi versioning: https://osf.io
3 Likes
I don’t disagree but can you say more about what types of requirements you’re referring to? Right now the case studies page says this:
To contribute a case study, please contact us through the Stan Forums. We require
- a documented, reproducible example with narrative documentation (e.g., knitr or Jupyter with software/compiler versions noted and seeds fixed) and
- an open-source code license (preferably BSD or GPL for code, Creative Commons for text); authors retain all copyright.
So it’s already the case that anyone can already submit a case study and the basic requirements are listed. Are you referring to additional requirements about the quality of the case study?
2 Likes
We could definitely be a bit more explicit than “contact us through the Stan Forums”. Maybe we should create a tag for case studies (edit: we actually have one, so we should probably encourage using it). We can also add instructions for eventually adding a case study to the Stan website via a PR.
1 Like
Is the goal to have an artifact that is citable? If so, this makes sense and should be very little effort. It looks like all the case studies are already in GitHub, and, as pointed out by @jroon, making a Zenodo deposit of a GitHub repo is easy.
If the goal is to have an artifact that is trivially runnable, then a little more work is necessary.
2 Likes
Yeah, I was referring to having an explicit contact or instructions for submission and description of the approval process (who checks, what gets checked, how one can contest a decision if necessary), and the acceptance process (who to contact if case study isn’t added, what time frame to expect things to be added, etc).
In the past some of the case study have just been added without question and some have gone through unofficial review that comment on content/quality; it just hasn’t been consistent. I personally don’t think it’s feasible to set any requirements on the quality – unless people are aiming to start a journal of some sort – and am just hoping for as explicit a process as possible so that everyone in the community feels welcome to contibute.
4 Likes
Thanks for clarifying. That all makes sense to me.
Here is an example of what I mean by having an artifact that is trivially runnable:
https://renkulab.io/projects/cramakri/neighbor_interactions
It’s the repo from one of the case studies, but I added a Dockerfile that makes it possible to create an environment for running the code. Following the instructions there brings you to an RStudio environment where you can step through the Markdown file (at least up to line 271, where there is an attempt to load a file that isn’t available in the repo).
Should probably add for context that we already provide DOIs for StanCon contributions (discussed e.g., StanCon contributed talks now have DOIs).
I think DOIs would be useful (at least because most reference managers let you easily import items by DOI). Also agree that fleshing out the submission process in just a bit more detail makes sense. But I would rather it stays quite simple - we might at some point want to run a journal, but I don’t think this is the time :-D
2 Likes