Signal transduction is characterised by state changes in components. In experiments, we measure these variables - or elemental states - as modifications at specific residues or bonds between pairs of components. Single components may have many elemental states that, much like switches, can be combined into many specific configuarations or microstates. Most modelling formalisms use a microstate-based description, leading both to a combinatorial complexity and an ambiguity in the relationship between experiments (elemental states) and model (microstates) that get worse the larger the model scope (in terms of elemental states) is. Furthermore, microstates are moving targets, as they depend on the elemental states the model considers, meaning that changes to a microstate model tend to have far-reaching consequences.

By describing the network in terms of (combintions of) elemental states, the rxncon language gives the model the same resolution as empirical data. This both minimises the (unnecessary) complexity and maximises the congruence between experiment and model. Furthermore, elemental states do not depend on each other, making the rxncon language highly composable. This makes it much easier to update, extend and merge rxncon models, and greatly facilitates the iterative and cooperative work that is required to build models at the genome scale.

Read more: Network reconstruction; the rxncon language

rxncon is a higher level "biological" language that is compilable instead of executable . This makes the language intuitive to use, as the rxncon network is built by statments such as: "Kinase X phosphorylates Target Y" or "Kinase X phosphorylates Target Y only when Kinase X is phosphorylated on Residue Z". The first statement is an elemental reaction: This statement only defines a possibility, Kinase X can phosphorylate Target Y, without stating when this reaction can happen. The second statement is a contingency, constraining the reaction statement by specifying a necessary context, in this case the phoshorylation at an activating residue. More complex requirements can be defined by Boolean combinations of elemental states, making it possible to define arbitrarily complex requirements. Hence, the model can be made as complex as data requires, but does not need to be more complex.

Read more:The rxncon language

Building a rxncon model means making very specific statements about molecular biology. We define which reactions are known to be possible (in the reaction list) and what we know about the conditions they are active under (in the contingency list). Each statement must be made in terms of elemental states, making them both highly specific and directly related to (possible) experiments. A carefully built and well annoated model therefore constitute a high-quality knowledge base - which can be visualised or used as a template for (automatic) model generation. Model examples

We developed the rxncon compiler to compile the higher level "biological" language into executable model code or graphical formalisms. The compilation is automatic and can use different options depending on target. Currently, we support the following compilation targets: Rule-based models in the BioNetGen language, a parameter-free and mechanistic bipartite Boolean formalism, the reaction graph to visualise the reaction topology, the elemental species-reaction graph to visualise the complete regulatory structure, and the regulatory graph for a condensed visualisation of the regulatory structure (omitting neutral states). The graphical compilation targets can reuse previous layout, minimising the cost for iterative network extension, visualisation and model creation.

Read more: Parameter-free simulation; graphical formats

We are currently finalising the workbench. It is not yet ready for use.

The rxncon workbench makes it even easier to work with rxncon. It combines a local model repository - with versioning - with the tools for visualisation and model creation. Model versioning simplifies model development: When the model file is changed and uploaded again, the active file gets overwritten but the old file gets stored and can be accessed anytime. There is in other words no reason to have multiple files for the same model. The rxncon workbench can be installed directly from the Python package index through "pip install rxncon_workbench".