# CellML

CellML is an XML based markup language for describing mathematical models. Although it could theoretically describe any mathematical model, it was originally created with the Physiome Project in mind, and hence used primarily to describe models relevant to the field of biology. This is reflected in its name CellML, although this is simply a name, not an abbreviation. CellML is growing in popularity as a portable description format for computational models, and groups throughout the world are using CellML for modelling or developing software tools based on CellML. CellML is similar to Systems Biology Markup Language SBML but provides greater scope for model modularity and reuse, and is not specific to descriptions of biochemistry.

## History

The CellML language grew from a need to share models of cardiac cell dynamics among researchers at a number of sites across the world. The original working group formed in 1998 consisted of David Bullivant, Warren Hedley, and Poul Nielsen; all three were at that time members of the Department of Engineering Science at the University of Auckland. The language was an application of the XML specification developed by the World Wide Web Consortium – the decision to use XML was based on late 1998 recommendations from Warren Hedley and André (David) Nickerson. Existing XML-based languages were leveraged to describe the mathematics (content MathML), metadata (RDF), and links between resources (XLink). The CellML working group first became aware of the SBML effort in late 2000, when Warren Hedley attended the 2nd workshop on Software Platforms for Systems Biology in Tokyo.
The working group collaborated with a number of researchers at Physiome Sciences Inc. (particularly Melanie Nelson, Scott Lett, Mark Grehlinger, Prasad Ramakrishna, Jeremy Rice, Adam Muzikant, and Kam-Chuen Jim) to draft the initial CellML 1.0 specification, which was published on the 11th of August 2001. This first draft was followed by specifications for CellML Metadata and an update to CellML to accommodate structured nesting of models with the addition of the <import> element. Physiome Sciences Inc. also produced the first CellML capable software. The National Resource for Cell Analysis and Modeling (NRCAM) at the University of Connecticut Health Center also produced early CellML capable software called Virtual Cell.
In 2002 the CellML 1.1 specification was written, in which imports were added. Imports provide the ability to incorporate external components into a model, enabling modular modelling. This specification was frozen in early 2006. Work has continued on metadata and other specifications.
In July 2009 the CellML website was completely revamped, and an initial version of the new CellML repository software (PMR2) was released.
In July 2020 the CellML 2.0 specification was published, in which resets were added. Resets allowed for setting the value of a variable to any value when a prescribed condition is met. The directionality between connections was dropped to aid in the reusability of components, and the definition of units was restricted to the model only.
In support of the CellML 2.0 specification the libCellML project was started in 2015 to provide application developers with a model based API C++ library. The library was quickly expanded to provide support for Javascript, Julia, and Python. The latest release of the software is version 0.5.0. The 0.5.0 version of the library supports the majority of the CellML 2.0 specification, it also supports reading of CellML 1.1 and CellML 1.0 models. A major point of interest is that the libCellML library does not support writing to older CellML standards.

## The structure of a CellML model

A CellML model consists of a number of components, each described in their own component element. A component can be an entirely conceptual entity created for modelling convenience, or it can have some real physical interpretation (for example, it could represent the cell membrane).
Each component contains a number of variables, which must be declared by placing a variable element inside the component. For example, a component representing a cell membrane may have a variable called V representing the potential difference (voltage) across the cell membrane.
Mathematical relationships between variables are expressed within components, using MathML. MathML is used to make declarative expressions (as opposed to procedural statements as in a computer programming language). However, most CellML processing software will only accept a limited of range of mathematics (for example, some processing software requires equations with a single variable on one side of an equality). The choice of MathML makes CellML particularly suited for describing models containing differential equations. There is no mechanism for the expression of stochastic models or any other form of randomness.
Components can be connected in other components using a connection element, which describes the name of two components to be connected, and the variables in the first component which are mapped to variables in the second component. Such connections are a statement that the variable in one component is equivalent to another variable in another component.
CellML models also allow relationships between components to be expressed. The CellML specification defines two types of relationship, encapsulation and containment, however more can be defined by the user. The containment relationship is used to express that one component is physically within another. The encapsulation relationship is special because it is the only relationship that affects the interpretation of the rest of the model. The effect of encapsulation is that components encapsulated beneath other components are private and cannot be accessed except by the component directly above in the encapsulation tree. The modeller is free to use encapsulation as a conceptual tool, and it does not necessarily have any physical interpretation.

## Specifications

CellML is defined by core specifications as well as additional specifications for metadata, used to annotate models and specify simulations.

### CellML 1.0

CellML 1.0 was the first final specification, and is used to describe many of the models in the CellML Model Repository.
CellML 1.0 has some biochemistry specific elements for describing the role of variables in a reaction model.

### CellML 1.1

CellML 1.1 introduced the ability to import components and units. In order to fully support this feature, variables in CellML 1.1 accept variable names as initial values.

### CellML 2.0

CellML 2.0 made some significant changes, the changes are listed below:
* Introduced the ability to reset state variables.
* Dropped the directionality in connections.
* Units can now only be defined at the model level.

### Metadata specifications

CellML has several metadata specifications, used to annotate models or provide information for running and/or visualizing simulations of models.
* The metadata 1.0 specification is used to annotate models with a variety of information; relevant references, authorship information, the species the model is relevant to, and so on.
* Simulation metadata provides the information required to reproduce specific simulations using a CellML model.
* Graphing metadata provides information to specify particular visualizations of simulation output, for example to reproduce a particular graph from a paper.

## CellML.org

CellML.org aims to provide a focal point for the CellML community. Members can submit, review, and update models and receive feedback and help from the community. A CellML discussion mailing list can be found at CellML-discussion mailing list. The scope of this mailing list includes everything related to the development and use of CellML.
A repository of several hundred biological models encoded into CellML can be found on the CellML community website at CellML Model Repository. These models are actively undergoing a curation process aiming to provide annotations with biological ontologies such as Gene Ontology and to validate the models against standards of unit balance and biophysical constrains such as conservation of mass, charge, energy etc.