Data is not knowledge.
Data can reveal relationships between events – correlations that may or may not be causal in nature; but by itself, data explains nothing without some form of conceptual model with which it can be assimilated into an intellectual framework that allows one to reason about it.
Computational modeling is not in the mainstream of life science research in the way that it is in other fields such as physics and engineering. And while all scientific concepts are implicitly models, most biologists have had relatively little experience of the kind of explicit modeling that we’re talking about here. In fields like biology where exposure to computational models is more limited, there is a tendency to consider their utility largely in terms of their ability to make predictions – but what often gets overlooked is the fact that models also facilitate the communication and discussion of concepts by serving as cognitive frameworks for understanding them.
Next to the challenge of representing the sheer complexity of biological systems, this cognitive element of modeling may be the single biggest reason why modeling is not in the mainstream of the life sciences. Most biological models use idioms borrowed from other fields such as physics, where modeling is both more mature, and firmly in the mainstream of research.
For a model to be truly useful and meaningful in a particular field of intellectual activity, it needs to support the conceptual idioms by which ideas and knowledge are shared by those in the field.
In other words, it should be possible to put questions to the model that are couched in the conceptual idiom of the field, and to receive similarly structured answers. To the extent that this is not true of a model, there will be some degree of cognitive disconnect between the model and the user which will impede the meaningful interaction of the user with the model.
Nowhere can this be more clearly seen than in the field of software design. Software applications make extensive use of cognitive models in order to facilitate a meaningful and intuitive interaction with the user. As a very simple example – software that plays digital music reproduces the play, forward and reverse buttons that were common on physical media devices like cassette and VHS players. This is because almost everybody has the same expectations about how these interface components are to be used, based upon their prior experience with these devices. As an aside, it’s interesting to reflect on the fact that while the younger generation may see these interaction motifs everywhere in the user interfaces of software media players, many of them will never have seen the original devices whose mechanical interfaces inspired their design.
The psychology and design that determines these interactions with the objects and devices that we use, is such an important area of study that it has given rise to an entire field that is commonly referred to as User Experience (UX) or User Experience Design. UX lies at the intersection of psychology, design and engineering and is concerned with the way that humans interact with everything in the physical world from a sliding door to the instrument panel of an airliner – and of course, their analogs in the virtual world; web browsers, electronic books, photo editing software, online shopping carts and so on.
Affordances and signifiers are the currency of UX design, facilitating the interaction between the user and the object or software. If you consider an affordance as a means of interaction (like the handle on a door for example), signifiers are signs for the user that suggest how the affordances might work. To use our very simple door handle example – a handle that consists of a flat metal plate on the door suggests that the door be pushed open. A handle consisting of a metal loop more strongly suggests that the door should be pulled open. For the purposes of illustration, this is just a very superficial and simple example of the kind of cognitive facilitation that effective UX design can support. By contrast, consider the role that UX design plays in highly complex, human-built systems whose interactions with the user are predicated on multiple and often interdependent conceptual models, each of enormous complexity in its own right. In some cases, a single, erroneous interaction with such a system might even destroy the system and/or lead to the loss of human life.
So what does all of this have to do with scientific modeling?
By facilitating a cognitive connection between the user and an object, a device or a piece of software, effective UX design makes the interaction easier, more intuitive and more meaningful. Insofar as a computational model is being used to develop a conceptual framework that explains data, effective UX design similarly facilitates the cognitive leap from data to knowledge.
Perhaps the best way to appreciate this is to see it in action, and if you’ll bear with me, I would like to illustrate this with an example from my own experience.
As VP of Biology at a venture-funded software startup building a collaborative, cloud-computing platform to model complex biological pathways, a major part of my role in the company was to serve as the product manager for the software. In practice, this actually comprised two roles. The first was an internal role as the interface between the company’s biology team tasked with developing the applications for our product, and our software engineering team who were tasked with building the product. The second was an external-facing role as a product evangelist and the liaison between our company and the life science research community – the potential client base for whom we were building our product.
One component of our cloud-computing platform was an agent-based simulation module for modeling cell signaling pathways. The ‘players’ in these simulations were as you would expect, mostly proteins involved in cell signaling pathways – kinases, phosphatases etc. and any kind of phosphoprotein whose cellular activity is typically modulated by the kind of post-translational modification events that proteins like kinases and phosphatases mediate.
As a simulation proceeded on the cloud, it could be tracked by the user through a range of different visualizations in their web browser. One of these displayed the concentrations of the different molecular species present in the simulation, over time. This was initially presented as a graph like this:
But if you think about the way that a biologist in the laboratory would do this experiment, this presentation of the results, while being information-rich, would not be what he or she was used to. The analogous lab experiment would probably involve sampling the reaction mixture at regular intervals and for example, running these aliquots as a time series on a gel to visualize their fluctuations over the course of the experiment.
My initial proposal that we add a visual element to the graph that reproduced what the biologist would see if they were to run the reaction mixture from a particular time point on a gel, was met with some degree of skepticism from the software engineers .
To be fair, it has to be said at this point that any good software engineering team (consisting of developers, business analysts, product managers etc.) always will (and should) set a high bar for the approval of new features in the code, especially where there is any kind of significant cost in time, money or resources required for their implementation. We were fortunate in our company, to have just such an excellent software engineering team and so their initial resistance to this idea was not wholly unexpected. The main argument against it was that it would not be an information-rich visual presentation of the simulation results in the way that the graph already was, and furthermore, that it was redundant since this information was already presented at a much higher resolution in the graph.
When however, in my capacity as external liaison with our potential client base, I tested the response of the life science research community to a mock-up of this feature, the results were amazingly positive.
We asked biologists who agreed to be interviewed, to compare the version of the simulation interface that contained only the graph, with a mock-up of an updated version (shown above), that also contained a simulated Western blot display with a time slider that could be moved across the graph to show what the Western blot gel would look like at each sampled time point.
Their responses were striking. What we heard most often from them (and I’m aggregating and paraphrasing the majority response here), was that the version of the interface with the Western blot display made a great deal more sense to them because it helped them to make the mental leap between the data being output from the model and what the model was actually telling them. In their minds and perhaps most importantly, it also reinforced the idea of the computational simulation as a virtual experiment whose results could help guide their decisions about which physical experiments to do in the lab.
Despite this new visualization not being information-rich as the software engineers had rightly pointed out – in its ability to frame the output from the simulation model in an idiom that was meaningful to the biologist, it created a richer and deeper cognitive connection between the biologist-modeler and the biology that was being represented and explored in the model.
Recognizing that if modeling is ever to really become a part of the mainstream in life science research in the way that it is in physics, we took very seriously, the idea of doing biological modeling in an idiom that is appropriate for biology. This idea permeated every aspect of the development of our collaborative computational modeling platform, especially since it was also clear from our own product and market research, that biologists were no more willing to become mathematicians or computer scientists to use models in their own research, than people were willing to become mechanics in order to drive cars.
Take a look for example, at this cartoon a biologist drew of a cell signaling pathway (thanks Russ). It illustrates perfectly the paradigm of an interconnected network of signaling proteins that is in essence, the consensus model in the biology community for how cell signaling works. At some level, it matters little that we cannot consider this to be a realistic, physical model of cell signaling since it implies the existence of static ‘biological circuits’ that in reality do not exist in the cell. In using this model however, biologists are not suggesting this at all. This model does a very good job of representing conceptually, the network of interactions that determine the functional properties of a cell signaling pathway.
There are some obvious intuitive benefits to this model (and many more very subtle ones). For example, if we were to try to trace the network edges from one protein (node) to another and discovered that they were not connected by any of the other proteins, we could infer that none of the states available to the first protein, could ever have an influence on the states of the second.
Here for comparison, is the analogous representation of that same cell signaling pathway, assembled on our cloud computing platform using a set of lexical rules that describe each of the ‘players’ and their interactions. Even the underlying semantic formalism that we used as as a kind of biological assembly language to represent the players (usually proteins) and their interactions, was couched in terms of a familiar and relatively small set of biological events (binding, unbinding, modification etc.) that are in themselves, sufficient to represent almost everything that happens in a cell at the level of its signaling pathways.
In summary then, insofar as computational models facilitate thinking and reasoning about the biological systems we study and collect data from, they can help us much more effectively if they allow us to work in the idioms that are familiar and appropriate to our field. This notion can be more fully grasped by considering its antithesis – the use of ordinary differential equations (ODEs) to model biological systems, which still tends to be the dominant paradigm for biological modeling despite being an exceedingly opaque, unintuitive and largely incompatible approach for modeling systems at a biological scale.
It is also clear that software developers need to work closely with experts who have specialized domain knowledge if they are to create computational modeling platforms that will not only be effective for their particular domain, but also widely adopted by its practitioners. In the case of biology, it was clear to us when we were developing our modeling platform, that its success would depend in no small part, on the appeal that it could make to the imagination and intuition of the biologist. With computational modeling as with software development, even the most meticulously crafted of tools will have little or no impact or utility in its field if a cognitively dissonant user experience results in it rarely or never being used.
© The Digital Biologist