XAS File Format

There has been some discussion recently on the IFEFFIT mailing list about the possibility of building a new database of refefence XAS spectra. This is a capital idea. The existing examples of reference spectra databases (here are links to three different efforts) are limited in scope, poorly organized, under-documented, not designed to be searched in a flexible manner, and difficult for interested outsiders to add new data to.

A new database can be designed to address all of those issues. Some good ideas for a new database that have been suggested include

• through-the-web uploading and annotaing of data, probably after 'logging on' (as with the FAQ).
• simple visualization, even if just plotting mu(E).
• link to crystallographic info. Say, an atoms.inp or a CIF.
• easy searching.
• either "user comments" added by others (aka Amazon-style reviews) or some way to indicate that the data is "good".
• add separate fields for compound name and elemental composition (should make searching easier for elements)
• add fields for source of model compound (i.e. purchased from vendor {vendor name, purity, etc} or if synthesized {give journal reference to synthesis procedure})
• add check box if phase purity has been checked by other analytical methods and add a text field where the user could describe what other techniques were used.
• add field for which edge was collected (k-edge, L1-edge, etc).
• under link to crystallographic info you could add a field for Journal Reference to crystal structure.

As the author of ATHENA and ARTEMIS, I am very interested in a light-weight API for a reference spectra database that can be used to import data directly from the database into my (or indeed into anyone's) analysis software without needing to use a web browser or to save the data in a user-selected, intermediate file.

A separate but intimately related issue is the concept of a standardize file format for the interchange of XAS data. As it stands today, every beamline cooks up its own data file format. Some of these are easy enough for the users of the beamline to deal with once they leave the synchrotron. Others are not so easy. There are many compelling reasons to attempt to settle on a standard for XAS data interchange, including

• Establishing a common language for transferring data between beamlines, data analysis packages, and members of the international XAS community.
• Increasing the relevance and longevity of experimental data by reducing the amount of ``data archaeology'' future interpretations of that data will require.
• Enhancing the user experience by promoting interoperability among data acquisition systems and data analysis packages.

Here is a rough draft of proposal for a data interchange format specification.

This is a rough draft hacked together by Bruce Ravel and Ken McIvor containing our initial ideas about what a standard data file should contain and what form it should take. We are eager for imput and suggestions.

One point that merits explicit mention is that the header structure suggested by this specification will make uploading data and meta-data to a web-based database extremely simple. Much of the meta-data one would want associated with data in a database is encoded into the file format at the time the file is written. The web application could then parse that data from the file, thus relieving much of the burden of data entry from the person contributing the data.

Another important point to emphasize is that the publication of a final specification must be concurrent with the publication of libraries written in a variety of common programming languages for reading and writing these files.