Technical Specifications and Model Handling

Selected documentations by M. Roux, PhD - CEO BioDataConsulting

The purpose of technical specifications is to provide human-readable documents for quality controls and review; it gives the features of all inputs and outputs, definitions and relations between elements, etc.

In Model-Driven Data management, models are first class entities and model processing (including mapping, weaving, etc.) must be carefully documented, not only to keep track of model handling but to have strong, sharable and implementable solutions. Applied to Life Sciences, Model-Driven Data management obeys the same rules, regardless of the field concerned

Model mapping: ISA2FuGE

Motivation

The motivation behind this mapping was to provide detailed correspondences between the ISA tabular model (ISA-TAB) and the FuGE object model (FuGE-OM), both used for Omics data management (see the Case Study page, for details on both ISA-TAB and FuGE-OM standards as well as data challenges in Omics sciences ).

Methodology

A mapping is a set of specifications that describe the relationship between two knowledge representations (or schemas) and constitutes the essential building blocks of data exchange and data integration. Source-to-target mapping intuitively represents inter-schema correspondences between the source schema and the target schema, including a semantic correspondence. Four basic techniques are known for mapping model elements:

Document

In this specification document, we made correspondences with elements of the ISA-TAB source schema and the target FuGE model using the meaning of corresponding items to achieve matching of models. Nevertheless, a one-to-one ISA-TAB to FuFE correspondence was not sufficient to ensure equivalence and additional single- or multiple-attribute FuGE classes and therefore relations were added. In addition, there needs to be some pre-existing FuGE objects before the mapping which are described before the mapping is performed.

#ISA2FuGE specifications document (PDF 1300 MB)

Metamodeling integration architecture: GO extensions and Multiscale modelling

Motivation

A complex domain can be hardly described by a single metamodel attached with models, which could be further broken down into models and metamodels to describe either fundamental domain features (e.g., measurement features) or modelling constructs (e. g.constructs dedicated to the technical integration of domain knowledge).
We developped metamodeling integration architectures for the management of (i) the ontology extensions, which were proposed for adding new terms and relations to Gene Ontology (GO), the main ontology for gene annotation, and (ii) the multiscale modelling of the heart, which relies on connecting (weaving) several models

Methodology

Metamodels and models can be organized into a metamodelling architecture such that:

To manage GO extensions, an upper-level metamodel is designed to be the root of an inheritance hierarchy of metamodels; this upper-level metamodel relies on the three types of ontological relationships introduced by the Basic Formal Ontology (BFO): (i) intra-ontological relationships, which relate terms within a single ontology, (ii) trans-ontological relationships, which relate two terms from different ontologies that have the same definition of relevance (iii) meta-ontological relationships, which relate two terms from ontologies with different definitions of relevance; then, derived metamodels are defined by forbiding relationships that are not used in specific application families.

Similaly, metamodeling integration architecture is of great help for model validation in multiscale modeling: metamodels often take the form of 'Russian doll', nested within each other to represent more and more finely objects, relations and properties of the intended modeling; then, models are derived to define what is, actually, represented. Multiscale model validation is acheived through a step-by-step process using consistent model operators (dependency, transformation, etc.)

Documents

We are using metamodeling integration architecture to precisely determines which parts of the knowledge structure are shared. In using GO extensions, applications that share a base of agreement that is described by a common metamodel will interoperate in contrast to those which are derived from semantically different metamodels(see for example, m2GO and OBOmti in "GO extensions architecture" docuemnt). In multiscale modeling, model validation is a matter of debate; metamodeling integration architecture provide a method for model validation in the sense, given by IEEE, of determining that the requirements and the final as-built system fulfil its specific intended use. In other words, models are not validated against "real world" but against its "intended use", which can be represented through a metamodeling integration architecture.

# GO extensions architecture document (PDF 360 MB)

# GO extensions architecture flyer (PDF 1100 MB)

# Multiscale modelling of the heart flyer (PDF 140 MB)