Data sharing in Surface Science
John R. Kitchin, “Data sharing in Surface Science”, Surface Science 647, 103-107 (2016). https://doi.org/10.1016/j.susc.2015.05.007
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
In 2010 the editors of Surface Science reminded authors of the journal’s policy that atomic positions determined in a paper, whether measured or computed, must be accessible to readers, and that letter was followed by Prospectives debating whether the CIF format or other formats should be the standard. This Prospective argues that the need has since grown well beyond atomic positions, noting that NSF, NIH and DOE now require data sharing plans, and asks how authors can share both data and methodology in a way that is readable by people and also addressable by machines (Kitchin 2016).
Approach
The paper is a short Prospective built around worked examples taken from the Supporting Information of a recent Surface Science paper by the group on core-level shifts in Cu-Pd alloys (boes2015). The Prospective was itself written in org-mode and exported to LaTeX, and the code listings it shows were executed within the document, with their printed output included. Note: the source used here is the accepted-manuscript PDF, whose extracted text is interleaved with watermark letters, but the prose and listings are readable.
Key findings
The Supporting Information PDF of the Cu-Pd paper carries two attached files, the org source and a JSON data file, which appear as thumbtack icons that some PDF readers can open; they can also be pulled out with the pdftk command-line tool. The JSON file was written with the Atomic Simulation Environment (ASE) database module. A few lines of Python list the database entries and their keywords (for example 72-atom fcc ground-state cells with Cu fractions from 0.88 down to 0.38), retrieve the geometry of one entry and write it out as a CIF file, and print the stored VASP INCAR settings (such as a 400 eV plane-wave cutoff and core-level calculation flags), the k-point grid (4 x 6 x 4), the PBE functional, the unit cell, the atomic positions and the total energy (about -614.29 eV for the entry shown). The point is that a computer can extract the file, read it, and regenerate input files to rerun the calculation or start new ones in another code.
The author openly notes that the listing differs from the code in the original Supporting Information, because the ASE database interface changed in the meantime and keyword searching no longer worked as before. The lesson drawn is that data formats evolve, but the data itself is not lost: it is still plain JSON and can be read without ASE. Other fit-for-purpose formats used by the group are cited, including custom JSON (mehta2014), CSV files loaded into sqlite (curnan2014) and embedded Excel spreadsheets (hallenbeck2013), and these are contrasted with the group’s older practice of printing parameter tables.
The second approach stores data inside the org-mode document. An org table (here the experimental Cu core-level shift versus composition for a composition spread alloy film) renders as an ordinary table in the exported PDF but can also be read directly by a code block, which the paper does to replot the data. The group reports having written nine publications this way over two years, and having embedded TPD, reactivity and segregation data in Supporting Information files. Because org code blocks are executable in Emacs and can be tangled into standalone code, the Supporting Information can serve as a code repository too; a Python library can be extracted from the Supporting Information of boes2015a. For data sets too large for Supporting Information, about 1.8 GB of DFT results for xu2015 were deposited on Zenodo from a GitHub repository; the author expresses less confidence in the longevity of such repositories than in data embedded in published manuscripts.
Significance
The Prospective brings the argument of kitchin2015 to the surface science community, framing it against that journal’s own atomic-position policy and the CIF debate. Its distinctive contributions are a concrete demonstration of turning shared DFT data back into a CIF file and calculator inputs, and the observation that a software API change broke the published code but not the data, which underlines the value of plain, documented formats. It concludes that access alone does not make data useful: context and examples of use are needed, and manuscripts written in org-mode supply them with little extra work because the data analysis is already part of the document.