# A Naming System for “The Internet of Things” Adapted to Industry - A Case Study in Electrical Engineering

Anne Dourgnon, Tuan Dang

► To cite this version:

Anne Dourgnon, Tuan Dang. A Naming System for “The Internet of Things” Adapted to Industry - A Case Study in Electrical Engineering. 6th IFIP International Workshop on Artificial Intelligence for Knowledge Management (AI4KM), Jul 2018, Stockholm, Sweden. pp.77-90, 10.1007/978-3-030-52903-1_7 . hal-03478013

HAL Id: hal-03478013

https://inria.hal.science/hal-03478013

Submitted on 13 Dec 2021

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# A Naming System for “The Internet of Things” adapted to industry - A case study in Electrical Engineering

Anne Dourgnon and Tuan Dang¹

¹ EDF R&D, Chatou, France
anne.dourgnon@edf.fr, tuan.dang@edf.fr

**Abstract.** The development of information systems (IS) in the field of electrical engineering represents a significant challenge: virtual reality has to be explicit and remain true to the functional and behavioral perception of real industrial objects. The digitization of processes, names and functions is, in any case, not all that simple. One needs to study reality to understand the underlying cognitive representations. This paper presents two points that we feel are important: the denomination of computer objects in relation to their real-world correspondence and the functional representation within the IS.

**Keywords:** Industrial Information System, IIS, Industry 4.0, IoT, IIoT, Conceptual representation, Functional representation, Semantic issue.

## 1 Introduction

As part of the digital transformation process in the era of what is called “Industry 4.0” we are investigating the cognitive representation of industrial equipment by field operators in a power plant. This investigation will allow us to create a better representation of an equipment, designated as “object” thereafter in the industrial information system so that its conceptual model reflects as better as possible its cognitive representation in the mind of field operators. The naming convention of an industrial equipment in the Industrial Information System (IIS) plays an important role in such representation and it reflects an implicit understanding of how an equipment is integrated and interact with the whole industrial process. From our experience, we observe that in existing practices, the designation of objects is tightly linked to the perception of the object in its environment. This is contrary to the view point of Ashton when he talked about the Internet of Things (IoT): “Ideas and information are important, but things matter much more” (Ashton, 2009).

The ideas and information about the object manipulated count much more during the evolution of the IIS because they are durable whereas things are changing depending on their revamping.

With this in mind, we feel that it would be impossible to develop Industrial IoT (IIoT) without taking into account two fundamental points about the cognitive representations:

- The first point concerns the designation of objects: relational vs position names.
- The second point concerns functional point of view: devices that cannot be represented 'as is' in the IS.

Naming convention should take into account these two points to help field opera-
tors to understand physical, behavioral and functional role of the equipment/device.

In the following chapters we will use examples to address these two points and present the lessons learned while developing intelligent IS dedicated to electrical engineering in power plants. We conclude our paper with the description of challenges which still need to be resolved.

## 2 “The Internet of Things”

In their paper about “The Internet of Things”, Gershenfeld, Krikorian and Cohen (Gershenfeld & al., 2004) consider "Naming is one of the primary functions of servers". They distinguished five names: "A networked computer has five different names: a hardware Media Access Control (MAC) for the physical address on the local network (such as "00:08:74:AC:05:0C"), an IP address on the global network ("18.7.22.83"), a network name ("www.mit.edu"), a functional name ("the third server from the left") and the name of a cryptographic key to communicate with it securely". Naming is indeed a key point in IIoT: an efficient codification of name helps to quickly identify the devices.

Let's take an example of the Instrumentation & Control (I&C) of a hydroelectric power generation unit. In this example, the I&C functionalities are done by Alstom's Controbloc automation cells. Let's see how the codification of names is done.

### 2.1 Relational names of devices

Figure 1 shows the excerpt of I&C's schema concerning the Controbloc controller. A controller has many names.

<figure><img src="image_2.png" /><figcaption>**Fig. 1.** Names of the controller in a hydraulic power plant's I&C schema.</figcaption></figure>
In this example, we can see that four names are used to designate the same device: CD1, CTB2, ULG21 and UR1.

Let's take the first name. The controller is designated as CD1 : Controller “Deux” (Two) of group No.1. This name is formed from the name “Controbloc” and the name of the Power Plant unit with which it is associated: here, hydraulic unit No.2. This is a *relational name* –or *associative name*.

What matters here is the relationship between the I&C device and other devices in
a given environment and context: the hydraulic groups, the control or display units,
the network and the computers. All this four names are expressing relationships with
the environment.

For Gershenfeld an al., it's a functional name ("the third server from the left"). We
will see in next paragraph (2) what a functional name is for us.

This codification of names is said “dynamic” as it reflects the operating mode of I&C system. Generally speaking, it appears that the systems of relational names are dynamic and reflecting a continuous nature of functional interaction between devices of a system. These interactions are due to functional links.

If no functional links does exist, no dynamic relation is to be created. This error is
sometimes found in models. For example, the relation between a cover and a tub does
not exist.

<figure><img src="image_3.png" /><figcaption>**Fig. 2.** Example of relation between a cover and a tub.</figcaption></figure>

The relation between Cover and Tub is artificial and, in fact, can evolve. For ex-
ample, a fitting cover can be introduced. So, definitely, this relation is not an object.

## 2.2 Position names of devices

Let's go in the hydraulic power plant, in the “real world”. Figure 3 is a photo showing
the top of a Controbloc Controller. You can see that this Controller has two names: it
is identified as “CG1”, on the left, and by “04 KAS 001 AR”, on the right.
<figure><img src="image_4.png" /><figcaption>**Fig. 3.** Example of position names used for the identification of an I&C cabinet.</figcaption></figure>

These two names have their own specific meaning.

**CG1.** The designation on the left “CG1” means: Unit main Controbloc. This name specifies that the Controbloc cabinet is *general* (main server), not *local* (slave servers). It’s the name used by the hydroelectric power operators.

It is coded and reads from left to right:

- “C” for Controbloc.

- “G” for “Group” and not for “General” (A “General Controbloc” is also referred to as a “Common Controbloc” and is designated as “C”).

- “1” for primary, as opposed to secondary, which is designated as “2”.

In this hydroelectric power plant, the controllers are not assimilated to I&C nor I&C to the Controbloc automation cells. The designation “CG1” explicitly mentions the Controbloc automation cells.

This name is not a relational name as CD1. Here, in the hydraulic power plant, people see *where* the controller is (near the hydraulic unit No.4). But they need to know which one of the Controbloc it is: it’s the main Controbloc.

**04 KAS 001 AR.** On the right, “04 KAS 001 AR” is an identification code: it is a technical designation referred to as the equipment system ID number. It is easily read from right to left; it is controller cabinet No.1 of hydraulic unit<fnref n="1" /> No.4:

- “AR” stands for cabinet (ARmoire, in French).

- “001” is the cabinet number.

- “KAS”: The KAS code is derived from the coding “K”, for plant "core" and “AS” for controllers. For hydroelectric power plant operators, the KAS code represents “everything connected to the Controbloc”.

- “04” represents hydraulic unit No.04.

<footnote n="1">¹ hydraulic unit = turbine + generator</footnote>
These equipment system ID numbers are part of an identification coding system borrowed from the nuclear power field and transposed here in the hydroelectric power field. The essential part of this designation is not its immediate meaning but rather its identification capability. In this respect, it is similar to the taxa of the nomenclature applied to living organisms (Simpson, 1961). This identification code relates to extrinsic implicits and groups together codes (AR, KAS), which seem as strange to us as do the Latin names of plants. That does not mean they are meaningless. They have meaning in a whole system context.

**Relative or absolute references.** In this I&C example, we note two systems of non-redundant names: the relational (or associative) names that correspond to *relative references* (used in the **information** system) as well as position names that correspond to *absolute references* (these are physical markers that actually exist in the field). Relational names are surnames, in the sense of supernumerary: additional name.

Relational names are dynamic, position names are in contrary said “*static*” as they do not reflect any interaction between devices. This fixed positions identification system could be qualified as *a discontinuous system*.

It is interesting to note that depending on the environment in which devices are deployed and thus their designation by users are very different. Concerning the example of Controbloc controller, in a hydroelectric power unit, some Controbloc are said “general” and some are said “local”. This difference does not exist in nuclear I&C where Controbloc controllers are also used.

So, when we compare to the five given names of the IoT, we see that the “real world” is much more complex.

## 2.3 Relational names and position names are complementary

Here's another hydroelectric power generation example. The valves are mainly large water control valves as shown here (Figure 4).
<figure><img src="image_5.png" /><figcaption>**Fig. 4.** Head valve of the Lau Balagnas hydroelectric power plant. (©EDF – Gilles de Fayet)</figcaption></figure>

Let's see the designation of the valves. The Engineering Team gave us a classification of all the valves (see below, left-hand column). In this classification are listed all the types of valves of the hydraulic power plant. The position names: “Spillway valve”, “Head valve”... coexist with the relational names “main system”, “auxiliary system”. We note that it is not the *type* of valve that matters but its *position* (head...) and its relation with its environment.

A digitization process was launched and, after digitization (right-hand column), most relational names have disappeared, because they have been considered obvious. Now there is no easy way to review the relationship between these valves.

<table><caption>**Table 1.** Classification of valves before and after digitization in the IS.</caption><thead><tr><th>Classification of Valve before digitization</th><th>Classification of Valve after digitization</th></tr></thead><tbody><tr><td><ul><li>- main system</li><li>o main valve<ul><li>o spillway valve</li><li>o head valve</li><li>o intake valve</li></ul></li><li>o secondary valve<ul><li>o stone trap drain valve</li><li>o water chamber drain valve</li><li>o etc.</li></ul></li></ul></td><td><ul><li>- spillway valve</li><li>- head valve</li><li>- intake valve</li></ul><ul><li>- secondary valve (stone trap drain valve, water chamber drain valve, etc.)</li></ul></td></tr></tbody></table>
<table><tr><td><strong>- auxiliary system</strong></td><td></td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;o main valve</td><td></td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;o water valve</td><td></td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;o oil valve</td><td></td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;o air valve</td><td></td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;o secondary valve</td><td></td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;o water valve</td><td>- auxiliary system main water or oil valve</td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;o oil valve</td><td>- auxiliary system main air valve</td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;o air valve</td><td></td></tr><tr><td><strong>- other control systems</strong></td><td></td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;o main valve</td><td></td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;o water valve</td><td>- other water valve</td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;o oil valve</td><td>- other oil valve</td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;o air valve</td><td>- other air valve</td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;o secondary valve</td><td></td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;o water valve</td><td></td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;o oil valve</td><td></td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;o air valve</td><td></td></tr></table>

The position names and the relational names naturally coexist in our cognitive representations. The classification before digitization clearly highlights this duality. The relational names and the position names are complementary and relational names should be conserved, even if they seem obvious. These two aspects must thus be maintained in IIoT, while taking care to make this information explicit. Otherwise, there is a risk that this knowledge may be lost as well as the risk of incompatibility of the designations used by the various IS.

The use of relational and position names are rather well adapted to the devices and equipment: the system is structural. We will see that the designation of things by their functional names is also a key issue in the IS.

# 3 Functional names

## 3.1 Structural vs Functional domain

The IoT let us think that everything is “object” and could be designed by relational and/or position names. We think that it’s not always the case.

Indeed, the second important point of our feedback concerns structural vs functional systems.

**Thermal units.** In the thermal units (fossil-fuel power generation plants), we build from scratch with standard devices plants which will realize energetic functions. The representation is “object oriented” and is moreover the one of the IoT.

These plants relies on a structuring system that conceptualizes the equipment. The standard devices have an identification code: French ECS (EDF Coding System) and German KKS (Kraftwerk Kennzeichensystem) for example. These coding systems
strongly differentiate the equipment. The input for the design of the functions is these
equipment codes.

On another side, expertise in exploiting hydraulic resources has been developed
over thousands of years. Nature “offers” functions: waterfall and stream to which the
infrastructures should be adapted. The waterfall or the stream do not have “tags”.
They are just there.

**Hydroelectric units.** In hydroelectric power plants, we adapt to natural and geo-
graphic constraints and construct specific plants: mountains, valley and water are each
time different! We have functions and we adapt equipment to these functions. Then,
the relation between equipment is required first: main system, main valve. And sec-
ond, the position relative to the function: “Head valve” means in fact “Head valve of
the waterfall”. An engineer told us that from an hydraulic power plant to another, he
had to learn again everything: the relations between systems and the positions of the
equipment do change. The waterfall itself does not have a tag, but the position of the
equipment does.

**Structural or functional?** It is not obvious to know whether or not a domain naturally falls within an object representation or a functional representation.

In the thermal units, equipment are strongly differentiated but functions are not.
Equipment may be included in several functions (a kind of overlap). The functions are
artificially drawn. One of the goals is to define functional "human-size" systems:
when a plant system features more than 9 sub-functions, the system is no longer con-
sidered "human sized". The delineation of functions is therefore accompanied by
breakdown rules, for example: "The creation of elementary systems having less than
10 actuators or sensors shall be avoided". Contrary to what takes place in hydroelec-
tric power production plants, the delineations of the functions of these systems are not
natural as they are simply not easy to grasp.

It is different for hydraulic power plants. In the turbine handbook, the input is a list
of all the parameters of the natural functions (rate of flow...). Facing these parameters
are the turbine characteristics which are needed. A few turbines are listed, with a lot
of technical characteristics.

In the building and operation of hydroelectric power plants, the functional repre-
sentation of equipment counts much more than the object representation of things
because most of the time, things have to be adapted to the environmental and geo-
graphical constraints to realize such elementary functions to achieve final expected
functions, taking the example of « waterfall » and “stream” to which the infrastruc-
tures should be adapted. There is little similarity between two generation plants. In
this field, the representation is functional.

Conversely, in the building and operation of thermal power generation plant, the
designation of things by their relational and position names is more dominant. Indeed,
things are much more standardized in thermal power plants, and similarity is very
present.
## 3.2 Functional conceptualization

**Water supply and Dam.** Let's take a look at the hydroelectric power plants along a valley. It is highly structured into functional assemblies as shown in the following figure «which is a graphical representation of all dams».

<figure><img src="image_6.png" /><figcaption>**Fig. 5.** Description of hydraulic structures.</figcaption></figure>

The functional sets are the following:

- A: everything which supply water,

- B: everything which stop the water,

- S: general systems.

As this diagram shows, the functional sets are strongly differentiated. They are often symbolized by manufactured objects: supply line, retaining structure or dam, etc.

<figure><img src="image_7.png" /><figcaption>**Fig. 6.** Two examples of functional groups.</figcaption></figure>
The manner in which the labelling is shown may lend one to think that these sets are equipment. Based on Lévi-Strauss studies, we would point out that it is the privilege of the highly differentiated functional representations to be labelled in this manner. These manufactured objects are themselves the remnants of functional groups maybe owing to the ancient history of hydraulic techniques. And this may be sometimes confusing.

In order to avoid any misunderstanding, the experts emphasize that these sets are in fact functions. They note: “Supply function”, “Dam function”, etc. which initially seems a bit odd but correctly reflects the underlying functional conceptualization.

**Functional Group.** A Functional Group "produces goods and services that others [i.e., other Functional Groups] can only obtain through it." (Lévi-Strauss, 1966). These groups thus exchange goods (in other words, equipment) but also services (in other words, transformations).

Let's see the diagram on a smaller scale.

<figure><img src="image_8.png" /><figcaption>**Fig. 7.** Description of a dam.</figcaption></figure>

The diagram clearly outlines three functional groups:

- Code G: everything used to produce electricity, symbolized by the hydroelectric units,

- Code F: everything used to return the water to the river, symbolized by the tailrace,

- Code E: everything for power transmission, difficult to symbolize.

We could think that the delimitation of the groups is due to geographical constraints. A technician said: "I know that the breaker of hydroelectric unit No.1 is there". But which function does the breaker belongs to? hydroelectric unit No.1? Or the power transmission system?
Greater detail must thus be provided to clearly differentiate the functional assemblies. Also in the following diagram, the expert clearly outlines the functional groups:

<figure><img src="image_9.png" /><figcaption>**Fig. 8.** Functional representation laid out by an expert</figcaption></figure>

In these highly differentiated systems, "you know where you are, in fact": "you're physically at the dam" because the context is implicitly represented.

Surprises are sometimes encountered in IS when a functional representation is modelled directly on an equipment representation: "someone placed a telecom function on a supply structure since a head valve was equipped with a telephone". In this case, the "telecom" function needs to be differentiated from the "general and common services" function to which it had been assigned.

**Wheel repair workshop.** Let's consider an example where we are physically in a workshop: here a wheel repair workshop. The planning of this workshop enumerates everything used to repair the wheel of the hydraulic power plant. The planning first describes the wheel around which the functional repair workshop is organized.
<table><caption>**Table 2.** Wheel repair workshop planning.</caption><tr><td>Functions</td><td>A hydroelectric power plant at the base of a large lake, features 4 vertical-axis Francis turbine generators rated at 90 MW each. It operates at peak performance. The turbine wheels weigh 40 tons each and measure 4 m in diameter; they are made of ordinary, non-alloy steel.</td></tr><tr><td>Planning</td><td>The wheels undergo periodic monitoring within the scope of the method.</td></tr><tr><td>Inspections</td><td>Annual inspection with checks of the cavity zones, dye penetrant testing of sensitive points to detect possible cracks and to measure labyrinth clearances.</td></tr><tr><td>Archiving of inspections</td><td>These inspections are recorded on standardized sheets.</td></tr><tr><td>Weekly analysis of findings</td><td>During the last inspection and based on the checks recorded previously, the plant manager noted a change in the size of the cavitation ranges on the wheel of Unit No.1, along the trailing edges of the vanes, camber side, near the connection with the belt. In addition, the clearances at the lower labyrinths are worse.</td></tr><tr><td>Weekly selection of interventions</td><td>He feels that an intervention on this wheel would be necessary as early as the following year:</td></tr></table>

The system is based on a functional representation where the functions are therefore explicitly formulated. Conversely, the object representations given in the introduction then become implicit: wheel, workshop, etc.

## 4 Challenges for IOT

"There are, in fact, only two true models of concrete diversity: one in terms of nature, namely that of the diversity of species; and the other in terms of culture provided by the diversity of functions<fnref n="2" />" (Lévi-Strauss, 1966).

Conceptualization is not the same for functional systems and structural models. In order to know which way to use, one must study and understand how it all works.

"There are several reasons why it is complicated for individuals to explain how they work", explains Sophie Le Bellu, who is committed to explaining expert gestures within the scope of her thesis, "work often requires an understanding of the body, incorporated knowledge. Man also has to deal with an undeniable language deficit:

<footnote n="2">² Our translation.</footnote>
there are no words to explain and express everything. Often people start by explain-
ing, then they stop saying "it's complicated". Another phenomenon, the concept of
social representations, does not make speaking easy either: the company has an idea
of what a given trade involves and the parties concerned themselves are an integral
part of this social vision" (Le Bellu, 2000).

The inability to express oneself may be associated with not only being unable to
find the right words or with taboos (everything relating to one's body in the corporate
environment), but also to mental representations that are too obvious to be made
aware of: and, as such, they cannot be formulated.

The last reason mentioned, that of the company's social view, should also be in-
cluded. If the IS takes an opposing view of a trade, by studying it under an object-
oriented prism when it is based on functional representation, it becomes difficult for
the interested parties to clearly express and formalize their thoughts within the pro-
posed framework. The explanations, the formalizations may be deficient -the expert
was unable to adopt the new framework- but they can also become excessive, over-
flowing the imposed framework: the expert requires notes, diagrams and other addi-
tional explanatory tools. Unconsciously, he attempts to re-establish himself within a
transformed model.

Then, the explanations that he provides do not stand on their own; they themselves
need to be explained. We thus shift from a nearly-wordless model to one that is over-
explained. The model of underlying understanding has itself shifted.

Today, we are in the era of the IoT. Following the interconnection of individuals,
there is every reason to believe that the objects themselves will be extensively inter-
connected. But redundancies due to functional mismatch can occur. The progress
toward the "digital factory" and the paradigm of the IIoT highlights the object model.
However functional representations cannot be converted 'as is'.

The functional representations are somewhat delicate as they feature a very strong
conceptual structure, derived from highly-structured technico-economic, and/or or-
ganizational, requirements. In the digital factory era, when expertise will no longer be
transferred by men, the digital machines must be able to keep track of and justify this
conceptualization. This notably wills that the outlines of the functional groups be
traced and retained. The functional outline diagrams that trace the history of each
installation must be retained.

The virtual world has transformed our way of looking at our real world. The termi-
nology of industrial reality is based on a system of position names while IS essentially
use a system of relational names, which interconnects the objects. The two naming
systems must nevertheless coexist; one cannot be substituted for the other. And the
second point, and possibly the most delicate: certain industrial realities underlie func-
tional conceptualizations that we cannot transpose into a world of objects without
distortion.

Communication protocols is an example of massive use of IoT concepts. An inter-
working framework now includes a semantic level (mostly developed with ontolo-
gies) where the naming conventions is a real challenge. That is the difficult question
that we have been working on.
The cognitive representation of industrial equipment by field operators in a power plant has to be included in “Industry 4.0”. This cognitive representation allows the operators to interact in confidence with digital systems: industrial maintenance can be done “as usual”. This requirement should be part of the standards promoted by “Industry 4.0” to guarantee the durability of the systems during the whole life cycle.

## References

1. Ashton, K.: That 'Internet of Things' Thing, RFID Journal (2009).

2. Chaussecourte, P., Glimm, B., Horrocks, I., Motik, P., Pierre, L., The Energy Management Adviser at EDF, ISWC, Sydney (2013).

3. Gershenfeld, N., Krikorian R., Cohen, D.: The Internet of Things, Scientific American, 76-81(2004).

4. Lambert, D., Saulwick, A., Nowak, C., Oxenham, M., O'Dea, D.: An Overview of Conceptual Frameworks, Australian Government/ Department of Defence, Defence Science and Technology Organisation/ Command, Control, Communications and Intelligence Division, Australia (2008).

5. Lévi-Strauss, C.: The Savage Mind. University of Chicago Press, Chicago (1966).

6. Le Bellu, S.: Capitalisation des savoir-faire et des gestes professionnels dans le milieu industriel, Mise en place d'une aide numérique au compagnonnage métier dans le secteur de l'énergie, Doctoral Thesis, University of Bordeaux II, Bordeaux (2011).

7. De Saussure, F.: Cours de linguistique générale. Payot, Paris, Nouvelle édition (2005).

8. Simpson, G.G.: Principles of Animal Taxonomy. Columbia University Press, New York (1961).

9. Sowa J.: Knowledge Representation: Logical, Philosophical, and Computational Foundations. Brooks/Cole Publishing Co., Pacific Grove, CA (2000).

10. Vanlehn, K., Van de Sande, B.: Acquiring Conceptual Expertise from Modeling: The Case of Elementary Physics, In: Anders Ericsson K. Development of Professional expertise. Toward Measurement of Expert Performance and Design of Optimal Learning Environments, Cambridge University Press, New York, 356-378 (2009).