Data Models |
|
|
As discussed in the background section, one of the big challenges for a modeling system is to separate out the different aspects of a model into independent layers. The structures used to represent and store a model should have nothing to do with any modeling system or implementation. Ideally, the same should also be true of the structures used to define classes of models. Catacomb 3 makes a big improvement in this direction over earlier versions. Here we first consider the situation with Catacomb 2 and then look at what is new in version 3. What was wrong with the old data modelIf you look at a model saved by catacomb 2, you will find that it is moderately readable - it contains an indented tree with chunks of text like <catacomb.channel.KSchannel> and <conductance>1.234</conductance>. This has some benefits of readability, but it doesn't solve the portability problem. The object names refer to Java classes in Catacomb's own implementation, and the field names are actual java variable names. In effect XML is used as a convenient serialization of an internal object tree. (On a historical note, this aspect of Catacomb 2 is only cosmetically different from Catacomb 1, which used the c-like struct definition syntax from Yorick, probably the best interpreted language for scientific computing). The good thing is that this is easy to implement, but there are at least three reasons why it is not a good long-term strategy:
A better approachIn contrast, a model in Catacomb 3 looks about as clean and generic as you can get while still using XML. [needed: some embedded examples] There is no extraneous meta-data. Everything in there is required for the biological component being described. Nothing seems to be specific to the fact that this is a Catacomb model. Most important, though, the text used for the names of elements and attributes is also independent of Catacomb. These are chosen by whoever specified the particular class that the model belongs to (what you do when you create components on the "components" tab of the Catacomb 3 user interface.). So how are the type specifications stored? [needed: examples] These also have no application specific meta-data, but they do use a set of element and attribute names that is built into Catacomb. The element names include Type, Set, Table, List, Int, Float, Boolean, TextLine, TextBlock, Reference, QuantifiedList, Extern, Choice, Color, Plug and Socket. For each of these there is an XML specification, using the same elements themselves, built into Catacomb (a lot of catacomb is written in XML, including all the user interface layouts [needed: publish these]). In effect, the above terms are Catacomb's choice of tags for defining general purpose object trees. It should be a simple matter to write XSL transforms or equivalents to map specifcations stored using these terms into the structures used by another modeling system provided it has a comparable level of abstraction in its model structure. Mapping to systems with any lower level of abstraction is likely to require a lot of work. And the point?In summary, once you have taken the time and trouble to develop a good parameterization within Catacomb for some class of biological entities, then you should never have to do it again. You may well need a different representation of the same thing one day, but it should be much easier, practically and technically, to generate the new from the old one automatically rather than to start again from scratch. This means first that it is well worth creating high quality, well documented components for use in models. And second, that you can hope for more incremental modelling work, where new models build up from existing ones, rather than the more common case where each model starts from scratch and much time is spent repeating the same work. Data model details[needed: about the other bits - plugs, sockets, connection flavors, implementation specifications etc. ] |
|
Catacomb 3