Meeting Minutes 11 September 2000

Get the PDF!

1  Summary

The 11 September meeting was fairly muted; Warren was even accused of "not being his usual self", whatever that means. However some fairly good work was achieved. Perhaps most important was a proposal for specifying the mathematics underlying a pathway model — a method so inelegant and counter-intuitive it's just bound to be controversial and get changed again in the near future. Some specific methods for solving the requirements proposed in the initial CellML requirements document were also discussed. We also started work on a new scheme for capturing geometric and encapsulation relationships based on grouping.

2  Pathway Model Math

Although some attractive diagrams of pathway models had appeared in the specification and meeting minutes generated before this point, the Auckland team had not devoted any serious attention to how one might go about actually describing the math underlying a pathway model. Even the most basic model (as depicted in Figure 1) caused us quite a few headaches, because we had to consider the following points:

• Variables should be declared in the appropriate place. After all, we want model definition to be reasonably intuitive.
• The value of variables can only be changed in the component where they are declared. This makes validation a hell of a lot easier.

Figure 1 An extremely simple reaction pathway taking two reactants A and B, and producing a single product C.

So consider the simple pathway A+B -> C, and imagine that this is part of a much bigger pathway model, where A and B are in fact the products of other reactions, and C is an input to several other reactions. It makes sense to declare a component to contain each variable, where for example the value of each variable corresponds to the concentration of some ion in the component. Each variable is declared with a role value of out in its respective component. The reaction in our pathway depends on the values of A and B (at the very least the reaction requires that the concentrations of A and B be greater than 0), so these variables must be declared with a role of in on the pathway. The interesting part comes when we consider that the pathway modifies the values of A, B and C. The intuitive and elegant approach to this is to put the equation A+B -> C into the pathway, but we're not allowed to modify any of the variables in the pathway, so this won't work.

A possible solution can be nicked from the field of electro-physiological modelling. Consider the case of calcium concentration in the intra-cellular subspace of some typical EP model. Numerous currents in the extra-cellular membrane and internal buffering mechanisms all affect the calcium concentration. The change in this variable over time is the sum of all of the currents in to and out of the component. The actual currents themselves are calculated in the appropriate components, perhaps the individual channels in the membrane, and passed back to the intra-cellular subspace.

In pathway modelling, the analogy is to only calculate currents in pathways, and sum these currents within a reactant. So why not call these currents that occur in the reaction component delta_A, delta_B and delta_C. These are calculated in the reaction so must be declared with role out there, and role in in the reactant components. The actual math in the reaction component might look like this (where we use code instead of MathML for simplicity):

if ((A > 0) && (B > 0))
{
  delta_A = delta_B = -1.0*rate_constant;
  delta_C = rate_constant;
}
else
{
  delta_A = delta_B = delta_C = 0;
}

In the reactant components, the "currents" from multiple reactions are given different variable names (this is handled by the mapping in the connections), and conservation laws are written as a sum of these currents. For example, in the component corresponding to reactant A, if the current from the reaction previously defined is mapped to a variable called delta_A_abc, we might have:

dA/dt = delta_A_abc + delta_A_efa;

Note that some information about the direction of a pathway can be obtained by looking at which connected reactants provide inputs to a pathway. Any connected component that isn't providing variables is presumably an output. A better approach to classifying pathways using the ontology will be presented in some upcoming meeting minutes.

3  Some Requirements Issues

The conversion of the requirements document from a certain proprietary format into a free structured document format raised a few specific issues. Firstly, it was speculated that property grouping and re-use could be handled by a generic re-use mechanism like CRIM (proposed for FieldML in April 2000). CRIM needs a bit of a review with regard to the CellML requirements.

Requirement 7 alludes to variable scope, lifetime and access privileges. Access privileges appear to be handled by the role property of a variable under the current system. Lifetime can probably be evaluated by software, and is not something that should have to be specified in a model definition. Scope (i.e., the components which are allowed access to a certain variable) is best handled in the ontology — this kind of rule is not part of the essential model information.

Stochastic mathematics and property inheritance were also identified as important issues, but were dealt with at that meeting, pending some questions to be put to the Physiome team at the upcoming phone conference.

4  Grouping

Some form of component grouping was proposed by Poul to try and make the specification of geometry, encapsulation and variable (i.e., inheritance) hierarchies a bit easier to see. One could write a lot about the grouping ideas that were bandied around at this meeting but the opinions of the Auckland team have changed so radically over the 24 hours between the meeting and the time this document is being written, it's not actually worth committing them to paper. Have a look in subsequent meeting minutes.