\documentclass[11pt]{article}
\setlength{\topmargin}{-2cm}
\setlength{\textheight}{24cm}
\setlength{\oddsidemargin}{-.5in}
%\setlength{\evensidemargin}{.5in}
\setlength{\textwidth}{7.5in}
\setlength{\parskip}{3mm}
\setlength{\parindent}{0mm}

\usepackage{epsfig}
\usepackage{comment}
\usepackage{graphics}
\usepackage{graphicx}
\usepackage{hyperref}
\usepackage{times}
\usepackage[authoryear,round]{natbib}
\usepackage{subfigure}

\newcommand{\Rfunction}[1]{{\textsf{#1}}}
\newcommand{\Robject}[1]{{\texttt{#1}}}
\newcommand{\Rpackage}[1]{{\textit{#1}}}
\newcommand{\Rslot}[1]{\textsl{#1}}
\newcommand{\Rclass}[1]{\texttt{#1}}

\begin{document}

\bibliographystyle{amsplain}

\author{Elizabeth Whalen\\Harvard School of Public Health \\ 
        Duncan Temple Lang\\University of California at Davis \\
        Robert Gentleman\\Fred Hutchinson Cancer Research Center}
\title{Generalizing the Model View Controller Paradigm}

\maketitle

\begin{abstract} 
In this paper we consider a generalization of the model
  view controller (MVC) paradigm to allow for more flexible handling
  of submodels. Instead of using a single MVC we develop a tree
  structure of related MVCs, where each MVC has a single parent, but a
  parent can spawn many different child MVCs. Communication between
  parent and child MVCs allows for very flexible linking of the
  MVCs. We provide an implementation of our work in the R package
\Rpackage{MVCClass} available at \url{http://www.bioconductor.org}. 
\end{abstract}


\setlength{\baselineskip}{20pt}


\section{Introduction}
\label{Sec:Intro}

%\subsection{Background}
%\label{Ssec:Backg}

%%Cite DataDesk as a system that does this, 
%% also this book:  Andreas Buja, Catherine Hurley, and John Alan McDonald. Elements of a viewing pipeline for data analysis. In W. S. Cleveland and M. E. McGill, editors, Dynamic Graphics for Statistics. Wadsworth and Brooks/Cole, Belmont, Ca., 1988.

%% also this paper: Interactive data visualization using focusing and linking
%%Full text     pdf formatPdf (541 KB)
%%Source        IEEE Visualization archive
%%Proceedings of the 2nd conference on Visualization '91 table of contents
%%San Diego, California
%%SESSION: Multivariate visualization table of contents
%%Pages: 156 - 163  
%%Year of Publication: 1991
%%ISBN:0-8186-2245-8 (PAPER) 

%% EAW: put new citations below
There are many ways to visualize multivariate data when more than
two or three dimensions are needed to view the data.  Many authors
\citep{intGrUnwin, DynGraphics, IEEEVisual, GGobi, DataDesk}
have suggested that linked, interactive views of the data
provide a valuable and important set of tools for comprehending such
data.  The model view controller (MVC) paradigm, as introduced in the
Smalltalk system \cite{Smalltalk}, is now a standard
mechanism for implementing such systems.  The paradigm has proven very
effective and allows for clear separation of different components.
In this paper we consider an extension of the MVC paradigm to allow
for, what we believe to be, an easy expansion to linked data sets.

The sorts of problems we are interested in, are those where a user
might begin with a large data set, identify some interesting subset
and want to create interactive views of that subset.  In some cases the
natural data representation of the subset is in a form other than that
of the initial data set.  This leads to complications in the usual MVC
paradigm, where the data (i.e. the model) are often presumed to be in
a single, standard format when implementing the design.  We found that 
adding new views under such conditions could be quite problematic and 
often led to very complex code.  As we shall demonstrate, there are 
also issues that arise due to mappings that are not one-to-one between 
elements on different views.  Hence we considered an approach that 
created new MVC instances that were linked to the parent MVC that 
spawned them. 

In particular, our implementation consists of a hierarchy of MVCs,
stored as a tree, as shown in Figure \ref{Fig:Hier}.  Each parent can 
have multiple children, but the
children have a single parent.  Communication between parent and
child is bidirectional, and a variety of different filters can be used
to control flow.  Thus, we can devise a number of purpose built MVC
classes, each with a model appropriate to the specific data of
interest, that can be linked in a natural way.  Interacting with the view
in a child MVC, first sends a message to the child MVC, which will
update all of its views, but the message will also propagate to the
parent MVC (and further up to the root).  Similarly, messages propagate 
to the child MVCs if the user initially interacts with a view in the 
parent MVC.  The MVC can choose to react, or not, to messages from its 
parent or children -- all control being in
the hands of the users, should they want it.

\begin{figure}[ht]
  \begin{center}
    \includegraphics[height=2.5in, width=4.2in]{Hierarchy2.jpg}
    \caption{ The Parent-Child Relationship Between \Robject{MVCs}. }
    \label{Fig:Hier}
  \end{center}
\end{figure}

\subsection*{A motivating example}
\label{sec:micro}

Our development of this model was driven primarily by an interest in
analyzing high throughput biological data.  Such data tend to be large
and very complex, and hence ideally suited to interactive
visualization.  In order to provide the reader with some idea of the
sorts of interactions we would like to support, we provide here a short
description of a type of experiment and some of the likely
interactions that would be of interest to a data analyst.

A gene expression experiment provides data on the expression of mRNA
abundance on thousands to tens of thousands of genes for some number
of samples. Usually there are many fewer samples than genes. There is
much that is known about the genes, such as what chromosome they are
located on and what sorts of activities they are engaged in, and in many
cases we want to restrict attention to a specific subset of genes, or
to alter the view so that rather than being gene centric it becomes
centered on some biological aspect, such as chromosome location.

One particularly rich data source is the Gene Ontology (GO), \cite{GO}
which provides three controlled vocabularies that are represented as
directed acyclic graphs, with a root node. Terms typically have a
child-parent relationship, with the child terms being more specific
and the parent terms more general. The root node represents the most
general term. Genes are then annotated at specific nodes in these
graphs where the node is determined, by a domain expert, to describe a
property of the gene. A gene is then also associated with all parents,
since if the specific term applies so must all more general ones.

%% FIXME: perhaps we could have a heatmap and a few of the other views
%% here?
%% EAW: put them below
There is often substantial interest in relating gene expression data
to such a graph based model, or to chromosomal locations, or to
activity in known biological pathways. Data mappings for this latter
aspect can be obtained from different sources such as \cite{KEGG}.
Further, users typically want to begin with a heatmap view. Then from
that derive a GO graph view, and additionally a chromosomal location
view. In order to interact with the GO graph, the primary unit is the
node in that graph (though edges could also be considered the primary 
unit), while
for the heatmap view the basic element is generally the gene.  In Figures
\ref{Fig:heatmap} and \ref{Fig:GOgraph}, a heatmap view of gene expression
from Chronic Lymphocytic Leukemia (CLL) patients and the corresponding GO
graph are shown, respectively.  By interacting with the heatmap to color one
gene blue (shown as gene PDE8A on the heatmap), which causes the corresponding
GO nodes to be colored blue, one can easily see how this gene relates to the
GO terms.  Also by interacting with the node with an arrow next to it in
Figure \ref{Fig:GOgraph}, which represents the signal transducer activity GO
term, one can create a heatmap view that shows only the genes annotated at
that node, as shown in Figure \ref{Fig:heatmapsub}.  Notice how all genes
annotated at the signal transducer activity GO term have a blue label in
Figure \ref{Fig:heatmapsub}, which shows that this view was derived from a
blue colored node in Figure \ref{Fig:GOgraph}.  Compare the heatmaps in
Figures \ref{Fig:heatmapsub} and \ref{Fig:heatmap}.  The heatmap in Figure
\ref{Fig:heatmapsub} is just a subset of the heatmap in Figure
\ref{Fig:heatmap}, however in Figure \ref{Fig:heatmapsub} eleven genes have a
blue label and in Figure \ref{Fig:heatmap} only one gene has a blue label.
The difference in these heatmaps indicates that views are synchronized based
on the parent-child relationships.  Figure \ref{Fig:heatmap} is the parent of
Figure \ref{Fig:GOgraph}, which is the parent of Figure \ref{Fig:heatmapsub}.
Figures \ref{Fig:heatmap} and \ref{Fig:GOgraph} are synchronized, and Figures
\ref{Fig:GOgraph} and \ref{Fig:heatmapsub} are synchronized, but Figures
\ref{Fig:heatmap} and \ref{Fig:heatmapsub} are not synchronized by color
because they do not have a parent-child relationship: Figure \ref{Fig:heatmap}
is the grandparent of Figure \ref{Fig:heatmapsub}.

\begin{figure}[ht]
  \begin{center}
    \includegraphics[height=5in, width=5in]{heatmap.jpg}
    \caption{ Heatmap view of gene expression from Chronic Lymphocytic
      Leukemia (CLL) patients. }
    \label{Fig:heatmap}
  \end{center}
\end{figure}

\begin{figure}[ht]
  \begin{center}
    \includegraphics[height=4.3in, width=4.3in]{GOgraph2.jpg}
    \caption{ Gene Ontology (GO) graph that is associated with the genes
      displayed in the heatmap in Figure \ref{Fig:heatmap}.  Notice that one
      gene (PDE8A) is colored blue in the heatmap and all of the corresponding
      GO terms are colored blue in the graph.  The arrow next to one of the
      nodes indicates that this node was used to create the view shown in
      Figure \ref{Fig:heatmapsub}.  The node with the arrow next to it
      represents the signal transducer activity GO term. }
    \label{Fig:GOgraph}
  \end{center}
\end{figure}

\begin{figure}[ht]
  \begin{center}
    \includegraphics[height=5in, width=5in]{heatmapsub.jpg}
    \caption{ A heatmap view that shows only the genes that are annotated at
      the node in Figure \ref{Fig:GOgraph} that has an arrow next to it.  This
      node represents the GO term, signal transducer activity, and as shown in
      this heatmap, eleven genes are annotated at this node.  Notice that all
      the labels in this heatmap are colored blue, indicating that the parent
      node that was used to create this view was also colored blue.  
      % should I also mention that this is different from the genes that are
      % selected in the grandparent model, which is shown in Figure
      % \ref{Fig:heatmap}??  These eleven genes are also shown in the
      % grandparent view, but only one of them is colored blue showing that
      % views are synchronized by parent-child relationships.
     }
    \label{Fig:heatmapsub}
  \end{center}
\end{figure}

\subsection*{Overview}

We found that constructing a single MVC that would encompass all
anticipated views was very cumbersome. It would also be inefficient
since a MVC model for the GO graph, or for a chromosome view would
also be of substantial interest, regardless of whether there was an
initial heatmap view or not. Thus, we looked for a solution that was
based more on component software constructed within an object oriented
programming environment.
%%FIXME: cite the JSS submission
We had several objectives, or design criteria. They were that the
software should be extensible in a high level language. We chose R as
the language for our implementation and wanted to allow users that
knew no other languages to be able to extend and enhance the
system. Therefore, we built our software on top the \Rpackage{RGtk} package of
D. Temple Lang \cite{RGtk}, since it provides such an interface. We also vastly
preferred Gtk over Tcl/Tk since its widgets are more sophisticated,
which we found results in a much shorter development time.

We wanted to provide a system that was usable and extensible by
relatively naive end users and hence have provided a graphical user
interface (GUI) which they can use to both carry out an analysis, but
also supports a variety of extensions, such as changing the actions
performed in response to events. We also wanted to support a more
sophisticated developer who might want to take our basic infrastructure
and create an interactive system, say for the interactive analysis of
time series data, using our design. Hence, all commands are
available both through the GUI and through command line functions.

In this paper we describe an extensible design for creating linked,
interactive views of linked data sets using an extension of the MVC 
paradigm.  Section \ref{Sec:Back} gives definitions of the terms used in this
paper and describes the MVC paradigm along with its
limitations.  Then Section \ref{Sec:OneMVC} describes our implementation of
the MVC paradigm and how it was extended to accommodate linked data sets.

\section{Background}
\label{Sec:Back}

\subsection{Definitions}
\label{Ssec:Def}

We first give our definitions of linked views, and
linked data sets.  Our model is typically a statistical data
matrix which represents data on a number of variables, for a
number of samples.  By \textit{linked view} we mean that if a
component that represents data (such as a point on a plot or a row in
a spreadsheet) changes its appearance on one view, then the
corresponding component in all other views also changes appearance.
In our example, correspondence is determined by the sample,
but there are other possibilities, as we shall explain later.  As an
example, suppose that the model consists of the gene expression levels
from say 50 samples and 10,000 genes.  The model can be represented as
a matrix of 50 columns and ten thousand rows.  We have two choices for
linking, either the entities can be the samples, or they can be the
genes. If the entities are the genes then when two scatter plots are
created as views, where the first plot displays sample one versus sample two 
and the second displays sample three versus sample four, then the points
on each plot that referred to the same gene are corresponding
components.  If instead we had chosen to link on samples, then we
could produce pairwise plots of gene expression values and would link
them through the sample IDs.

%%FIXME: need to reference iPlots from Simon, and some of these refs need
%%to be put up at the front where I have a citations in parens
%%EAW: added a reference to iPlots below
Linked views, which have a long history in statistics, are now
considered a standard feature of interactive data visualization
software \cite{GGobi}.  Linked views have been implemented in several
pieces of statistical software, such as DataDesk \cite{DataDesk},
XLisp-Stat \cite{Lisp}, iPlots \cite{iPlots}, and GGobi \cite{GGobiMan}.  
Implementing linked views is generally based on the MVC paradigm
\cite{DesignPatterns}, which is widely used and well understood.  We describe
it in detail in Section \ref{Ssec:MVC}.

%We take a fairly general view of interactivity.  Users can interact via
%a pointing device, such as a mouse, or via key strokes, or any of many
%other types of input devices.  Interactivity means that there is an
%immediate response to some user action.  It is a powerful paradigm and allows
%users to quickly navigate and explore complex documents or complex
%data sets.  As an example, suppose that a user has two views: one view
%is a graph where each node represents a particular set of genes while
%the other view is a heatmap of gene expression data.  If the user
%clicks on a node then the response to this action could be to
%highlight all genes in the heatmap view that correspond to the
%selected node.

By \textit{linked data sets} we mean that the data have more than one
conceptual grouping and that there is a relationship between these
different conceptual groupings.  Linked data sets are 
familiar to users of relational databases.  Data in a relational
database are typically stored in many linked tables with rows in
different tables linked to each other through a unique identifier
called a key.  In this example, each table can be considered a data set
and they are linked through the keys. 
Linked relational database tables could be combined into one
large table, but doing so would result in a large amount of redundancy if
the elements in the different tables are linked in one-to-many or many-to-many
relationships.  Instead in relational databases, the tables are created such
that each data element only needs to be stored in one table and then is linked
to data elements in other tables.  Our design will build on this
concept, but the idea is more general and we shall discuss other situations
where the linked data sets do not easily correspond to tables.  As an example
suppose we have gene expression data and we
also know the Gene Ontology (GO) molecular function terms for these genes. 
These data have a many-to-many relationship where each gene can be
annotated at more than one GO term and each GO term can describe more than one
gene.  Now these data could be combined in one data structure, but in
our design we find that creating a MVC for the gene expression data and a MVC
for the GO graph allows us to create views where we can explore the
relationships between the genes and the GO terms.  To explore these
relationships between data elements in different MVCs, we
must have a map that goes from the entities in one data set to those in the
other, as well as the inverse map, in order to propagate signals between the
MVCs.  

\subsection{Model View Controller (MVC) Paradigm}
\label{Ssec:MVC}

The MVC paradigm \citep{DesignPatterns} is a design that consists of
three types of objects: the controller, which defines what actions
occur in response to user input; the view, which consists of displays
of the data; and the model, which manages the data.  The power of the
MVC design is that it decouples the views of the model from the model
itself by creating a subscribe/notify procedure between them. In other
words, the views subscribe to a particular model and the model must
notify the views when a change occurs so that the views can be
updated.  This allows multiple views of the model that are linked, but
are not aware of each other.  And similarly, the model has no
particular knowledge of any of the views, just how to notify them of
changes to the contents of the model.   

In the MVC paradigm the components are separated, but they need a 
method to communicate with each other, which can be implemented using 
a messaging system.  If we have linked data sets, then Figure
\ref{Fig:firstMP} displays the steps that are needed to synchronize 
each model with its views as well as synchronizing the linked data sets 
when a user interacts with a view.
In the figure there are only two views, one of model A (note 
that once a data set is loaded in a MVC, we call it a model) and the
other of the linked model B.  When a user
interacts with the scatter plot view of model B, the response to
this interaction is for the controller to tell model B to update itself 
(this is indicated
on the figure as a circled 1).  In Step 2, the scatter plot view is
told to update itself.  Next, in Step 3, because model B is linked
to model A, model B sends a message to model A.  In Step 4,
the information from model B is converted into information that
model A understands.  In Step 5, this information is received by
model A and model A updates itself.  Finally, in Step 6, model
A tells its view to update itself.

% In the design presented in this paper, the components consist of
% \Robject{MVC} objects and communication within and between
% \Robject{MVC} objects is performed by message objects.  This solution
% uses the power and simplicity of the MVC design and expands it to the
% multiple data set problem.  Now we can build on the original MVC
% design, which has been well tested, instead of starting a new design
% from scratch.  The strength of this multiple linked MVC design is that
% it uses MVC components, which can be individually created and then
% linked.  Thus, these components are reusable.  These design decisions
% are discussed further in Sections \ref{Sec:OneMVC} and
% \ref{Ssec:MultMVC}.

%\clearpage

%%FIXME: please update the figure so that it has A and B, not 1 and 2
%%for the data sets - it was too confusing
%%EAW: it's changed
\begin{figure}[ht]
  \begin{center}
    \includegraphics[height=3.3in, width=6in]{firstMessagePassing.jpg}
    \caption{ Linked views of linked models.  When a user interacts with
      the scatter plot, the first step, indicated by a circled 1,
      is for the controller to tell model B to update.  Then all views of
      model B must be updated.  Next any data that are linked to model B must
      be notified that model B changed.  This information from model B must be
      altered so that it can be understood by linked models, which is shown
      in the fourth step.  Finally, model A is notified that it should
      update in response to the change in model B and then all views of
      model A are updated. }
    \label{Fig:firstMP}
  \end{center}
\end{figure}

% In Section \ref{Ssec:Design}, the design of linked, interactive views based on
% the MVC paradigm is discussed.  However, the limitation with this design is
% that it expects one data set, which limits the type of data we can visualize.
% There are many situations where multiple data sets occur, particularly any
% time there are experimental or study data linked to meta-data.  Being able to
% visualize data from multiple data sets is helpful to understand the
% relationships between variables.  Thus, after discussing the limitations of
% the MVC design in Section \ref{Ssec:Limit}, an extension of the MVC design is
% discussed in Section \ref{Sec:Extend}.  This extension supports the creation of
% linked \Robject{MVC} objects.  The design of individual \Robject{MVC} objects
% is discussed in 
% Section \ref{Sec:OneMVC} while the implementation of linked \Robject{MVC}
% objects is discussed in Section \ref{Ssec:MultMVC}.  The goals of the software
% discussed in this paper are to create linked views of linked data sets, to
% create interactive views where the response to an event can be changed, and to
% create an extensible design that allows future users to make additions.

% \subsection{Design and Implementation of Linked, Interactive
%   Views}\label{Ssec:Design} 

% Focusing on linked, interactive views as a powerful visualization tool, the
% next step is to determine how to design a software package that can implement
% this method.  A popular design for creating linked views of data is the
% MVC paradigm.  This design consists of three types of objects: the controller,
% which defines what actions occur in response to user input; the view, which
% consists of displays of the data; and the model, which manages the data.  This
% paradigm is powerful because it decouples the views from the model.  Thus,
% only one copy of the data needs to be stored and then all views refer to this
% data set.  With all views based on the same data, any changes to the data can
% be propagated to all views, which creates linked views. 

% To link the views to this one data set there is a subscribe/notify procedure
% between the views and the model.  The views subscribe to a particular model
% and the model must notify the views when a change occurs so that the views
% are updated.  This design allows multiple views of the model that are
% linked, but are not aware of each other, as shown in Figure \ref{Fig:ExMVC}.
% Each view is responsible for visually representing some aspect of the model
% and thus, it is not necessary for a view to be aware of other views.  By
% keeping each view ignorant of other views, views can added and removed without
% affecting each other. 

% \begin{figure}[ht]
%   \begin{center}
%     \scalebox{0.5}{\includegraphics{ExMVC.jpg}}
%     \caption{ A Model with its Views. }
%     \label{Fig:ExMVC}
%   \end{center}
% \end{figure}

% Notice that although the components (model, view, and controller) in the MVC
% design are independent of one other, there needs to be communication
% between them so that information can be shared.  Examples of this
% communication between components include the model notifying views that the
% data have changed, a view asking the controller how it should respond to user
% interaction, and a view telling the model that the data should change in
% response to user interaction with the view.  This message passing between
% components in the MVC paradigm is discussed in detail in Section
% \ref{Ssec:OneMess}.   

% In \cite{EW05}, we discuss the creation of R software to fulfill three goals:
% to create views that are linked, to create views that are interactive, and to
% create a design that is extensible.  To satisfy the overall goals of the
% design, two R packages, called \Rpackage{MVCClass} and \Rpackage{iSPlot},
% were created.  The \Rpackage{MVCClass} package implements the class and
% generic function definitions needed for the MVC design and the
% \Rpackage{iSPlot} package creates the front end to let the user create linked,
% interactive views of two-dimensional data, such as data frames and matrices,
% through a GUI or through command line functions.  The reason for
% separating the software into two packages was that it allowed the class
% definitions in the \Rpackage{MVCClass} package to be used by any other R
% package that wanted to create linked views. 

\subsection{Limitations of the MVC Paradigm}\label{Ssec:Limit}

When implementing the MVC paradigm, it is often assumed that there is 
one data set, which is called the model, that all views reference.  
But problems arise when the data consist of more than one conceptual 
grouping.  For example, consider data stored in a relational database, 
such as the data shown in Figure \ref{Fig:MultMVC}.
%Figure~\ref{Fig:DBTab}.  
Here the database
consists of three tables, State, City and StateCity.  The State table
has three columns, State (the key), Life Expectancy, and Income.  The
City table has three columns, City (the key), Precipitation, and
Temperature.  The StateCity table has two columns, State and City.
This last table relates which cities are in which states.  In this
example, each city can be in only one state, but each state can have
more than one city so there is a one-to-many relationship between
states and cities.  In order to support interactive views of all data
tables, in a standard MVC implementation, it seems that either all 
data must be combined into a single large table, or
the processing and accessing of the model data must become much more
complex.  Notice that the MVC paradigm allows a model that is complex, but
accessing the model data is more straightforward when the data is a single
conceptual unit.  This single data structure as a model creates a well 
defined message passing system between the model and its views as well as
between the model and the controller.

%where there are
%multiple tables of data and rows in different tables are linked
%through a unique identifier called a key.  Although these tables of
%data could be combined into one large table, there are several reasons
%not to do this.  Keeping the data in separate tables reduces
%redundancy, particularly when the rows are related by a one-to-many or
%a many-to-many relationship.

%  Also separate data tables generally lead
% to more maintainable data.  By storing only one copy of each piece of
% information (in a row in one table), it is easier to ensure that the
% data are correctly updated when a change occurs.  All other tables
% that are connected with this information can then just reference this
% row that has been updated.

%Consider Figure \ref{Fig:DBTab} shown below.  Here the database
%consists of three tables, State, City and StateCity.  The State table
%has three columns, State (the key), Life Expectancy, and Income.  The
%City table has three columns, City (the key), Precipitation, and
%Temperature.  The StateCity table has two columns, State and City.
%This last table relates which cities are in which states.  In this
%example, each city can be in only one state, but each state can have
%more than one city so there is a one-to-many relationship between
%states and cities.  In order to support interactive views of all data
%tables, in a standard MVC paradigm, it seems that either all data must
%be combined into a single large table (Figure \ref{Fig:OneDBTab}), or
%the processing and accessing of the model data must become much more
%complex. 

%\begin{figure}[ht]
%  \begin{center}
%    \includegraphics[height=0.9in, width=3.5in]{newDatabaseTables.jpg}
%    \caption{ Example of relational database tables. }
%    \label{Fig:DBTab}
%  \end{center}
%\end{figure}

%\begin{figure}[ht]
%  \begin{center}
%    \includegraphics[height=1.2in, width=1.5in]{newOneDatabaseTable.jpg}
%    \caption{ Example of a combined table. }
%    \label{Fig:OneDBTab}
%  \end{center}
%\end{figure}

%\begin{figure}[ht]
%  \begin{center}
%    \subfigure[Example of relational database
%    tables.]{
%    \label{Fig:DBTab}
%    \includegraphics[height=1.2in, width=3.5in]{newDatabaseTables.jpg}}
%    \hspace{.3in}
%    \subfigure[Example of a combined table.]{
%    \label{Fig:OneDBTab}
%    \includegraphics[height=1.2in, width=1.5in]{newOneDatabaseTable.jpg}}
%    \caption{Relational database tables.}
%%    \label{Fig:DBTab}
%  \end{center}
%\end{figure}

We felt that neither approach of combining linked data into one data 
structure or of having a complex model had much appeal.  A single large 
table suggests that all data are similar, and still leaves issues about how
to deal with ensuring that when, for example, a state is selected all
cities within it are highlighted.  The second approach requires writing a
large amount of code, but is unlikely to be extensible.  One area of 
interest is a setting where one representation of the data is as a
graph (with nodes and edges) while the other is as a rectangular array. 
We can envisage lots of different MVCs that operate on graph based data, and
equally MVCs that operate on matrix based data.  Specifying a mechanism
by which these can interact allows us to create two visible classes
that others can use, but still provide interaction between
appropriately linked instances of the two classes.  We also argue that
there are other specific types of models that represent
specific types of data (e.g. time series) and it would make sense to
implement these as other specialized MVCs.  

% Clearly, this information could be combined into one large table, called
% CombinedStateCity, as shown in Figure \ref{Fig:OneDBTab}.  The
% CombinedStateCity table has the following columns: State, Life
% Expectancy, Income, City, Precipitation, and Temperature.  Now if a state's
% life expectancy changes, all instances of this state need to change
% in the new large table.  For example, if the state had the information for
% three cities recorded, then the state has three rows in the
% CombinedStateCity table and each row needs to change the value for the
% state's life expectancy.  If instead only one record was kept per state, as
% shown in Figure \ref{Fig:DBTab} above, then this process is less error
% prone and requires less memory to store the data.  Another consideration in
% combining data sets is that it may give the appearance of a relationship
% between variables that does not exist.  For example, it may not make sense to
% compare the Income data stored in the State table to the Precipitation data
% stored in the City table.  Combining the data tables assumes that there is a
% relationship between the variables in all of the tables.  This example shows
% that there are advantages to storing the data in separate structures.

%\clearpage

% In a relational database all of the data are stored in tables, but consider the
% situation where there are multiple data sets that are of different data
% structures.  For example, suppose that you have experimental microarray data,
% which look at gene expression levels.  This experimental data can be
% stored as a two dimensional data structure, such as a matrix, where rows are
% genes and columns are samples.  Linked to this experimental data are meta-data
% that give information about the genes studied in the microarray experiment.
% For example, this meta-data may be terms from Gene Ontology, which form a
% directed acyclic graph, describing the molecular functions carried out by
% these genes.  These two data sets (the experimental data and the meta-data)
% are linked through the genes.  Each gene can have more than one molecular
% function and each molecular function can have more than one gene annotated at
% that function so there is a many-to-many relationship between the genes and
% the molecular functions.  Though these two data sets are linked, the
% microarray data and the Gene Ontology data are different data structures.   

% Now for the original MVC design, where one data set is expected, it is not
% clear how to combine these two data sets into one data set.  The meta-data
% graph could be stored as a matrix, but a graph is a data structure that can be
% well represented as an object with slots for nodes and edges, especially if
% the graph is sparse.  As with relational database tables, combining the data
% sets complicates data storage, alteration, and retrieval.  For example, by
% combining the data sets a structure may be forced on the data that may not fit
% well, especially if the original data sets are instances of different classes.
% In contrast, keeping the data sets stored separately in their original
% structures simplifies the processes of storing, updating, and accessing the
% data.   

%\subsection{Extending the MVC Design}
%\label{Ssec:Extend}

%As discussed in Section \ref{Sec:Intro}, the MVC design typically uses a 
%single
%conceptual unit, such as a data frame or a matrix, for the model.  And
%we believe that such an approach is a good one.  
%We believe that MVCs should be specialized to certain types of data, such 
%as a graph or a data frame, as this allows them to provide
%better and more natural interactions.  However, we additionally argue
%that there is great benefit to considering linking these different
%MVCs when the underlying data themselves are derived from the same source.
%We believe that there will often be a hierarchical relationship
%between the models and the MVCs that contain them.  We have found
%that allowing the user to create new MVCs based on a current MVC is an
%important and useful paradigm.

%Each \Robject{MVC} is a coherent object and the interactions between
%\Robject{MVCs} are encapsulated in a set of messages.  We use one
%\Robject{MVC} object to handle each model.  Thus, within a
%\Robject{MVC} object, one can create linked views of that particular
%model, using the standard MVC design.  Between \Robject{MVC}
%objects we propose a second messaging system that allows messages to
%be sent between linked models.  In Figure \ref{Fig:MultMVC} we show one 
%view for state-level data and one view for the city-level data.  The state 
%and city data are linked based on the color.  But there are two distinct 
%MVCs, not one.  The city data have one MVC and the state data a second.  
%Even though there are two \Robject{MVC} objects here, the views are linked.

% \small
% \begin{tabular}[t]{ | l | r | r | }
%   \hline
%   State & Life Expectancy & Income \\ \hline
%   Pennsylvania & 70.43 & 4449 \\ \hline
%   California & 71.71 & 5114 \\ \hline
%   Minnesota & 72.96 & 4675 \\ \hline
% \end{tabular}
% \hspace{10pt}
% \begin{tabular}[t]{ | l | r | r | }
%   \hline
%   City & Precipitation & Temperature \\ \hline
%   Philadelphia & 39.9 & 39 \\ \hline
%   Pittsburgh & 36.2 & 37 \\ \hline
%   Los Angeles & 14.0 & 68 \\ \hline
%   San Francisco & 20.7 & 56 \\ \hline
%   Sacramento & 17.2 & 55 \\ \hline
%   Duluth & 30.2 & 18 \\ \hline
%   Minneapolis St. Paul & 25.9 & 22 \\ \hline
% \end{tabular}

% \begin{table}[h]
%   \begin{center}
%     \begin{tabular}{ | r | r | }
%       \hline
%       State & City \\ \hline
%       Pennsylvania & Philadelphia \\ \hline
%       Pennsylvania & Pittsburgh \\ \hline
%       California & Los Angeles \\ \hline
%       California & San Francisco \\ \hline
%       California & Sacramento \\ \hline
%       Minnesota & Duluth \\ \hline
%       Minnesota & Minneapolis St. Paul \\ \hline
%     \end{tabular}
%     \caption{State and City Values.}\label{Tab:CityState}
%   \end{center}
% \end{table}

% \normalsize
% As an example, suppose that one has two data sets: one with information at the
% state level and one with information at the city level.  These tables are
% shown in Table \ref{Tab:CityState}.  The State data include Life Expectancy
% (in years from 1970) and Income (per capita from 1974) data
% while the City data include Precipitation (in inches from 1975) and Average
% High Temperature in January (in Fahrenheit from 2005)
% data.  These two data sets are linked by the StateCity table that links cities
% with the states they reside in.  Now for these two data sets there are
% two \Robject{MVC} objects.  One \Robject{MVC} object for the State data and
% its views and one \Robject{MVC} object for the City data and its views. 

%\begin{figure}[ht]
%  \begin{center}
%    \includegraphics[height=5in, width=6in]{MultipleMVC.jpg}
%    \caption{ Example of two \Robject{MVC} objects.  These two \Robject{MVC}
%      objects are linked by the StateCity table and the color of the points
%    indicates the linking between the data.  The points referring to the state
%    of Pennsylvania are red, the points referring to the state of California
%    are blue, and the points referring to Minnesota are green. }
%    \label{Fig:MultMVC}
%  \end{center}
%\end{figure}

%In Figure \ref{Fig:MultMVC} we show one view for state-level data and
%one view for the city-level data.  The state and city data are linked
%based on the color.  But there are two distinct MVCs, not one. 
%The city data have one MVC and the state data a second.  Even though 
%there are two \Robject{MVC} objects here, the views are linked.

% Not only does this solution use the power and simplicity of the MVC design, but
% this multiple MVC design is structured to fit the linking seen in the multiple
% data sets.  Clearly, the design should be built around the problem and
% multiple \Robject{MVC} objects with messaging between the \Robject{MVC}
% objects fits the problem of creating linked views of multiple linked data
% sets.  In designing an appropriate messaging system between \Robject{MVC}
% objects, consideration is given to what information should pass between
% \Robject{MVC} objects and to how messages propagate between \Robject{MVC}
% objects.  As for the relationship between the \Robject{MVC} objects, it should
% reflect the relationship between the data sets. 


\section{MVC Implementation Details}
\label{Sec:OneMVC}

We believe that MVCs should be specialized to certain types of data, such 
as a graph or a data frame, as this allows them to provide
better and more natural interactions.  However, we additionally argue
that there is great benefit to considering linking these different
MVCs when the underlying data themselves are derived from the same source.
We believe that there will often be a hierarchical relationship
between the models and the MVCs that contain them.  We have found
that allowing the user to create new MVCs based on a current MVC is an
important and useful paradigm.

Each \Robject{MVC} is a coherent object and the interactions between
\Robject{MVCs} are encapsulated in a set of messages.  We use one
\Robject{MVC} object to handle each model.  Thus, within a
\Robject{MVC} object, one can create linked views of that particular
model, using the standard MVC design.  Between \Robject{MVC}
objects we propose a second messaging system that allows messages to
be sent between linked models.  In Figure \ref{Fig:MultMVC} we show one 
view for state-level data and one view for the city-level data.  The state 
and city data are linked based on the color.  But there are two distinct 
MVCs, not one.  The city data have one MVC and the state data a second.  
Even though there are two \Robject{MVC} objects here, the views are linked.

\begin{figure}[ht]
  \begin{center}
    \includegraphics[height=5in, width=6in]{MultipleMVC.jpg}
    \caption{ Example of two \Robject{MVC} objects.  These two \Robject{MVC}
      objects are linked by the StateCity table and the color of the points
    indicates the linking between the data.  The points referring to the state
    of Pennsylvania are red, the points referring to the state of California
    are blue, and the points referring to Minnesota are green. }
    \label{Fig:MultMVC}
  \end{center}
\end{figure}

%\subsection{Implementation Details}
%\label{SSec:OneOver}
%
%We have implemented linked, interactive views of linked data sets
%using an object-oriented programming design which allows for
%extensibility.  We provide this implementation in the
%\Rpackage{MVCClass} package, written in R, which implements the basic
%classes and generic functions.  The \Rpackage{MVCClass} package
%defines the individual model, view, and controller classes as well as
%the \Rclass{MVC} class that binds the individual model, view, and
%controller classes together into one unit.  The package also defines
%the message classes that allow the components to communicate with each
%other.  Thus, the \Rpackage{MVCClass} package contains the classes
%necessary for creating linked views.

\subsection{Model}
\label{Ssec:OneModel}

In our MVC design, the model stores the data and among other things it
supports all updating and other mechanisms that might be needed.
Information can be sent to the model to add, update, and remove data
and after every change the model is responsible for sending messages
to the views indicating which changes have occurred.  In our
implementation we created a single virtual class that represents an
abstract model and that has storage locations for data that are
needed by all models.  Then, we created a number of subclasses, one for
each type of model.  Currently, we have implemented three types of models, 
one based on data frames, one based on graphs, and one based on the 
expression set class of data used by the Bioconductor project \citep{BIOC}.

%In Figure~\ref{Fig:Model} we show the inheritance
%structure for the three types of models we have implemented, one based
%on data frames, one based on graphs and one based on the expression
%set class of data used by the Bioconductor project \citep{BIOC}.

%%FIXME: we need to send the complete paper2 to the BioC tech report
%%series and then cite it here, saying something like: Complete
%%implementation details are provided in XXX.

% Figure \ref{Fig:Model} shows the inheritance structure for the model
% classes. Here the virtual class, \Rclass{gModel}, has the slots
% \Rslot{modelData}, \Rslot{linkData}, \Rslot{virtualData}, and
% \Rslot{modelName}.  These four slots are common information that all models
% need to store.  The \Rslot{modelData} slot is the data set for this model, the
% \Rslot{linkData} slot is a list of two functions, \Rfunction{toParent} and
% \Rfunction{fromParent}, which let this model send information to its parent
% model and receive information from its parent model, respectively (see
% Sections \ref{Ssec:OneMVC} and \ref{Sssec:MultLink} for more information on how
% parent and child models are linked), the \Rslot{virtualData} slot is data
% pertaining to the views that needs to be stored with the model so that it can
% be shown in all views of this model, and the \Rslot{modelName} slot is the
% name of the model. 


%\begin{figure}[ht]
%  \begin{center}
%    \includegraphics[height=3in, width=4.7in]{ModelClass.jpg}
%    \caption{ Inheritance for Model Objects. }
%    \label{Fig:Model}
%  \end{center}
%\end{figure}


% We encapsulate the particular data model in the class definition, which allows
% for efficient dispatch, and accessor functions that are appropriate for the
% underlying implementation.  The specific model classes used in the
% \Rpackage{iSNetwork} package to represent data are \Rclass{dfModel},
% \Rclass{graphModel}, and \Rclass{exprModel}.  The \Rclass{dfModel} class
% represents a model where the \Rslot{modelData} slot has class data frame (or
% matrix), the \Rclass{graphModel} class represents a model where the
% \Rslot{modelData} slot has class graph, and the \Rclass{exprModel} class
% represents a model where the \Rslot{modelData} slot has class exprSet, a class
% used to represent gene expression data \cite{BioC}.

As mentioned previously, the model classes must also perform certain
operations and these operations are reflected in the methods that are
defined for the classes.  All three model classes have an
\Rfunction{updateModel} method.  This method is called whenever the
data need to be updated in response to a user interacting with a view.

Although only three model classes are currently implemented, future
users are welcome to make additions to the model classes for new data
structures they want to represent.  For example, a user may want to add a new
model class called \Rclass{tsModel} to represent time series data.
To make this addition, the user extends the \Rclass{gModel} class, which is
the general model class, in his or
her own R software package.  More information on extending the classes can be
found in the \Rpackage{MVCClass} and \Rpackage{iSNetwork} vignettes, which are
supplied with the software packages.

\subsection{Views}\label{Ssec:OneViews}

The view classes represent the visual depictions, or renderings, of
the model.  There are some data that are required by all views, and all views
must respond to a certain subset of events so we have implemented the view
classes by first creating a single, virtual class which the specialized
views extend.  As with our model classes, this allows us to define
methods and data storage once, for the virtual class, and only extend
it for views that specifically require additional data storage, or
specialized handling.  The object model for the view classes is shown
in Figure \ref{Fig:View}.

\begin{figure}[ht]
  \begin{center}
    \includegraphics[height=4in, width=5in]{newViewClass.jpg}
    \caption{ Inheritance for view objects. }
    \label{Fig:View}
  \end{center}
\end{figure}

As for specific view classes, the \Rclass{spreadView} class represents
a spreadsheet view of the data.  This view requires input data that are
inherently two-dimensional and for graph data, we make a reduction to the 
list of nodes and some attributes.  Other views we have implemented 
include: scatter plots
(\Rclass{sPlotView}), graphs (\Rclass{graphView}), and heatmaps
(\Rclass{heatmapView}).

Since all views are expected to be interactive they have methods that
correspond to the different supported user interactions.  The events
we are most interested in responding to include key press events,
where a certain configuration of keys are pressed; button click
events, where one of the mouse buttons is clicked over the view; and
mouse movement events, where the cursor moves over the view.  When an
event occurs it creates a signal, that is caught by the signal
handler.  The signal handler then calls the callback function and it
is in the callback function that the corresponding method is called.
For example, when the user clicks the mouse button and the cursor is
over a scatter plot view, it is the scatter plot's
\Rfunction{clickEvent} method that is invoked.  Then within the
\Rfunction{clickEvent} method, the \Rfunction{identifyView} method is called
to convert the pixel coordinates into an object in the plot.

All views need an update method so they can alter themselves when the
model sends them a message that the data have been altered. The
actions taken depend on the view, for example for a spreadsheet view
the method may select or unselect a row on the spreadsheet while for
a scatter plot view the method may change the appearance of a point on
the plot.  The inheritance structure of the view classes is
extensible.  For instance, if a user wanted to add a new plot view,
say a density plot, they can create a new view class that inherits
from \Rclass{plotView}, perhaps called \Rclass{dPlotView}.

\subsection{Controller}
\label{Ssec:OneCont}

The controller performs two tasks: the first task is to maintain state,
such as what response will occur for a particular user interaction, 
and the second task is to control message passing.  Messages, which are
discussed in Sections \ref{Ssec:OneMess} and \ref{Sssec:MultLink}, are
responsible for creating new components, such as models and views, and for
passing information between components, such as a view asking a model for
information.  The controller determines when these messages are created and
ensures that they are sent to the proper recipient.

For the second task, the controller gives the user restricted access
to the state information through an application program interface
(API) and thereby lets the user change the response to different events. 
In our implementation users can interact either through a GUI
or through command line functions.  Through the API the user can load
data, create views, set the response to user interaction with a view,
quit the program and perform other functions.  On the GUI, which we call the
control window, users can decide which action is taken next by interacting
with one of the menus: \texttt{File}, \texttt{Edit},
\texttt{Display}, \texttt{Event}, and \texttt{Window}.  If the user
would rather not use the GUI, there are command line functions that
provide access to the same functionality that is available through the
GUI.  

% The GUI is shown in Figure \ref{Fig:ContWin} and is referred to
% as the control window.

% \begin{figure}[ht]
%   \begin{center}
%     \scalebox{0.35}{\includegraphics{ControlWindow.jpg}}
%     \caption{ The Control Window. }
%     \label{Fig:ContWin}
%   \end{center}
% \end{figure}

We support multiple loaded \Robject{MVCs}, but the control window menus
and the command line functions only perform operations on one
\Robject{MVC} object at a time.  Thus, we make use of the concept of
an \textit{active} \Robject{MVC} object, where the active
\Robject{MVC} object (and thus, the active model) means that
operations performed through the control window menus or through the
command line functions affect that \Robject{MVC} object. Users can
switch between active models, but since the interactions could be
quite different, there must always be an active \Robject{MVC}. 

Although the same menus always appear on the control window,
the items under each menu may change depending on the type of model
that is active.  For example, the \texttt{Display} menu allows users
to create views of the active model, but only certain views are
appropriate for a type of model, as mentioned in
Section~\ref{Ssec:OneViews}.  If the active model was a data frame
model (\Rclass{dfModel}), then the views that the user could create
are a scatter plot (\Rclass{sPlotView}) and a spreadsheet
(\Rclass{spreadView}), but a graph plot (\Rclass{graphView}) does not
make sense.  Thus, when the model in the \textit{active} \Robject{MVC} is
of class \Rclass{dfModel}, then the Display menu has menu items to
create a scatter plot and a spreadsheet.

Because one of our goals is to create a software package that is
flexible and extensible, users and developers can add menus and menu items 
to the control window through the command line to access new
functionality that they have created.  As an example if a future
programmer wants to add a new type of view, such as a histogram, then
a new menu item for that view could be added to the \texttt{Display}
menu.  When adding to the API, command line functions should be created as
well as menu items to access the new functionality.

\subsubsection{Linking Events to Functions}
\label{Ssec:OneEvent}

Linking callback functions to events, such as a button click, a mouse
movement or a key press event, is what allows users to have an
interactive environment.  When an event occurs, the callback function linked
to the event (this information is stored in the controller in the MVC)
determines the response to that event.  To create
a flexible environment it is important to be able to change the
response to an event.  For example, when a left button press event
occurs, a user may sometimes want a point to be colored and at other
times she may want a point to be hidden.  However, different responses
to an event may require functions with different signatures, where a function
signature is the combination of the function name along with its parameters.
In our example coloring a point requires two parameters, the new color to use
and the point to color, while hiding a point requires just one parameter, the
point to hide.  

% As shown in Figure \ref{Fig:EventFun}, the slots in the \Rclass{gEventFun}
% class are \Rslot{callFun}, \Rslot{shortName}, and \Rslot{preprocessFun}.  The
% \Rslot{callFun} slot is the callback function, the
% \Rslot{shortName} slot is a short description of the function that
% identifies the callback function, and the
% \Rslot{preprocessFun} slot is a list of all preprocessing
% functions that must be called before the callback function.

% \begin{figure}[ht]
%   \begin{center}
%     \scalebox{0.6}{\includegraphics{EventClass.jpg}}
%     \caption{ The gEventFun Class. }
%     \label{Fig:EventFun}
%   \end{center}
% \end{figure}

%%FIXME: I have tried to reword this part, but am not sure I have it
%%right, nor that I am following the design decision here.
%% EAW: When we decided that we wanted callback functions to be
%% interchangeable, we decided that the callback functions must have the same
%% signature so that calls to different callback functions would be
%% identical, as we wouldn't know ahead of time what function we would be
%% calling.  All callback functions must know which object in the plot to
%% act on, but there was no other universal information that all callback
%% functions needed.  Thus, for any other information that a callback function
%% would need, preprocessing functions were used.  As for that one parameter
%% that the callback function needed, the parameter type may be different
%% depending on the plot (and model) type - whatever is considered the object
%% of interest in a plot (and model).  Thus, for plots of data frames,
%% the object in the plot is considered a row from the data frame and for
%% plots of graphs, the object in the plot is considered a node in the graph. 

Since the intention is to be able to interchange the responses to an event,
the signatures of different callback functions should be the same.
In our design a callback function takes only one parameter. 
The class of that parameter depends on the type of model represented by the
\Robject{MVC}.  For example, for a graph model, the parameter corresponds to
the name of a node in the graph, while for a data frame model, the parameter
represents a case.  We expect a one-to-one relationship between the elements
on a view and the elements in the model.  Continuing the previous example,
each point on a scatter plot represents one case in the data frame model and
each node in the graph plot represents one node in the graph model.  Clearly
it is possible for two points in a scatter plot to overlap if they have the
same x axis and y axis values, but they are still considered two points
representing two cases in the model.


%%FIXME: I thought we talked about this, and found it to be a little
%%problematic, as the way this sounds every click will ask me to set a
%%color. Somehow, some of these are essentially global options that
%%need to be set once, and then used.
%% EAW: The preprocessing functions are called once when the callback function
%% is linked to the event - they are not called each time the event occurs.
Any other information a callback function may need is set using the
preprocessing functions, which are automatically called once by the controller
when the callback
function is linked to the event.  The preprocessing functions take no
parameters.  The purpose of the preprocessing functions is to set
variables that the callback function needs.  Thus, not all callback
functions need preprocessing functions.  If the callback
function sets the color of a node in a graph, then a preprocessing
function is needed to determine what color is used.  So in this
example, the preprocessing function opens a color browser to allow the
user to choose the new color.

%%FIXME: any chance you could elucidate here - what events get
%%excluded, and why are we wanting to be the "event police?"
%% EAW: Any callback function can be linked to any event, but developers may
%% only want certain callback functions available for certain events.  For
%% example, a developer may only want the color a point callback function to
%% be linked to a button click event (i.e. not the mouse over event) or the
%% tooltips callback function only linked with the mouse over event.  Thus,
%% I let the developer determine which events the callback function can
%% be linked to (if the developer wants, the callback function can be linked
%% to all events).  It is when a callback function is added as a possible
%% response to an event that the developer gets to decide which events it can
%% be a response to.  
%% Otherwise, I would just store a list of all callback functions, which could
%% be linked to any event.  I think the way it is implemented gives the
%% developer a little more control over how the callback functions are used -
%% but the developer is allowed to have his/her callback function be available
%% for all events. 
Users can link actions to events either through the GUI or via
command line functions.  The controller environment for each \Robject{MVC}
object stores a list, for each event, of appropriate callback functions that
can be linked to that event and it also stores which callback function is
currently linked to the event.  When a developer creates a new callback
function, the developer can decide which events the callback function can
potentially be linked to.  For example, the developer may only want the color
a point callback function to be available for a button click event and not a
mouse over event.

\subsection{Putting it all Together in a MVC Class}
\label{Ssec:OneMVC}
 
The \Rclass{MVC} class binds the model, view, and controller objects
into one object.  Thus, whenever a new data set is loaded, an
appropriate \Robject{MVC} object is created.  There is a one-to-one
relationship between the \Robject{MVC} instances and model objects.
%%FIXME: this seems like an implementation detail
%%Because of this relationship, the \Robject{MVC} object and the model
%%object are identified by the same name.
Our implementation consists
of a virtual class, \Rclass{MVC}, with three slots, which are
\Rslot{model}, \Rslot{viewList}, and \Rslot{controller}. The three
slots correspond to the three pieces of information that are needed to
bind the model, view, and controller into a single unit. This class is
sufficient for all single MVC activities. To support linked models
we extend this class with the \Rclass{linkedModelMVC} class, which has
two additional slots: \Rslot{parentMVC}, which is the name of the
parent model and \Rslot{childMVCList}, which is a list of the child models.
These are the models that will communicate with each other: parents send
information to their children and children send information to their parent.
More information on this communication is given in Section \ref{Ssec:MultMVC}.


%\begin{figure}[ht]
%  \begin{center}
%    \includegraphics[height=3.2in, width=1.2in]{fullMVCClass.jpg}
%    \caption{ The MVC Class. }
%    \label{Fig:MVCClass}
%  \end{center}
%\end{figure}

%%FIXME: at this point we could perhaps even include a real example
%%with pictures of what is described below?
%% EAW: Yes, we could.  My only concern is confusing the idea of views
%% with models.  I think it's important to show the inheritance
%% structure of the models and not just views of the models.  
Thus, the \Rclass{linkedModelMVC} class not only binds the model,
view, and controller objects together, but it also shows
that the \Robject{linkedModelMVC} objects can be related to each other 
through a
parent-child (tree) hierarchy, as shown in Figure \ref{Fig:Hier}.  In this
picture, modelA is the name of the original \Robject{MVC} object
(model) and from it, two \Robject{MVC} objects were created,
modelB and modelC. Then from `modelB', three
\Robject{MVC} objects were created, modelD, modelE, and
modelF.  As an example, modelA could be gene 
expression data, modelB could be gene expression data that is a subset of
modelA (based on filtering), modelC could be derived by performing
multidimensional scaling (MDS) on modelA, modelD could be the Gene Ontology
(GO) graph representing the molecular functions of the genes in modelB,
modelE could be the KEGG pathways that the genes in modelB are involved
in, and modelF could be the chromosome locations of the genes in modelB.

%\clearpage

%\begin{figure}[ht]
%  \begin{center}
%    \includegraphics[height=2.5in, width=4.2in]{Hierarchy2.jpg}
%    \caption{ The Parent-Child Relationship Between \Robject{MVCs}. }
%    \label{Fig:Hier}
%  \end{center}
%\end{figure}

As shown in Figure \ref{Fig:Hier}, there are many cases where there are
natural submodels that can be derived from a parent model.  We propose that
each submodel is itself a \Robject{MVC} instance, and hence can have multiple
linked views.  Even though each submodel is its own \Robject{MVC} instance,
there will be times when the submodel \Robject{MVC} needs to communicate with
its parent \Robject{MVC}.  There are many different ways of communicating
between parent and child \Robject{MVCs} and we discuss this in Section
\ref{Ssec:MultMVC}.

Deciding when new data should be added to the current model versus generating
a new submodel in a \Robject{MVC} instance should be done by comparing the
relationship between the new data and the data in the current model.  If the
new data has a one-to-one relationship with the elements in the current model,
then we believe that in most cases the new data should be added to the 
current model.  For example, if there is
a test statistic for each row in a data frame, then this could be added to the
model.  However, if the new data has a one-to-many or a many-to-many
relationship with the elements in the current model, then serious
consideration should be given to the creation of a submodel.  If there is
already an appropriate MVC class (e.g. if the submodel is a graph) then it can
be generated by creating a new instance of the appropriate MVC class.  If there
is no appropriate implementation, then the user will need to create one.  
As an example, consider the
relationship between genes and GO terms.  If the original model contains gene
expression levels and a user wants to explore the GO terms for these genes,
then we encourage the creation of the GO graph representing the GO terms, and
creating a new graph \Robject{MVC} object.
%%FIXME: maybe explicitly name the class in the above line
%% EAW: Not sure what you mean about naming the class: creating the GO graph
%% creates an object of class graphModel that is placed in the model slot of a
%% linkedModelMVC object.  As for naming the model (MVC), the user must decide
%% the name.

%New models, and thus new \Robject{MVC} objects, can either be loaded
%or they can be created from an existing \Robject{MVC}. As described in
%Section~\ref{sec:micro} we are interested in data analytic settings
%where experimental data are linked to meta-data and that different
%views of the data based on the meta-data are of substantial interest.
%In this situation, the experimental data can be thought of as
%determining what meta-data are studied.  Thus, there is a hierarchical
%relationship between these data sets where one \Robject{MVC} object
%creates another \Robject{MVC} object.  This focus led to the decision
%that a \Robject{MVC} object can have at most one parent \Robject{MVC},
%from which it was derived, but it can have many child \Robject{MVCs}.

\subsection{Messages Within a MVC Object}
\label{Ssec:OneMess}

In this section we discuss the messages that are sent between the
components of a single MVC object and later we will discuss the
support needed to link MVCs.  All communication is carried out via
message passing. We have implemented a set of message classes to
provide communication between different components of the MVC design,
such as when the model changes a message needs to be sent to the views
to let them know that they should be updated.  This communication
between the model, view and controller is crucial for the pieces to
work together and yet, still be independent of each other.

%%FIXME: lets talk about what we need to do, what sorts of messages
%%need to be sent, and less about how we implemented it, for this
%%paper. As noted elsewhere we can send the whole tech report to the
%%BioC Report series.

% The object model for the message classes was derived from the idea
% that all messages must have certain methods in common, such as
% \Rfunction{initialize} and \Rfunction{handleMessage}, because all
% messages must be created and handled in some manner so that the
% message is read and acted upon.  All messages are sent to
% the \Rfunction{handleMessage} method, which determines where the information
% should be sent and hence is the dispatcher.   Also, since messages
% are sent when something has changed, either through addition, alteration, or
% deletion, the message classes reflect only certain operations.  These
% common purposes for the messages allow the message object
% model to be constructed, and this model is shown in Figure \ref{Fig:Mess}.

% \begin{figure}[ht]
%   \begin{center}
%     \scalebox{0.6}{\includegraphics{newMessageClass.jpg}}
%     \caption{ Inheritance for Message Objects. }
%     \label{Fig:Mess}
%   \end{center}
% \end{figure}

% As with the view classes, the top message class,
% \Rclass{gMessage}, is a virtual class.  It contains no slots and its purpose
% is to bind the other message classes together.

%%FIXME: this needs a few more words. What do these messages do, and
%%why are they the only ones we care about?
%% EAW: I've added some sentences below.
%% My concerns/questions are:
%% Obviously the other message class that could be implemented is the delete
%% message (particularly, deleting a view and deleting a model).  I remember
%% talking about this a while back and I don't recall exactly why we decided
%% not to implement them.  At the time, we discussed the delete message we did
%% not let a model be deleted (at least it wasn't implemented yet).  Message
%% classes are meant to allow communication between the components - thus,
%% deleting a view may be considered to take place solely within the
%% controller (i.e. the response to a delete event for a view is handled by
%% the controller) and thus, a message between components is not necessary.
%% However, deleting a view seems to be the exact opposite operation as adding
%% a view and we have a message class for that operation.  
%% Plus, I'm not sure how adding a model is considered a way to communicate
%% within a MVC object since it creates the MVC object - adding a model
%% creates the MVC object that is added to the overall environment that stores
%% information about the system as a whole.
Currently, two types of messages that are passed within an MVC have been
implemented : an add
message and an update message.  Both messages request that some
modification be carried out.  Since adding a view requires different
information and methods from adding a model (and similarly with
updating views versus models), it makes sense to have two separate
message classes for these elements.  The adding a model message creates the
\Robject{MVC} object because of the one-to-one relationship between a model
and a \Robject{MVC}, whereas the adding a view message updates an
existing \Robject{MVC} object.  The updating a model message is sent by the
controller in response to an event (such as a button click event over a view)
and the updating a view message is sent by the model when the model has
changed.  Notice how these messages allow communication between components
of a \Robject{MVC} object.

%%FIXME: you use numbers, 1, 2, 3 and so on, for too many things. Use
%%letters to label objects, numbers are good for steps, as the numbers
%%mean something.
%% EAW: It's been changed.
An example of message passing within a \Robject{MVC} object is shown
in Figure~\ref{Fig:MPwithin}.  In this example, there are two views of the
model (view 1 and view 2), and the response to a user
performing a button click event over a point in the scatter plot is to
color the point red.  Setting the response to an event was discussed
in Section~\ref{Ssec:OneEvent}.  Here the user first clicks on a point
in view 1, which is shown as Step 1 (the circled 1 on the
figure).  In the figure, the point that has been clicked has an arrow
next to it.  Then, in Step 2, an update data message is sent by the 
controller to the
model, which updates itself accordingly, i.e. by changing the color
associated with the corresponding element.  After the model has been
updated, the views must be notified that a change has occurred so in
Step 3, an update view message is created and sent to all views of
this model.  In response to this message, the views update themselves in
Step 4 and now each view has one point that is colored red to reflect the
change in the model.

\begin{figure}[ht]
  \begin{center}
    \includegraphics[height=3.5in, width=5in]{newMPwithin2.jpg}
    \caption{ Message Passing within a \Robject{MVC} object.  The first step,
      indicated by a circled one, occurs when a user interacts with the y
      versus x scatter plot (view 1).  Then an update data message is sent by
      the controller to
      the model in the second step, which alters the model.  Next in the third
      step all views of this model are sent an update view message, which
      causes the views to be updated in the fourth step. }
    \label{Fig:MPwithin}
  \end{center}
\end{figure}

%%FIXME: say a bit about why and how the proper recipient is
%%identified, but don't get into the slots or class names, just
%%describe, succinctly, what needs to happen, and if possible how.
%% EAW: Not sure if you still want me to respond to this since you've
%%      commented out the following text.

% All four classes, \Rclass{gAddDataMessage}, \Rclass{gAddViewMessage},
% \Rclass{gUpdateDataMessage}, and \Rclass{gUpdateViewMessage}, have
% \Rfunction{initialize} and \Rfunction{handleMessage} methods, which perform
% the following tasks.  The \Rfunction{initialize} method is used to properly
% fill the slots of the object when it is created.  The
% \Rfunction{handleMessage} method is necessary to process the message.  Since a
% message is a form of communication between two components, once it is created
% it must be sent to the proper recipient and action must be taken in response
% to its information, which is the purpose of the \Rfunction{handleMessage}
% method. 

%%FIXME: say a few words about extension of existing methods, with a
%%more convincing example. Say, what if we allow users to drag a point
%%in a scatter plot. What happens then? It might be good to have a
%%single example, such as this, or the density plot, that you can talk
%%about in several different places. With the density plot, as we saw
%%in our discussion with DTL, we need to resolve where to put the
%%value of the slider, or density smooth.
%% EAW: Again, not sure if you wanted me to respond to this since the below
%%      text is commented out.

% As with the inheritance structures seen in previous sections, the message
% inheritance structure is designed to allow for extensibility.  For example, a
% user could create a \Rclass{gUpdateControlMessage} class that inherited from
% the \Rclass{gUpdateMessage} class.  This new class,
% \Rclass{gUpdateControlMessage}, could convey information that told the
% control window to be updated in response to a change in the active view (the
% active view is the view that has the focus).  Currently, the control window
% does not reflect what the active view is, but if a view was created that could
% be rotated, then a user may want the control window to have some type of
% interface to allow the user to control the rotation.  The goal for the message
% classes is that the design is flexible enough to allow a user to make
% additions or changes. 

\subsection{Details of Multiple MVCs}
\label{Ssec:MultMVC}

%%In one discussion I had with an interested party, they suggested
%%that it should be possible to subscribe to a MVC. So a new MVC is
%%created and it can insert itself as a child (possibly as a parent),
%%or it can simply ask to get messages from a particular MVC. This
%%would be one way to deal with letting parent child discussions be
%%optional, we have that structure, but when sending messages we look
%%at the subscribers slot, and send the message to all subscribers.

We now describe the support needed for multiple linked models.
Each \Robject{MVC} object represents one model and its views.  In our
paradigm models are linked through some additional meta-data. In
the case of gene expression data the GO view is linked to the heatmap
view through the mapping of genes to GO categories. In the city and
state example, the cities are linked via the states in which they are
contained. If, in the state MVC, a state is selected that information
can be propagated to the city MVC, but some piece of software must
link the state to the cities. %The message is interpreted by the model
%which changes some data and then sends messages to all views that
%there has been an update. - EAW: I commented out the previous sentence
%because I'm not sure how it fits into the paragraph.

Thinking of experimental data that are linked to meta-data as an
example, there are two \Robject{MVC} objects, one for the experimental
data and one for the meta-data.  In the example of experimental
microarray data that are linked to the Gene Ontology molecular
function graph (as discussed in Section~\ref{sec:micro}), these two models 
are linked in the following manner. The gene identifiers in the
experimental microarray data are linked to the GO terms.  Thus,
passing information between these two models requires that these
mappings be available.

%%FIXME: if it is not too much work, lets give the models names, not
%%numbers.
%% EAW: It's been changed.
Consider Figure~\ref{Fig:Hier}, which was shown previously.  If
modelA's model changes, then this information first gets passed to
modelB and modelC and these two \Robject{MVCs} may make changes to
their models based on this information.  Then modelB passes this
information to modelD, modelE, and modelF based on the changes
that modelB made to its model.  Thus, information passing between
modelA and modelD, for instance, only occurs through modelB.  So
messages can only be sent from parent \Robject{MVC} to child
\Robject{MVC} or from child \Robject{MVC} to parent \Robject{MVC}.
This communication between parent and child \Robject{MVCs} was shown in Figures
\ref{Fig:heatmap}, \ref{Fig:GOgraph}, and \ref{Fig:heatmapsub} in Section
\ref{sec:micro}.  Here views of the parent and child models are
synchronized, but the selected items in a grandparent model may not
match the selected items in a grandchild model (as shown by Figures
\ref{Fig:heatmap} and \ref{Fig:heatmapsub} where the selected genes are
different in these two heatmaps).  Deciding how to link \Robject{MVC} models 
is a difficult task especially when the relationship between elements in the 
two models is not one-to-one.


\subsubsection{Linking Models}
\label{Sssec:MultLink}

%%FIXME: but we said this above, so let's drop this section and move
%%this up, integrate with the discussion there. Say we use two
%%functions, toParent and fromParent. The rest has been said.
%% EAW: Not sure if you wanted me to change anything here.
For messages to pass between \Robject{MVC} objects, the information from one
\Robject{MVC} must be converted into useful information for a different
\Robject{MVC} object.  Thus, there needs to be some way to determine how data
from one \Robject{MVC} object relates to data in a different \Robject{MVC}
object.  This conversion is done by two functions that are stored in the
\Rslot{linkData} slot of the model objects.  The \Rslot{linkData}
slot is a list with two elements: a \Rfunction{toParent} function and a
\Rfunction{fromParent} function. 

When a child \Robject{MVC} is created from an existing \Robject{MVC}, the
child model's \Rslot{linkData} slot is filled with the two functions,
\Rfunction{toParent} and \Rfunction{fromParent}.  When the model in
the child \Robject{MVC} is updated, the \Rfunction{toParent} function in the
\Rslot{linkData} slot is used to convert the child model's data
change into useful information for the parent model if there are any linked
elements in the parent model.  

Now suppose that the parent model changed instead.  This information
needs to be passed to the child model.  However, a parent can have
multiple child \Robject{MVC} objects so the parent sends a message to
each child \Robject{MVC} to notify the child of the change and then
each child \Robject{MVC} handles the message by using its
\Rfunction{fromParent} function.  The \Rfunction{fromParent} function
converts the parent model's data change into useful information for
this particular child model.  Thus, the message sent to all children is the
same, but each child converts the message, using its \Rfunction{fromParent}
function, to make it specific for that child.
%Thus, the message sent may be specific
%to the child. 

The link functions, \Rfunction{toParent} and \Rfunction{fromParent}, can
become quite complex depending on the relationship between the elements in the
two models.  Suppose that the data elements in the two models have a
one-to-one relationship where data element 1 in child model A is linked to
data element 2 in parent model B.  Now if data element 1 in child model A is
selected, then the \Rfunction{toParent} function will pass along the
information that data element 2 in parent model B should be selected.  Here
the linking is straightforward.  However, if the data elements in the two
models have a one-to-many or many-to-many relationship, the decision about
which linked elements to update is more complex.  Now suppose that data
element 1 in child model A is linked to data elements 10, 11, and 12 in parent
model B and data element 2 in child model A is linked to data elements 12 and
13 in parent model B.  Here a many-to-many relationship exists between the
data elements.  If the user selects element 1 in child model A, the
\Rfunction{toParent} function must decide if elements 10, 11, and 12 should be
selected in parent model B or if only elements 10 and 11 should be selected in
parent model B (because element 12 in model B is also linked to element 2,
which is not selected, in model A).  

These two options for the linking function can be represented as \textit{any}
versus \textit{all} linking.  In \textit{any} linking, if any element is
updated, then the corresponding linked element is updated.  This linking could
also be represented as \textit{or} linking if one is thinking in terms of
boolean operators.  In \textit{all} linking, the element in the second model
is updated only if all linked elements are updated in the original model.
Similarly, this linking could be also be represented as \textit{and} linking
if one is thinking in terms of boolean operators.  

Making the previous example even more complex suppose that child model A also
had data element 3 which is linked to data elements 12, 13, and 14 in parent
model B.  Now if data elements 1 and 3 are selected in child model A, the
\Rfunction{toParent} function can link based on one of these options: i) select
data elements 10, 11, 12, 13, and 14 in parent model B, which indicates that
any items in model B that are linked to elements 1 and 3 in model A are
selected, ii) select data element 12, which indicates that only data elements
that are linked to both elements 1 and 3 in model A are selected, or iii)
select no data elements in model B, which indicates that only elements linked
to both elements 1 and 3 and no other elements in model A are selected.
Another consideration in the linking functions may be to change the response
depending on the type of selection being performed.  For example, \textit{any}
linking between models may be appropriate when an item in one model was
highlighted, but if an element is hidden, then \textit{all} linking may be
suitable.  This flexibility lets developers determine the appropriate
relationships between models, but also requires thoughtful responses and
potentially complex linking functions.

%The message classes for creating a child \Robject{MVC} from an existing
%\Robject{MVC} and for sending messages between \Robject{MVC} objects are shown
%in Figure \ref{Fig:BetwMess}.  The message types for passing information
%between \Robject{MVCs} are similar to the messages
%that are passed within \Robject{MVC} objects.  Now the add child message is
%similar to the add model message, and the send parent message and the send
%child message are similar to the update model message.

%\begin{figure}[ht]
%  \begin{center}
%    \includegraphics[height=4in, width=4.5in]{MVCMessageClass2.jpg}
%    \caption{ Inheritance for Message Classes that are Passed Between
%      \Robject{MVCs}. }
%    \label{Fig:BetwMess}
%  \end{center}
%\end{figure}

% The first message class that is discussed is
% \Rclass{gAddChildMessage}.  A \Robject{gAddChildMessage} object is very
% similar to a \Robject{gAddDataMessage} object because they are both adding a
% new model and a new \Robject{MVC} object.  The difference with a
% \Robject{gAddChildMessage} object is that it must fill in some extra
% information to tie this new \Robject{MVC} object to its parent \Robject{MVC}
% object.  The \Rclass{gAddChildMessage} class inherits from the
% \Rclass{gAddMessage} class, with the same slots of \Rslot{dataName},
% \Rslot{mData}, and \Rslot{type}.  The \Rslot{dataName} slot is the name of the
% new model (and new \Robject{MVC}), the \Rslot{mData} slot is a list that
% contains the
% model data and virtual data to fill the \Rslot{modelData} and
% \Rslot{virtualData} slots, respectively, of the new model, and the
% \Rslot{type} slot gives the type of the model (currently, the options are
% ``exprSet'', ``graph'', or ``data.frame'').  As with the previous
% message classes, the \Rclass{gAddChildMessage} class has two methods:
% \Rfunction{initialize} and \Rfunction{handleMessage}.  The
% \Rfunction{initialize} method properly fills the slots of the object when it
% is created and the \Rfunction{handleMessage} method ensures that the new
% model and \Robject{MVC} objects are created (which is what the
% \Rfunction{handleMessage} method for the \Rclass{gAddDataMessage} class does)
% and then it fills the \Rslot{linkData} slot of the new child model
% so that the \Rfunction{toParent} and \Rfunction{fromParent} functions are
% available for messaging between \Robject{MVC} objects and finally it stores
% information in the child \Robject{MVC} object's controller that determines if
% the child model was created from a subset of the parent
% model.  Thus, the \Rfunction{handleMessage} method for the
% \Rclass{gAddChildMessage} class both creates the child \Robject{MVC} object
% and relates it to the parent \Robject{MVC} object. 

% The next two message classes pertain to sending information to linked
% \Robject{MVC} objects when a parent \Robject{MVC} or child \Robject{MVC}
% object has changed.  These classes are \Rclass{gSendParentMessage} and
% \Rclass{gSendChildMessage} and they both inherit from the \Rclass{gMessage}
% class, as shown in Figure \ref{Fig:BetwMess}.  Because the messages are
% sending information to a linked \Robject{MVC} object, they both contain a slot
% for a \Robject{gUpdateDataMessage} object that was just used to update a
% \Robject{MVC} object.  The \Rclass{gSendParentMessage} class has one slot,
% \Rslot{childUpdateDataMessage}, and this slot contains the
% \Robject{gUpdateDataMessage} object that was used to update the child
% model.  Similarly, the \Rclass{gSendChildMessage} class has two
% slots, \Rslot{parentUpdateDataMessage} and \Rslot{childName}, where the
% \Rslot{parentUpdateDataMessage} slot contains the \Robject{gUpdateDataMessage}
% object that was used to update the parent model and the
% \Rslot{childName} slot contains the name of the child model that is
% being updated because a parent \Robject{MVC} can have more than one child
% \Robject{MVC}.  

% As with all the other message classes, these two send messages have
% two methods: \Rfunction{initialize} and \Rfunction{handleMessage}.  The
% \Rfunction{initialize} method properly sets the slots of the new object.  The
% \Rfunction{handleMessage} method for a \Robject{gSendParentMessage}
% takes the \Robject{gUpdateDataMessage} object from the child model
% and converts it to a \Robject{gUpdateDataMessage} object for the parent
% model using the \Rfunction{toParent} function.  Similarly, the
% \Rfunction{handleMessage} method for a \Robject{gSendChildMessage} takes the
% \Robject{gUpdateDataMessage} object from the parent model and
% converts it to a \Robject{gUpdateDataMessage} object for the child
% model using the \Rfunction{fromParent} function. 

An example of how messages are passed and converted between MVCs 
is shown in Figure \ref{Fig:MessPass}.  The message classes ensure 
that when a model is updated, its parent and child models are notified 
of the change and most importantly are notified of the change in a way that
each model can properly act upon that information.  Because each
\Robject{MVC} object has a different model (and thus a different data
set and potentially a different data structure), information that
pertains to the model for one \Robject{MVC} must be converted to
useful information for the linked model and this conversion is done by
the \Rfunction{toParent} and \Rfunction{fromParent} functions.

\begin{figure}[ht]
  \begin{center}
    \includegraphics[height=2.8in, width=4.5in]{newMP.jpg}
    \caption{ Message Passing Between and Within \Robject{MVCs}.  When a user
      interacts with the y versus x scatter plot, the first step, indicated by
      a circled one, is for the controller to send an update data message to
      model B.  After model B has been updated, all views of this model must
      be notified, which is shown in the second step when an update view
      message is sent.  Next any data that are linked to model B must be
      notified that model B changed, which is shown in the third step as a
      send parent message.  This message is converted into useful information
      for model A in the fourth step by the \Rfunction{toParent} function, and
      this information is sent to model A in the fifth step when an update data
      message is sent.  Finally, after model A is updated, an update view
      message is sent in the sixth step to update all views of model A. }
    \label{Fig:MessPass}
  \end{center}
\end{figure}

%%FIXME: please give models names, not numbers
%% EAW: fixed.

Figure \ref{Fig:MessPass} is very similar to Figure \ref{Fig:firstMP} shown in
Section \ref{Sec:Intro}.  Now, however, Figure \ref{Fig:MessPass} shows how
\Robject{MVC} objects are defined and how messages are passed within one
\Robject{MVC} as well as how this information gets passed on to its parent
\Robject{MVC} using messages.  Suppose for this example that when the user
clicks a mouse button over the scatter plot, the response to this event is to
color the point under the cursor 
red.  In this picture, the message passing starts when a user clicks a point,
that is indicated by the arrow, on the scatter plot.  An update data message is
sent to Model B in response to this user interaction.  As soon as Model B is
updated, it sends an update view message to all its views so that the views
are updated to reflect the changed data.  Now the scatter plot point that was
initially clicked is red.  Then a send parent message is sent because MVC
B, which is the \Robject{MVC} object for Model B, has a parent \Robject{MVC},
which is MVC A.  Next the \Rfunction{toParent} function converts the child's
update data message into an update data message that the parent \Robject{MVC}
understands.  Then the update data message that was created by the
\Rfunction{toParent} function is sent to Model A.  Finally, after Model A has
been updated, an update view message is sent to all of Model A's views.  It is
in this last step that the view of Model A has a point colored red to indicate
which data from Model A are linked to data from Model B.  All of the data and
the views are synchronized. 

\section{Conclusions}\label{Sec:Conc}


%Several examples of linked data sets were given at the beginning of
%this paper, including linked tables from a relational database, and
%meta-data that are linked to experimental data.  The MVC paradigm was
%discussed as a useful design for creating linked views of a data set.
%Starting with the MVC paradigm, this paper provided a design for
%implementing linked, interactive views of linked data sets based on
%expanding the MVC paradigm.  For visualizing linked data sets, the MVC
%design, which is a well known and thus, well tested software paradigm,
%was extended to multiple \Robject{MVC} objects where each
%\Robject{MVC} object contains one data set and its views.  This
%solution broke down the problem of linked, interactive views of linked
%data sets into components (\Robject{MVC} objects) that can be reused,
%extended and linked.

%Once the design settled on \Robject{MVC} objects as the component of interest
%for creating linked views of linked data sets, the next step was to determine
%how these \Robject{MVC} objects were related.  Because the focus in this paper
%was on experimental data that are linked to meta-data, a hierarchical
%relationship between \Robject{MVC} objects was built into the \Rclass{MVC}
%class definition.  The experimental data can be thought of as determining what
%meta-data are studied and thus, the meta-data are derived from the
%experimental data, which shows a parent-child relationship.  
 
%Another consideration in the design was creating a method for communicating
%within and between \Robject{MVC} objects.  This method must pass information
%between the components while keeping the components independent.
%Communication within a \Robject{MVC} object was handled using instances of the
%message classes, which performed one of four functions: adding a model, adding
%a view, updating a model, or updating a view.  Starting with this design, it
%seemed a natural extension to have message classes that passed information
%between \Robject{MVC} objects.  When a \Robject{MVC's} model is updated, it
%notifies its parent and child \Robject{MVCs} that a change has occurred using
%message objects.  Then when a \Robject{MVC} gets a message from a parent or
%child \Robject{MVC}, the \Robject{MVC} can either decide to ignore the message
%or read the message, which results in this \Robject{MVC's} model being
%updated.  However, the \Robject{MVC} object can not decide to only see certain
%types of messages.  It must either accept all messages and update its model
%based on the messages, or ignore all messages.  A future goal for message
%passing is to allow more selectivity in which messages are accepted between
%\Robject{MVC} objects so that the linking between \Robject{MVC} objects is
%more sophisticated. 

%%FIXME: this belongs in the introduction. Here you should say
%%something more like: RGtk worked well. We could construct the tools
%%we wanted, relatively easily. You should also say what worked well -
%%ie that we got lots of specialized MVCs that can themselves be
%%implemented and extended - mostly because they are simple, they are
%%easier to understand, an unintended consequence.
%%
%% what about message passing? How did it work? Did you need more or
%% fewer types than you thought? What about the between data set
%% links? How did they turn out? Hard or easy? How much can be
%% automated and how much needs to be done by hand. Can naive users
%% get linked MVCs (which might be a better way to describe it than
%% linked data sets), or do you need to know a lot to get the link
%% function right?
%%
%% EAW: I've tried to change the conclusions to include some of your comments.


The goals for this research were to create software implementations and
conceptual paradigms to support the use of linked views of linked data sets,
to create interactive views where the response to an event can be changed, and
to create an extensible design that allows future users to make additions.
The first goal was accomplished by implementing \Robject{MVC} objects as
components that communicate with each other through messages.  Encapsulating
each data set in a \Robject{MVC} object was particularly useful because it
allowed the reuse of code for communicating between the components of a
\Robject{MVC} object, which made generating new model and view classes easier.
However, communication between the \Robject{MVC} objects was, at times, more
complicated. 

The crux of the communication between \Robject{MVC} objects is the link
function, which converts information that one model can understand into
information that a linked model can understand.  As discussed previously, the
linking functions, \Rfunction{toParent} and \Rfunction{fromParent}, can be
quite complex if the relationship between the data elements in the two models
is one-to-many or many-to-many.  In response to an update in one model, the
linking function must decide if all linked elements in the second model
should be updated, if any linked elements should be updated, or if a subset of
linked elements should be updated.  These decisions must be made by the
developer to properly represent the relationship between the data elements in
the two models.  While this flexibility lets the developer represent different
relationships between different models, the developer is then responsible for
knowing what makes sense (for example, biologically) when creating the link
functions. 

The second goal of creating interactive views was met by using the
\Rpackage{RGtk} and \Rpackage{gtkDevice} packages \cite{RGtk} to create
devices that could respond to events.  Using these packages made creating
interactive views particularly straightforward because any static R plot could
be made interactive by plotting it on a Gtk device and by having the plotting
function return information about the location of plot objects on the device.
In addition the \Rclass{gEventFun} class was designed so that users could alter
the response to an event.  The response to an event could be as simple as
selecting the plot object that was just clicked by a mouse button or the
response could be as complicated as creating a new model.  This flexibility
lets the developer create a more varied interactive environment.

Finally, the last goal of creating an extensible design was achieved through
the inheritance structure for classes, which allows for extensions by the
user, and through command line functions, which let the user create new menu
items to add to the GUI and also let the user create new callback functions
that can be linked to events.  However, in terms of extensibility, certain
design decisions, such as expecting the models to be linked through a
parent-child hierarchy, may not work with some models.  As an example, the
linked tables from a relational database are not related through a tree
structure and thus, having parent and child \Robject{MVC} objects may not make
sense with these models.  However, the design allows users to add new types
of models, new types of views, and new message classes so there is still
flexibility for additions as long as the models are connected through
parent-child relationships.  These new class definitions could be created by
the user in a new package that extends the \Rpackage{MVCClass} package that
was discussed in this paper.  Other additions that the user may want to
perform, such as adding new menus to the GUI and adding new responses to an
event can be performed through command line functions that are defined in the
\Rpackage{iSNetwork} package, which is the front end for the design
described in this paper. 

The functionality that is provided in the \Rpackage{iSNetwork} package, which
is an implementation of the research discussed in this paper, is
discussed in detail in the vignette for this R package.  Users can load data,
create views of the data, interact with these views and change the response to
the interaction (these interactions include mouse button click events and
mouse movement events), and users can create child \Robject{MVC} objects
through the GUI or through command line functions.  With the functionality in
the \Rpackage{iSNetwork} package, the user can create views of linked models
and can explore visually the relationships between variables in different data
sets.  This functionality was implemented by extending the MVC paradigm in a
very natural way to encompass a much richer class of models and user
interactions. 

%\section*{Acknowledgements}
%We are indebted to Dr. Duncan Temple Lang for the creation of the
%\Rpackage{RGtk} and \Rpackage{gtkDevice} packages as well as helpful advice on
%their use.  

\bibliography{paper2}

\end{document}
