Background

This material correspends to an early release of version 3 and some of it is out of date. It is still included here for reference while the new documentation is being written.

Design Considerations

Catacomb 3 is designed to address two big problems that hinder the effective use of biological models:

• Many forms of modeling are close to programming, which means they are only accessible to small number of people. But ideally, everyone who studies biological systems should be making some sort of formal model. These should firm up the the mental models that people already have: computational systems are much better then mental models at giving quantitative results and following complex interactions of many components.
• Models tend to be tied to implementations so it is hard to move models between modelling systems or to mix components built for different systems.

The resolution of both these problems follows the standard paradigm of separating out the different aspects of a model. Part of the work behind a model involve writing software to perform numerical calculations; part of the work is in choosing a good structure and parameterization for a particular class of models; and part is in actually making models themselves - filling out structures and assigning values to parameters to represent particular things.

This closely matches the separation represented by XML (for actual models), XML schema (for model types) and programming languages (for model implementation). However, XML is a technology for IT experts, and XML schema even more so. The challenge in building a modeling system is to give access to the first two levels without depending on specific IT skills.

This has the benefit of modelling to be accessible to people who do not have the particular IT skills. But even for those who do, it is much better to think about how to structure a model without worrying at the same time about implementing it in some particular system. Moreover, models that are free from implementation details or system-specific constraints can be expected to last longer and be more widely used.

A Bit of History

This bit will be about Catacomb 2 and how the structures were hard-coded as java classes (ie created by programmers) with a GUI to create instances and connect them together. Lessons learned, etc - more to come...

The Catacomb 3 approach

This will explain the data model of the data model, how it is actually defined in itself, why this is a good thing, and why it can be confusing. Also, how code is generated from user-defined structures and what should (and more importantly shouldn't) be involved in implementing a model in code.

For now, the types section covers some of this from a more hands-on perspective.