Bioinformatics process management: information flow via a computational journal

Comparisons

Four aspects were used to analyze the environments discussed above: execution environment, workflow design, data management, and additional features. A comparison based on these aspects with other computations is discussed below. (See the appendix for introductions to the systems discussed in this section: PathPort, Pegasys, PISE, BioCoRE, MIGenAS, Taverna, and Wildfire.)

Abstract data interface

There has been a proliferation of specialized tools, interfaces, and ad hoc scripts to handle specific, repetitive tasks in narrow domains. The generality of these tools is sometimes limited by implicit data formatting, organization, and naming conventions. The presence of these low-level details can impede a system's usefulness. In the BCJ environment, the interface has been designed to shield the user from these details; every data element is simply an entry, regardless of its specific content type, providing a uniform, high-level abstraction to the user. Users are insulated from tedious low-level abstractions such as files systems and their computational hardware resources.

The BCJ environment maintains every entry created by every user. An entry can be a bioinformatics application, a workflow, an experiment, or a data set. The underlying framework collects and maintains a set of meta-data for each entry, including its name, author, creation and modification dates, and content type. Every application that plugs into the BCJ environment is an entry and is accessible through the standard entry interface. Many BCJ functions manipulate only meta-data fields of an entry, other BCJ functions are designed to manipulate only a specific content type, and are enabled only when an entry containing this content type is selected.

The BCJ environment provides a variety of navigators. These are functions that provide a hierarchical view of a collection of entries. Navigators establish a virtual organization of the entries. This allows the user to see the data organized to match a specific activity, by selecting the navigator most appropriate for the task. The most basic navigator, the Journal navigator, displays entries according to the journal in which entries are created. This navigator provides a view of entries, similar to a common file hierarchy with journals corresponding to file directories. Other navigators display entries related to a specific entry. For example, the dependency navigator displays entries that depend on the selected entry.

The BCJ can be extended through the addition of navigators. As new tools and techniques are incorporated into the environment, it is likely that some will implement novel data organization schemes requiring a new navigator.

Shared access to all entries must be balanced with the individual's need for security and privacy. The BCJ security model only allows the creator of an entry to modify it. This simple model is consistent with the larger computational journal paradigm. The journal is primarily a record of experimental steps. Once completed, a step may no longer be modified, however, it may be followed by additional experimental steps to refine results and investigate variations on the base experiment. This characteristic aids in maintaining the replication recipe provenance. If another user wants to make changes to data or an experiment created by another user, the user may create a new entry as a copy of the original one using the SaveAs operation, thereby maintaining data pedigree.

Read access to every entry is controlled by the group access attribute of the entry, where a group is a set of users. Only members of the associated group are able to view an entry and its contents. All manner of access to an entry is controlled by this attribute. Search results will only contain entries for which the initiator has group access. The BCJ environment provides administrative tools to manage groups.

The BCJ environment provides another form of access control. Every entry contains a committed attribute. Once set, the content of the entry may no longer be modified by any user, including the entry's creator. The committed attribute of an entry can never be reset. The committed attribute is fundamental both to encourage sharing among users and to ensure reproducibility of experimental results.

Single framework for diverse programs

A key feature of bioinformatics research is the breadth of programs that are being used by team members to address a shared goal. Frequently, specialized user interfaces are constructed around a set of closely related programs to facilitate their usage and to help perform repetitive tasks. However, integration of the process and results among these specialized interfaces is often difficult. The BCJ fundamental paradigm leverages the similar structures of computational experiments in biological experiments. These often are chained computations where the output of one is the input of another. However, the program's data formats and graphical interfaces can vary widely. Thus, within its common framework, the BCJ provides the flexibility for the problem – specific components. The BCJ environment provides common support for the experimental process, and flexibility and extensibility in the framework in these three key areas.

Designing a database schema broad enough to handle all forms of biological data can be a daunting undertaking. Specialized systems such as the Genomic Unified Schema (GUS) are designed for this [9]. For the BCJ role in performing and recording computational experiments, this generality is not a critical requirement. We have chosen a data model that simply stores the content of an entry as an uninterpreted stream of bytes. The BCJ domain does not attempt a structured biological database schema. Other systems exist for managing this problem with issues discussed elsewhere [9]. Instead, the BCJ uses a simple generic entry. Every entry is stored in the same table with a very simple schema. This schema consists of a fixed number of fields such as name, author, creation time, data type information, and a pointer to actual content which is stored as a vector of bytes. With this simple structure, support for a new data format simply requires the definition of a new content type.

No update or extension of a database schema is required. All BCJ environment functions that operate on the abstract entry interface, such as navigators and search tools, implicitly handle entries with content in the new format.

The content types are presented and manipulated through a plug-in framework that has become ubiquitous in Internet browsers. Although a BCJ environment may contain many plug-ins, the user sees a relatively simple, coherent interface (Figure 1). The functionality that a user interface plug-in provides fits into one of four categories where each member of a category adheres to a common interface: entry navigation, entry editing, auxiliary views, and experiment execution.

From the user perspective, the BCJ provides a mechanism to navigate among the potentially large number of entries. Each navigator provides a virtual organization of the entries, based on one or more relations among the entries. This allows the user to see the data organized to match a specific activity, by selecting the navigator most appropriate for the task. At creation time, each entry is assigned a parent journal. This provides an immediate and natural hierarchical view of all entries. This journal relationship provides a view of the entries that closely resembles the file directory hierarchy familiar to all computer users. This is the most basic of the BCJ navigators. Graphically, it uses a tree-list display that is widely used on computers to present such hierarchies, but with annotations that provide more detail than a basic hierarchical file system interface.

When an entry is selected, a plug-in associated with the entry's content type is selected to edit or view the content. Graphical editors are provided for workflow definitions and experiment definitions. When a new content type is defined in the BCJ environment, it is natural to incorporate a new editor plug-in tailored for the type. Many of the program inputs and outputs in the bioinformatics domain are textual. For these types, a generic text editor plug-in can be used. The editing area in the BCJ environment is subdivided into multiple panes so that the user can conveniently compare the content of two or more entries.

Some data formats, particularly binary data formats, are supported by sophisticated and optimized viewer programs. For example, three-dimensional graphical viewers are available for molecular dynamics simulation outputs. It is not practical to convert these programs to operate directly inside the framework. The BCJ environment provides an interface that allows a user to associate an external viewer, a program installed on his/her client machine, as the default viewer for a specified content type. Whenever an entry of one of these content types is selected for viewing, the BCJ environment automatically generates a local copy of the data on the client machine and invokes the associated program with this input.

In addition to editors and navigators, the BCJ environment provides a variety of additional views that present auxiliary information to support these primary tasks, such as the Queue Manager view, which displays the progress of currently executing experiments.

Graphical interface for experiment definition

Experiments are defined with simple block diagrams in a hierarchical fashion. Each block represents a program, or sequence of programs, to be executed. Input and output connections are made between blocks. In the BCJ environment, a block diagram is called a workflow. Figure 2 is an example of a simple workflow. Workflows provide a convenient and intuitive way for any user to define a customized task. Users are not required to be familiar with programming languages to define complex tasks. Once defined, a workflow may be reused. Workflows are just another entry content type, so they can be shared among all BCJ users. Experiments can be joined by connecting resources to form workflows. A data source can be used as an input to one BCJ resource with the output directed to another resource. The BCJ also provides a mechanism to annotate workflows. Figure 3 provides an example of a simple workflow definition.

Management of data provenance

When reviewing an experiment, the dependency navigator in the BCJ environment is particularly useful. The dependency navigator collects the set of entries upon which a selected entry is dependent, in a concise hierarchical view. The first level of the hierarchy contains the immediate dependencies of the selected entry. The second level of the hierarchy contains the dependencies for each of these entries, and so on. Figure 4 displays a sample dependency view.

Sequence-based investigation

To demonstrate sequence analysis in the BCJ environment, a simple example experiment was implemented that tries to identify a protein that may be a potential target for drug therapy in treating malaria. If there is sufficient divergence between some protein of the parasite and the host, then inhibition of the parasite protein is a potential target for drug therapy. In this experiment, we are interested in the divergence between the mosquito Plasmodium falciparum casein kinase and its vertebrate hosts. There are three applications used by the experiment: BLAST, CLUSTALW, and HMMER. The experiment involves the following computations: (1) identify similar proteins to the human casein kinase enzyme using BLAST, (2) create a global alignment using the sequences of the similar proteins that were extracted from the BLAST report using CLUSTALW, (3) construct a hidden Markov model (HMM) based on this multiple alignment, using components of the HMMER program suite, (4) run the model against the proteins in the Plasmodium falciparum genomic database (PlasmoDB) to identify proteins that may be functionally equivalent to human casein kinase.

In this experiment, we build two workflows. The first workflow contains the HMMER components. The second workflow, which will contain the complete experiment, will incorporate the HMMER workflow and the BLAST and CLUSTALW components.

The HMMER [9] program suite for biosequence analysis using profile HMM contains several components that are frequently used in a fixed order. In this workflow, we define a reusable component that may find value in other studies involving HMM. This workflow will construct an HMM based on the multiple alignment input, calibrate the model, and finally search a sequence database using this model.

To increase the flexibility of this computational component, the database is provided as a second input. As a design alternative, we could have chosen to specifically include PlasmoDB in this workflow (as a data source block) and have a single input to this workflow. A picture of the final workflow can be seen in Figure 3.

This workflow could be useful to a wide variety of researchers and does not contain any sensitive data or novel computation techniques, thus we set the group access control for this entry to ALL, so any user in the BCJ environment will have access to this workflow. To make the entry easier for others to find we could place the entry in a journal designated for shared workflows, and/or add an annotation briefly describing its functionality, so that other users can locate it with a search query.

In the complete workflow, we use the previously defined HMMER workflow as a resource. It also includes BLAST, to find proteins similar to the input protein, and CLUSTALW, to perform a multiple alignment of these similar proteins. The CLUSTALW program does not accept input in the format generated by the BLAST program, so the block, Extract Sequence, was inserted between them to perform the appropriate data conversion. Resource definitions include type information for each of their ports; the Workflow Editor does not permit connections between ports with incompatible types. These constraints help users construct only meaningful and valid workflows. Resources such as Extract Sequences serve the necessary role of automatic resolution of data reformatting. In addition, users can define new resource definitions that perform data format conversions to meet their specific requirements. The completed workflow is shown in Figure 2.

To define an experiment based on this workflow, the user provides a protein sequence input and a database to be searched with HMMER. For this example, Amino Acid Sequence was used, for the input is human casein kinase. The Search DB input is PlasmoDB. The output file, Related Proteins, will contain the sequences from PlasmoDB that are most similar to the profile HMM built from the human casein kinase related proteins. Figure 5 shows the completed experiment definition.

When defining the experiment, the user is queried to specify access control for the experiment definition. For example, the user may want to restrict any other access to the experiment and results, by setting the access control to NONE, pending validation of results. Later, the owner can modify access control to allow access by a wider range of users. At the completion of the experiment definition, a collection of jobs to perform the tasks defined by the workflow are submitted to the computational cluster for execution. The user tracks the progress of the experiment using the Queue Manager view.

The output entry generated by the experiment contains the top sequences from PlasmoDB that match the profile created by HMMER. From the results (Figure 6), we see that the top result has the gene ID of PF11_0377. This gene happens to encode P. falciparum's casein kinase 1. Based on these results, we see that this kinase would not be a good candidate for drug therapy.

The user can summarize what has been learned and annotate the experiment as shown in Figure 7. These annotations communicate reviews to other users and provide a log for the author. Annotations also enable search capabilities, since neither the experiment definition nor the output entry directly contain the lessons learned from the experiment.

Molecular dynamics experiment

Typically, molecular dynamics (MD) simulations involve a large number of simulations, where each varies from the previous only in the input data. The organization of the computations is often tailored to some specific application such as drug design or methodology development. Analysis of the simulation results will vary widely between simulation goal and investigators' styles. In addition, although the simulations are repetitive, there are numerous places during the study where interactions with the process and output are needed. Here, we demonstrate the use of the BCJ on such a representative MD simulation. For this experiment, we use the GROMACS package [13] and an example based on a tutorial [14].

There are five major steps in this experiment: (1) converting the protein structure from a common database format, PDB (Protein Data Bank), into a format suitable for GROMACS, (2) minimizing the energy of the system, (3) solvating the protein in a simulation box with water, (4) performing an MD simulation from the initial state, and (5) analyzing the simulation results. (Often, proteins are solvated then minimized, but for purposes of demonstration, the protein is minimized first.)

Each step can be run as an independent experiment with the outputs of each step appearing as entries in the user's journal. This stepwise procedure is useful for reviewing intermediate results. Alternatively, the steps can be incorporated into a single workflow, which is useful for a tested simulation procedure. The current example represents an intermediate approach in order to demonstrate aspects of the BCJ environment; two sub-workflows are combined into another workflow to perform the end-to-end experiment.

The workflow "Energy Min" shown in Figure 1 combines the first two steps of the procedure, since these two steps are standard initialization steps. This workflow has been designed with reuse in mind. The precise parameter settings for minimization may depend on the simulated molecule (one of the inputs); thus, a second input is defined for this workflow "MD params," which will translate the simulation parameters into GROMACS format. In addition, several output ports are defined for this workflow that are not specifically required in the example here. However, these additional outputs may be of use in another application that chooses to reuse this workflow.

The workflow "MD Sim" shown in Figure 8 combines steps three through five of the procedure outlined above. As with the previous workflow, care was taken so that the workflow could be reused. The "Solvent" input for the resource "genbox" is provided by the data source labeled "spc216.gro." An entry for this data in the BCJ environment was created by using the "Create New Entry" interface to import this information. It contains a GROMACS-specific description of "Simple Point Charge water" that is often used as the solvent in GROMACS experiments.

The workflow "Tutorial Example" shown in Figure 9 represents the complete process from the GROMACS tutorial. It makes use of the two supporting workflows described in the previous sections, demonstrating the hierarchical workflow definition integral to the BCJ environment. As described above, the supporting workflows were not designed only for this example tutorial. Each was designed generally, so that it could be used as a component in other molecular dynamics studies. Outputs not needed can be discarded by connecting each of them to a "Sink" block. The Workflow Editor requires these explicit connections since the ports to which they are connected were required. This consistency check by the Workflow Editor helps to ensure workflow correctness.

The workflow "Tutorial Example" defines only the process abstracted from the GROMACS tutorial. To begin a new project (or experiment), the user must import the original input data from an external source such as a public database. When data is imported to the BCJ, an entry is created and its content is initialized to that of a file provided by the user. The BCJ physically copies the data into the environment with subsequent references to the data in the BCJ through the entry. Thus, this experiment began by having the user import a number of files into the BCJ. Consequently, the workflow, Tutorial Example, allows one to perform this experiment for any protein from the PDB. Figure 10 displays the specific experiment definition corresponding to the example in the tutorial. The protein supplied as input is lysozyme, a serine protease. The MD parameters for the energy minimization are those supplied in the tutorial.

Numerous specialized programs have been developed for molecular visualization and interaction with molecular dynamics simulation. Rather than attempt to develop another molecular visualization subsystem directly in the BCJ environment (and then require BCJ users to become familiar with a new user interface), the BCJ environment invokes an existing tool, integrated as an external viewer, to display these results. For example, VMD, Visual Molecular Dynamics [15], can be used to display the output structure.