The COMODI ontology is needed because COmputational MOdels DIffer. COMODI defines classes and properties to represent changes in computational models on the semantic level. These terms empower users and software to describe model changes in detail. Software can implement user-specific filter options for model changes and potentially predict how a change in a model influences a simulation study.
The OWL encoding of the COMODI Ontology is available from our web server: comodi.owl.
The namespace for all COMODI terms is http://purl.uni-rostock.de/comodi/comodi#
.
Please cite COMODI as:
Martin Scharm, Dagmar Waltemath, Pedro Mendes, and Olaf Wolkenhauer (2016): COMODI: an ontology to characterise differences in versions of computational models in biology. Journal of Biomedical Semantics 2016; 7:46; https://dx.doi.org/10.1186/s13326-016-0080-2
The key words "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may", and "optional" in this document are to be interpreted as described in [RFC2119].
owl | <http://www.w3.org/2002/07/owl#> |
rdf | <http://www.w3.org/1999/02/22-rdf-syntax-ns#> |
xsd | <http://www.w3.org/2001/XMLSchema#> |
rdfs | <http://www.w3.org/2000/01/rdf-schema#> |
teddy | <http://identifiers.org/teddy/TEDDY_> |
comodi | <http://purl.uni-rostock.de/comodi/comodi#> |
All other namespace prefixes are used in examples only. In particular, IRIs starting with http://example.com
represent some application-dependent IRI [IRI].
COMODI consists of the following classes, object properties, and data properties. They are further defined in Section 4. You will find a description of the terms and concepts of COMODI in Section 3.
COMODI consists of five types of classes and five object properties which link these classes.
The central class is comodi:Change
. It represents a change (reflected in a delta) between two versions of a computational model.
The type of the change can be specified more precisely by using one of the subclasses of comodi:Change
: comodi:Insertion
, comodi:Deletion
, comodi:Update
, or comodi:Move
.
The comodi:Change
class is connected to four other classes, using the five object properties:
comodi:appliesTo comodi:XmlEntity
—
links a change to a comodi:XmlEntity
, e.g., an XML attribute (see comodi:XmlAttribute
).comodi:hasIntention comodi:Intention
— explains the intention of a change, e.g., an extension of the model (see comodi:Expansion
).comodi:hasReason comodi:Reason
— provides a reason for a change, e.g., a mismatch with the corresponding publication (see comodi:MismatchWithPublication
).comodi:affects comodi:Target
— indicates which part of the model has changed, e.g., a species definition (see comodi:SpeciesSetup
).comodi:Change
can be triggered by another comodi:Change
.
For example, the deletion of a node triggers the deletion of all its attribute.
To represent this knowledge, the comodi:Change
classes can be connected using the comodi:wasTriggeredBy
property.
In addition, the Teddy ontologoy [TEDDY] is linked into COMODI at the comodi:ModelBehaviour
node.
Thus, it is also possible to annotate changes that, for example, affect the stability using teddy:0000148 (stability characteristic).
The following figure visualises all classes in COMODI and their properties:
Unless otherwise noted, the following examples are based on differences that we detected in SBML- or CellML-encoded models. These differences are detected using BiVeS [BIVES]. To increase the readability, annotations of the examples are given in Turtle format [TURTLE]. Further examplesare provided on a Poster that we presented at the COMBINE 2015 and the ICSB 2015 [COMODI-POSTER].
The examples require a basic understanding of the encoding formats, please refer to the SBML and CellML homepage.
Let's assume a new species had been introduced into an SBML model. As a consequence, the current version of the document contains an additional node in the listOfSpecies
substree, e.g.:
<species name="Glucose" initialConc="0.6" />BiVeS detects this difference and generates a delta that looks like:
<insert> <node id="13" newTag="species" [...] / > <attribute id="14" triggeredBy="1" name="initialConc" newValue="0.6" [...] /> [...] </insert>Even though you would probably think of the insertion of a species as just a single operation, BiVeS recognises several changes: an insertion of a species plus the insertions of the species' properties and attributes. Thus, the delta contains multiple changes and every change should be annotated. Using the COMODI onology, we can speficy the nature of all changes in detail:
#13 a comodi:Insertion. #14 a comodi:Insertion.Here we assume that this insertion expands the model:
#13 a comodi:Insertion; comodi:hasIntention comodi:Expansion. #14 a comodi:Insertion; comodi:hasIntention comodi:Expansion.In addition, change
#13
was applied to an XML node and this change affects the reaction network. In contrast, change #14
was applied to an XML attribute and it affects the model setup, specifically the setup of this species. As we have this knowledge, we should encode it semantically:
#13 a comodi:Insertion; comodi:affects comodi:ReactionNetworkDefinition; comodi:appliesTo comodi:XmlNode; comodi:hasIntention comodi:Expansion. #14 a comodi:Insertion; comodi:hasIntention comodi:Expansion; comodi:affects comodi:SpeciesSetup; comodi:appliesTo comodi:XmlAttribute.Finally, change
#14
(the setup of the species' initial concentration) was triggered by change #13
(the insertion of the species). After including this information, the final annotation looks like:
#13 a comodi:Insertion; comodi:affects comodi:ReactionNetworkDefinition; comodi:appliesTo comodi:XmlNode; comodi:hasIntention comodi:Expansion. #14 a comodi:Insertion; comodi:hasIntention comodi:Expansion; comodi:affects comodi:SpeciesSetup; comodi:appliesTo comodi:XmlAttribute; comodi:wasTriggeredBy #13.
Let's assume you resolved a typo in the name of an SBML species. At first, the species definition in the SBML document did look like:
<species name="Gulcose" initialConc="0.6" />You recognised the mistake (typo in the name of the species) and corrected the species to produce the following species definition in the XML tree:
<species name="Glucose" initialConc="0.6" />Using BiVeS, you obtain the following delta:
<update> <attribute id="23" newValue="Glucose" name="name" oldValue="Gulcose" /> [...] </update>That means, BiVeS correctly recognises the update of the name attribute.
#23 a comodi:Update; comodi:hasIntention comodi:Correction. comodi:appliesTo comodi:EntityName; comodi:hasReason comodi:Typo.
The COMODI ontology can also be used to annotate SED-ML files. SED-ML is a language to encode simulation descriptions in a standardised format [SED-ML]. Software tools use SED-ML to encode changes to the model's setup and, thus, updates of the environment. For instance, a change of a parameter value in an SBML file can be encoded in SED-ML as:
[...] <model id="model1" name="some name" language="SBML" source="model1"> <listOfChanges> <changeAttribute id="change1" target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='V_m']/@value" newValue="10.27"/> </listOfChanges> </model> [...]This snippet changes the value of the parameter
V_m
to 10.27
.
The creator of this file might wanted to test a hypothesis, so (s)he had the intention of a trial.
This change obviously affects the parameter setup.
Using COMODI, the above section in the SED-ML file may be annotated to explain what the simulation description is going to do to the original model.
This time, we will add an <annotation>
node directly into the SED-ML document:
[...] <model id="model1" name="some name" language="SBML" source="model1"> <listOfChanges> <changeAttribute id="change1" target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='V_m']/@value" newValue="10.27"> <annotation> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:comodi="http://purl.uni-rostock.de/comodi/comodi#"> <rdf:Description rdf:about ="#change1"> <rdf:type rdf:resource="http://purl.uni-rostock.de/comodi/comodi#Update"/> <comodi:hasIntention rdf:resource="http://purl.uni-rostock.de/comodi/comodi#Trial"/> <comodi:affects rdf:resource="http://purl.uni-rostock.de/comodi/comodi#ParameterSetup"/> </rdf:Description> </rdf:RDF> </annotation> <changeAttribute> </listOfChanges> </model> [...]
IRI: http://purl.uni-rostock.de/comodi/comodi#AnnotationEncoding
IRI: http://purl.uni-rostock.de/comodi/comodi#Attribution
Attribution is textual description to thank and appreciated e.g. certain persons or institutions.
IRI: http://purl.uni-rostock.de/comodi/comodi#Change
A Change characterises how the description of a particular entity in a model differs from the description of that entity in another model or model version.
IRI: http://purl.uni-rostock.de/comodi/comodi#ChangedSpecification
Models are changed when the encoding standard is updated. In that case, the comodi:Reason of a change is a comodi:ChangedSpecification.
Example:
The upgrade from SBML Level 2 to SBML Level 3 resulted in many changes in SBML models, which were necessary due to the comodi:ChangedSpecification.
IRI: http://purl.uni-rostock.de/comodi/comodi#ComponentDefinition
A ComponentDefinition describes a small functional unit of the system.
IRI: http://purl.uni-rostock.de/comodi/comodi#Contributor
A Contributor is an annotation about a human being, who participated in the development of the model.
IRI: http://purl.uni-rostock.de/comodi/comodi#Correction
A Correction resolves an error in a model.
IRI: http://purl.uni-rostock.de/comodi/comodi#CreationDate
The CreationDate refers to the date and time when a model or a model entity was created.
IRI: http://purl.uni-rostock.de/comodi/comodi#Creator
A Creator is an annotation about a human being, who was involved in the initial development of the model or its representaiton.
IRI: http://purl.uni-rostock.de/comodi/comodi#Date
IRI: http://purl.uni-rostock.de/comodi/comodi#Deletion
A Deletion removes a component from the model.
Example:
A comodi:Change may delete a cellml:component from the network.
IRI: http://purl.uni-rostock.de/comodi/comodi#Elaboration
An Elaboration adds more detail to the model.
Example:
A new version of a model may provide a zoom into the model or certain structures therein, or it may provide more details on particular structures inside the model.
IRI: http://purl.uni-rostock.de/comodi/comodi#EntityIdentifier
IRI: http://purl.uni-rostock.de/comodi/comodi#EntityName
IRI: http://purl.uni-rostock.de/comodi/comodi#EventDefinition
An EventDefinition describes events that occur in the system.
Example:
Events are usually triggered by "something". They may have a delay and they typically have an effect on the system's dynamics.
IRI: http://purl.uni-rostock.de/comodi/comodi#Expansion
An Expansion adds new entities to the model in order to cover a significantly larger network, or to enlarge the domain of the model.
Example:
A model describing the Interphase of the Cell Cycle may be expanded to cover the Cell division.
IRI: http://purl.uni-rostock.de/comodi/comodi#FunctionDefinition
A FunctionDefinition describes a model-specific function that can be used in the model's maths.
IRI: http://purl.uni-rostock.de/comodi/comodi#HierarchyDefinition
A HierarchyDefinition describes, for example, how to achieve an encapsulation or how to encode hierarchical relationships.
Example:
A modification of the component hierarchy of a CellML model comodi:affects the comodi:HierarchyDefinition.
IRI: http://purl.uni-rostock.de/comodi/comodi#IdentifierEncoding
An IdentifierEncoding specifies the structure of identifiers. That includes the encoding of links to external resources and links to entities in the model document.
Example:
SBML used different identifier schemes in the past, including identifiers.org (http://identifiers.org/obo.go/GO:0000278) and MIRIAM URNs (urn:miriam:obo.go:GO%3A0000278).
IRI: http://purl.uni-rostock.de/comodi/comodi#Insertion
An Insertion adds a new component to the model.
Example:
For the reason of a comodi:Extension, we may insert a new sbml:parameter in the XML code.
IRI: http://purl.uni-rostock.de/comodi/comodi#Intention
An Intention specifies the aim of a change, particularly with respect to consequences in the future.
IRI: http://purl.uni-rostock.de/comodi/comodi#KineticsDefinition
A KineticsDefinition describes a kinetic law.
Example:
The sbml:kineticLaw specifies the rate law of a reaction. A change in the kineticLaw comodi:affects the comodi:KineticsDefinition.
IRI: http://purl.uni-rostock.de/comodi/comodi#KnowledgeGain
A KnowledgeGain is the process of acquiring new knowledge about the model, or the modeled system.
IRI: http://purl.uni-rostock.de/comodi/comodi#MathematicalModelDefinition
A MathematicalModelDefinition defines structural parts of the model that affect the dynamics of the system.
IRI: http://purl.uni-rostock.de/comodi/comodi#Merge
A Merge is the result of a combination, blend or unification of different models into a new model.
IRI: http://purl.uni-rostock.de/comodi/comodi#MetaIdEncoding
A MetaIdEncoding specifies the structure of meta-ids, that is global identifiers in the model that can be used to refer to model parts.
IRI: http://purl.uni-rostock.de/comodi/comodi#MismatchWithPublication
A MismatchWithPublication reflects that a discrepancy between the model and the corresponding publication was discovered.
IRI: http://purl.uni-rostock.de/comodi/comodi#ModelAnnotation
A ModelAnnotation provides meta-data about the model and its parts.
Popular annotations include RDF blocks, dc:terms and other controlled vocabularies.
IRI: http://purl.uni-rostock.de/comodi/comodi#ModelBehaviour
IRI: http://purl.uni-rostock.de/comodi/comodi#ModelCuration
ModelCuration is the process of analysing the model itself and its correspondence to the publication. (https://www.ebi.ac.uk/biomodels-main/curationtips)
IRI: http://purl.uni-rostock.de/comodi/comodi#ModelDefinition
A ModelDefinition specifies a certain aspect of a model. A model typically contains a positive number of model definitions.
Example:
The sbml:kineticLaw specifies the rate law of a reaction. A change in the kineticLaw comodi:affects the comodi:ModelDefinition.
IRI: http://purl.uni-rostock.de/comodi/comodi#ModelEncoding
The ModelEncoding defines how the different parts of the model are to be encoded.
Example:
In SBML or CellML, the comodi:ModelEncoding reflects the structure of the XML layer.
IRI: http://purl.uni-rostock.de/comodi/comodi#ModelId
IRI: http://purl.uni-rostock.de/comodi/comodi#ModelName
IRI: http://purl.uni-rostock.de/comodi/comodi#ModelSetup
The ModelSetup specifies necessary settings to initialise a model.
Example:
The amount of Glucose in an environment could be specified using a parameter. A change in the amount comodi:affects the comodi:ModelSetup, but does not affect the comodi:ModelDefinition.
IRI: http://purl.uni-rostock.de/comodi/comodi#ModificationDate
A ModificationDate refers to the date and time when a model or a model entity was modified.
IRI: http://purl.uni-rostock.de/comodi/comodi#Move
A move rearranges parts of the model.
IRI: http://purl.uni-rostock.de/comodi/comodi#NetworkDefinition
A NetworkDefinition specifies the biological entities, how they are related to each other, and how they interact.
IRI: http://purl.uni-rostock.de/comodi/comodi#_obsolete
Terms in this subtree are obsolete and shouldn't be used anymore.
IRI: http://purl.uni-rostock.de/comodi/comodi#OntologyReference
An OntologyReference refers to a a term in a third-party resource, using a URI.
Example:
An example of an ontology reference is "http://identifiers.org/obo.go/GO:0000278".
IRI: http://purl.uni-rostock.de/comodi/comodi#ParameterSetup
The ParameterSetup describes the value and units of a parameter in a model.
Example:
Parameters can be used to define the current environment of a model, such as the temperature. If the value of a parameter changes it comodi:affects the comodi:ParameterDefinition.
IRI: http://purl.uni-rostock.de/comodi/comodi#ParticipantDefinition
A ParticipantDefinition describes the participants in the network.
Example:
A comodi:Change of an sbml:Species used in an sbml:reaction targets the comodi:ParticipantDefinition.
A comodi:Change in a comodi:ParticipantDefinition indicates that the role or definition of the biological entity have changed.
IRI: http://purl.uni-rostock.de/comodi/comodi#PermutationOfEntities
A PermutationOfEntities changes the order of model parts sharing the same parent node in the XML document (shuffling siblings).
Example:
The import/export from different software tools may change the order of the sbml:species in the sbml:listOfSpecies. This shuffling is reflected in a comodi:PermutationOfEntities.
IRI: http://purl.uni-rostock.de/comodi/comodi#Person
A Person is an annotaion about a human being that, for example, contributed to the development of the model in some way.
IRI: http://purl.uni-rostock.de/comodi/comodi#PortDefinition
A PortDefinition provides structure to input and output values and enables a convenient graphical representation of models. Ports are the basis for the definition of links in a network of models, representing the flow of information.
IRI: http://purl.uni-rostock.de/comodi/comodi#ReactionDefinition
A ReactionDefinition describes a particular reaction taking place in the model.
Example:
A comodi:Change in a comodi:ReactionDefinition indicates that the biological meaning of a reaction has changed.
IRI: http://purl.uni-rostock.de/comodi/comodi#ReactionNetworkDefinition
A ReactioNetworkDefinition describes the structure of the network underlying a model.
IRI: http://purl.uni-rostock.de/comodi/comodi#Reason
The reason of a change focuses on the cause of a change.
IRI: http://purl.uni-rostock.de/comodi/comodi#ReversibilityDefinition
A ReversibilityDefinition describes the nature of the reaction, identifying it as reversible or irreversible.
IRI: http://purl.uni-rostock.de/comodi/comodi#RuleDefinition
A RuleDefinition specifies the values of the variables in a model, and the dynamic behaviors of those variables.
IRI: http://purl.uni-rostock.de/comodi/comodi#Simplification
A Simplification decreases the level of complexity by which the model or its entities are described.
IRI: http://purl.uni-rostock.de/comodi/comodi#SpeciesSetup
The SpeciesSetup defines a (biological) entity in the model.
Example:
Changes in the value of the initial concentration comodi:affects the corresponding comodi:SpeciesDefinition.
IRI: http://purl.uni-rostock.de/comodi/comodi#Target
The Target identifies the location of a comodi:Change, and characterises its nature. It thus defines where the comodi:Change takes affect.
Example:
A comodi:Change may affect the comodi:Annotation of a cellml:component.
A comodi:Change may also affect the comodi:UnitDefinition of an sbml:Species.
IRI: http://purl.uni-rostock.de/comodi/comodi#TextualDescription
The TextualDescription of a model is a human-readable explanation of the model. It can be surrounded by layout information, for example to present the textual description in a web browser.
Example:
One example for a textual description is the SBML <notes> element.
IRI: http://purl.uni-rostock.de/comodi/comodi#Trial
A Trial is a change resulting from playing around with the model.
Example:
Models may be examined to better understand their dynamic behaviour, or to test hypotheses. In these cases, the changes are the result of a comodi:Trial.
IRI: http://purl.uni-rostock.de/comodi/comodi#Typo
A Typo is a misspelling, e.g. in the description or name of a model or a model entity.
IRI: http://purl.uni-rostock.de/comodi/comodi#UnitDefinition
A UnitDefinition specifies a unit.
IRI: http://purl.uni-rostock.de/comodi/comodi#Update
An Update replaces a part of the model with another part.
Example:
A comodi:Change may require the exchange of a species definition with an updated one.
IRI: http://purl.uni-rostock.de/comodi/comodi#VariableConnectionDefinition
A VariableConnectionDefinition describes how variables in a model are connected with each other.
Example:
A CellML model defines the participants of a biological system as variables. These variables can be part of different cellml:components. The comodi:VariableConnectionDefinition then defines how the variables are connected across the cellml:components. A change in these connections thus comodi:affects the comodi:VariableConnectionDefinition.
IRI: http://purl.uni-rostock.de/comodi/comodi#VariableSetup
The VariableSetup defines the values of variables in a model component.
IRI: http://purl.uni-rostock.de/comodi/comodi#VcardEncoding
The VcardEncoding specifies how to refer to other people/institutions in a machine readable format.
IRI: http://purl.uni-rostock.de/comodi/comodi#XmlAttribute
An XmlAttribute contains data related to a specific XML element. (http://www.w3schools.com/xml/xml_attributes.asp)
IRI: http://purl.uni-rostock.de/comodi/comodi#XmlEntity
An XML entity is part of the instance of an XML-encoded model.
IRI: http://purl.uni-rostock.de/comodi/comodi#XmlNode
An XmlNode represents a node in the XML tree.
IRI: http://purl.uni-rostock.de/comodi/comodi#XmlText
An XmlText represents the textual content of an element or attribute.
IRI: http://purl.uni-rostock.de/comodi/comodi#affects
IRI: http://purl.uni-rostock.de/comodi/comodi#appliesTo
IRI: http://purl.uni-rostock.de/comodi/comodi#hasIntention
IRI: http://purl.uni-rostock.de/comodi/comodi#hasReason
IRI: http://purl.uni-rostock.de/comodi/comodi#wasTriggeredBy
IRI: http://purl.uni-rostock.de/comodi/comodi#hadValue
IRI: http://purl.uni-rostock.de/comodi/comodi#receivedValue
The authors would like to thank the COMBINE community and the participants of the 2015 ICSB for valuable discussions and their expertise that significantly improved the outcome of this work.
Further to this, the authors would like to thank Silvio Peroni for developing LODE, a Live OWL Documentation Environment, which is used for representing the Cross Referencing Section of this document and Daniel Garijo for developing the Java tool widoco, which was used to generate this website, and the Protege team for providing Protege, the software tool we used to build the ontology.
This work was funded by the German Federal Ministry of Education and Research (BMBF) as part of the e:Bio program SEMS, FKZ 031 6194.
An annotation scheme encodes the structure of semantic annotations attached to the model or to the model entities.