BACKGROUND
task analysis
there are two broad motivations for comparing the similarities and differences within a family of models.
in the first case, a research team is building a family of models up from a base model over time.
as members leave the project, new members join to replace them.
the continuity of the project is thus greatly facilitated by the ability of the new members to browse the history of the model and identify when and where modifications were made.
identifying the common core among the family of models is essential, since the elements that are not present in the core represent modifications to the model.
in the second case, a researcher intends to model a particular signaling pathway or set of pathways.
as part of this process, they would want to see what elements of that pathway have been previously modeled, and explore the relationships among existing models in the literature.
the researcher downloads several models from one of the several existing online databases  in a commonly-used model exchange format such as the systems biology markup language   <cit> .
the researcher would like to see at a glance which model components are shared and which are unique.
starting from these two motivating cases, and through close interaction with domain experts, we identified the following major tasks where visualizations can benefit model comparison in the area of cell signaling.
because of the similarities between model usage in this domain and in other domains, we assert that many of these tasks have global applications to model comparison beyond the cell signaling domain.
identify similar structures within models.
identifying similar structures is beneficial because if two different models share a common core, it is likely that those models can be combined to form a single, more-complete model.
additionally, searching for a single structure common to a significant subset of a family of models can help to identify models missing this structure.
this can help researchers make observations about the functionality of that subset of models.
identify structures that differ between pairs of models.
performing a pairwise comparison similar to task  <dig> with the goal of identifying structures that differ between the models helps researchers identify model components present in one model that do not appear in the other.
researchers can use this information to explore the functional effects of the structural differences between models.
when identifying both the similarities and differences between graphs, minimizing layout differences is essential to enable the user to see changes  <cit> .
sort/cluster models by similarity.
sorting models by degree of similarity helps to minimize visual differences between graphs in proximity to each other, facilitating comparison  <cit> .
as such, a method for computing the similarity of a pair of models should be developed or found from literature.
following this, the models should be laid out based on these scores in a clear and visually pleasing way.
support pairwise detailed comparison.
building upon the similarity and difference comparison of a pair of models, a researcher should also be able to examine the similar or differing structures of the models in more detail.
in particular, the researcher may wish to examine the individual rules within the model to determine the level of similarity.
explore the functional effects of differences between model structures.
the researcher may also wish to explore the functional effects of model changes.
in particular, the researcher should be able to perform a pairwise comparison of the simulation results or other species and reactions in the generated network of a model, in order to identify how the changes within a model affect the generated outputs.
organize and browse model repositories.
a researcher should be able to use this system to organize and browse a set of possibly unrelated models from a database or online repository.
the researcher should still be able to look at the similar and different structures across the collection of models under examination.
enable the ability to share model layouts withother researchers.
finally, if a researcher wishes to highlight important structural features that were custom-encoded into a model, that researcher must be able to also convey the structure of the model along with the model itself.
to keep the model interactive and to share all of the properties of the model, simply sharing a screenshot of a model is not sufficient.
therefore, although the model language may not specify any kind of set structural information, that structural information needs to be maintained.
this task analysis breakdown shows that a number of problems related to the comparison of models can be solved or aided with visualization.
specifically, tasks 1– <dig> can be performed with a clear visual representation of the model, and are specifically addressed in this work.
task  <dig>  on the other hand, is not specifically a visualization challenge, but can be facilitated by specific aspects of our visualization system.
related work
computing graph similarity
a number of methods have been proposed for computing the similarity of two graphs.
zeng et al.
<cit>  computes a similarity score for a pair of graphs by computing the edit distance between two graphs, counting the number of edit operations to nodes and edges required to transform graph g into graph h. bunke and shearer  <cit>  computes a similarity score by finding the maximal common subgraph, looking for the largest isomorphic subgraph present in graphs g and h. ullman  <cit>  presents an algorithm to find subgraph isomorphisms using a brute-force tree search, but pruning the tree to reduce the number of successor nodes that need to be examined.
our approach for determining a graph similarity score builds off of these ideas, looking both at maximal common subgraphs, while also considering the differences between graphs that can be computed through edit counts.
simulation journaling
a number of recent projects have included simulation journaling components to track simulations, steer computations, and perfect models.
the world lines system  simulates flood response and control, storing options for different simulations as a timeline tree.
similar to world lines are tracking graphs, as seen in widanagamaachchi et al.
<cit> , which show the evolution of features over time as a collection of feature tracks that may merge or split.
likewise, the porgy system  <cit>  enables simulation steering through direct manipulation of graph components, using a node-link representation to show transitions between graph states.
our system notes the links between models and simulations through their proximity to each other as computed by the custom similarity score noted above.
visualizing temporal network changes
misue et al.
<cit>  notes that the primary factor to consider when visualizing network changes over time is preserving the user’s mental map — minimizing unnecessary changes to the structure of the graph while emphasizing patterns within the graph.
four primary mechanisms have been used for visualizing changes in networks while preserving the mental map.
using an extra dimension to show network changes over time can add to clutter in the visualization, but can be effective when used appropriately, with either a full extra dimension  <cit>  or simply a “half-dimension”  <cit> .
small multiples are useful to show side-by-side comparisons of two or more networks, but with the disadvantage of losing some of the detail of the networks due to the reduced size, and are featured in ego networks  <cit>  and the semantic graph visualizer project  <cit> .
animations are useful in directly showing how a graph transforms over time, but have the occasional issues of being overly complex or too fast to be accurately perceived  <cit> .
such animations have been studied in projects such as dynavis  <cit> .
finally, interactions for comparing graph states over time come in various forms, including interactive tree layouts  <cit> , configurable layout algorithms in 3d graphs  <cit> , and time sliders  <cit> .
methods
the top design of our tool is informed by our formal task analysis .
since many of these tasks feature comparisons, we selected a small multiples top design; this design allows the comparative exploration of models.
we mitigated the issue of detail loss by providing a zoom function to the individual multiples, using animated transitions in the zoom action as suggested by shanmugasundaram and irani  <cit>  and using slow-in/slow-out pacing as recommended by dragicevic et al.
<cit> .
the front-end also allows the exploration of previous simulations and versions for a specific model.
the small multiples view provides a compact, scalable, visual encoding of models through an abstraction called an interactive contact map
<cit> .
the view further allows the comparison of similarities and differences between pairs of models represented as contact maps.
an interactive contact map is a compact, interactive graph representation of a complete model  <cit> ; this representation lies at the core of our scalable approach.
the molecules and binding sites in the biological model become nodes in an undirected graph, while the reaction rules are mapped to edges and component states.
the contact map provides a global, compact view of the model.
as discussed below, the interactive contact map can visually map models featuring hundreds of species and thousands of reactions into compact graphs featuring dozens of edges and nodes.
the small multiples view is enabled by three modules: a contact map manager, a comparison engine, and a layout stabilization and overlay module.
contact map manager
the contact map manager handles the parallel loading of a family of models from disk, generating contact map representations for these models and laying the contact maps out on screen.
it further supports interactions such as panning and zooming, highlighting similarities and differences between pairs of models, identifying common edges and nodes across an entire family of models, showing the states of a model, and opening the model in the default editor interface for closer inspection of parameters and simulation outputs.
each contact map is kept concise and scalable by limiting the number of nodes in the map: molecules and binding sites are uniquely identified by single nodes, regardless of how many times they appear in the model rules.
for example, the epidermal growth factor receptor  model in figure  <dig> contains  <dig> different reaction rules, which are compressed into a contact map with six edges and three modifiable components.
the rules of the model generate a system of  <dig> species and  <dig>  unidirectional reactions involving those species.
it is worth noting that the contact map is an abstraction of the generative-model for the system, not of the implied reaction network.
molecules are represented as large nodes that contain smaller, internal nodes that represent binding sites  and components containing states that are modified by the rules .
note that a modifiable component may also participate in bonds .
the reaction rules in the model are represented as the edges connecting the binding sites, and several rules may map to a single edge.figure  <dig>
egfr contact map.
an example contact map from the egfr family.
the model contains five distinct types of molecules , each comprised of one or more components , which can have one or more states .
each edge represents a possible binding interaction to a component , specified by one or more rules.
components shown in purple have states that are modified by the action of one or more rules.
the rule-based model represented by this contact map generates a reaction network with  <dig> species and  <dig>  reactions.
by default, the contact map is drawn using a force-directed layout algorithm which is intended to minimize edge crossings to preserve clarity.
a user can manipulate the location of the nodes to convey structural information about molecules and components with the layout of the graph  <cit>  .
the contact maps corresponding to the members of a model family are laid out in a small multiple display and rendered in grayscale in order to focus attention on the similarity and difference highlights generated by the comparison engine.
comparison engine
the comparison engine serves two major purposes.
first, it sorts the models by complexity in order to minimize differences between neighboring panels and thereby preserve the viewer’s mental map of the core model.
second, it calculates similarities and differences between the models, both pairwise and across the full family, which are then passed to the contact map manager for display.
sorting models
to compute the visual similarity of a graph , we create first an adjacency matrix representation.
in an adjacency matrix, each row and column is labeled with a node from the graph, and the matrix itself contains a  <dig> or  <dig> depending on whether or not an edge exists between the two nodes.
in our contact map implementation, a node can either be a molecule, a component, or a state.
we follow a bottom-up approach in the construction of the adjacency matrix.
starting from the finest granularity, a state is guaranteed to be a row/column in the adjacency matrix.
a component is included as a row/column if it has no states already included in the matrix.
a molecule is guaranteed to have at least one component, although that component could represent the entire molecule.
this numerical representation of the graph enables us to construct a visual similarity metric as described below.the first challenge in computing a similarity score for two models is defining what makes two graphs similar.
there are two descriptive examples for model pairs that are similar, shown in figure  <dig>  in the first, two graphs share a large number of nodes and edges, representing a majority of each graph.
these two graphs are certainly similar, as their only differences represent a small percentage of the overall structure.
in the second example, two graphs only share a small number of nodes and edges, but one graph is a subgraph of the second.
since the structure of the smaller graph is mostly  contained within the larger graph, we can argue that these graphs are also similar.figure  <dig>
model overlaps.
two graphs that share a large number of nodes and edges.
the only difference between these two graphs is the red highlighted node and edge.
two graphs that share a common structure.
the blue highlighted region has an identical structure, and so the second graph is a subgraph of the first.
to account for both of these similarity examples, we propose and construct four similarity matrices which reflect graph similarity.
a similarity matrix has the same basic structure as an adjacency matrix.
however, instead of nodes in the rows/columns, a similarity matrix contains an entire model.
instead of boolean edge existence values inside the matrix, a similarity matrix contains a real number representing how similar two graphs are by some measure.
the first two of our similarity matrices handle the first similarity example case.
one similarity matrix counts the number of nodes that the two graphs share, while another counts the number of edges that the two graphs share.
the other two similarity matrices handle the second similarity example case.
one similarity matrix counts the percentage of nodes that the two graphs share, while another counts the percentage of edges that the two graphs share.
in each of these cases, we calculate the percentage of nodes/edges in the smaller graph that are present in the larger graph.
hence, if graph g is a subgraph of graph h, then the similarity score by this measure is 100% for both nodes and edges, regardless of the number of nodes in graphs g and h.
we calculate an absolute similarity score by multiplying the number of nodes that the graphs share and the percentage of nodes that the graphs share, multiplying the number of edges that the graphs share and the percentage of edges that the graphs share, and finally adding these two values together.
thus, to compute the absolute similarity between two graphs, we use of the following similarity formula:
<dig>
to sort the models in our small multiples view, we precompute similarity scores for each pair of graphs.
we also compare each graph to the most complete graph, and sort the models row-wise into the small multiples view based on their similarity score in comparison with the most complete model.
in our implementation, we assume that the most complete graph is the graph with the greatest number of nodes and edges.
the assumption is based on our understanding of the iterative development of biological model families - researchers continue to add molecular structures and interaction rules to models to obtain an increasingly complete representation of the physical process.
as such, the number of nodes and edges will generally increase as the model is developed.
an example of this layout is shown in figure  <dig>  and is described more fully in “layout stabilization and overlay module”.figure  <dig>
egfr
models.
four sample multiples from the egfr family of models sorted by similarity score relative to the most complete model .
the most complete model generates a reaction network with  <dig> species and  <dig>  reactions.
model comparison
the second feature of the comparison engine is its ability to locate similarities and differences between models, which are then displayed using a bubbleset overlay  <cit> .
for computing similarities, we iterate over all nodes and edges in one model, creating an identifier for each.
we create a unique identifier for the structure we are searching for .
we then iterate across all models, searching for that structure .
if the structure exists in the other model, we add that structure to an internal list.
once the iteration is complete, the internal list of structures is passed to the contact map manager for display.
similarly, for computing differences, we must iterate over the nodes and edges of both models, looking for structures that exist in one model but not the other.
when such a structure is found, it is likewise added to an internal list.
in addition to pairwise comparison, our system also supports identifying a single node or edge across the entire model family.
this will allow a researcher to identify which members of a family of models contain a certain problematic rule, or a binding site that is no longer of functional relevance to the behavior of the model.
because each of these comparison processes require nested iteration over the node and edge sets of both models, the computational complexity of our comparison algorithm is o.
layout stabilization and overlay module
laying out the contact maps in a consistent manner across all of the small multiples facilitates the visual comparison of similar models, and in fact may be required for visual comparison in more complex models.
we implement layout stabilization by storing the nodes and their user-assigned positions for a particular graph, and then applying the stored layout across a family of models.
nodes not present in the stored layout are assigned positions using a force-directed algorithm.
by default, layout positions are taken from each individual model.
however, the user may override this choice by selecting a stored layout from a drop-down list.
when further analyzing a subset of models in a family, it is helpful to easily identify similarities and differences in the structures of each model.
the similarities and differences that we compute via the comparison engine are highlighted with a bubbleset overlay  <cit>  on the relevant small multiples.
when running a differences comparison, if one graph is a complete subgraph of the other, the result in the smaller graph will be an empty overlay bubbleset .
to show that this subgraph model is a member of the comparison, the backgrounds of models under pairwise comparison are highlighted.
an example of a similarity comparison bubbleset highlight with layout stabilization is shown in figure  <dig> figure  <dig>
similarity comparison.
the comparison engine in action, showing the similar nodes and edges  between two models from the egfr family.
the model  being compared to the most complete model  generates a reaction network with  <dig> species and  <dig>  reactions.
availability and requirements
the mosbie system is open source and cross platform, with 32- and 64-bit releases available for windows, linux, and mac os x. the system uses java, rich client platform , perl, and prefuse libraries.
mosbie is implemented as a perspective in the rulebender interface for rule-based modeling  <cit> ; the rulebender release includes the bionetgen software  <cit>  as well as nfsim, which is an additional simulator that allows for efficient simulation of large models  <cit> .
no installation is required: unzip the downloaded archive to a directory and the application will run directly.
the system can be downloaded at http://visualizlab.org/mosbie.
sample models are located in the samplemodels/bng directory of the decompressed directory.
all the example models and auxiliary layout files used in this paper can also be found in the additional file  <dig> provided with the manuscript.
RESULTS
in this section we report on the performance of mosbie.
we follow with two case studies from the application domain, and finally report feedback from domain experts.
performance analysis
we report the time required to calculate the similarity matrices, as well as the time to sort a collection of models, using an hp pavilion g <dig> machine with  <dig> gb ram and an i <dig>  <dig>  ghz dual-core processor.
our test set of  <dig> models from the fceri family represents biological systems with thousands of species and tens to hundreds of thousands of reactions.
for example, the fceri_fyn model generates a reaction network of  <dig>  species and  <dig>  reactions, and the fceri_fyn_trimer model generates  <dig>  species and  <dig>  reactions.
in their interactive contact map representations, the models in this family are captured as graphs with between  <dig> and  <dig> nodes and  <dig> to  <dig> edges.
the model set includes the nine models reported below in the first case study, plus eleven duplicates of these nine models to reach a total of twenty.
this duplicate set construction enables the performance evaluation of our approach on a larger set models of the same significant size as the original fceri family.
the duplicate approach is reasonable in this case: because it iterates through models in the same fashion regardless of their structure, the comparison algorithm computing time is not reduced when duplicate models are compared.
we found that computing the four similarity matrices on this set  required  <dig>  seconds and that sorting the models based on their similarity to the most complete model required  <dig>  seconds.
this computation time stands in contrast to the  <dig>  seconds required to load the collection of models from disk and build the contact maps.to evaluate the performance of our browsing system, we calculated the average computing time for model comparison.
we evaluated computing both similarities and differences across five model families, including the three families reported in the case studies and feedback section .
smaller model families ranging from  <dig> to  <dig> combined nodes and edges took less than  <dig> milliseconds for comparison runs.
the largest model family we attempted had a combined  <dig> nodes and edges; the mean comparison time was slightly over one second.figure  <dig>
comparison time.
the average calculation time of  <dig> similarity and difference comparisons on five different model families.
the error bars represent one standard deviation in comparison time.
the curve of best fit follows a quadratic equation, which follows from the o comparison algorithm .
using the same test set of models and identical machine configuration as in the previous experiment, we computed the amount of time required to  locate a node in the family of models,  locate an edge in the family of models,  compare the similarities between a pair of models, and  compare the differences between a pair of models.
in all cases, the comparison took less than a quarter of a second to complete, including the call to the comparison engine and the display refresh.
case study 1: comparison of a model family
in this case study, a computational biologist explores a family of rule-based models that describes signaling through the fc εri membrane receptor  <cit> , looking at various properties of the set of models.
the biologist begins by loading the family of models; a directory is selected through a standard dialog box and all models in that directory are loaded into the system.
reading the models from disk and generating the contact maps from the rules requires roughly one second per model.
as the models are loaded, the comparison engine computes the similarity matrices for the family, sorts the models, and lays them out appropriately into the small multiples panel.
this reflects task  <dig> from our task analysis.
next, the biologist enables layout stabilization across the model family .
with this new layout, the biologist notices that all of the models seem to have a common core structure, with a large rec molecule centrally located, and surrounded by syk, lyn, lig, and occasionally fyn molecules.
to confirm that this common structure does indeed exist, the biologist selects the “compare similarities” radio button, then begins to select pairs of models to compare.
through this selection process , the biologist confirms via a bubbleset overlay that this core structure does exist throughout the model family, with a few small differences.
one such comparison is shown in figure  <dig> figure  <dig>
fceri
similarity comparison.
a similarities comparison within the fceri model family, highlighting the similarities between the fceri_fyn and fceri_fyn_trimer models.
the fceri_fyn model  generates a reaction network with  <dig>  species and  <dig>  reactions, while the fceri_fyn_trimer model  generates a reaction network with  <dig>  species and  <dig>  reactions.
to investigate some of these differences more closely, the biologist switches the radio button selection to “compare differences,” which generates a different bubbleset overlay.
in one case, comparing the fceri_fyn and fceri_fyn_trimer models, the biologist notices that a single binding site in the lig molecule differs between the two models .
this “compare differences” action maps to task  <dig> from our task analysis.
noting this difference of a single binding site, the biologist now wishes to learn how this change in the model affects the concentrations of certain species in the model simulations.
even subtle changes to the model can result in significant changes in the network output.
by selecting the “open simulations” option from a context menu on either highlighted model, the most recent simulations for each model are identified and opened for the researcher to compare.
these simulations are shown in figure  <dig>  which addresses tasks  <dig> and  <dig>  it should be noted that to validate the significance of this comparison the user would need to check that the parameter values governing reaction rates and initial species concentrations were the same between the two models.
this can be done in several steps in mosbie by opening the corresponding model input files and comparing the parameter blocks.figure  <dig>
fceri
differences comparison.
a differences comparison between the fceri_fyn_trimer  and fceri_fyn  models, showing a binding site in fceri_fyn_trimer that does not exist in fceri_fyn.
simulation outputs.
the simulation outputs for fceri_fyn_trimer and fceri_fyn, showing similar curves for the concentrations of recpbeta, recpgamma, recsyk, and recsykps, but with fceri_fyn_trimer having concentrations 50% higher than fceri_fyn.
with the simulation outputs displayed, the researcher can note that, while the concentrations of the observables follow similar curves, the fceri_fyn_trimer outputs grow at a rate roughly 50% faster than those in the fceri_fyn model .
additionally, the concentration of recsykps is higher than the concentration of recpbeta throughout the full simulation of fceri_fyn_trimer, whereas the opposite occurs in fceri_fyn.
from this observation, the researcher notes that it is clear that the addition of a third ligand site significantly increases the rate of phosphorylation of the receptor  and of syk .
the effect on syk phosphorylation is amplified in comparison to the effect on receptor phosphorylation, which is seen by a change in the ordering of the curves in the top and bottom panels.
it is worth emphasizing that the comparisons shown in figures  <dig> and  <dig> involve large models.
the fceri_fyn model generates  <dig>  species and  <dig>  reactions and the fceri_fyn_trimer model generates  <dig>  species and  <dig>  reactions.
these models may take several hours to generate and simulate.
as noted by the domain experts, mosbie reveals structural differences between models based on existing simulation data, without the user having to regenerate the results.
thus, mosbie potentially saves hours of simulation time.
case study 2: comparison of models from a database
in this second case study a researcher is developing a model of the egfr signaling network.
the researcher wants to see what molecules and interactions have been included in previous models, with an eye toward integrating these into the new model.
the researcher finds two models of egfr signaling in the biomodels database  <cit> , with model ids biomd <dig>  and biomd <dig> , and downloads them as reaction networks in sbml format.
both models are fairly large — model  <dig> has  <dig> species and  <dig> reactions and model  <dig> has  <dig> species and  <dig> reactions — and the only visual representations of the models provided in the respective papers  <cit>  use different nomenclature and layout, making them difficult to compare visually.
these models are not rule-based and the molecular compositions of the species in each model are not explicitly provided.
however, the models can be converted into a rule-based format and the species’ molecular compositions recovered using a recent web-based tool called the atomizer  <cit> .
following successful translation to bionetgen language  format, both models are loaded into mosbie and their contact maps displayed.
because the two models use slightly different names to refer to some of the molecules they share in common, these mappings had to be identified and modified manually in the model editor.
manual layout of the contact maps reveals the implicit molecular components and interactions of the original model .
the initial layout of the contact maps for the two models is somewhat different.
to facilitate comparison, layout stabilization is applied using the layout for the larger model, followed by correction of the position of the plcg molecule in model  <dig> and its corresponding binding site in egfr to line up with other molecules and components in the contact map.
selecting the “compare similarities” radio button, followed by zooming and recentering, results in the view shown in the bottom row of figure  <dig> figure  <dig>
comparison of two models of egfr signaling from the biomodels database  <cit> .
left column: biomd <dig>   <cit> ; right column: biomd <dig>   <cit> .
contact maps with custom layout  and similarity comparison with layout stabilization  for the two models are shown.
the region highlighted in green shows that the two models share a core set of molecules, components, and interactions.
model  <dig> is comprised of  <dig> species and  <dig> reactions, whereas model  <dig> is comprised of  <dig> species and  <dig> reactions.
note that both models are encoded in sbml and are not rule-based models.
contact map representations were generated by extracting the implicit molecular structures of these models using the atomizer  <cit> .
the similarity comparison immediately highlights a core set of elements common to both models.
in fact, model  <dig> contains all molecules and interactions present in model  <dig>  except for the plcg molecule.
the comparison in figure  <dig> also shows that, in addition to containing a number of additional molecules and interactions, model  <dig> also considers synthesis and degradation of egf and egfr, which are represented by the unstructured nodes connecting to those molecules.
the similarity in the core structures of the models was not noted in the paper describing model  <dig>  <cit> , even though this model was published after the paper presenting model  <dig>  <cit> .
without mosbie, it is difficult to identify similarities and differences between models published in the literature because they are usually presented in the form of long lists of equations that use different nomenclature.
although the nomenclature problem must still be addressed manually, in our opinion this case study demonstrates the power of mosbie to enable model comparisons that would be prohibitive without monumental effort.
domain expert feedback
in addition to the two case studies reported above, three computational biologist domain experts  requested the mosbie system for the purpose of exploring model sets.
the experts were most interested in using the system for locating core structures that are common across model families, including the tlr <dig> family shown in figure  <dig>  these core structures can be ideal sites for merging similar models into a larger structure.figure  <dig>
the tlr <dig> family of models.
a similarity comparison between models tlr4_v <dig> and tlr4_rps_v <dig> in the tlr <dig> family.
tlr4_v <dig> generates a reaction network with  <dig> species and  <dig>  reactions, while tlr4_rps_v <dig> generates a reaction network with  <dig> species and  <dig>  reactions.
as noted in “performance analysis”, comparison times for a pair of models of the size of those in the tlr <dig> family  approach one second, which is still roughly equivalent to the time required to load each model from disk and generate the contact map.
figure  <dig> shows a similarity comparison between two models in this family.
we found that the researchers were still pleased with this comparison computation time, as it is still significantly faster than a manual comparison.
the domain experts expressed satisfaction with the layout stabilization module.
they noted that, in addition to making it easier to visually compare models in the explorer view, they could also package the layout information with the model files when sharing models with other researchers.
this allows the experts to highlight certain structures in discussions without either providing a screenshot or worrying about differences in the layout computed on each machine.
it also enabled the experts to store their own custom layouts for models across multiple sessions.
discussions with our domain experts led us to develop additional features that were not explicitly presented in the case studies.
for example, the experts felt that the ability to highlight the location of a single node or edge across the entire model family  would be useful for identifying which models in a family are missing a key structure.
these discussions were also useful for refining some features of the system overall, such as using a grayscale color scheme for the small multiples so that the similarity and difference bubblesets stand out even more.
finally, our domain experts also praised the ability to browse the results of past simulations, as some model structures result in very large networks that take significant resources to run.
in this case, researchers would not want to rerun simulations.
specific to our first case study, the fceri_fyn_trimer model requires close to an hour to perform the network generation stage of the simulation.
discussion and
CONCLUSIONS
in the absence of a contact map, obtaining a global understanding of the contents of even a single rule-based model from a set of rules in text form is difficult.
this difficulty is compounded when doing model comparison.
while a binary comparison of two models based on ≲  <dig> rules could be done by hand — by someone well versed in reading rules — mosbie offers the power to compare many models at once, as shown in the first case study.
this first case study, where we compare nine different models with relatively subtle structural differences, illustrates this scaling issue.
as shown in both case studies, mosbie allows detection of patterns that might otherwise be difficult to see.
the results of our case studies indicate that mosbie effectively meets the tasks we have identified for browsing sets of models  without requiring specialized training on the system.
our domain experts were able to begin to explore the families of models immediately, noticing similarities and differences in model structures and identifying relationships between the model results that were being compared.
task  <dig>  organizing and browsing online repositories, is not discussed in the case studies because there is currently no such online repository for rule-based models.
however, introducing an online database of models is an interesting research direction that we are currently pursuing  <cit> .
when such a repository is developed, our system will be useful for comparing models that overlap in their composition, provided that a consistent annotation scheme is used to allow for accurate determination of common model components.
the visual comparison features that we have implemented could facilitate model merging in situations where models are developed by multiple research groups .
a prerequisite step for comparison of models developed by different groups is the modification of identifiers — molecule names, component names, and component states — such that shared elements have the same identifiers in all of the models being compared or merged.
differences in protein nomenclature are, however, common in the literature  <cit> .
annotations such as uniprot id numbers  could also be employed to facilitate identification of common identifiers.
a tool that allows synonyms in the protein nomenclature is an interesting direction of future work.
in addition, to fully accomplish cross-group model merging additional interface features would be required, such as visual molecule and rule merging.
a limitation of mosbie is that the browser-view model comparison is currently based only on contact maps.
it is possible for models with similar but distinct rule sets to yield identical contact map representations in this browser view.
detecting such differences would require performing comparisons on more fine-grained representations of model structure, using for example the interactive approach described in  <cit> .
however, performing comparisons on more fine-grained representations of model structure in mosbie is beyond the scope of the current work.
in conclusion, we have introduced a novel, powerful tool for analyzing structures and dynamics within biochemical model families.
our open-source system uses a compact, scalable visual abstraction called an interactive contact map and a similarity metric over this abstraction to enable the clustering of similar models.
an intuitive interface further allows researchers to seamlessly compare pairs of models directly, to identify similarities and differences in the structure of models, and to directly compare model simulation outputs.
this approach effectively streamlines the analysis of models, both existing and newly created.
domain expert feedback and two case studies highlight the benefits of using this exploratory system in the context of systems biology.
electronic supplementary material
additional file 1:
the bngl models and position files necessary to generate the figures presented in this work.
abbreviations
rbmrule-based modeling
mosbiemodel simulation browser and interactive explorer
egfrepidermal growth factor receptor
sbmlsystems biology markup language
rcprich client platform
y317tyrosine 317
shcsrc homology  <dig> domain-containing-transforming protein c1
fc εrihigh affinity immunoglobulin epsilon receptor
recreceptor
sykspleen tyrosine kinase
lyntyrosine-protein kinase lyn
ligligand
fyntyrosine-protein kinase fyn
recsykpssyk-phosphorylated syk-receptor complex
recpbetabeta-subunit phosphorylated receptor
recpgammagamma-subunit phosphorylated receptor
plcgphospholipase c gamma
tlr4toll-like receptor  <dig>
competing interests
the authors declare that they have no competing interests.
authors’ contributions
jw wrote the implementation of the explorer interface, with links back to the original rulebender software.
jrf and lah provided expert systems biology feedback and helped to direct the design of the tool and case studies.
jjt contributed to the design and implementation of the second case study.
gem conceived and directed the design, implementation, and testing of the tool.
all authors listed contributed to and approved the final manuscript.

 task analysis there are two broad motivations for comparing the similarities and differences within a family of models. in the first case, a research team is building a family of models up from a base model over time. as members leave the project, new members join to replace them. the continuity of the project is thus greatly facilitated by the ability of the new members to browse the history of the model and identify when and where modifications were made. identifying the common core among the family of models is essential, since the elements that are not present in the core represent modifications to the model. in the second case, a researcher intends to model a particular signaling pathway or set of pathways. as part of this process, they would want to see what elements of that pathway have been previously modeled, and explore the relationships among existing models in the literature. the researcher downloads several models from one of the several existing online databases in a commonly-used model exchange format such as the systems biology markup language. the researcher would like to see at a glance which model components are shared and which are unique. starting from these two motivating cases, and through close interaction with domain experts, we identified the following major tasks where visualizations can benefit model comparison in the area of cell signaling. because of the similarities between model usage in this domain and in other domains, we assert that many of these tasks have global applications to model comparison beyond the cell signaling domain. identify similar structures within models. identifying similar structures is beneficial because if two different models share a common core, it is likely that those models can be combined to form a single, more-complete model. additionally, searching for a single structure common to a significant subset of a family of models can help to identify models missing this structure. this can help researchers make observations about the functionality of that subset of models. identify structures that differ between pairs of models. performing a pairwise comparison similar to task with the goal of identifying structures that differ between the models helps researchers identify model components present in one model that do not appear in the other. researchers can use this information to explore the functional effects of the structural differences between models. when identifying both the similarities and differences between graphs, minimizing layout differences is essential to enable the user to see changes. sort/cluster models by similarity. sorting models by degree of similarity helps to minimize visual differences between graphs in proximity to each other, facilitating comparison. as such, a method for computing the similarity of a pair of models should be developed or found from literature. following this, the models should be laid out based on these scores in a clear and visually pleasing way. support pairwise detailed comparison. building upon the similarity and difference comparison of a pair of models, a researcher should also be able to examine the similar or differing structures of the models in more detail. in particular, the researcher may wish to examine the individual rules within the model to determine the level of similarity. explore the functional effects of differences between model structures. the researcher may also wish to explore the functional effects of model changes. in particular, the researcher should be able to perform a pairwise comparison of the simulation results or other species and reactions in the generated network of a model, in order to identify how the changes within a model affect the generated outputs. organize and browse model repositories. a researcher should be able to use this system to organize and browse a set of possibly unrelated models from a database or online repository. the researcher should still be able to look at the similar and different structures across the collection of models under examination. enable the ability to share model layouts withother researchers. finally, if a researcher wishes to highlight important structural features that were custom-encoded into a model, that researcher must be able to also convey the structure of the model along with the model itself. to keep the model interactive and to share all of the properties of the model, simply sharing a screenshot of a model is not sufficient. therefore, although the model language may not specify any kind of set structural information, that structural information needs to be maintained. this task analysis breakdown shows that a number of problems related to the comparison of models can be solved or aided with visualization. specifically, tasks 1– can be performed with a clear visual representation of the model, and are specifically addressed in this work. task on the other hand, is not specifically a visualization challenge, but can be facilitated by specific aspects of our visualization system. related work computing graph similarity a number of methods have been proposed for computing the similarity of two graphs. zeng et al. computes a similarity score for a pair of graphs by computing the edit distance between two graphs, counting the number of edit operations to nodes and edges required to transform graph g into graph h. bunke and shearer computes a similarity score by finding the maximal common subgraph, looking for the largest isomorphic subgraph present in graphs g and h. ullman presents an algorithm to find subgraph isomorphisms using a brute-force tree search, but pruning the tree to reduce the number of successor nodes that need to be examined. our approach for determining a graph similarity score builds off of these ideas, looking both at maximal common subgraphs, while also considering the differences between graphs that can be computed through edit counts. simulation journaling a number of recent projects have included simulation journaling components to track simulations, steer computations, and perfect models. the world lines system simulates flood response and control, storing options for different simulations as a timeline tree. similar to world lines are tracking graphs, as seen in widanagamaachchi et al., which show the evolution of features over time as a collection of feature tracks that may merge or split. likewise, the porgy system enables simulation steering through direct manipulation of graph components, using a node-link representation to show transitions between graph states. our system notes the links between models and simulations through their proximity to each other as computed by the custom similarity score noted above. visualizing temporal network changes misue et al. notes that the primary factor to consider when visualizing network changes over time is preserving the user’s mental map — minimizing unnecessary changes to the structure of the graph while emphasizing patterns within the graph. four primary mechanisms have been used for visualizing changes in networks while preserving the mental map. using an extra dimension to show network changes over time can add to clutter in the visualization, but can be effective when used appropriately, with either a full extra dimension or simply a “half-dimension”. small multiples are useful to show side-by-side comparisons of two or more networks, but with the disadvantage of losing some of the detail of the networks due to the reduced size, and are featured in ego networks and the semantic graph visualizer project. animations are useful in directly showing how a graph transforms over time, but have the occasional issues of being overly complex or too fast to be accurately perceived. such animations have been studied in projects such as dynavis. finally, interactions for comparing graph states over time come in various forms, including interactive tree layouts, configurable layout algorithms in 3d graphs, and time sliders. methods the top design of our tool is informed by our formal task analysis. since many of these tasks feature comparisons, we selected a small multiples top design; this design allows the comparative exploration of models. we mitigated the issue of detail loss by providing a zoom function to the individual multiples, using animated transitions in the zoom action as suggested by shanmugasundaram and irani and using slow-in/slow-out pacing as recommended by dragicevic et al.. the front-end also allows the exploration of previous simulations and versions for a specific model. the small multiples view provides a compact, scalable, visual encoding of models through an abstraction called an interactive contact map. the view further allows the comparison of similarities and differences between pairs of models represented as contact maps. an interactive contact map is a compact, interactive graph representation of a complete model; this representation lies at the core of our scalable approach. the molecules and binding sites in the biological model become nodes in an undirected graph, while the reaction rules are mapped to edges and component states. the contact map provides a global, compact view of the model. as discussed below, the interactive contact map can visually map models featuring hundreds of species and thousands of reactions into compact graphs featuring dozens of edges and nodes. the small multiples view is enabled by three modules: a contact map manager, a comparison engine, and a layout stabilization and overlay module. contact map manager the contact map manager handles the parallel loading of a family of models from disk, generating contact map representations for these models and laying the contact maps out on screen. it further supports interactions such as panning and zooming, highlighting similarities and differences between pairs of models, identifying common edges and nodes across an entire family of models, showing the states of a model, and opening the model in the default editor interface for closer inspection of parameters and simulation outputs. each contact map is kept concise and scalable by limiting the number of nodes in the map: molecules and binding sites are uniquely identified by single nodes, regardless of how many times they appear in the model rules. for example, the epidermal growth factor receptor model in figure contains different reaction rules, which are compressed into a contact map with six edges and three modifiable components. the rules of the model generate a system of species and unidirectional reactions involving those species. it is worth noting that the contact map is an abstraction of the generative-model for the system, not of the implied reaction network. molecules are represented as large nodes that contain smaller, internal nodes that represent binding sites and components containing states that are modified by the rules. note that a modifiable component may also participate in bonds. the reaction rules in the model are represented as the edges connecting the binding sites, and several rules may map to a single edge.figure egfr contact map. an example contact map from the egfr family. the model contains five distinct types of molecules, each comprised of one or more components, which can have one or more states. each edge represents a possible binding interaction to a component, specified by one or more rules. components shown in purple have states that are modified by the action of one or more rules. the rule-based model represented by this contact map generates a reaction network with species and reactions. by default, the contact map is drawn using a force-directed layout algorithm which is intended to minimize edge crossings to preserve clarity. a user can manipulate the location of the nodes to convey structural information about molecules and components with the layout of the graph. the contact maps corresponding to the members of a model family are laid out in a small multiple display and rendered in grayscale in order to focus attention on the similarity and difference highlights generated by the comparison engine. comparison engine the comparison engine serves two major purposes. first, it sorts the models by complexity in order to minimize differences between neighboring panels and thereby preserve the viewer’s mental map of the core model. second, it calculates similarities and differences between the models, both pairwise and across the full family, which are then passed to the contact map manager for display. sorting models to compute the visual similarity of a graph, we create first an adjacency matrix representation. in an adjacency matrix, each row and column is labeled with a node from the graph, and the matrix itself contains a or depending on whether or not an edge exists between the two nodes. in our contact map implementation, a node can either be a molecule, a component, or a state. we follow a bottom-up approach in the construction of the adjacency matrix. starting from the finest granularity, a state is guaranteed to be a row/column in the adjacency matrix. a component is included as a row/column if it has no states already included in the matrix. a molecule is guaranteed to have at least one component, although that component could represent the entire molecule. this numerical representation of the graph enables us to construct a visual similarity metric as described below.the first challenge in computing a similarity score for two models is defining what makes two graphs similar. there are two descriptive examples for model pairs that are similar, shown in figure in the first, two graphs share a large number of nodes and edges, representing a majority of each graph. these two graphs are certainly similar, as their only differences represent a small percentage of the overall structure. in the second example, two graphs only share a small number of nodes and edges, but one graph is a subgraph of the second. since the structure of the smaller graph is mostly contained within the larger graph, we can argue that these graphs are also similar.figure model overlaps. two graphs that share a large number of nodes and edges. the only difference between these two graphs is the red highlighted node and edge. two graphs that share a common structure. the blue highlighted region has an identical structure, and so the second graph is a subgraph of the first. to account for both of these similarity examples, we propose and construct four similarity matrices which reflect graph similarity. a similarity matrix has the same basic structure as an adjacency matrix. however, instead of nodes in the rows/columns, a similarity matrix contains an entire model. instead of boolean edge existence values inside the matrix, a similarity matrix contains a real number representing how similar two graphs are by some measure. the first two of our similarity matrices handle the first similarity example case. one similarity matrix counts the number of nodes that the two graphs share, while another counts the number of edges that the two graphs share. the other two similarity matrices handle the second similarity example case. one similarity matrix counts the percentage of nodes that the two graphs share, while another counts the percentage of edges that the two graphs share. in each of these cases, we calculate the percentage of nodes/edges in the smaller graph that are present in the larger graph. hence, if graph g is a subgraph of graph h, then the similarity score by this measure is 100% for both nodes and edges, regardless of the number of nodes in graphs g and h. we calculate an absolute similarity score by multiplying the number of nodes that the graphs share and the percentage of nodes that the graphs share, multiplying the number of edges that the graphs share and the percentage of edges that the graphs share, and finally adding these two values together. thus, to compute the absolute similarity between two graphs, we use of the following similarity formula: to sort the models in our small multiples view, we precompute similarity scores for each pair of graphs. we also compare each graph to the most complete graph, and sort the models row-wise into the small multiples view based on their similarity score in comparison with the most complete model. in our implementation, we assume that the most complete graph is the graph with the greatest number of nodes and edges. the assumption is based on our understanding of the iterative development of biological model families - researchers continue to add molecular structures and interaction rules to models to obtain an increasingly complete representation of the physical process. as such, the number of nodes and edges will generally increase as the model is developed. an example of this layout is shown in figure and is described more fully in “layout stabilization and overlay module”.figure egfr models. four sample multiples from the egfr family of models sorted by similarity score relative to the most complete model. the most complete model generates a reaction network with species and reactions. model comparison the second feature of the comparison engine is its ability to locate similarities and differences between models, which are then displayed using a bubbleset overlay. for computing similarities, we iterate over all nodes and edges in one model, creating an identifier for each. we create a unique identifier for the structure we are searching for. we then iterate across all models, searching for that structure. if the structure exists in the other model, we add that structure to an internal list. once the iteration is complete, the internal list of structures is passed to the contact map manager for display. similarly, for computing differences, we must iterate over the nodes and edges of both models, looking for structures that exist in one model but not the other. when such a structure is found, it is likewise added to an internal list. in addition to pairwise comparison, our system also supports identifying a single node or edge across the entire model family. this will allow a researcher to identify which members of a family of models contain a certain problematic rule, or a binding site that is no longer of functional relevance to the behavior of the model. because each of these comparison processes require nested iteration over the node and edge sets of both models, the computational complexity of our comparison algorithm is o. layout stabilization and overlay module laying out the contact maps in a consistent manner across all of the small multiples facilitates the visual comparison of similar models, and in fact may be required for visual comparison in more complex models. we implement layout stabilization by storing the nodes and their user-assigned positions for a particular graph, and then applying the stored layout across a family of models. nodes not present in the stored layout are assigned positions using a force-directed algorithm. by default, layout positions are taken from each individual model. however, the user may override this choice by selecting a stored layout from a drop-down list. when further analyzing a subset of models in a family, it is helpful to easily identify similarities and differences in the structures of each model. the similarities and differences that we compute via the comparison engine are highlighted with a bubbleset overlay on the relevant small multiples. when running a differences comparison, if one graph is a complete subgraph of the other, the result in the smaller graph will be an empty overlay bubbleset. to show that this subgraph model is a member of the comparison, the backgrounds of models under pairwise comparison are highlighted. an example of a similarity comparison bubbleset highlight with layout stabilization is shown in figure figure similarity comparison. the comparison engine in action, showing the similar nodes and edges between two models from the egfr family. the model being compared to the most complete model generates a reaction network with species and reactions. availability and requirements the mosbie system is open source and cross platform, with 32- and 64-bit releases available for windows, linux, and mac os x. the system uses java, rich client platform, perl, and prefuse libraries. mosbie is implemented as a perspective in the rulebender interface for rule-based modeling; the rulebender release includes the bionetgen software as well as nfsim, which is an additional simulator that allows for efficient simulation of large models. no installation is required: unzip the downloaded archive to a directory and the application will run directly. the system can be downloaded at http://visualizlab.org/mosbie. sample models are located in the samplemodels/bng directory of the decompressed directory. all the example models and auxiliary layout files used in this paper can also be found in the additional file provided with the manuscript.  in this section we report on the performance of mosbie. we follow with two case studies from the application domain, and finally report feedback from domain experts. performance analysis we report the time required to calculate the similarity matrices, as well as the time to sort a collection of models, using an hp pavilion g machine with gb ram and an i ghz dual-core processor. our test set of models from the fceri family represents biological systems with thousands of species and tens to hundreds of thousands of reactions. for example, the fceri_fyn model generates a reaction network of species and reactions, and the fceri_fyn_trimer model generates species and reactions. in their interactive contact map representations, the models in this family are captured as graphs with between and nodes and to edges. the model set includes the nine models reported below in the first case study, plus eleven duplicates of these nine models to reach a total of twenty. this duplicate set construction enables the performance evaluation of our approach on a larger set models of the same significant size as the original fceri family. the duplicate approach is reasonable in this case: because it iterates through models in the same fashion regardless of their structure, the comparison algorithm computing time is not reduced when duplicate models are compared. we found that computing the four similarity matrices on this set required seconds and that sorting the models based on their similarity to the most complete model required seconds. this computation time stands in contrast to the seconds required to load the collection of models from disk and build the contact maps.to evaluate the performance of our browsing system, we calculated the average computing time for model comparison. we evaluated computing both similarities and differences across five model families, including the three families reported in the case studies and feedback section. smaller model families ranging from to combined nodes and edges took less than milliseconds for comparison runs. the largest model family we attempted had a combined nodes and edges; the mean comparison time was slightly over one second.figure comparison time. the average calculation time of similarity and difference comparisons on five different model families. the error bars represent one standard deviation in comparison time. the curve of best fit follows a quadratic equation, which follows from the o comparison algorithm. using the same test set of models and identical machine configuration as in the previous experiment, we computed the amount of time required to locate a node in the family of models, locate an edge in the family of models, compare the similarities between a pair of models, and compare the differences between a pair of models. in all cases, the comparison took less than a quarter of a second to complete, including the call to the comparison engine and the display refresh. case study 1: comparison of a model family in this case study, a computational biologist explores a family of rule-based models that describes signaling through the fc εri membrane receptor, looking at various properties of the set of models. the biologist begins by loading the family of models; a directory is selected through a standard dialog box and all models in that directory are loaded into the system. reading the models from disk and generating the contact maps from the rules requires roughly one second per model. as the models are loaded, the comparison engine computes the similarity matrices for the family, sorts the models, and lays them out appropriately into the small multiples panel. this reflects task from our task analysis. next, the biologist enables layout stabilization across the model family. with this new layout, the biologist notices that all of the models seem to have a common core structure, with a large rec molecule centrally located, and surrounded by syk, lyn, lig, and occasionally fyn molecules. to confirm that this common structure does indeed exist, the biologist selects the “compare similarities” radio button, then begins to select pairs of models to compare. through this selection process, the biologist confirms via a bubbleset overlay that this core structure does exist throughout the model family, with a few small differences. one such comparison is shown in figure figure fceri similarity comparison. a similarities comparison within the fceri model family, highlighting the similarities between the fceri_fyn and fceri_fyn_trimer models. the fceri_fyn model generates a reaction network with species and reactions, while the fceri_fyn_trimer model generates a reaction network with species and reactions. to investigate some of these differences more closely, the biologist switches the radio button selection to “compare differences,” which generates a different bubbleset overlay. in one case, comparing the fceri_fyn and fceri_fyn_trimer models, the biologist notices that a single binding site in the lig molecule differs between the two models. this “compare differences” action maps to task from our task analysis. noting this difference of a single binding site, the biologist now wishes to learn how this change in the model affects the concentrations of certain species in the model simulations. even subtle changes to the model can result in significant changes in the network output. by selecting the “open simulations” option from a context menu on either highlighted model, the most recent simulations for each model are identified and opened for the researcher to compare. these simulations are shown in figure which addresses tasks and it should be noted that to validate the significance of this comparison the user would need to check that the parameter values governing reaction rates and initial species concentrations were the same between the two models. this can be done in several steps in mosbie by opening the corresponding model input files and comparing the parameter blocks.figure fceri differences comparison. a differences comparison between the fceri_fyn_trimer and fceri_fyn models, showing a binding site in fceri_fyn_trimer that does not exist in fceri_fyn. simulation outputs. the simulation outputs for fceri_fyn_trimer and fceri_fyn, showing similar curves for the concentrations of recpbeta, recpgamma, recsyk, and recsykps, but with fceri_fyn_trimer having concentrations 50% higher than fceri_fyn. with the simulation outputs displayed, the researcher can note that, while the concentrations of the observables follow similar curves, the fceri_fyn_trimer outputs grow at a rate roughly 50% faster than those in the fceri_fyn model. additionally, the concentration of recsykps is higher than the concentration of recpbeta throughout the full simulation of fceri_fyn_trimer, whereas the opposite occurs in fceri_fyn. from this observation, the researcher notes that it is clear that the addition of a third ligand site significantly increases the rate of phosphorylation of the receptor and of syk. the effect on syk phosphorylation is amplified in comparison to the effect on receptor phosphorylation, which is seen by a change in the ordering of the curves in the top and bottom panels. it is worth emphasizing that the comparisons shown in figures and involve large models. the fceri_fyn model generates species and reactions and the fceri_fyn_trimer model generates species and reactions. these models may take several hours to generate and simulate. as noted by the domain experts, mosbie reveals structural differences between models based on existing simulation data, without the user having to regenerate the results. thus, mosbie potentially saves hours of simulation time. case study 2: comparison of models from a database in this second case study a researcher is developing a model of the egfr signaling network. the researcher wants to see what molecules and interactions have been included in previous models, with an eye toward integrating these into the new model. the researcher finds two models of egfr signaling in the biomodels database, with model ids biomd and biomd, and downloads them as reaction networks in sbml format. both models are fairly large — model has species and reactions and model has species and reactions — and the only visual representations of the models provided in the respective papers use different nomenclature and layout, making them difficult to compare visually. these models are not rule-based and the molecular compositions of the species in each model are not explicitly provided. however, the models can be converted into a rule-based format and the species’ molecular compositions recovered using a recent web-based tool called the atomizer. following successful translation to bionetgen language format, both models are loaded into mosbie and their contact maps displayed. because the two models use slightly different names to refer to some of the molecules they share in common, these mappings had to be identified and modified manually in the model editor. manual layout of the contact maps reveals the implicit molecular components and interactions of the original model. the initial layout of the contact maps for the two models is somewhat different. to facilitate comparison, layout stabilization is applied using the layout for the larger model, followed by correction of the position of the plcg molecule in model and its corresponding binding site in egfr to line up with other molecules and components in the contact map. selecting the “compare similarities” radio button, followed by zooming and recentering, results in the view shown in the bottom row of figure figure comparison of two models of egfr signaling from the biomodels database. left column: biomd; right column: biomd. contact maps with custom layout and similarity comparison with layout stabilization for the two models are shown. the region highlighted in green shows that the two models share a core set of molecules, components, and interactions. model is comprised of species and reactions, whereas model is comprised of species and reactions. note that both models are encoded in sbml and are not rule-based models. contact map representations were generated by extracting the implicit molecular structures of these models using the atomizer. the similarity comparison immediately highlights a core set of elements common to both models. in fact, model contains all molecules and interactions present in model except for the plcg molecule. the comparison in figure also shows that, in addition to containing a number of additional molecules and interactions, model also considers synthesis and degradation of egf and egfr, which are represented by the unstructured nodes connecting to those molecules. the similarity in the core structures of the models was not noted in the paper describing model, even though this model was published after the paper presenting model. without mosbie, it is difficult to identify similarities and differences between models published in the literature because they are usually presented in the form of long lists of equations that use different nomenclature. although the nomenclature problem must still be addressed manually, in our opinion this case study demonstrates the power of mosbie to enable model comparisons that would be prohibitive without monumental effort. domain expert feedback in addition to the two case studies reported above, three computational biologist domain experts requested the mosbie system for the purpose of exploring model sets. the experts were most interested in using the system for locating core structures that are common across model families, including the tlr family shown in figure these core structures can be ideal sites for merging similar models into a larger structure.figure the tlr family of models. a similarity comparison between models tlr4_v and tlr4_rps_v in the tlr family. tlr4_v generates a reaction network with species and reactions, while tlr4_rps_v generates a reaction network with species and reactions. as noted in “performance analysis”, comparison times for a pair of models of the size of those in the tlr family approach one second, which is still roughly equivalent to the time required to load each model from disk and generate the contact map. figure shows a similarity comparison between two models in this family. we found that the researchers were still pleased with this comparison computation time, as it is still significantly faster than a manual comparison. the domain experts expressed satisfaction with the layout stabilization module. they noted that, in addition to making it easier to visually compare models in the explorer view, they could also package the layout information with the model files when sharing models with other researchers. this allows the experts to highlight certain structures in discussions without either providing a screenshot or worrying about differences in the layout computed on each machine. it also enabled the experts to store their own custom layouts for models across multiple sessions. discussions with our domain experts led us to develop additional features that were not explicitly presented in the case studies. for example, the experts felt that the ability to highlight the location of a single node or edge across the entire model family would be useful for identifying which models in a family are missing a key structure. these discussions were also useful for refining some features of the system overall, such as using a grayscale color scheme for the small multiples so that the similarity and difference bubblesets stand out even more. finally, our domain experts also praised the ability to browse the results of past simulations, as some model structures result in very large networks that take significant resources to run. in this case, researchers would not want to rerun simulations. specific to our first case study, the fceri_fyn_trimer model requires close to an hour to perform the network generation stage of the simulation. discussion and  in the absence of a contact map, obtaining a global understanding of the contents of even a single rule-based model from a set of rules in text form is difficult. this difficulty is compounded when doing model comparison. while a binary comparison of two models based on ≲ rules could be done by hand — by someone well versed in reading rules — mosbie offers the power to compare many models at once, as shown in the first case study. this first case study, where we compare nine different models with relatively subtle structural differences, illustrates this scaling issue. as shown in both case studies, mosbie allows detection of patterns that might otherwise be difficult to see. the results of our case studies indicate that mosbie effectively meets the tasks we have identified for browsing sets of models without requiring specialized training on the system. our domain experts were able to begin to explore the families of models immediately, noticing similarities and differences in model structures and identifying relationships between the model results that were being compared. task organizing and browsing online repositories, is not discussed in the case studies because there is currently no such online repository for rule-based models. however, introducing an online database of models is an interesting research direction that we are currently pursuing. when such a repository is developed, our system will be useful for comparing models that overlap in their composition, provided that a consistent annotation scheme is used to allow for accurate determination of common model components. the visual comparison features that we have implemented could facilitate model merging in situations where models are developed by multiple research groups. a prerequisite step for comparison of models developed by different groups is the modification of identifiers — molecule names, component names, and component states — such that shared elements have the same identifiers in all of the models being compared or merged. differences in protein nomenclature are, however, common in the literature. annotations such as uniprot id numbers could also be employed to facilitate identification of common identifiers. a tool that allows synonyms in the protein nomenclature is an interesting direction of future work. in addition, to fully accomplish cross-group model merging additional interface features would be required, such as visual molecule and rule merging. a limitation of mosbie is that the browser-view model comparison is currently based only on contact maps. it is possible for models with similar but distinct rule sets to yield identical contact map representations in this browser view. detecting such differences would require performing comparisons on more fine-grained representations of model structure, using for example the interactive approach described in. however, performing comparisons on more fine-grained representations of model structure in mosbie is beyond the scope of the current work. in conclusion, we have introduced a novel, powerful tool for analyzing structures and dynamics within biochemical model families. our open-source system uses a compact, scalable visual abstraction called an interactive contact map and a similarity metric over this abstraction to enable the clustering of similar models. an intuitive interface further allows researchers to seamlessly compare pairs of models directly, to identify similarities and differences in the structure of models, and to directly compare model simulation outputs. this approach effectively streamlines the analysis of models, both existing and newly created. domain expert feedback and two case studies highlight the benefits of using this exploratory system in the context of systems biology. electronic supplementary material additional file 1: the bngl models and position files necessary to generate the figures presented in this work. abbreviations rbmrule-based modeling mosbiemodel simulation browser and interactive explorer egfrepidermal growth factor receptor sbmlsystems biology markup language rcprich client platform y317tyrosine 317 shcsrc homology domain-containing-transforming protein c1 fc εrihigh affinity immunoglobulin epsilon receptor recreceptor sykspleen tyrosine kinase lyntyrosine-protein kinase lyn ligligand fyntyrosine-protein kinase fyn recsykpssyk-phosphorylated syk-receptor complex recpbetabeta-subunit phosphorylated receptor recpgammagamma-subunit phosphorylated receptor plcgphospholipase c gamma tlr4toll-like receptor competing interests the authors declare that they have no competing interests. authors’ contributions jw wrote the implementation of the explorer interface, with links back to the original rulebender software. jrf and lah provided expert systems biology feedback and helped to direct the design of the tool and case studies. jjt contributed to the design and implementation of the second case study. gem conceived and directed the design, implementation, and testing of the tool. all authors listed contributed to and approved the final manuscript. 
we also present feedback provided by domain experts and discuss the benefits, as well as the limitations, of the approach. the development of families of such models, either by a single research group or by different groups working within the same area, presents significant challenges that range from identifying structural similarities and differences between models to understanding how these differences affect system dynamics. models are clustered using a custom similarity metric, and a visual interface is provided that allows a researcher to interactively compare the structures of pairs of models as well as view simulation results. we illustrate the usefulness of mosbie via two case studies in the cell signaling domain.
 mechanistic models that describe the dynamical behaviors of biochemical systems are common in computational systems biology, especially in the realm of cellular signaling. the development of families of such models, either by a single research group or by different groups working within the same area, presents significant challenges that range from identifying structural similarities and differences between models to understanding how these differences affect system dynamics.  we present the development and features of an interactive model exploration system, mosbie, which provides utilities for identifying similarities and differences between models within a family. models are clustered using a custom similarity metric, and a visual interface is provided that allows a researcher to interactively compare the structures of pairs of models as well as view simulation results.  we illustrate the usefulness of mosbie via two case studies in the cell signaling domain. we also present feedback provided by domain experts and discuss the benefits, as well as the limitations, of the approach. electronic supplementary material the online version of this article contains supplementary material, which is available to authorized users. keywords visualizationvisual computingrule-based modelingcell signalingissue-copyright-statement© the author 2014 