The laboratory notebook

To be useful, research has to be reproducible and accessible. Fortunately, experiments on a computer are very reproducible and accessible by nature. The computer can easily do the same computation over and over again. The reproducibility and accessibility of a computational result can be preserved, if the research project is organized as a what SEP calls a reproducible research document Schwab et al. (1996). Reproducibility allows the frequent and automatic recomputation of all results by a script: the essential function in the maintenance of research results. A simple paper publication of research does not suffice.

How about a laboratory book (don't be fooled by the name: this is of course a software application) that organizes reproducible documents? Currently, a reproducible document consists of L^ATEX, programs, data files that are all linked by the rules in a makefile. The envisioned lab-book implements the same functionality in an object-oriented system.

The lab-book distinguishes the the contents level, the logic and functional structure, and the page layout description.

• the contents elements such as paragraphs, programs, figures, buttons, etc. These elements are references to sources such as files, URLs, applets (anything that can implement the yet unspecified documentComponent interface. The sources are loaded only when needed.
• the logical relationships between the various contents elements (information that is usually stored in a traditional makefile). If the button is pressed
• the page layout that describes how the various elements ought to be presented (if possible). Applications that can handle page layout (e.g. postscript printers) will honor these instructions, while others (e.g. an HTML browser) will ignore them.

Is that new? Knuth literate programming (Web) connects programs and documentation. The Openbook (I think by SUN) does something similar, I think. There must be other efforts of that type for Internet browsers.

The lab-book can be automatically translated into several representations and formats, such as a chapter in a book in postscript format, a stand-alone HTML document, a standard makefile in ASCII, or a set of slides in DVI format. Depending on the environment that renders the lab-book, the various parts adopt. Each part knows of its appropriate adoption.

The lab-book is not supposed to be a huge stand-alone program, but a simple organizational tool that combines many independent software units to a functional document. I expect the various document components to be objects with some base functionality (such as a rendering in various environments). Alternatively, the translation could be handled by the lab-book using plug-ins similar to a browser. Each object has methods that declares if the object is up-to-date, that up-dates the object (build rule), and that frees any resources used when rebuilding the object (clean rule). For example, the paragraphs could still be written in L^ATEX. To translate a document to HTML the L^ATEXdocument is informed about the new format. It then invokes its latex2html translation. If the script is not available, the L^ATEXfile detexs itself and returns an ASCII version.

Such a lab-book would of course be reproducible: any reproducibility command translates directly to the reproducibility command of its components. I discuss object-oriented reproducibility in greater detail in Schwab (1998).

I want to distribute my lab-book documents on the Internet. If the lab-book were written in Java, the lab-book itself could become the document that is transmitted in a net connection (rather than a derivative such as an HTML or postscript version). By the way, PDF fails to distinguish the logical level and the page layout level. Consequently, the document cannot be adopted to various environments. CD-ROMs may still be needed for reliable data storage.