Frequently Asked Questions
CellML is an XML based format designed to facilitate distribution and reuse of reference descriptions of mathematical models.
CellML is primarily designed to describe mathematical models of cellular biological function, but is not domain specific; it can be used to describe models from essentially any field, or biological models at smaller or larger spatial scales. From a mathematical point of view, CellML 1.1 is primarily used to describe models using real numbers, ordinary differential erequations (ODEs), differential algebraic equations (DAEs), and simple linear algebra.
These capabilites are particularly suited to lumped parameter models and descriptions of reaction kinetics and interactions between biomacromolecules, small molecules, etc. As such, CellML is well suited to describe models of a wide range of physiological processes, including metabolism, electrophysiology, signal transduction, cell division, immunology, muscle contraction etc.
For more information regarding the capabilities and competencies of CellML, the reader is referred to the publication "CellML and associated tools and techniques" by Garny et al.
CellML is designed to facilitate distribution and reuse of models. If you are a modeller, encoding your model in CellML means that you can easily share your work in a manner that is platform and application agnostic. CellML is highly modular, meaning that it is easy to build systems from pre-existing models. CellML models can also be hosted at the CellML Model Repository, providing a permanent URL to reference. Creating a description of your model in CellML will enhance the impact it has within the scientific community.
Representation of spatiality is not currently possible from within CellML, although work is underway to tie CellML into other Physiome Project formats which can represent spatiality, such as FieldML.
Please see the CellML 1.1 Specification at http://www.cellml.org/specifications/cellml_1.1 for more information.
CellML provides a 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.) 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 primarily aimed at exchanging information about pathway and reaction models.
The SBML FAQ's answer to this question is also relevant here.
It should be noted that CellML and SBML aim to address similar goals, but diverge with respect to their core competencies. The two communities have been involved in each other's development since their respective inceptions, and we continue to have a close working relationship. The CellML and SBML development teams are actively discussing how the two languages can be made to work together.
Yes, you can translate SBML to CellML, albeit poorly. An XSLT based translator is available but only simple reaction-based models can be translated. A prototype tool that uses a Ruby script to translate SBML models into mathematically valid CellML descriptions is also in the works.
Development of a comprehensive tool able to provide seamless round-trip translation is a high priority, and is the subject of an ongoing collaboration between the CellML and SBML communities.
Yes. COR can be used to translate CellML into C, C++, Delphi, Fortan77, Java, MATLAB, Pascal and Tex. The CellML API's CellML Code Generation Service is also able to generate C and MATLAB code, with more languages planned for the future.
CellML is primarily a description and exchange language, so to use CellML, simply define the parameters and equations of your model and you are ready to share your description. Any CellML compatible editing and/or simulation environments can then be used to work with the model.
CellML models can be written and edited using a standard text editor, but there are a number of tools available to facilitate the process and make it considerably easier. PCEnv (Physiome CellML Environment), COR (Cellular Open Resource), and JSim are three such tools which offer CellML editing interfaces.
A number of tools are able to simulate CellML models. PCEnv, COR and JSim are full environments which allow the user to create, edit and simulate CellML models. Tools such as CellMLSimulator, which is a more lightweight simulator based on the CellML API, are also able to solve CellML models.
The CellML API provides a powerful platform for developers to interface with, build and simulate CellML models, as well as RDF parsing functionality and more. The CellML API is written in C++.
The CellML API is currently accessible from C++, but creating Java bindings to the API is a high priority for the CellML development team.
If you would like to reference CellML, please reference either of the following papers:
Cuellar, A.A., Lloyd, C.M., Nielsen, P.F., Bullivant, D.P., Nickerson, D.P. and Hunter, P.J. "An overview of CellML 1.1, a biological model description language" SIMULATION: Transactions of The Society for Modeling and Simulation International. 2003 Dec;79(12):740-747.
Lloyd CM, Halstead MD, Nielsen PF. "CellML: its future, present and past" Prog Biophys Mol Biol. 2004 Jun-Jul;85(2-3):433-50.
The CellML Model Repository at http://models.cellml.org offers hundreds of freely available, curated descriptions of biological models.
The CellML Model Repository is a centralised, curated online repository where the cellular modelling community submits CellML models to facilitate their distribution and reuse. The repository uses a code versioning system in a similar manner to repositories such as Sourceforge to provide extensive version and modification history tracking of models.
Yes - you will need to register with the site first.
Absolutely. The CellML Model Repository provides users with permanent URLs for models which they can reference. Access controls are also available to allow reviewers to access a model without exposing it to the public.
The CellML Project does not assume the copyright of these models, so this question is probably best directed to the model author(s). It is, however, a reasonable assumption to make that you be able to build on the work of other researchers, if due credit is given. If you would like to reference the CellML Model Repository please reference the following publication: Lloyd, C.M., Lawson, J.L., Hunter, P.J. and Nielsen, P.F. "The CellML Model Repository." Bioinformatics. 2008 September;24(18):2122-2123.
The CellML tutorials introduce most of the fundamental concepts of CellML.
(Where "flat" refers to the CellML concept of listing all of the components (in any order), and then later grouping the components together and "hierarchical" refers to the listing of components so that they are nested, allowing the branching to be inherent in the file layout.)
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 specification will possibly define other grouping relationships, perhaps for associating properties with a group of components. (You may also do this presently 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.
The primary difference between CellML 1.0 and CellML 1.1 is the addition of the 'import' element. This element facilitates modularity and reuse of models and model components by allowing a modeller to import models described within other files. In such a manner, large collaborative networks of models can be created out of modular components, rather than monolithic structures. A tool that facilitates the interconversion of models written in CellML 1.0 and CellML 1.1 is available.
For more information on the differences between the two versions of CellML, please see the "Differences between the 1.0 and 1.1 specifications" document.
Metadata is data about data. CellML Metadata allows a modeller to annotate their model with information about its provenance their name and contact, the names and contacts of contributors, the citation if relevant, descriptions of the model, modification comments, information about the license under which the model is distributed. Elements of the model can also be associated with terms that describe the biological relevance of those elements. For example, a variable called 'A' representing the concentration of ATP might be annotated with terms asserting that the variable represents a concentration, of a small molecule species, which has the chemical name 'adenosine triphosphate.' CellML Metadata can also inform tools how best to simulate a model and graph the results of the simulation.
We aim to keep the core CellML specification as clean as possible, defining only how to represent basic, domain aspecific elements, and the mathematics which describes the interactions of these elements. All other information about the model is expressed as metadata. This approach is followed to allow CellML to be as extensible as possible by defining new metadata within formats such as constrained vocabularies (such as RDF) and ontologies (such as OWL).
CellML is designed to facilitate modular descriptions of models. The 'import' element in CellML 1.1 allows users to easily connect hierarchies of models together by pointing to the location of the files describing those models. This means that each module can be maintained independently and keep its own modification history and metadata without affecting other modules.
Yes. CellML Metadata allows modellers to link CellML elements to URIs defining resources, including constrained vocabularies, ontologies etc. An OWL serialisation of CellML is under development, which will allow linking of OWL representations of both CellML elements and metadata constructs to resources, providing much more flexibility than the current scheme.
Yes. Both the core CellML Specification and the CellML Metadata specification are under continual development. A list of proposed additions / developments to CellML 1.2 can be found here.
Certainly, please submit your ideas to the cellml-discussion mailing list. It can be helpful to search the tracker before submitting feature requests; it may well be that your requested feature is already planned or in development.
Yes, both PCEnv and COR allow users to validate their models against the CellML specification. There is also a validation service within the CellML API.
Yes, our MIME-type is application/cellml+xml
The RFC entry is: RFC4708 - CellML Media Type
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 consisted of David Bullivant, Warren Hedley, and Poul Nielsen, at the time (~1998) all members of the Department of Engineering Science at the University of Auckland. The language was based upon the emerging XML specifications developed by the World Wide Web Consortium. Existing XML-based languages were leveraged to describe the mathematics (content MathML), metadata (RDF), and links between resources (XLink). The working group collaborated with Melanie Nelson and a number of other researchers at Physiome Sciences Inc. to draft the initial CellML 1.0 specification published in early 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.
The CellML project is run as an open democracy by the community who develop and use it. Senior members of the community from Oxford University and The University of Auckland currently form the core group that drives work on the specification and other important resources such as cellml.org, the CellML Model Repository and the CellML API.
The CellML community is managed by a Steering Group who oversee the community's constituent projects to ensure compatibility and coherency. Under this group sit a number of domain specific working groups composed of individuals with interest and expertise in relevant areas. The community at large is consulted on all major decisions involving the fate of CellML associated resources that it has a stake in.
The CellML project hosts an annual workshop to showcase developments and to discuss issues related to the CellML Specifications and management of the community. The CellML Workshop also functions as the annual general meeting of cellml.org
The IUPS Physiome project is an ambitious, international collaborative project with the goal of creating comprehensive, quantitiative models of physiology using a multiscale approach, and making these models freely available to the scientific community. CellML fits into The Physiome Project at the cellular scale, and is designed to easily tie in with models at the tissue and/or molecular scales.
The CellML tracker is a component of the Bugzilla-based Physiome Tracker, which is used to identify, discuss and track issues related to the CellML project. It can be found at https://tracker.physiomeproject.org/.
The CellML project is built by an open, democratic community on an open source / free ethic. Any and all contributions are welcome, and we encourage you to get involved. The best way to do this is by sending a message introducing yourself to our mailing list email@example.com - you can join the list at http://www.cellml.org/mailman/listinfo/cellml-discussion.