CellML Metadata Roadmap

This is a draft, work-in-progress roadmap for the CellML Metadata Specifications (#2 - revised)

Roadmap for CellML Metadata Specification Development

This roadmap primarily focuses on what should be added or rewritten to the current draft CellML Metadata 1.0 Specification

Draft 2, post discussion with Andre and Tommy in Singapore.

CellML Metadata Specification 1.0

=> fix link, finalise as is.

CellML Metadata Specification 1.1

Prime directives:

  • Convert all as much metadata to Dublin Core compliance as possible. t
  • Implement modular specification structure
  • Achieve final draft of Metadata 1.1 specification by 4th April 2009 for presentation at CellML Workshop 2009

  • proposal to split into an 'umbrella' specification and submodules
    • graphing
    • simulation
    • citation
    • annotation
    • biological annotation
  • in which case 'core' CellML Metadata specification will primarily just define how modules are organised and how the metadata is serialised in RDF/XML.

  • See http://www.cellml.org/specifications/metadata/graphs
  • current graphing metadata spec draft needs to be implemented (in PCEnv or Andre's tools) to be tested before it gets codified in the specification
  • things to add:
    • add ability to represent axes (ticks, linear/logarithmic/etc, colour(?))
    • gridlines
    • line thickness
    • background colour
    • need to rationalise how RDF containers are dealt with in the specification

Timeframe: dependent on implementation of current draft in PCEnv for testing / ironing. This work is unlikely to be implemented in PCEnv 0.7 and therefore unlikely to be completed by the time of the workshop.


  • most components of simulation metadata (as currently used by PCEnv) are non-standard
  • should be standardised at some point in the future

Timeframe: The current simulation spec as is (see link above,) could be finalised pending testing within PCEnv, although it would definitely be advantageous to implement it in David (Andre) Nickerson's CellMLSimulator. Andre would like to have CellMLSimulator implement the current simulation spec, but does not forsee having time for this between now and April 2009.



  • remove BQS, replace with DC citations
  •  adding an URN identifier where one exists as well as the citation would provide for both machine and human readable citations
    • e.g. MIRIAM (LSID?)
  • rework keywords in metadata (currently implemented in BQS - use DC citations 'subject')
  • serialise keywords, suggest in spec that constrained vocab be used
    • to allow, for example, a modification note that says "changed value of X from 1 to 2, as per [citation]', where in some cases it might also be appropriate to make X a reference to the variable in question (e.g., if we for some reason, wanted very detailed document histories)

Timeframe: DC citations is easily implemented. It would be reasonable to use a mixture of DC citations and MIRIAM as discussed in the tracker; MIRIAM for citations is also easily implemented.

  • model version metadata (see Tracker Item 1413)
    • Model version metadata must be VCS-generic and provide ad-hoc 'release' versioning
    • Should be somewhat informed by PMR2
    • Perhaps just add a 'revision identifier' attribute within the 'cmeta:modification' set
  • modification history metadata should require that the 'contributor' DC / vCard metadata tag be embedded within a modification history note
    • (this is possible now but not required - requirements should be implemented by software - a suggestion should be made within the spec that this is useful)

Timeframe: draft of model version metadata by workshop should be reasonable.

  • <removed> curation flags (see Tracker Item 87)
    • constrained vocabulary system for representing model curation status, partially informed by MIRIAM
    • At this point it is looking unlikely that curation flags will be included in the CellML Metadata 1.1 specification, because we would like to test the system within PMR2 before we do this. At this point a generalised system based on CellML Metadata is also not necessary for software other than PMR2.

    • Curation flags would also only be valid for a specific revision of a model, so they would not be transferable to the next version. Such epheremal metadata may not be worth serialising as CellML Metadata. </removed>

Biological annotation

  • See Tracker Item 1408
  • Perhaps clean up this section slightly
  • remove cmeta:sex, cmeta:species (?)
    • unnecessary to use cmeta for these annotations, should be replaced by an extensible solution - could use keywords, although this is a less granular solution
  • change 'bioentity' to 'biological annotation' (?)
    • so non-entities can be annotated (this is just semantics)

Timeframe: little to be changed. draft achievable by workshop although controversial.

Defining distribution / usage license of models in metadata

Timeframe: minimal work required - draft possible by Workshop

Best practices

  • if we create a normative spec in line with proposals for the CellML 1.2 spec, we should create an annotated spec that defines best practices
  • from David Nickerson:

"I think a large part of the individual specifications will be a best practice/worked examples section. These are essential to help ensure model users and developers annotate models in a consistent manner - at least as consistent as is required to ensure unambiguous interpretation of the data. Such examples will also aid tool developers in both processing and generating model annotations. Such a section in the umbrella specification would then show how to combine all the individual annotations. Perhaps this sort of data would be better off on the website somewhere outside the specification? but there would need to be some clear connections."

Timeframe: outlines / proposals for draft would be reasonable to expect by workshop

CellML Metadata Specification 2.0+

  • formalise Sarala's work on CellML-OWL into CellML metadata
  • provide a framework for using it appropriately

Timeframe: optimistically 12-18 months

Experimental Protocols

  • for conducting electronic experiments
  • e.g. integrate across range of variable values

Timeframe: ?

Model Parameterization

  • For documenting model assumptions with respect to parameter ranges, which may be interdependent.

  • For more details and some conceptual examples, see page 10, second paragraph of “Beard, D. A.; Britten, R.; Cooling, M. T.; Garny, A.; Halstead, M. D. B.; Hunter, P. J.; Lawson, J.; Lloyd, C. M.; Marsh, J.; Miller, A.; Nickerson, D.; Nielsen, P. M. F.; Nomura, T.; Subramaniam, S.; Wimalaratne, S. M. & Yu, T. CellML metadata: Standards, tools and repositories Transactions of Royal Society, 2008, submitted”.

Timeframe: ?

Model Behaviour

  • Model behaviour metadata would document the behaviour of the model using given parameters and/or combinations of components.
  • This metadata would likely reference simulation and graphing metadata
  • See Tracker Item 87 comment 12

  • Could form part of an automated re-check (or re-definition of model behaviour) after model modification/version update (see Tracker Item 91 comment 3)

Timeframe: ?

Model Visual Representation
  • See Tracker Item 1465
  • A framework to faciltate creating and editing of CellML models visually using software tools
  • From Abhishek Tiwari:
"As we may have plans to create a visual model design/editing interface for PCEnv, where we can create/edit CellML models simply by drag and drop of nodes(entityies or reactants) and connecting them using edges(interactions or reactions) in an object oriented way.  Such a tool will require to stores fine details of model's visual representation in a specific annotation format, which will reproduce the representation when we reopen the model for editing. 

Model visual representation metadata specification can provide annotation about node type (entity or object type, simple or composite), node specification (size, shape, color and coordinates on visual canvas), edge type (interaction, process, complex formation or reaction), and other fine details about visual representation of model. This approach for model visual representation is different from on fly visual representation for CellML models (Sarala Dissanayake's work), but might be useful for future development of CellML related tools."