T1400 Tender Stage Information the Lexicon

Classification: Restricted

CONCON CURCUR

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 Draft q Report Reference Date 8/12/99 TW * IVO * No. SKA * R1401 TNO * DUT * Status Draft/Issued/Revised Rev. VTT * Revised 2 KTH * STABU * Date Release to CEC

1 WWW 6/3/2000 -- CEC

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 Dutch

UnitName S[0:?] LexiCon Name SymbolName S[0:?] QtyName S[0:?] QtySymb S[0:?] ] ? :

0 BltObjQty S[0:?] [ S Quantity e

m CompQty S[0:?] Symbol a ] N ? j : b 0 [ O y ] t t ] FunName S[0:?] S l

? ? t : Q B i : 0 n n 0 [ [ u U S S F y

t b Q m

BltObjFun S[0:?] y

Built Object Function S t i n U

Specializ. Component Specializ. S[0:?] S[0:?] 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 it in its definition. These associations however should be interpreted as typical instead of mandatory. For

3 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 combination of several values. For example, the ‘quality class’ of ‘concrete mortar’ might include ‘strength’, ‘consistency’ and ‘chemical resistance’.

4 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.

SC SC SC

FC FC FC FC FC 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 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.

5 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 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 FC- SC 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 hierarchy. In a construction project in which an object is realized or altered, the composition hierarchy follows the design steps.

6 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. 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.

7 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”.

name named_type STRING

supertypes L[0:?] domain defined_type

entity_definition (ABS) simple_type

attributes L[0:?] enumeration_type underlying_type (ABS) domain base_type elements L[1:?] attribute STRING name (ABS) STRING aggregate_type upper element_type INTEGER lower INTEGER

9 Fig. 7. A simplified model of the EXPRESS language

The following table shows how the models can be mapped: Lexicon IFC Built objects All subtypes of IfcProduct + generic types. Quantities All attributes (names) of IfcObject Functions PropertySets Units Attribute types Values - Symbol -

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 IFC 1.5.1 1.5.1 PropertySet Express HTML

EXPRESS Data Manager PropertySet Access

IFC to LexiCon C++

LexiCon Access

Fig. 8. The system used to transfer the IFC model to Lexicon.