The COMODI ontology is specifically designed for the annotation of differences between versions of a computational model in the life sciences. In the following we show the usefulness of COMODI for annotating changes, predicting the effects of changes on the simulation result, and filtering versions of a model for specific differences.
Annotation of changes
SBML models typically use parameters to define the kinetics of a process. The corresponding entity in the SBML document looks as follows:
Here the value of the parameter Km1 is 23.24 molesperlitre.
Updating the parameter value to 23.42 molesperlitre results in an update of the corresponding XML entity. The new version of the model contains the following piece of SBML code:
BiVeS identifies the difference as an update of the paramter value. The XML-encoded serialisation provides the new and the old value of Km1:
Using COMODI the detected update can now be annotated. Some information can directly be inferred and thus be annotated automatically with BiVeS. For example, we know that the above is an update and can link it to the XML entity
. BiVeS is even able to recognize that this change corresponds to a change of the
. The combination of several statements using terms of the different branches allows users to be very specific. COMODI offers terms describing the reason and the intention of a change. Following the example from the previous section, the annotation of the parameter update might look like4:
The full example is included in Additional file 1 and explained in Additional file 2.
Prediction of the possible effects of a change
The modification of the
also affects the
(cmp. ontology terms in Fig. 2) and thus potentially influences the simulation results. Similarly, modifications of a
can influence the simulation outcome. Finally, changes in the network structure (e. g., modification of the
by transforming a reactant into a modifier) will not only affect the simulation outcome, but in addition the visual representation of the network. For this subset of changes, modellers should be notified of any modification.
Another case are changes that affect the
. For example, models are regularly updated to remain compliant with new versions of format specifications. These changes are especially relevant for software tools dealing with model code. As not all tools feature the full set of SBML constructs , for example, the upgrade of a model may require the use of another software tool. Thus, changes that result from modifications of the format specification can be of indirect interest for modellers. They may not affect the modelled system but the tools that are needed to interpret and simulate it.
However, other changes may not be as relevant. It can be helpful to hide them and thereby help users focus on important changes. For example, the reading and subsequent writing of a model file using different software tools, such as COPASI  or CellDesigner , often results in a re-shuffling of elements within the document. However, the sequence of certain elements might not matter to the encoded model. In SBML for example, the order of parameters defined in the
is irrelevant for the encoded system, as SBML does not give any semantic meaning to element orders . Thus, changes that only affect the order of elements, can be neglected. Even if BiVeS reports them in its XML serialisation, these changes can be discarded if annotated with the corresponding COMODI terms. For other types of changes, the decision whether to neglect a change or not depends on the user. A new identifier scheme for the semantic annotations, for example, is relevant to curators and tool developers, while it is probably irrelevant for the majority of modellers. However, modellers who based their model analysis, comparison, or visualisation on semantic annotations need to be notified about this type of change. Here, COMODI terms need to be evaluated based on the users’ preferences.
Filtering by change
The COMODI ontology enables software to automatically filter the list of changes to show only the relevant changes for a given question. For example, if a developer is interested in the model versions before and after an update of the SBML specification, he or she can search for changes annotated with
and display only those versions of a model that are linked to such a change.
Another, more complex filter is the one for “relevant changes only”. It is difficult to determine what exactly a relevant change may be, and relevance depends on the application domain and user. However, in the context of curation, the curators could define their set of changes that they want displayed and neglected, respectively. The needs of specific user groups may result in different profiles.
Filtering can also be used to display only model versions that are the result of a specific change, while neglecting all other versions. For example, each release of BioModels generates new model versions. However, if the only changes are updates of the SBML level, for example, then it suffices to display a reduced number of model versions to the user, instead of providing them all released versions.