What would be a real game changer for me is to have a domain (but not inference tool)-specific language for the kinds of semi-mechanistic generative epi models we use + a package to represent this in a convenient data structure in R. This is because I expect R to remain popular in epi research and public health for quite some time, while probabilistic programming is evolving fast and I don’t know how long people will still like stan.
If there was a ppl-agnostic structure to represent the different models in epinowcast, EpiNow2, EpiSewer, epidist, etc. (and I think that @samabbott and @sambrand have already laid the conceptual groundwork for this in EpiAware, although in Julia and maybe still a bit tightly coupled with Turing), and a package with helper functions to produce corresponding stanargs (including inits and priors, as mentioned above) that follow some clear convention, then we would as a first step “only” have to
- adjust our
stanmodels to receive arguments for the “data” block from this representation - adjust the interface functions of our
Rpackages to define the inputs forstanvia this ppl-agnostic representation (instead of directly specifying stan arguments as we now do most of the time)
This would not necessarily require a shared stan library as it leaves the ppl implementation of the models completely open (it remains the responsibility of the developer to implement the model correctly and to reject representations that your stan model cannot implement).
The immediate advantage of this would be cleaner interface functions in R with a lower entry barrier for new contributors - right now, I can at least say for epinowcast and EpiSewer that IMO you need quite an in-depth understanding of the respective stan model (including variable names!) to work on the interface functions… which is really bad.
The more long-term advantage of this would be that this could pave the way for transitioning to other ppls (or offering several backends) while still offering our tools in R. I guess that in Julia you could ideally take such a representation and directly construct the respective EpiAware model during runtime. And if someone wants to try build that with stan/brms, we won’t stop them 