I am performing an analysis of targeted proteomics for a study with rather sophisticated study design.  As a result of this and other issues (like novelty of the data itself) I found myself writing a lot of custom code  (such as visualization, normalization, etc.).  The code just begs to organize itself into a package.  However, there would be no use for this package except reproducing the data analysis for the corresponding manuscript and/or perhaps exploring the data further.  Nonetheless, I really want my data analysis to be reproducible by others and somehow refer to the real code in the manuscript instead of referring to method names (like - this was done by random forest approach [ref]).

So this tentative package doesn't fit the "software" category, because it is not generic enough and tied to a specific study.  It doesn't fit into "data" packages because it is not data only.  "Annotation" type is out for obvious reasons too.  I guess there is always an option to forget about packaging R code all together and provide a long-long script in the supplement.

What would you suggest?

Thanks,

Vlad

Dear Vlad

it is a great idea to keep and maintain your code and a reproducible transcript of the analyses for a paper as a package. For instance, Hiiragi2013 and HD2013SGI are recent cases where we did this for two of our papers, in case you want to see how we did it. The vignettes reproduce all major tables, figures and findings of the papers. Having that helps us a lot e.g. with addressing other scientists' questions on them.

Best wishes

Wolfgang

Definitely organize your code as a package, how ever you end up distributing it! It might be an experiment data package, or simply a package that you make available to others through non-Bioconductor means (e.g., github).

I would suggest checking out knitr if you haven't already. It makes it easy to combine text and figures with the code used to generate them.

You can even use it to write your entire manuscript in something like LaTeX or Markdown, and have the code used to the generate the figures embedded in the same document. This way, you can simply distribute a single document, along with any data requirements, etc. and someone could regenerate your entire manuscript, figures included.

Another possibility would be to have a separate knitr document which generates all the figures as a supplementary file, and write the main manuscript text separately using whatever approach you are comfortable with.

A quick search for "knitr reproducible research" should give you some pretty good ideas of where to start, e.g.

- https://github.com/umd-byob/presentations/tree/master/2013/0903-knitr_reproducible_research

- http://yihui.name/en/2012/06/enjoyable-reproducible-research/

Hi Vlad,

I would second Martin: definitely put your code in a package. Even if it doesn't become a Bioconductor package (maybe it doesn't need to). Note that if you want to get more advice from the BioC developpers, you should really ask on the Bioc-devel mailing list. This support site is for Bioconductor users.

Cheers,

H.

Thanks for suggesting an experiment type of package.  The ones I have looked at before contained no R code - just data. Examples of experimental packages with code Hiiragi2013 and HD2013SGI are right on target.  This is what I was looking for.

My guess is that the original intent of experimental packages was to serve as a supplement to software packages as opposed to become a data repository.  But perhaps once is while it is OK and helpful to come up an experimental package that is not directly supporting any of the software packages, but rather demonstrates a complicated analysis workflow.

Thank you all for suggestions!

Vlad