Classification: Restricted
CON
CUR
Brite-EuRam BE 96-3016
CONCURrent Engineering in Building
and Civil Engineering
T1400 Tender stage information – the
LexiCon
Authors
WP1
Kees Woestenenk, STABU
Contributions by
WP1
Anita Bouman-Eijs, TNO
Distribution
Date
TW
IVO
SKA
TNO
DUT
VTT
KTH
STABU
WWW
CEC
Draft q
8/12/99
*
*
*
*
*
*
*
*
Report Reference
No.
R1401
Status Draft/Issued/Revised
Rev.
Date
Release to CEC
Revised
1
6/3/2000
2
--
1. Introduction
As a result of several years of employing the Dutch National Building Specification system, STABU has
reached the conclusion that one of the major problems in the construction industry is the lack of a common
language. This language problem becomes visible when looking at the way information is exchanged
between applications and between participants, which is especially true for the stage between inception and
tendering. Instead of using a common information base during project development and reusing the
information stored in that information base, one might observe that data is gathered and stored on a per
application and per participant base, leading to redundant and therefore inconsistent data. Another
consequence is that providers of reference data – like STABU – have to maintain their own libraries, facing
the impossibility to synchronize data structures.
In this report, emphasis is on the LexiCon, a model development by STABU in cooperation with the Dutch
BAS organization and which forms one of STABU’s major contributions to the CONCUR project. The
aim of LexiCon is to provide a structure for a common language as meant above.
The LexiCon identifies physical objects and spaces as classes of interest for the construction industry, with
a scope reaching from the largest construction works (e.g. an Airport) to the smallest articles delivered by
manufacturers (e.g. nails or sand). Each class is defined by a set of attributes and each attribute is a class as
well. The LexiCon approach solves the problem of synonyms, homonyms and translations between
languages. The LexiCon is implemented in a relational database and the application provides an object
oriented interface to the underlying database. This interface supports both specialization hierarchies as well
as composition hierarchies.
The LexiCon will initially be populated with objects selected from existing sources, like classifications and
product catalogues, in at least two languages, English and Dutch, with the possibility of adding other
languages.
The LexiCon is based on ISO STEP, and intents to be populated and maintained by the users on a
worldwide scale, combined with local and individual extensions.
Within the CONCUR project the LexiCon will be used as a CASE-tool for the storage of the Objects of
Interest identified by the CONCUR partners. A link will be established between the LexiCon and the IMS
system at the level of the CONCUR/IFC151 schema that is to be used during the deployment trails. This
would involve viewing CONCUR data structures:

IFC entries

property sets (both those defined in IFC151 and CONCUR specific e.g. for piping)
 derived properties.
The CONCUR/IFC151 LexiCon work will be published via the LexiCon WWW-access module developed
by TNO.
2. The structure of the LexiCon
The structure of the LexiCon is very simple and straightforward in that it follows the approach of the
process industry in STEP (rather than the domain specific approach of STEP/AEC) with a generic
metamodel and an object library. It is based on ISO 10303-221:1997 (AP221) and ISO 15926 and is
similar, but less complex, especially in the way it is implemented, to the object libraries derived from those
standards. As in the object libraries, the LexiCon consists of a collection of types of objects, named Built
Objects, which are of relevance to the industry, which are described in a structured, computer-interpretable
way, by attributes (see Figure 1).
2
ID
English
LexiCon
Name
Dutch
UnitName S[0:?]
Quantity
BltObjFun S[0:?]
Component
S[0:?]
Function
Specializ.
S[0:?]
QtyUnit S[0:?]
FunName S[0:?]
UnitSymb S[0:?]
Symbol
CompQty S[0:?]
Built Object
Specializ.
S[0:?]
QtySymb S[0:?]
BltObjQty S[0:?]
FunQty
S[0:?]
BltObjName S[0:?]
SymbolName S[0:?]
QtyName S[0:?]
Unit
Reference
Fig. 1. EXPRESS-G Diagram (simplified) of the LexiCon
Built Objects are abstractions of artifacts resulting from, used or modified by, construction activities. The
scope of Built Objects reaches from construction complexes (e.g. an Airport) to commodities (like bolts),
and also comprises materials (like sand) and substances (like aluminum). Though Built Objects are in
principle tangible, spaces and other logical or abstract objects are regarded as Built Objects as well.
The term Built Object refers to a category of classes, in other words, a Built Object forms the top level of a
hierarchy of classes which are specialization’s of the same category. In this hierarchy, Characteristics of
Built Objects are inherited from the higher levels by the specialized classes. For example, a ‘beam’ is a type
of ‘construction’ and has a length of its own, and a mass inherited from the higher level Built Object
‘construction’. In its current implementation, the LexiCon only supports single inheritance, but this is only
a practical constraint.
Built Objects are known by Names, which are real-world terms. For example, ‘building’ is a valid Name for
a Built Object, and so are ‘door’, ‘pipeline’ and ‘hinge’. A Built Object may have any number of Names
associated with it, all of which are valid synonyms. For example, ‘beam’ and ‘joist’ refer to the same Built
Object. For practical reasons - to prevent redundancy in listings of Built Objects - one of the associated
Names has the status preferred. Names may also be in any language, which means the LexiCon can be
multilingual. Currently, only English and Dutch have been implemented, but any other language can be
added without a problem. Names in different languages are not direct translations, instead they refer to the
same Built Object. For example, in English ‘trap-door’ refers to a Built Object, which might be part of a
floor, a roof or a ceiling, whereas in Dutch these parts are referred to by different names. Here ‘trap door’
refers to different Built Objects in the LexiCon, because each Built Object has different Characteristics. It
also follows from the example that Names are not restricted to a single class, but may be used as
homonyms for several classes, just as is the case in everyday language.
Characteristics defining Built Objects are categorized into Composition, Functions and Quantities and
these are also regarded as class categories in the LexiCon. These classes are associated with a Built Object
when used in the Built Object’s definition. A Built Object may have any number of classes associated with
3
it in its definition. These associations however should be interpreted as typical instead of mandatory. For
example, a typical Function of a ‘floor’ is ‘physical support’, but this does not mean that every instance of
a ‘floor’ is actually employing this Function.
Composition refers to the internal structure of a Built Object; the parts (Components) of which it is
composed. Components in the LexiCon are Built Objects in their own right, with their own definitions (i.e.
their proper set of attributes). For example, typical components of a ‘joisted floor’ are ‘joist’ and ‘floor
sheeting’, which are both Built Objects themselves. In the LexiCon the list of typical components is not
necessarily exhaustive. It should always be possible to add components when instantiating the Built Object.
Functions are Characteristics that, when associated with a Built Object, define its possible involvement
(behavior) in its environment. In other words, a Function describes which role a Built Object may play.
Earlier, ‘load bearing’ was given as an example of a typical Function of a ‘floor’. A Function cannot be
quantified, as it indicates a role. Instead, it relies on Quantities to fulfill its role. For example, ‘thermal
barrier’ indicates a Function, relying on a Quantity like ‘thermal resistance’ for a description of the actual
performance. In the LexiCon, Functions form their own category of classes, also grouped into a
specialization hierarchy. For example, ‘thermal barrier’ is a specialization of the more general Function
‘barrier’.
Each Function is defined by a set of Quantities. As with Built Objects, Functions can have any number of
Names. When a Function is associated with a Built Object the Quantities associated with that Function will
be – indirectly – associated with that Built Object. From the viewpoint of the Built Object this means that a
Function-related Quantity is only relevant to a Built Object when the Built Object actually has to fulfill that
Function, otherwise it could be ignored. Because a Built Object may be involved in more than one Function
there are several sets of Quantities involved. While a Quantity may occur in several Functions, the level of
performance (the value of the Quantity) depends on the Function, and this implies that the value of a
Quantity associated through Functions may be different for each Function. For example, both Functions
‘load bearing’ and ‘physical barrier’ will have an associated Quantity ‘strength’, each with its proper, but
different, value. Both these Functions could be associated with the Built Object ‘wall’. If an instance of
‘wall’ is actually ‘load-bearing’ then the ‘strength’ related to this Function would be instantiated as well,
otherwise this ‘strength’ would not be of any relevance. The ‘strength’ related to ‘physical barrier’ would
still apply.
Quantities are Characteristics that can be associated with Built Objects, either directly or through
Functions. The term Quantity is a general term (borrowed from ISO 31: Quantities and Units for every
Characteristic that can be "quantified" (expressed in a value). A Quantity directly associated with a Built
Object is a property, e.g. ‘mass’ is a property of a ‘construction’. Quantities associated with Functions are
input (load), performance, activity and output, e.g., as mentioned before, ‘thermal resistance’ is a
performance related to the Function ‘thermal barrier’. Again, as with Functions, Quantities form their own
category of classes.
As with the other class categories, Quantities can have any number of Names. In addition to that, Symbols
are often used to represent a Quantity. For example, ISO 31 uses the Symbols ‘E’, ‘U’ and ‘W’ for the
Quantity ‘energy’. A Quantity needs a textual definition, which often will refer to some kind of standard. A
Quantity will be measured by a Value that will be expressed in a Unit. In the LexiCon, the Value is
regarded as a parameter, to be provided on instantiation. It is possible, however, to define a Value domain
in the LexiCon for a Quantity. A Value domain can be of several types. It includes the type of values
covered by the SI Quantities, and, in extension to that, also values which are expressed as classes (e.g. a
quality class for concrete mortar, or a RAL-number for a color), as well as values expressed as text (e.g.
‘red’ as the value of a color).
Also associated with Quantities are Units. A Quantity can have any number of Units associated with it. Of
course, there will be a logical constraint in the actual Units associated with a Quantity: A single Quantity
logically can only be associated with compatible Units. Compatible, however, includes Units that can be
converted into other Units, thus the Units ‘centimeter’ and ‘inch’ might be associated with the same
Quantity.
Units again form a category of classes, and the term Unit is also borrowed from ISO 31: Quantities and
Units. Like Quantities, the Unit classes form a flat list, and may have any associated number of Names and
Symbols. Depending on the Value domain of a Quantity, the category of Unit classes contains additional
Units compared to ISO 31, for example ‘class’ is a category of Units. This type of Unit must have a
definition in some document (see References, below). In the case of a ‘class’, this Unit could be a
4
combination of several values. For example, the ‘quality class’ of ‘concrete mortar’ might include
‘strength’, ‘consistency’ and ‘chemical resistance’.
All classes may also be associated with References. Again, any number of References can be associated
with a single class. References are external sources, such as standards and other documents. As mentioned
before, a number of Quantities and Units refer to ISO 31. But References may also be used to link existing
classification tables to the LexiCon classes. This way, the LexiCon classes can be approached through these
classification tables.
All classes also make use of single lists of Names and Symbols, ‘single’ means that Names and Symbols are
kept as unique entries in a list per language. This way Names and Symbols provide a ‘keyword entry’ to the
classes of the LexiCon.
In summary, the LexiCon is (a database) comprised of a set of interrelated classes, categorized into Built
Objects, Functions, Quantities, Units, as well as a list of (language dependent) Names and Symbols, and a
list of References. Built Objects are defined by (typical) Compositions, Functions and Quantities as
attributes. Functions have Quantities as attributes and Quantities consist of Values, which are expressed in
Units.
To be implementable, the LexiCon has to be populated with the Built Objects and other class categories and
their associated Names and Symbols in a specific language. It is anticipated that population of the LexiCon
will be carried out by local construction experts.
3. Contents of the LexiCon
A very important idea behind the LexiCon is the distinction between Functional Concepts and Solution
Concepts. Such a distinction was first made by Gielingh in his GARM, there called Functional Units and
Technical Solutions. Because of the way it was presented as a schema, this idea became known as the
‘Hamburger model’. For a similar illustration see Figure 2.
FC
SC
FC
FC
SC
FC
FC
FC
SC
FC
Fig. 2. Functional Concepts and Solution Concepts
A Functional Concept focuses on the behavior of a Built Object in its environment. In the LexiCon this
shows in the associations between Built Objects and Functions. Behavior is similar to function; in
Ekholm's ontological approach, a function is categorized as a mutual (external) property, in contrast with
intrinsic (internal) properties describing the parts of a system. The behavior of a Built Object is based on its
capabilities, and is triggered by requirements coming from its environment. In which environment a Built
Object will be placed is outside its own control, hence its definition should be independent of the
environment. That is why the environment is regarded as a triggering mechanism for behavior. The
behavior is how a Built Object reacts on the requirements of the environment, expressed in performance.
The Built Object is capable of performing, but it only performs when required to do so by the environment.
Behavior and appearance together make what the outside world sees of a Built Object. For example, a
'floor' is an example of a Functional Concept. We know what may be expected from a floor (the expected
behavior or functionality and related performance), without knowing how it is constructed. The idea of a
Functional Concept corresponds to a certain degree with the definition of Elements, in ISO/TR
14177:1994: "The physical parts and systems of a facility, each with a characteristic function (e.g.
enclosing, furnishing or servicing building spaces). Elements are defined without regard to the type of
5
technical solution or the method or form of construction. (…)". A Functional Concept differs from that
definition in that it is not limited to parts and systems of a facility, and that it is not restricted to a single, or
characteristic function.
A Solution Concept focuses on the internal structure, or Composition, of a Built Object, comparable with
Technical Solutions in GARM, as well as Ekholm's intrinsic properties, or the Designed Elements in
ISO/TR 14177:1994. In the LexiCon the Solution Concept is visible in the association between Built
Objects which form a Composition. The components of a Built Object together provide the capabilities of
the Built Object for its behavior to the outside world. There may be many Solution Concepts for a single
Functional Concept, where each Solution Concept is structured differently. For example, a ‘floor’ may be
resolved as an ‘in situ concrete construction’, by ‘prefabricated concrete slabs’, as a ‘timber construction’,
or by other solutions. Ultimately, one of the possible solutions will be chosen, in which case one
Functional Concept will be associated with one Solution Concept (see Figure 3).
The relationship between a Functional Concept and a Solution Concept is an inheritance relationship: the
Solution Concept inherits the Characteristics of the Functional Concept. Hence a Solution Concept ‘is a’
Functional Concept with additional Characteristics. These additional Characteristics are found in the way
the Solution Concept delegates the functionality of the Functional Concept to its components. Regarded the
other way around, the components together form a functional assembly, represented by the Functional
Concept. This also fits with the idea of ‘requirements’ as opposed to ‘design’. The ‘design’ is the proposed
solution for a set of ‘requirements’, in other words: ‘requirements’ belong to Functional Concept, whereas
the ‘design’ shows as the proposed Solution Concept.
FC
SC
FC
FC
FC
SC
FC
FC
FC
SC
FC
FC
FC
Fig. 3. Composition hierarchy of Functional Concepts and Solution Concepts
Hence, a population of Built Objects will be a continuous chain of Functional Concepts and Solution
Concepts. Each level in this chain will represent a level on which Design decisions have been made. These
levels reach from large complexes to small commodities. The LexiCon itself does not show a single
Composition hierarchy, but instead provides sets of possible Solution Concepts for every Functional
Concept-level, as shown in Figure 2. In a project this will result in a Composition hierarchy with fixed FCSC combinations, as shown in Figure 3.
4. The LexiCon as a Type Library
As discussed in the previous section, the LexiCon consists of a collection of types of objects (called Built
Objects in the LexiCon) organized in a specialization hierarchy. Projects can use these types as templates
for objects, which are part of the project. The natural organization of objects in a project is a composition
6
hierarchy. In a construction project in which an object is realized or altered, the composition hierarchy
follows the design steps.
Built Objects are described by attributes, which fall into the categories Functions and Quantities, which are
also types in the LexiCon. Quantities are measured in Units, the value of which should be provided when
the Built Object is instantiated in a project. The problem, of course, is which value should be given? The
LexiCon could provide support for this by means of its object structure. This structure could be used by all
sorts of general information, regulations, standards, research results, product information systems, cost
information systems and job recipes. Retrieving this information directly from the source normally requires
a lot of effort and is far from easy. And, in addition, one has to know of the existence of certain
information.
Regulations contain requirements about Built Objects. Many modern building codes formulate performance
requirements, instead of prescribing solutions. It should be possible to link these performance requirements
to Functional Concepts in the LexiCon. The LexiCon can then provide the possibility of associated
Solution Concepts. Some of these Solution Concepts could receive a type approval, as an approved known
solution. The user then not only gets the requirements associated with the Built Object, but can also browse
the LexiCon for solutions.
Definition
by Attributes
Categories of
classes:
Built Objects
Specialisation
hierarchy
Figure 4. View of the LexiCon interface.
Standards for the construction industry often provide minimum or maximum values for (product)
performances, as well as methods to measure these performances. The Quantity types used in standards
could also be part of the LexiCon. This way it would be easy to refer to the standard for the domain of
values for a Built Object’s Quantity. These value domains could differ between standards, which is
especially true at an international level. For example, Fire Resistance would be an international concept.
The required values however, as well as the method of measurement, could differ substantially between
countries. By referring to the values described in local standards such a Quantity could be localized.
7
The LexiCon might also provide access to results of research carried out by construction research institutes.
They could be involved in the decision making process of designing a Solution Concept for a given
Functional Concept.
Product information systems, and product documentation from manufacturers, provide suggestions for
Solution Concepts, which could be attached to the Functional Concepts in the LexiCon, preferably in such
a way that the specification of a selected product could be imported electronically.
The problem with current cost information systems and job recipes is that they are built upon their own
object types. The Built Objects of the LexiCon would provide a common base, thus providing
interoperability.
5. Web application
Within the CONCUR project the development of a web-version of the LexiCon is started at TNO. All
object data in the database can be accessed using an internet browser such as Netscape or Internet Explorer.
The web-version has the same kind of user interface as the off-line version of the LexiCon. Only the
functionality is restricted to browsing the object data. The user is not able to add new object data or change
the object data. In future it will be possible to discuss an object on-line by adding issues to an object and by
replying to existing issues. Also the voting for those issues could be done on-line. An overview of the
existing issues can be browsed using an internet browser and the web-version of the LexiCon.
The web-version is implemented using the internet technologies HTML (HyperText Markup Language),
ASP (Active Server Pages), VBscript and JavaScript. These technologies are used to retrieve the data from
the ACCESS database using SQL (Standard Query Language) statements. The JAVA applet dipuTree is
used to implement the tree-views. The web-version of the LexiCon will be made available for a selected
group of people. This restriction (... of beveiliging ? ...) may be implemented by installing the web-version
of the LexiCon on an intranet or extranet.
6. Use of the LexiCon in CONCUR
Within the CONCUR project the LexiCon will be used as a CASE-tool for the storage of the Objects of
Interest identified by the CONCUR partners. A link will be established between the LexiCon and the IMS
system at the level of the CONCUR/IFC151 schema that is to be used during the deployment trails. This
would involve viewing CONCUR data structures:
 IFC entries

property sets (both those defined in IFC151 and CONCUR specific e.g. for piping)
 derived properties.
The CONCUR/IFC151 LexiCon work will be published via the LexiCon WWW-access module developed
by TNO.
As an example, the product types in IFC 1.5.1 have been imported into the LexiCon, using a C++
application, developed by Robert Noack, KTH Sweden..
The result is shown in Figure 6, where the left column shows Built Objects with IfcFloor highlighted. Items
immediately below are generic types of the floor and have their own property sets. The right column shows
quantites at the top (i.e.,entity attributes) and functions below (i.e. property sets with properties). There are
currently no functionality to capture inserted information into property sets.
8
Fig. 6. LexiCon with the IFC model.
One of the problems to view the IFC in LexiCon is that IFC consist of some 280 concepts, each with its one
properties. This makes an automated transfer of the model desirable, however this is not quite
straightforward because of the different schemas they are described by. The IFC is defined mainly in
EXPRESS language, which has only generic concepts, such as entities and attributes, see Fig. 7. LexiCon
on the other hand is designed for handling construction specific information, and includes concepts such as
Built Object and Function, see Figure 1. Thus, mapping the two schemas have to include some semantic
rules, such as “If entity_definition::name is ‘IfcBuilding’ then create built object with that name”.
named_type
name
domain
supertypes L[0:?]
defined_type
(ABS)
simple_type
entity_definition
attributes L[0:?]
(ABS)
attribute
STRING
underlying_type
enumeration_type
domain
base_type
elements L[1:?]
STRING
name
(ABS)
aggregate_type
STRING
upper
element_type
lower
9
INTEGER
INTEGER
Fig. 7. A simplified model of the EXPRESS language
The following table shows how the models can be mapped:
Lexicon
IFC
Built objects
Quantities
Functions
Units
Values
Symbol
All subtypes of IfcProduct + generic types.
All attributes (names) of IfcObject
PropertySets
Attribute types
-
The IFC is modeled so that the number of classes should be minimized, which has led to the concept of
generic types. It means that the products in IFC are detailed to a certain level where the leafs of this
hierarchy tree have a list of generic types, e.g. the list for IfcFloor is SolidFloor, LayeredFloor and
ElementedFloor. There are recommended geometric representations for some of these types, and also
property sets that only apply to one of the generic types of a floor. The generic types are treated as subtypes
of Built Object in the Lexicon to be able to show the property sets in a common way.
The system developed for transferring the IFC model is shown in Figure 8. There are several tools for
reading EXPRESS models, here the EXPRESS Data Manager is used. It does include a mapping language
(EXPRESS-X) that could been used for transferring the IFC model to Lexicon, but since there are rather
few transformations and more database operations it seems to be an overkill to use that. Instead a small
C++ program does the job. An obstacle is that the predefined property sets is only defined in HTML
documents, using tables. Extracting the definitions to a database is necessary, a simple relational database
such as Microsoft Access is sufficient enough.
IFC
1.5.1
Express
IFC 1.5.1
PropertySet
HTML
EXPRESS
Data Manager
PropertySet
Access
IFC to
LexiCon
C++
LexiCon
Access
Fig. 8. The system used to transfer the IFC model to Lexicon.
10