The CellML language grew out of the work of a Masters student at the University of Auckland who developed an XML-based format for storing configuration information for a computer-based biological model. In 1998, engineers at the University of Auckland's Bioengineering Group and scientists at Physiome Sciences recognized the potential of XML for the exchange of cellular models between different simulation applications and databases. They started work on the language now known as CellML. One of the initial project aims was to reduce inconsistencies between the published versions of models and their implementations by allowing authors to submit their models to an online repository for validation by other researchers.

The first models created with CellML were electrophysiological models of heart cells. The language has now been generalized with the aim of being able to specify virtually any type of cellular-level model. In generalizing the language, CellML is now capable of describing many types of mathematical models.

CellML has been particularly successful at enabling modelling at the cellular level. Electrophysiological, signal transduction, and metabolic pathway models have been created using CellML. Mechanical models (such as those that simulate heart muscle cell contraction) are another area of study.

Scientists from the University of Auckland, with input from the biological community at large, are:

CellML provides a very powerful and general way of describing most classes of cellular model. Its focus is on a component-based architecture (facilitating easy re-use of models and parts of models) and the mathematical description of models. A CellML document defines the minimum amount of information needed to properly archive models and to run simulations, leaving a lot of work for processing software in terms of rendering, and simulation configuration. Other languages in this field (see the related efforts page for more details) focus on a specific problem or are tailored to a specific piece of software.

The language most similar to CellML is the Systems Biology Markup Language (SBML) being developed by a forum of software developers led by the Caltech ERATO Kitano Systems Biology Project. CellML and SBML are both XML-based exchange formats for describing cellular models. CellML describes the structure and underlying mathematics of cellular models in a very general way and has facilities for describing any associated metadata. SBML is aimed at exchanging information about pathway and reaction models between several existing applications.

The CellML and SBML development teams are actively discussing how the two languages can be made to work together. It is anticipated that it will be reasonably straightforward to convert pathway model definitions between CellML and SBML without losing information about model structure and function.

Over the next year, the CellML team will be developing software capable of editing and running CellML models. We will continue development of the CellML Metadata structure. We are also in the middle of discussions concerning the next level of CellML which will include separate ontologies. If you are interested in becoming involved, see the page of this website.

A model is a network that may have numerous hierarchical relationships defined over it, where these relationships will not necessarily coincide. Consider a signalling pathway with some abstract relationships in it that spans numerous regions which occur in different parts of the geometric hierarchy (i.e, in different physical locations in the cell). In such a case, it would be difficult if not impossible to construct a uniform hierarchy without conflicts. The principal hierarchy in an electrophsyiological model should be geometric, as well. But a modeller may wish to use an abstract relationship between components (such as encapsulation) to hide unnecessary complexity from the user within a single component.

Also, in the future, the CellML team will possibly want to define other grouping relationships, perhaps for associating properties with a group of components. (You may also do this now using a relationship in an extension namespace.)

No, connections themselves do not have direction. A connection can be made between any two components, and since the connection does not have direction, the values of the attributes component_1 and component_2 of the nested <map_components> element in a <connection> can be in any order. Which component the modeller designates as the first component and which is the second component is an arbitrary designation, just so long as the <map_variables> element belonging to the same <connection> element contains a variable_1 attribute with the value of a variable defined in the component listed as component_1 and a variable_2 attribute with the value of a variable defined in the component listed as component_2.

Though connections do not have direction, the variables mentioned do have a direction. The direction is implied in the <variable> declaration by the use of the public_interface or private_interface attributes.

An interface in CellML is a component's door to any other component. An interface can be public or private. In CellML a private interface only occurs between a parent component and its encapsulated child. A parent component will send and receive variables through a private interface to and from the encapsulated component. However, the encapsulated child will send and receive variables to and from its parent component through a public interface. The encapsulated child does not know it is encapsulated and does not differentiate between its parent and its siblings. All other interfaces between one component and another are public.

In the forward direction, the reaction rate will have a negative value and the stoichiometry will always be a positive value. A reactant's delta variable will be negative because the delta variable is the change in concentration divided by the change in time, or in a simplified equation:

Equation (1)

Since the reactant is being consumed during a forward reaction, the initial concentration will be larger than the final concentration resulting in a negative delta variable. Thus, the implied mathematical relationship between the delta variable and the rate variable for reactants is correct without the negative multiplication factor, while the products, with a positive delta variable, must have the negative multiplication factor in its implied mathematical relationship between the delta and rate variables.

Development of the CellML API is currently underway. To follow progress of the API, see the API Development page. You can also visit the Tools section of the website to download available CellML tools.

See Appendix A of the CellML 1.0 Specificiation for a detailed explanation of how to use the CellML 1.0 DTD to validate models.

The figures that appear in the documentation in the examples section of the CellML website were drawn by hand with a vector drawing graphics package called XFIG.