This page describes various concepts to do with the cardiac electrophysiology web lab. It's usually out of date (see various tickets etc.).
The Cardiac Electrophysiology Web Lab (WL2) links models of cellular electrophysiology with protocols describing experimental procedures, and with experimental data obtained from the same procedures. Users can simulate and view the outcome of applying any protocol to any (compatible) model, and can compare the results to stored experimental data files. Using the same interface, users can compare data files to each other, or inspect the predictions of different models for the same experiment. Moving beyond qualitative comparison, numerical error measures can be defined and then minimised by algorithmically tuning model parameters.
The figure above shows the general outline of WL2. The individual components and their connections are described below.
A model is a system of ordinary differential equations (ODEs) that describes (some aspects of) the electrophysiology (EP) of a cell, plus a physiologically viable set of initial states. Most models describe either a single ionic current, or a set of currents plus the ionic diffusion mechanisms that give rise to the cellular action potential (AP). Some models also include other aspects such as signalling or contraction mechanics.
Models are written in CellML 1.0 or 1.1.
In the current implementation, models are stored on the website, but we'd like to move to a situation where they're kept in external repositories, e.g. the Physiome Model Repository (PMR, also known as the CellML Model Repository).
The WL2 uses Git for version control of models and protocols: see version control. Where the reference copy is stored externally, the Web Lab will store a clone of the repository.
Models are linked to protocols via an ontology that lists common model variables, e.g. the major currents (INa, ICaL, IKr, etc.) and their maximum conductances. Currently, annotation happens by modifying the CellML files.
The annotation mechanism may change, with annotations living inside the model and/or in a triplestore.
We currently use the oxmeta ontology, which is distributed as part of Chaste.
We'd like a community ontology, but seems best way to achieve this is to just do whatever we feel like and wait until there are enough other people who want this too
- Note 1: There is also an rdf file.
- Note 2: The XML namespace for the annotations is
https://chaste.comlab.ox.ac.uk/cellml/ns/oxford-metadata(not a link! for historical reasons). - Note 3: ICEPO is an ontology of qualitative effects of mutations on ion channel function: ftp://ftp.nextprot.org/pub/current_release/controlled_vocabularies/cv_modification_effect.obo .
See e.g.
It would also be great to move beyond shared variable names, and start documenting model provenance, using relations to (oxmeta?) variables, such as is_parameter_for.
Once we have a way to reference our models and data sets, we should also be able to add weak provenance data, such as ModelX:VariableY is_derived_from DataSetZ or ModelX:Component1 is_inherited_from ModelY:Component2 or is_adapted_from.
The fitting specification (see #fitting) will provide strong provenance data, in the form of a complete description of how to obtain a parameter value from a model, protocol, and data set.
See e.g.
Linking models to annotated data would automatically solve the problem of annotating models with e.g. species info (we could even say things like "27% human" if the annotations were really complete). See previous feedback.
Protocols are written using the Functional Curation language, using this syntax.
We might move some post-processing into sandboxed Python
SED-ML is a community standard to describe experiments, but its capabilities are much more limited than functional curation
The Minimum Information About a Simulation Experiment (MIASE) project describes the minimum things that any standard encoding simulation experiments should contain. (paper | wiki | website) It is not a format for representing experiments, however.
The current Functional Curation protocols rely on a cardiac specific and a cardiac-non-specific library of functions (written in FC syntax). If we continue down this road these need to be documented and stored somewhere as some kind of standard library.
WL2 needs the capability to display and process experimental data. See e.g.
The current prototypes use CSV data.
See e.g.
The MICEE standard lists a bunch of things that should be stored about experimental data.
(paper)
- Note 1: The MICEE website seems to be offline.
We need someone to host data (annotated) files. Initially, we can do this locally
WL2 does not include initial preprocessing such as capacitance artefact removal, leak correction, subtraction protocols etc. It does include secondary preprocessing such as calculating IV curves from (cleaned up) current recordings. To allow initial preprocessing to be inspected and/or re-done, we would ideally store (1) cleaned up, annotated data in an approved exchange format, and (2) free-form raw data along with pre-processing code (e.g. proprietary data formats and matlab scripts).
Further pre and post-processing currently happens via functional curation (see Protocols).
Models will be read using our own CellML reading code, cellmlmanip, that reads CellML, creates SymPy equations, and can manipulate them (e.g. adding a protocol-defined stimulus).
Next weblab_cg will use cellmlmanip to read CellML files and then print code for use with the web lab.
LibCellML is the planned new library for reading (but not manipulating) CellML 2.0 files. We've added Python bindings to it, and would like to use it eventually, provided it has real benefits over a simple plain-Python reader.
Currently, simulations can be run using either Chaste or a Cython back-end. Ultimately, we will only use weblab_fc.
WL2 will include fitting, or inference algorithms, e.g. derivative-free non-linear methods for optimisation, and methods to estimate parameter distributions in a Bayesian framework.
This will happen using PINTS.
Fitting takes a lot of processing power, especially when you do it repeatedly (which is often needed to test the quality of the fit). This means we'll probably need some sort of offline component for people to experiment with, after which users can upload a fitting spec and ask us to run it.
We will use version control throughout WL2, so that all entities (models, protocols, data sets, results) can have multiple versions. To this end, each model and protocol will have its own Git repository. BiVeS is used to compare model versions.
Every entity requires a unique identifier, which can be used to create links on the web site, but is also accessible to fitting specifications and model and data annotations. These take the form of a uniform resource identifier (URI), more specifically, a uniform resource locator (URL). We currently have unique canonical URIs for each version of each entity type that Web Lab handles (see todo, add link).
Specific versions of Git repos for entities can be downloaded as COMBINE archives. We could define subtypes for this, but it's not strictly required.
We will allow all entities (models, protocols, data sets) to be either private, shared with a limited audience, or fully public.
See e.g.
At one point, we mentioned it would be nice to allow comments / discussion threads of all entities.
See e.g.
WL1 provides a hidden REST API to allow other services to communicate with it. WL2 will keep this feature, but extend and document it. See the infrastructure page for details.