Information Models

An 3D engineering model

This site is about Information Modelling (modelling of data, modelling of interfaces, modelling of tasks, i.e., of work, of technical documents, of knowledge and of processes). The idea I want to put forward is that modelling is the key, not only of controlled content design, but also of sound planning of content delivery devices, such as interfaces of dynamic or static systems, or documentation in any flavour.

By this I mean  something quite simple: as a model is an abstraction over some entity type relating to a purpose and context, only the features relevant to both (intended purpose and context) will be accounted for in a model rightly designed for them. Further using models to derive or describe real-life entities, be they data, devices, documents, buildings, processes or whatever, is a way to constrain these to the structure of the model and, therefore, gain a fine-tuned control of their capacities in every respect.

An ontology-driven model of the “cheese”, “milk” and “region” concepts

A distinguished feature of models is that they are expressed in some kind of dedicated language: models of buildings (plans) are written in a conventional 2D drawing language, familiar to architects or engineers, models of data in UML, RDF, OWL or other, models of tasks in TIM (Task-oriented Information Modelling) if it is me who encodes them, models of documents in XML, models of electric circuits in Modelica, models of natural languages in HPSG, LFG, etc., models of manufacturing systems in Petri nets, and so on and so forth.

A UML model of class concurrent associations

Modelling languages are made out of symbols; authorised combinations of these build expressions. As a whole, they can be seen as the grammar of models, thus meta-models. In order to write out models, an Information Engineer is bound to master such tools, if he wants his constructs to be understood by colleagues and production teams who share his lingua franca.

A TIM task model of a lock gate operation

The models shown above are expressed via graphical conventions. The textual model of the conditional task appearing in the TIM model above is as follows:

T01.1.1 [Closing the chamber facing the bow of the boat].

Pre-condition: S01 [status : open ; O01* [gate]]  v  S02 [status : open ; O02* [gate]] ^ P01 [location : between ; O03* [lock chamber] O01*, O02*] ^ S04 [location : in front of ; O03*, O05* [bow of boat]].

Input: ¬ S03 [status : closed ; O03*].

Output: S03.

Side-effect: S

A01 [click ; O04* [button]] ^ P02 [function : command of ; O06* [light], O04*] ^ PO3 [position : on green ; O04*].

A02 [click ; O04*] ^ P04 [function : command of ; O08* [door], O04*] ^ P05 [position : open ; O08*].

A03 [click ; O04*] ^ P04 [function : command of ; O09* [valve], O04*] ^ P05 [position : open ; O09*].

Textual modelling languages include the very popular HTML as well as the major tool for structuring content, XML. Meta-models set powerful constraints on what can be expressed via their syntax, lexical span and semantics. They insure that models obtained by using them are free of any type of ambiguity, consistent and coherent.