[IPython-dev] Concise citations for the Scipy stack

[Simon Cropper]

Hi Mark

My personal view when publishing work done with any software is...

1. Each bit of software used, its version and who released/sold it and
    if it is readily available on the Internet, a URL to the release
    should be cited. All foss software have specific attribution
    requirements so care should be made to ensure these are met.
2. In the methodology you need to outline the specific configuration
    or setup for any program that is able to vary the output of an
    algorithm based on different settings; and any work/papers that help
    justify these settings.
3. Where appropriate, as you are publishing in the academic arena,
    cite vanilla background papers -- like you suggested in your
    original post -- supporting the framework/library methodology.
4. Finally, to avoid problems with varying definitions of what actually
    constitutes the Scipy stack, outline only those software packages or
    libraries used. As pointed out by Aron the objective is to give
    enough information to the reader that your analysis can be
    reproduced.

The problem is however that journals don't like gray literature or web 
references, let alone software or data sinks references. This can be 
clearly seen by the lack of any advice on how to cite this type of 
information in author guidelines on most reputable peer-reviewed 
journals. My suggestion here is to err on the side of providing too much 
information rather than brevity -- especially in the description of the 
software (include name, version, etc) and when pointing to the 
publisher/distributor (include name of publisher and URL). That said, 
assume the URL is transitory and include enough data that someone could 
search the web for a particular foss or dataset using the text you 
provided).


On 03/02/15 06:11, Mark Voorhies wrote:
> I'm putting together a set of "software tools" references for a paper that we are preparing to submit.
> I am trying to balance acknowledging as much of our infrastructure as possible, while minimizing the
> number of references that have no direct (i.e., unambiguously obvious to the reader) connection to the
> methods section of the paper (e.g., citing Tornado, git, h5py, or MySQL is probably going too far; likewise,
> I think it's reasonable to cite R but not rpy2).
>
> Based on http://www.scipy.org/citing.html, I think a good minimal set (for a paper with heavy use of
> IPython for matplotlib-based plotting, including KDEs from scipy.stats, and a lot of vanilla python
> sequence/expression analysis code) is:
>
> NumPy & SciPy
> Stéfan van der Walt, S. Chris Colbert and Gaël Varoquaux. The NumPy Array: A Structure for Efficient Numerical Computation, Computing in Science & Engineering, 13, 22-30 (2011), DOI:10.1109/MCSE.2011.37
>
> Matplotlib
> John D. Hunter. Matplotlib: A 2D Graphics Environment, Computing in Science & Engineering, 9, 90-95 (2007), DOI:10.1109/MCSE.2007.55
>
> IPython
> Fernando Pérez and Brian E. Granger. IPython: A System for Interactive Scientific Computing, Computing in Science & Engineering, 9, 21-29 (2007), DOI:10.1109/MCSE.2007.53
>
> Thoughts?
>
> --Mark
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>

-- 
Cheers Simon

    Simon Cropper - Open Content Creator

    Free and Open Source Software Workflow Guides
    ------------------------------------------------------------
    Introduction               http://www.fossworkflowguides.com
    GIS Packages           http://www.fossworkflowguides.com/gis
    bash / Python    http://www.fossworkflowguides.com/scripting