Monera Model Editor


Ed Frank
Kaitlyn Hwang



The Monera Model Editor is meant to support the creation, modification, and versioning of systems biology models. In time, these models will span many biophysical processes; however, at the moment, the editor prototype focuses on biochemistry.

The editor fits into a processing model that distinguishes between reconstructions and models. [Replay baby-steps paper]. In brief, a reconstruction catalogs the actual biophysical elements of a biological system. A model, on the other hand, while based upon a reconstruction, has the objective of understanding and predicting the behavior of the biological system. It may choose to ignore portions of the system, may choose to replace portions with analogies that simplify the system or allow the model to focus its attention elsewhere, and may choose to insert purely hypothetical elements. If a reconstructions is "parts," then a model is "purpose." A model ultimately attempts to bridge the gap from a set of parts to a set of dynamical variables that can be computed upon to predict the behavior of the system.

Show diagram of high level workflow:

    genomes -> reconstructions -> models -> dynamical data
We're taling about the 2nd arrow.

The Monera Model Editor focuses on models, not reconstructions. Reconstruction typically requires extensive capabilities for compartive studies, e.g, compartive analysis of the genome of the subject organism with the genomes of others in order to assign fuction. This is not the purpose of the editor and, thus, it does not provide facilities for these operations. [But it's not so cut and dried...]

Instead, the Model editor focuses on information management: selection of reconstruction elements, hierarchical organization of a model, association of reconstruction elements within the hierarchy, versioning [future release], association of application specific data with a model.

Model Editor Thesis

The thesis behind the editor is that, to do this on a large scale, models can not be completely entered by hand. They must be constrained by accumulated information in biological databases. Thus the editor presumes a database with reconstructions and general biochemistry already exists. [ At this early stage, this is not a great's where we want to end don't be too religious about this yet]

The Editor thus works by building higher level constructs from lower level entities. At each step along the way, the editor enforces a constraint that the data exist in a backing database or datastore. The supported hierarchy right now is:

Organization of the Editor

The Editor is organized, visually, into a notebook of pages, each selected by a tab at the top. There are 4 notebook pages, labeled "Metabolite," "Reaction," "Navigator," and "Catalog." You edit by switching between these to build up your model. The pages are now described, lowest level to highest. First, we must introduce the concept of Data Source.

Data Source

The Model Editor works in terms of database independentend object model that represents the hierarchy just described. Any database or that can convert its data to this format can be supported. We refer to these as "Data Sources" or "Foundries." Two are supported right now: WIT and BSS. WIT is the WIT3 prototype database at ANL. BSS is the BioSimScratch prototype database used for prototyping this application. At present, BSS is much better supported.

In several pages you will have the option of choosing a data sorce via a drop-down selector. Thus the Model Editor allows the formation of models from data accumulated over numerous databases. By extending the architecture slightly, we will later allow the databases be remote, network services.

Metabolites Page

On the Metabolites Page you can search Data Sources for Metabolites. Metabolites have a Short name (used in printing reactions, graphs, etc.) and Long names (more detailed biochemical names). You can search by either, combining the search criteria by OR or AND. For each case, you can search for exact match (EQUALS), by substring (CONTAINS) or by LIKE. "LIKE" is a backdoor that lets you insert a valid, unquoted SQL clause to follow a LIKE operator. This presumes that the data source is SQL based, which may not always be true.

There is an ADD button that allows you to add a metabolite to the database. The OK button produces and immediate transaction and commit! Added metabolits automatically are added to the Search Results Table.

Search Results Table vs. Selected Results Table

When you do a metabolite search, the results land in a table at the upper right. Each search appends to this table, but there is a clear button you can hit to reset the table. You can left-click rows in the table, or Contrl-left-click to extend the selection, and then hit the SELECT button. This copies the sub-selection of the search results down to the Selected Results Table at the bottom of the page. This allows you to give broad searches for metabolites and then accumulate subsets into the Selected Results Table. The utility is explained next.

Reactions Page

The Reactions Page allows you to find Reactions in the database. The search is by input metabolites, output metabolites and by enzymes. [Enzymes not supported yet]. The drop down box allows you to choose three searches, INPUT, OUTPUT and FROM METABOLITE PAGE (Described just below). After choosing, you hit the SEARCH button.

Like the Metabolites page, the Reactions Page has both a Search Results Table and a Selected Reactions Table. They function just as on the Metabolites page.

The meanings of INPUT, OUTPUT and FROM METABOLITE PAGE are as follows:

Catalog Page

The Catalog Page shows a tree rooted with "Data Sources" under which there is branch for each data source. If you expand a data source, you will see all available reconstructions and models available from that data source.

You may select a reconstruction or model and then hit the "Load to Navigator" button at the bottom right. The mouse indicator will turn to an hour glass until the data are loaded.

The data are loaded to the Navigataor page, so you do not see a change on the catalog page. This may be confusing at first. Just hit the Navigator tab after hitting the tab.

Note: you may load as many reconstructions and models as you wish. Each show up in the Navigator page as indepentend trees. You can copy/paste between the loaded models and reconstructions.

Navigator Page

The Navigator page is split into two pieces, left and right. The left is the Tree Navigation Panel and the right is the Information Display Panel. The tree navigation panel shows all of the trees loaded from the Catalog Page. You can open/close the branches to explore the models and reconstructions.

You can select a node in any of the trees. Doing so causes the editor to determine if there are any associated reactions with that node. If so, the set of reactions is shown to the right in the Information Display Panel.

Within the Information Display panel, you can left-click a reaction to select it. A right click pops up a menu that allows you to cut the reaction, copy the reaction, or paste previously cut or copied reactions OR paste in all of the reactions from the Selected Reactions Table on the reactions page.

When a tree node is selected (highlighted), you can use the right mouse button to pop-up an edit menu. That menu allows you to cut, copy, and paste tree nodes between arbitrary, loaded trees [will change in the future so that some trees are read only]. You can also choose "New Root Node" to create a whole new tree for a new model." You can also choose "Add Sub Element" to add a new branch under the selected node. These operations allow you to build up the model hierarchy. Note that when you cut/paste branches, you are doing a deep copy of the branch, including all associated reactions.

You can also choose Paste Reactions from the popup to paste previously cut or copied reactions OR paste in all of the reactions from the Selected Reactions Table on the reactions page.

Writing Out the Editing Results

This is where you scream. At the moment, writing is not supported, except for writing Metabolites. We are adding this ability now. Underlying the feature is a clear statement of deep vs. shallow copy, the statement about the impact of a change in one tree if data are copied to another, a clear statement about search for reactions when they are otherwise redundant but have been deep copied between trees and statements about versioning.