The LexiCon set of programs [1] and way of working is one of the main building blocks of the eConstruct project. The LexiCon will provide the means to deal with multiple classifications and languages, making it possible to identify objects regardless of the language or classification system that is used. It is called LexiCon (with a capital C in the middle) to make clear that it is a specific product and thereby to distinguish it from the generic term lexicon.

Inner workings of LexiCon

The LexiCon consists basically of three parts:

The LexiCon Explorer

A computer program used to view, create and edit vocabularies (lexicons) according to the LexiCon meta-model.

The LexiCon SpecExplorer

A program to view, create and edit information about a specific project or object in the 'language' defined by a specific vocabulary (a lexicon created by above LexiCon tool).

The LexiCon meta-model

This meta-model specifies the rules to which an implementation or a message must comply to be compatible with the other parts of LexiCon. The LexiCon meta-model defines what can be said and expressed using the LexiCon system[2].

To sum it all up, the meta-model specifies the rules by which one can create a vocabulary (a lexicon) in the Lexicon Tool. That vocabulary is used by the LexiCon SpecExplorer to describe real-world objects or projects (Figure 5-4).

Figure 5-4. The structure of LexiCon

Underlying model

Figure 5-5 shows the meta-model of the LexiCon, simplified for clarity. This meta-model will be explained more fully in the section called The model in Chapter 6 and is the basis of the ceXML model.

Figure 5-5. UML diagram of the LexiCon meta-model

Functional unit and technical solution

An important concept for the LexiCon is the FU/TS concept (meaning Functional Unit/Technical Solution). The idea comes from the General AEC[3] Reference Model (GARM) by Wim Gielingh. That boils down to a divide and conquer-like way of dealing with an object description. On one side one has a functional unit "something to stand on" and on the other side you have the technical solution "a floor supported by beams". The attributes and requirements of the functional concept are to be met by the technical solution, so that the requirements for the total solution are appropriately propagated to the technical subparts.

Figure 5-6. Explanation functional unit and technical solution ("the hamburger model") [W. Gielingh, 1988]

Influence on ceXML

One of the main points to be covered in this graduation project is testing the exchange of building/construction data with the LexiCon. The kernel of the LexiCon is the meta-model it uses. Within this meta-model, the LexiCon can describe items in multiple languages and it can link items to multiple classifications. These possibilities make it a needed ingredient of eConstruct and, likewise, this LexiCon meta-model will serve as a design guideline in the creation of a ceXML vocabulary. I call it a design guideline (I will not use the exact meta-model). Another reason for this is that I will implement the meta-model in XML[4], which will bring about some changes to the meta-model.



The LexiCon is made by STABU, a Dutch organisation which (amongst other tasks) builds a information system covering the entire building process.


When seen this way, the information that is put into the LexiCon system is basically a model. I present it in this way because I use the information in the LexiCon system as a vocabulary. This vocabulary serves as a model to which the communication in my system complies. Thus, the level above that vocabulary is - from this viewpoint - a meta-model.


Architecture, Engineering and Construction


"Implementing the meta-model in XML" in this case means that I write a DTD according to the information in the meta-model. Any XML file complying to that DTD can be said to comply to the meta-model.