Examples of Effective Data Sharing in Scientific Publishing

data-sharing
reproducibility
literate-programming
org-mode
ACS Catalysis (2015)
Published

2015

Doi

John R. Kitchin, “Examples of Effective Data Sharing in Scientific Publishing”, ACS Catalysis 5(6), 3894-3899 (2015). https://doi.org/10.1021/acscatal.5b00538

Read the paper

This summary was written by a language model from the paper and has not been checked line by line. Rely on the published paper for details.

Question

Funding agencies (NSF, DOE and NIH are named) increasingly require data management and sharing plans, but they do not say how the sharing should be done, and the tools used to write manuscripts typically produce only figures and tables that are neither machine readable nor easy to reuse. This Viewpoint asks how data, analysis and code can be shared inside the ordinary journal publishing environment, so that by the time a manuscript is finished its data is already integrated and ready to share with no additional effort (Kitchin 2015).

Approach

The paper is a perspective illustrated with worked examples drawn from the group’s own publications. The main worked example is the Supporting Information of boes2015a on H2 adsorption on CuxPd1-x alloy surfaces. The Viewpoint itself was written in org-mode, and the code listings shown in it are the code that was actually executed inside the document, with the output captured by Emacs (the full outputs are in its own Supporting Information). Note: the extracted text of the PDF interleaves the two columns and omits the code listings themselves, so this summary describes the listings only through the surrounding prose.

Key findings

The first approach is to attach data files to the Supporting Information PDF. File attachments are a standard part of the PDF specification; they can be added with PDF editing tools, with the LaTeX attachfile package, or in Word, and extracted by double-clicking the thumbtack icon in a reader or with the command-line tool pdftk. The boes2015a Supporting Information carries two attachments: a JSON data file and the org source that generated the PDF. The JSON file holds the geometries and computational parameters of every DFT calculation in that paper. Using Python, the author shows how to rebuild the VASP inputs for a single calculation (a clean Pd hydride slab): the INCAR parameters are read from a nested dictionary and written to a file, the POSCAR is generated from the stored symbols, positions and cell through ASE, and the k-point data indicate a 10 x 10 x 1 Monkhorst-Pack grid. POTCAR files cannot be shared under the VASP license, so only their identity is recorded; the paper notes that not all data can always be shared, but enough usually can for an expert to reproduce the work. Other papers used other formats: CSV files in curnan2014 and Excel files in hallenbeck2013. Some readers refuse to open executable or zip attachments, and very large data sets are better placed in a DOI-issuing repository, as was done for a roughly 1.8 GB DFT data set on Zenodo accompanying xu2015 (whose long-term archival quality the author flags as uncertain).

The second approach embeds data directly in the text of the org-mode source that is itself attached to the PDF. In org-mode a table is both human readable (rendered as an ordinary table in PDF or HTML) and machine addressable (usable as a data source for code blocks). A short Python function is shown that parses the org file, finds a named table and returns its contents, demonstrating that the data is not tied to Emacs. The example imports the experimental surface versus bulk composition table for CuxPd1-x at 900 K and replots it. Raw temperature-programmed desorption spectra were placed in the embedded org file of an earlier paper rather than in the PDF, where they would have filled hundreds of pages.

In the perspective section the author argues that attaching files is immediately available to nearly every author, but neither attachments nor copying code into LaTeX keeps the analysis synchronized with what was actually run, whereas org-mode integrates narrative, data, code and analysis in one document. MATLAB notebooks, IPython and Jupyter are acknowledged as similar tools. On standards, the paper argues that no single standard fits all experimental and computational needs and that authors should start sharing now in fit-for-purpose formats, letting valuable data be reused and best practices emerge. This distributed model, with data held by publishers and downloaders and curated by domain experts, is contrasted with centralized databases, which work well in uniform specialized fields (the Protein Data Bank and crystallography databases are cited) but require standard formats and server maintenance.

Significance

The Viewpoint is an early, concrete statement of the Kitchin group’s practice of writing papers in org-mode with machine-readable data embedded in the Supporting Information, applied across both experimental and computational catalysis work. Its central argument, that data sharing will only become routine when it is built into the authoring workflow rather than added afterward, anticipates the group’s later calls for better reporting of data and code for machine-learned models in kitchin2018.