Introduction
It’s pretty widely recognized in the scientific community that computer models, or what I prefer to call programmatic models, have a number of issues that need to be addressed before this type of model can be taken seriously as a research tool. Some of these issues seem philosophical at first, but I suggest that they mostly boil down to pragmatic research methodology questions that need to be resolved from that vantage point.
Very broadly, beliefs about computer modelling often include the following:
-computer models are not as rigorous or functional as mathematical models,
-computer models are too opaque, which makes them difficult to understand and validate,
and
-computers models are implemented using technology (programming languages, software, hardware) that is constantly in flux, and, as a result, these models are too ephemeral and disposable to make lasting or substantial contributions to scientific research.
As part of the exploitation research project, we want to address these outstanding modelling methodology issues. In this article I’ll provide an update on some of our progress on this front, and a sketch of the strategy we’ve been developing to surmount these challenges.
Background – The Xholon Framework
One strategy we’ve pursued throughout the project is the use of Ken’s Xholon, which, as mentioned in a previous blog article, is based on two main conceptual elements: the idea of holons, developed by Arthur Koestler, and the idea of interacting entities, or objects. The concept of interacting objects is prevalent in computer theory, but was notably promoted by the ObjecTime commercial product and related language (eventually renamed ROOM, for Real-Time Object-Oriented Modeling) in the form of interactions of agents via message-passing.
ObjecTime was used for modelling the real-time behaviour of event-driven systems like computer networks. It modelled these systems using the concept of actors that connected to and communicated with each other by passing messages via ports. The actors themselves were state machines that could be connected to other agents and then collectively used to model and understand the behaviour of dynamic networks.
Xholon was originally created as an open-source replication of ObjecTime. However, in addition to replicating the ObjecTime conceptual framework of actors and message-passing, Xholon also incorporated the idea of holons, which are objects that are at the same time part of another object but also themselves a whole object (e.g. A wheel is part of a car, but also a whole object in and of itself).
Due to this part-whole focus, Xholons, which are intended to act as the most basic or abstract type of object in the Xholon implementation, are situated by default in hierarchies, which can be represented mathematically as DAGs and programmatically as binary tree data structures (we will subsequently refer to these structures generally as ‘trees’). All Xholon objects are set up to have children, siblings and a parent. They also have ports, which do not have to be used, but can optionally connect and pass messages to Xholon objects either within or outside of a specific tree, extending the overarching graph structure from a collection of DAGs to a more complex connected graph structure.
Ken initially implemented Xholon using Java. As Java objects, Xholons automatically gained the ability to associate additional variables and functions with each Xholon object.
Ken has continuously updated the Xholon implementation using different languages (e.g. Javascript) and programming practices (e.g. functional programming) as technology has developed. This has been necessary to ensure the Xholon implementation’s ongoing usability and ability to integrate with newer technologies. It also highlights the importance of having an implementation independent conceptual modelling framework upon which to draw when creating models that are eventually to be implemented programmatically in, for example, the current implementation of Xholon or another implementation framework.
Conceptually speaking, all of the specific implementations of Xholon have preserved the two main Xholon Framework concepts: (1) objects are arranged in binary trees and (2) objects can connect to other objects either through the parent child relationships established by these trees or via ports, which establish additional connections between particular objects. In addition, it is expected that at least one of the trees of objects will either implicitly or explicitly capture the part-whole relationship between objects. Any implementation meeting these structural specifications would be considered to be consistent with the current version of the Xholon Conceptual Framework.
The Conceptual System Modelling Framework
While working over the last several years to develop multi-agent models in the Xholon Implementation, we have also been motivated by the need for consistent and explicit model representation. As a result, we have aimed to make the models we are developing implementation independent – i.e. we want to be able to provide a conceptual, human readable, but still rigorous description of a model that is then readily and consistently implemented programmatically.
The goal is for the conceptual description itself to be independent of any particular computer language or software implementation but precise enough to be equivalently implemented in different implementation frameworks. This effort has steadily moved us towards a modelling strategy that has the potential to overcome some of the larger programmatic modelling issues that I’ve stated above.
In order to separate the model itself from the code implementing the model we have used the consistently present elements of Xholon to form the basis of a more specific and constrained conceptual framework for modelling systems. We’re calling this conceptual offshoot of Xholon the Conceptual System Modelling Framework (CSMF). CSMF is more constrained and less abstract than the Xholon Conceptual Framework, but still general enough to conceptually model a wide diversity of systems, if not all systems.
CSMF is centred around four conceptual tree structures. The Inheritance Hierarchy (tree) represents object types and sub-types: the IS-A relationship. It is a legacy of object oriented class inheritance structures present in all object oriented programming languages. A second tree – the Composite Structure Hierarchy – represents a hybrid relationship IS-CONTAINED-BY/IS-A-PART-OF relationship. The inclusion of this tree is motivated by the holon concept.
The third and fourth trees, the Object Properties tree and the Actions tree, explicitly define object properties and actions. The availability of these final two trees is implicit in object oriented implementations of Xholon. However, their explicit inclusion in the CSMF is important because it allows a particular model description to be unambiguously implemented using any computer language or modelling environment (e.g. Netlogo, JavaScript frameworks, non-object oriented programming environments).
Creating an implementation independent modelling description has not been our only goal. With the conceptual modelling framework established, we have also developed a strategy for methodically transforming the models described by the CSMF into mathematical models. Then, we have developed a strategy for turning the resulting mathematical models into a marked up version of the model in question that is machine readable, through the use of MathML. Finally, we are currently developing a strategy for translating this machine readable MathML version of the mathematical model into a specific implemented programmatic model (e.g. an implemented Xholon model).
A concrete example of this process will be provided in a subsequent article. I’ll conclude my current article by highlighting the ways in which this process addresses some of the concerns about computer models that I first noted above – specifically: model rigour, model transparency and model longevity.
The Conceptual-Mathematical-Implementational Chain
There has been a longstanding debate about whether or not computer models are functionally equivalent to mathematical models. As well, putting this first issue aside and assuming for the moment that these two types of models can be considered to be functionally equivalent, there is further the question of whether or not the equivalent mathematical model to a particular programmatic model can ever be considered to be a good mathematical model, for some definition of ‘good mathematical model’. I have written about this in a previous blog article.
The exercise we have undertaken shows that by using the CSMF it is possible in a methodical way to map the resulting conceptual model for a particular system or situation directly onto a mathematical version of the model. If we were to assume that all computer models (or even more generally, all models) could be represented by CSMF (which is admittedly a large assumption), then being able to translate CSMF models into mathematical models would mean that all computer models could be turned into mathematical models.
On the one hand, this is not a particularly exciting a claim, since at some level we know that computers are based on numbers and logic, and therefore must, in an almost trivial sense, be translatable into mathematical models. Here, however, we are suggesting this is also the case at a more meaningful and comprehensible level of abstraction.
Our exercises in this area suggest that the CSMF structure is mainly a more compact and cognitively penetrable strategy for representing the sort of mathematical models that would quickly become unwieldy if created solely as mathematical models, due to the large number of related sets of variables that would need to be represented independently and explicitly in the mathematical model, relative to how they are represented on the CSMF and implemented models. We cannot definitively confirm this conjecture, as we are not mathematicians. However, if this is correct, the CSMF could effectively act as a shorthand for the mathematical representation of a system.
At the same time, the mapping we’ve developed does suggest that, if this particular mapping is used, the resulting model would be one that mathematicians would consider to be an inelegant mathematical model, at best. At worst, they may also consider the resulting mathematical model to be effectively unusable in any meaningful sense. In particular, it’s most likely that any given resulting mathematical model generated in this way would not consistent of solvable systems of equations, that could in turn result in overarching generalizable insights that are true for any and all values of the variables involved.
That said, there are perhaps an increasing number of mathematical models for which this is also true, as increasingly complex systems are modelled. It may just be that this is the nature of complex models more generally. At the same time, it is also likely that the strategy we have developed here is not the only mapping strategy, and, given that we are not mathematicians, it is also with high probability not the best mapping strategy. Thus there is hope that, with the right type of mapping, the mathematical models generated may become more elegant.
As well, in the same way that computer generated logical proofs are not the most elegant, but still get the job done, we suggest that, inelegant though a resulting model may be, it will still have certain useful properties related to how the model will be programmatically implemented. Specifically, the proposed strategy for translating conceptual and programmatic models into mathematical models may solve the issue of longevity of programmatic models.
One of the issues with computer models, as stated above, is that they are concretely implemented on a specific piece of hardware using a particular version of a particular programming language. One outcome of this implementation is that it is often difficult for anyone other than the specific person programming the model to understand what the model is representing, or what commitments the model is making about the nature of the system being modelled. Another outcome of this situation is that very quickly the model itself becomes obsolete and unusable. These two aspects combined make most researchers very skeptical of the long-term usefulness of specific computer models.
Mathematical models avoid these issues in two ways. First, mathematics is extremely rigorously defined, so while the mapping between the system and the mathematical model may be contentious, exactly what the mathematical model itself is expressing is not. Second, mathematics is not going to go out of style, or be supplanted by an entirely new technology or cognitive tool, any time soon.
Given all of this, if it were possible to translate a mathematical model methodically into a specific implemented computer model, this would alleviate some of the issues currently associated with computer models. The mathematical model could be translated into multiple equivalent computer models, all of which should essentially perform in the same way. It would be even better if this could be done automatically, as then any time the hardware and software changed, the model could be reliably re-implemented.
One way to achieve this is to make the mathematical models themselves machine readable, which is a goal arguably shared by the people who developed Math Markup Language, or MathML. The MathML framework was originally developed to make the display of mathematical equations easier on webpages. However, in addition to the version of it called ‘presentation MathML’ a second version, ‘content MathML’ was created to act as a semantic mark up language. The goal of content mathML was to label strings in such a way that they could properly be interpreted as mathematical objects.
Because of this, content MathML has the ability to act as a bridge between mathematicians and programmers and, by extension, mathematical models and programmatic models. A mathematical model that has been marked up into MathML can be rigorously translated into an implemented program that can run the mathematical model.
Ken and I do not yet (and most likely will never) have rigorous proofs to show that all of reality can be represented by CSMF models, that all CSMF models can, in turn, be represented mathematically, that all mathematical models can, in turn, be represented by MathML and that all MathML marked up models can, in turn, be implemented programmatically. As well, even if this chain were to be trivially true (because, for example, we know that computers run on 1 and 0s and logic gates) it’s possible that it might not be usefully true. Nonetheless, even if it is only partially true and partially feasible, it would still usefully increase the levels of rigour, transparency and longevity of computer models.
In a subsequent article I will provide some concrete examples of how this modelling chain plays out.