Identifying concepts and relationships in building codes: classification system approach

Publisher’s version / Version de l'éditeur:

International Journal of Construction Information Technology, 1, 3, pp. 53-72,

1993

READ THESE TERMS AND CONDITIONS CAREFULLY BEFORE USING THIS WEBSITE.

https://nrc-publications.canada.ca/eng/copyright

Vous avez des questions? Nous pouvons vous aider. Pour communiquer directement avec un auteur, consultez la première page de la revue dans laquelle son article a été publié afin de trouver ses coordonnées. Si vous n’arrivez pas à les repérer, communiquez avec nous à PublicationsArchive-ArchivesPublications@nrc-cnrc.gc.ca.

Questions? Contact the NRC Publications Archive team at

PublicationsArchive-ArchivesPublications@nrc-cnrc.gc.ca. If you wish to email the authors directly, please see the first page of the publication for their contact information.

NRC Publications Archive

Archives des publications du CNRC

This publication could be one of several versions: author’s original, accepted manuscript or the publisher’s version. / La version de cette publication peut être l’une des suivantes : la version prépublication de l’auteur, la version acceptée du manuscrit ou la version de l’éditeur.

Access and use of this website and the material on it are subject to the Terms and Conditions set forth at

Identifying concepts and relationships in building codes: classification

system approach

Vanier, D. J.

https://publications-cnrc.canada.ca/fra/droits

L’accès à ce site Web et l’utilisation de son contenu sont assujettis aux conditions présentées dans le site LISEZ CES CONDITIONS ATTENTIVEMENT AVANT D’UTILISER CE SITE WEB.

NRC Publications Record / Notice d'Archives des publications de CNRC:

https://nrc-publications.canada.ca/eng/view/object/?id=7e792462-1e2e-41dd-9b34-24c01566e8af https://publications-cnrc.canada.ca/fra/voir/objet/?id=7e792462-1e2e-41dd-9b34-24c01566e8af

I de nt ifying c onc e pt s a nd re la t ionships in building c ode s:

c la ssific a t ion syst e m a pproa c h

N R C C - 3 6 9 2 8

V a n i e r , D . J .

1 9 9 3

A version of this document is published in / Une version de ce document se trouve dans:

International Journal of Construction Information Technology,

1, (3), pp. 53-72,

93

http://www.nrc-cnrc.gc.ca/irc

The material in this document is covered by the provisions of the Copyright Act, by Canadian laws, policies, regulations and international agreements. Such provisions serve to identify the information source and, in specific instances, to prohibit reproduction of materials without written permission. For more information visit http://laws.justice.gc.ca/en/showtdm/cs/C-42

Les renseignements dans ce document sont protégés par la Loi sur le droit d'auteur, par les lois, les politiques et les règlements du Canada et des accords internationaux. Ces dispositions permettent d'identifier la source de l'information et, dans certains cas, d'interdire la copie de documents sans permission écrite. Pour obtenir de plus amples renseignements : http://lois.justice.gc.ca/fr/showtdm/cs/C-42

IDENTIFYING CONCEPTS AND RELATIONSHIPS

IN BUILDING CODES:

CLASSIFICATION SYSTEM APPROACH

D J Vanier4

AIIS'I'RACr: Building codes, standflrds and regulations arc an essential part of tltc con. truction process . Primarily dcoling with new ｣ｯｮｾｴｲｵ｣ｴｩｯｮ＠ and life safety, the building code is one of the factors dicwting the direction of architectu ral and engineering design . There is eonsidcrnblc design information and knowledge contai ned in these documents a nd they nrc dirrlcult to represent using traditional computer ·ystcms. Expert systems have been ｵｾ｣､＠ to model small domain ｾｰｰｬｩ｣｡ ｴｩ ｯｮｳ＠ in building codes but do not model the m:tcro environment of a building code or formalize lhe intricme interweaving and relationships of the ingrained knowledge. The National Buil<ling Code of <.:anadu Classification System uses a rigorous investigation methodology to identify concepts I objcet.s in the building code and their rclntions.hips and Jlropcrlies. The nu tbor describes the classification system methodology and the daut storage requirements. Examples derived fro m tJ1c Natio nal Building Code o f Canada demonstrate how concept.s nre idcntlncd, tested, validated and recorded.

Keywords: Information technology, classification, building standards, knowledge, computers.

INTRODUCTION

There is considerable design information and knowledge contained in bujldingstan-dards regulati ns and codes (the term 'building code' i u ed in this paper) and this information and knowledge are difficult to represent using traditional computer ys-tems . Conventional knowledge representation uses expert sysys-tems (Sharpe 1991) to model only small domainsofbuildingcodes such a fire exits (Fryeeral , 1992), fire

ep-aration (Heikkila and Blewett, 1991) structuraJ loading (Marksjo and Hatjiandreou, 1985) or wind pressures (Marksjo et al , 19 9). However with the exception of

BCAider (Sharpe, 199:1 ), there are no products that represent the macro environment of n building code or formalize the intricate interweaving and relationships of comp -nents (the term 'concept' is used in thi paper) of an entire building code. There is a need for harmonizing the concepts and relations contained in individual building code and for standardizing these over complementary or alternative building codes.

The National Building Code of Canada (NBCC, 1990) Classification System u es a rigorous investigation methodology to identify the concepts and relation contained in a building code. ll employs a variation of Nijssen Information AnaJysis Modelling (Nijssen and HaJpin, 1989; de Waard 1992) to record the concepts and relation con-tained in the NBCC. The identification , testing, validation and recording of building code concepts and relations assi ts the encoding of the engineering and building sci-ence information and knowledgecontained therein. However, capturing thi inf . rma-tion and knowledge is a formidable task , venin the restricted domain of one building code.

'D J Vanier. Research Orriccr,lnstitute for ｒ ･Ｎｾ｣ｮｲ｣ ｨ＠ in Construction. Na.tlonal ｦｴ｣ｾ ･Ｓｲ｣ｨ＠ Council Cnnadu , Montreal

ｮｯｾ､Ｎ＠ Ounwa, nnu.Ja K lA OR6.

l11c lnterna ticmul Jounwl of onstruction lnfornmti nn Tcchnulogy. 1993, Vol 1. No 3, Page 53-72

Note: Di cuss ion open unllll June 1!194. The rmmuscript ror the pnper wos submiued ror review ond possible publi-cation on 22J unc 1993. © The University ofSnlford 1993.

THE PROBLEM

·Building codes are complex documents and, as a result, are difficult to represent accurately in electronic format: (1) Engineering and architectural design information is infinitely more diverse than conventional business data, (2) the fundamentals of physics form an integral part of this information, (3) many factors contribute to the evolution of a building code that are not logical at first glance or are not based on solid engineering or architectural principles, and (4) building codes are legal documents.

One only has to examine a simple, three-component arch to realize the complexity of engineering and architectural design information. Minsky (1986) exhaustively investigated this simple arch and demonstrates that considerable knowledge and experience is required for an infant to construct an arch using two columns and a span-ning beam: he believes that computers possess the same knowledge and reasospan-ning capabilities as an infant. If one were to represent this simple arch as a number of con-cepts and relations, it can be easily demonstrated that the information model would be . rich with detail. That is, considerable information is required, such as columns support beams, foundations should be level, columns must be positioned carefully, and beam support area should be maximized. This knowledge level is increased one order of magnitude if the infant or computer wishes to place a second arch on top of the first. Building codes may be orders of magnitude above this.

Building codes are developed by committee consensus; they typically evolve over time rather than adhering to a rigorous implementation plan. As new materials are developed or new hazards are encountered, building codes are modified. Typically the new provisions are appended or inserted into the existing linear structure in the most expeditious fashion by the code writing bodies. This contributes to the apparent com-plexity of these documents. In addition, building codes are legal documents and there-fore have an extra degree of intricacy: every letter, word and punctuation mark is checked by a team of discipline experts, technical editors and lawyers. Even after all this review, revisions and errata are always issued. One can easily see that representing building code knowledge and information in computer format is difficult.

MODELLING

To understand a complex mechanism, an elaborate procedure, a computer prog-ram, or a domain of knowledge, one must have a mental or physical image of the salient functions of that thing. Modelling, such as product modelling, is one way to rep-resent complex information. In some cases it is not necessary to have a complete model of the thing, but only those components that affect the area of interest.

Modelling generally serves three purposes: (1) to test alternatives, (2) to record decisions, and (3) to communicate ideas. This might be an oversimplification but gen-erally these three reasons justify why we build and use models. If we could remember the whole knowledge base about a thing, there is only need for that mental model. A set of architectural or engineering drawings is a model of a building. It allows the desig-ners to test alternatives such as "how many beams support the snow loads?" or "should the corridors be wider?" It also records the decisions made by the designer and saves them for future reference and testing. For extremely simple buildings, experienced contractors do not even need plans or specifications, they have a mental model. A model is one way to represent the knowledge and information contained in a building code.

NBCC CLASSIFICATION SYSTEM

The general hypothesis of the Classification System is that a structure of concepts and relations exists in the NBCC. It has not been formalized to date, although it is understood by knowledgeable practitioners. The NBCC Classification System is therefore a model of the engineering and architectural relations among concepts within the delimitations of the building code.

Other papers on the topic of the NBCC Classification System (Vanier, 1991, 1992) have identified numerous advantages of such a model such as:

* A retrieval system to extract NBCC custom codes

*

A classification model for provincial building codes, national codes and construc-tion standards

*

A verification tool to assist code writing bodies

*

A model to assist the production of new publications based the NBCC

* A classification system to assist future development and research in electronic build-ing codes.

However, there are many obstacles to overcome before reaping these benefits. There are five major problem areas that must be overcome in order for the NBCC Classification System to succeed. The first relate to the actual size and complexity of the NBCC. The second is how to identify and record knowledge . The third is the size of lhe investigation domain oft he constn1ction industry. Th fourth i · ·olving circular-ity problems in a complex interwoven domain. The last deals with the intended use of the Clas ification System: Can one model satisfy the demands of a wide selection of potential users? It is hoped the completed Classification System addresses all these problems.

CLASSIFICATION SYSTEM APPROACH

The Cia ification System models the concepts and relations contained in the NBCC. The approac h adopted for identification, classification and recording of these concepts and relations relies on the vernacular and text of the source document. The ge ne ral procedure fori o lating the concepts and relations is to identify technical terms in the NBCC, find the relations between these terms, itemize their properties and the values, and record everything in a database. Computer tools have been used exten-sively to examine the contents of the Articles of the NBCC. Word proximities, word repetitions and synonyms provide links to other concepts.

Conventions

A number of conventions for representing the components of the NBCC Clas ifica-tion System are used in this paper. Concept a re rea l or abstract components refer-enced in the NBCC; when identified in the text they arc enclosed in square parenth-eses (eg,. [Buildings], [Structurai_Design]) . Relations are the association between two or more concepts and are shown in angle parenthesis (eg, <fype_of>, <Part_ of> ,

<Derived_from> ). Properties of a concept ｾｲ･ｩ､･ｮｴｩｦｩ･､＠ as rsuildings!Height and the property values as (I storey

I

2 storeys}. Boolean logic is represented u ·ing round parentheses with the AND and OR operators as in the example: ((Live AND Load) OR (Live AND Load )). An asterisk' * at the end of a term means a wild card of any number of characters such as (Live AND Load") .

The NBCC Classification System consists of the Concept Identification Methodol-ogy, Data Collection Sequencing and the Data Structure.

Evolution of the concept identification methodology

This section and the following describe rhe methodology for extracting the lassifi-cation System concept , relation and propcrtic . The methodology was developed using an evolving process refining the stage a more experience wa gained with investigating and rec rding thi information . The (irst portion i presented in its chronologica l order. The reason for de cribing th evolution of the methodology is to outline the significance of various features and parts , and to identify advantage: · and disadvantages of specific versions . The final methodology for extracting th compo-nents of the Classification System is hown in Figs.l to 5. Tt is been broken down into 5 epa rate flow charts fof presentation purpo e on ly· but it con ' titute a continuous , unbroken series of steps.

First Version : At first, a simple structure was adopted. It consists of identifying a con-cept, recording it and investigating it. Although naive, it serves well for self-contained concepts but fails when concepts were intertwined or heavily hierarchical. A view of this first model is shown in Fig 1.

Second Refinement: The second version of the methodology provide an audit trail and future investigation list. This version enhance the methodo.logy by tracking what has been investigated as well as what is identified for future concept investigation . Thi is a self-contained subroutine depicted in Fig 1 (c) and is used throughout the methodol-ogy.

Third Refinement: At this time in the investigation of concepts it was discovered that alternate vocabularies are used in different Parts of the NBCC and sometimes even in the same provision. It was made clear in the investigation of [Lighting] when no refer-ences was found for [Daylighting] in the NBCC. This indicates the need for a thesaurus. Subsequent investigation into the Canadian Thesaurus of Construction Sci-ence and Technology (TC/CS, 1978; Vanier, 1992a) identified a need for providing the widest possible vocabulary for each concept, relation and property. In the case of [Daylighting], the NBCC term is [Natural_ Lighting].

Fourth Refinement: The TC/CS also provides a comprehensive generalization and aggregation (ie, <Type_of> and <Part_of>) hierarchy in its form of Broader/Nar-rower and Wider/Part Terms, respectively. This greatly reduces the amount of time required to develop these relations for the Classification System. For example, [Emergency_Generatorsj are a <Type_ of> [Eiectrical_Generator

J

and [Emergency_ Generators] are a <Related_ Term> to I Auxiliary_ Generators]. The detailed TC/CS analy i of con ｴｾｵ｣ｴｩｯｮ＠ industry terminology is invaluable in the initial development of the aggregation and generalization relati n for U1e Classification System.

Start with NBCC Definitions

Pcrf<)nn Boolean Search for all words in Phrase

Concept lnv.cstigatlon Methodology

All Subroutines are enclosed in outlined boxes

Investigate Concepts

Subroutines

Examples

Ｑ｜ｾﾷｲＺ･ｳｳ＠ ro exir ｭ･｡ｮｾ＠ that part ol a me£/lls '!(egres.r within a

floor area that ...

I. I .2.1. This Code appl ics to the design. construction and ncmpancv of new

lmildings. and the alrerarinn

Part 4 Structural Design

Part 3 Usc and Occupancy Part 9 Housing and Small Buildings

Investigate Concepts

Deli nc the domain Examples Acouticallnsulation 17 INSULATED 191NSULATING 180 INSULATION I INSULATIVE OACOUSTIC* Thermal Insulation Rating Sound Insulation Airhorne Sound Insulation in Buildings

High-Temperature Thermal Insulation 111e1mallnsulation, Cellulose Fihre, Loose Fill

Insulated Steel Doors Insulating Fihrchoard Insulating Glass Units

Sound or Acoustic and Insulation

Sound Control Sound Transmission Class

9.11 Sound Control

9.11 I Sound Transmission Class Rating (Airhorne Sound) "Classification for Rating Sound Insulation," "Lahoratory Measurement of Airhomc Sound Transmission

Loss of Building Partitions"

ASTM E413, "Ciassilication for Rating Sound Insulation." ASTM E336. "Measurement of Airhome Sound lnsulntion in

Buildings.

Sound Insulation

Create new Concept or alter existing Concept Paste Preliminnry search on

Concept record Perform word proximity

Search

Establish hierarchical domain Parent Part I Parent Type

Child Part I Child Type

Create New Concept Investigate Concepts Investigate Concepts Examples Sound Insulation Sound and Insulation Sound Insulation Insulation for sound aborption

Sound Control Sound transmission class ratings Airborne Sound Transmission Loss

Rating Sound Insulation Airborne Sound Insulation

Part Type

Parent

Child

sound and

transmission or insulation or control

Perform full context search

Review individual context relations

Check Thesaurus for alternate terms

Drtailed Conccp Investigation

Examples sound and

transmission or insulation or control lighting and sound effects alarm signal has sounded 3.3.4.6. Sound Transmission to restrict sound transmission 9.11 Sound Control

9.11.1. Sound Transmission Class Rating 9.11.2. Required Sound Control ｌｯ｣｡ｴｩｯｮｾ＠

9.11.1.1. Determination of Sound Transmission Class ｒ｡ｴｩｮｾｳＮ＠ . . 9.11.2.1. M1mmum Sound Transm1ss1on Class Ratings

a sound transmission class rating of at least 50 a sound transmission class rating of at least 55 Sound Insulation is a material used to reduce the sound transmission through assemblies soundproofing sound retardant sound resistant sound pressure sound power sound measurement sound loudness auditory thresholds sound levels sound intensity sound propagation acoustical correction Isolate 3 NOISE sound refraction sound diffraction sound barriers sound baffles sabine coefficient absorptivity sound absorbants reverberation time room acoustics diffused sounds musical sounds speech sounds transient sounds auditory perception noise(acoustics) structure borne noise background noise air borne sounds impact sounds masking noise white noise electroacoustics vibration insulating sound attenuation 2 AUDIBILITY 14AUDIBLE 31MPACT 8 WHITE 10 VIBRATION 7 VIBRATIONS I AUDIBLY I MUSIC

Sound or Noise or Acoustics and

Insulation or Barrier or Isolate or Separate

Investigate Relations

Examples Background Noise Lighting and sound effects Sound Transmission Class

ASTM E413

Classification for Rating Sound Insulation ...

'Vbackground noise v'lighting and sound effects

ｾｳｯｵｮ､＠ transmission class

background noise lighting and sound effects sound transmission class ASTM E413

Classification for Rating Sound Insulation ... ASTM E413

Classification for Rating Sound Insulation ... Standard_fo:

Sound or Noise or Acoustics and

Insulation or Barrier or Isolate or Separate

Rctum to previous Concept

Related Terms or RTs are fundamental to thesauri and provide additional informa-tion for the development of the Classificainforma-tion System. Related Terms, unfortunately, do not describe the type of relationship that exists, such as [Importing] <Related_ to> [Exporting].

Two other features of the TC/CS assist the devel pment of the Classification Sys-tem namely UF and US or <U ed_ for> terms and <Use> terms , respective ly in Class ification System vernacular. These provide colloquial terms along with the proper technical term. For example, [Abra ive_ Paper

.I

is <Used_for> [Emery_ Papersj and for (Emery_Papers] <Use>[Abrasive_ Paper

1.

The US and UFterms are recorded in the Classification System and used as ynonyms for ea rching.

Fifth Refinement: Words in close proximity are semantically related (Ruge and Schwarz,l991). Thi led to the next refinement for capturing words in proximity to concepts under investigation . These term are recorded in the concept association list as shown in Fig 3 and they provide additional vocabulary for earching.

Sixth Refinement: It is necessary to investigate the possible 'application oriented relationships' (Brodie et al, 1984) of the NBCC. A large portion of these relations are in the architectural or engineering domain or in the form of regulatory provisions. This implies that conventional relations from other domains or generic domains such as <ls_a> or <Part_ of> are not the only ones that are needed for representing the heuristics in the architectural or engineering disciplines.

In addition, relations, like concepts, must also be parsimonious otherwise the voc-abulary grows unacceptably; that is, redundancy and inaccuracy is introduced and vag-ueness results. Relations, therefore, must be investigated with the same rigour as con-cepts as they possess the same aggregation and generalization characteristics. For example, <Adhered_to>, <Welded_to>, and <Taped_to> are all specialized instances of <Permanent_Hxation>. The methodology outlining the steps for inves-tigating classification of relations is included in Fig 5.

Seventh Refinement: Properties and their values, like concepts and relations, should also be parsimonious. By definition, a property must be consistent throughout the data set. The methodology outlining the steps for investigating classification of properties is included in Fig 5.

Description of concept identification methodology

Although the procedure described in this section might not be optimized to extract the Classification System components, it is rigorous and methodical. It ensures that all occurrences of terminology are quickly and efficiently located; that loose ties are not overlooked; that related provisions are not omitted; and that variations in terminology are identified and investigated. Even in the seemingly small domain of the NBCC, the problem of identifying concepts, relations and properties is nontractable, because of the complex engineering and architectural heuristics. It is therefore nece sary to dis-sect the problem into the smalle. t manageable components and solve these problems first; and then proceed from detail to global. Thi analysis of the mall problems i an

important phase as it can reduce !1 horrifyingly large task into a number of manageable small ta ks.

Typically it takes only minutes to investigate one detailed concept. It can take as long a one week to invc tigate genera l concepts such a [Health] , [Structurai_ Pro-tection}. [Lighting] or [Insulatio n] ; but in doing so, a large number of more detai led concepts are identified a nd investigated.

Fig J through Fig 5 give a detailed flow chart of the steps in the Concept Identifica-tion Methodology . In su mma ry, the general procedure for investigating ClassificaIdentifica-tion System components is as follows:

(a) Identify Domain: Concentrate on the details first and broaden search as more con-cepts in a domain are investigated.

(b) Morphological Root : Select the initial term, check morphological root, and check for word occurrences in the document to identify the NBCC vocabulary domain. (c) Proximity terms : Search for related terms in close proximity to the subject term so

as to broaden the search domain.

(d) Full NBCC search: Search for proximity terms to find related terms and to estab-lish full NBCC domain.

(e) Create concept: Create new concept, capture word proximity, and establish hierarchical structure. ·

(f) Concept Details: Investigate concept in detail, establish relations to other con-cepts, and create definition of concept.

(g) Thesaurus: Check thesaurus for alternate terms in order to expand vocabulary to general construction terminology.

(h) Full broad search: Search NBCC with the expanded vocabulary derived from the thesaurus.

(i) Identify relations: Examine relations to other concepts indiviciw=tlly.

(j) Establish new relation: Use steps (a) to (h) to identify the full domain of a relation. (k) Identify properties and property values: Develop properties and their values of the concept and distinguish these from relations. Use steps (a) to (h) to establish full domain of a property.

Data collection sequencing

The previous section dealt with the micro-level of the investigation; this section deals with the Data Collection Sequencing and the macro-level of the investigation. Namely, what is the sequencing for concept examination or what are the first concepts

to investigate?

The NBCC is a logical document containing standard Definitions, well-defined Parts, consistent formatting, and reli able engineering and architectural information. All of these provide clues as to possible sequences to investigate the concepts and rela-tions.

Owing to the complexity of the NBCC and the variation in the Parts, there is no opti-mal way to approach the problem of where to start and how to proceed. The Data Col-lection Sequencing, forming the top part of Fig 1, was selected as a logical procedure

for starting the Concept Identification Methodology and for identifying which would be the subsequent investigation areas:

(1) Identify the Domain of Interest: The domain is the restricted portion of the NBCC investigated at one time. Typically, this would involve a physical portion of the NBCC, but in some cases this would be a conceptual selection of ideas. For exam-ple the domain could be Part 5 of the NBCC or the restricted domain of [Ther-mal_Insulation] within the global concept of [Insulation].

(2) Start with Definitions: There are 158 official Definitions in the NBCC. These are all concepts or properties. The majority of the Definitions are concepts and are very general in nature. However, some Definitions are properties of concepts that are not Definitions such as [Walls] Resistance_Rating and [Ceilings] Fire-Resistance_ Rating.

(3) Do small self-contained portions of the document: Parts 1, 2, 5, 6, 7 and 8 are rela-tively short and are self-contained domains. Part 2 proved interesting because it is primarily a list of 255 related standards; each is a concept with relations to other standards. Parts 5, 6 and 7 contain less than 5 pages each and are self-contained domains with little relationship to other Parts. Part 8 deals with the construction and/or demolition site and provides considerable knowledge about temporary structures and site safety.

( 4) Proceed from specific to general concepts: General concepts are very difficult to investigate without a good understanding of the domain. This is necessary because of the use of uncontrolled vocabulary in building codes (Fenves et a/1976) and the use of similar terms in unrelated domains; [Insulation] is an example covering a broad spectrum from acoustics to thermal protection. Fenves et al (1987) suggest always proceeding from small objects to larger objects; this advice should be fol-lowed.

(5) Do each concept rigorously: It is only through thorough evaluation of a concept that its relations are established. Cursory evaluation of concepts or inattention to terminology have both contributed to initial misunderstanding of concepts. The [Insulation] example clearly illustrates the problems. [Insulation] is not only for keeping heat in, it can also be used for acoustics or for keeping heat out. In addi-tion, some insulations can be used for other functions, as in the case of an open-weave drainage material. Therefore it is important to evaluate each concept and relation rigorously.

(6) Do not break investigation continuum: Owing to the interweaving of concepts it is necessary to follow one thread at a time; record when a new thread is being investigated and return to previous threads 'when completed. This is common sense .

. (7) Proceed with terms at same level, then subclass, then superclass: Given the option of investigating a number of potential concepts related to the one in question, it is best to select those at the same structure level. This adds more definition to the current investigation. Proceed to the subclass level to meet the requirement of (3) above. Finally, investigate the superclass to define the entire domain, once the macro level has been thoroughly analysed.

Data structure

A graphical representation assists the description of the intricate relations between concepts (de Waard, 1992). However, this proved difficult to control physically using conventional Nijssen Information Analysis Method (NIAM) modelling. This necessi-tated developing software that controls the recording of information and that permits changes depending on the evolving modelling requirements.

The concepts are stored in records as shown in Fig 6. All the information regarding one concept is stored on this record. The superclass information is recorded on this record for the concepts, the subclass relations are derived from its subclass's records (the italicized words signify derived data from other records). To simplify the presen-tation of the information a number of fields are hidden such as the Definitions field and the Article field. These can be displayed by clicking the appropriate button on the screen. ｬＡｨｴｾｯＺｊｩｷ＠ ｯｵｾｴＺＺｲ＠ .Mi.7f1.v· fo'i'M::k'f',. Pan_ of

11

nherited Properties

I

Pan_of Properties

0

S10rage Garege Heating

0

Yes,No

0

Properties

S10rage Garage At111ehmen Built in, At111Ched ,Dew:

RelatwD3

£.

ｾｾＡＺｴＡＺｃｾｰｪ＠

Relations

I

0

Ticket and At12nd.ant Booth:!

0

Figure 6: Concept record displaying field information

Classification system data fields

Any field contained in the concept record can have one-to-many relations. This means that any concept can have any number of <Part>, <Part_of>, <Type>, <Type_of>, properties, inherited properties, and relations. The following fields are used for data storage:

Superclass type: This field in upper right of Fig 6 contains the super lass <Type_of> relal:ons of concepts. Relations are estab li hed explicitly for the supercla s <Types> by the person doing the classification. Only an existing concept can be added to this field; if it does not exist it is created using the Concept Identification Methodology. The examples in Fig 6 can be read as [Storage_ Garages] are <Type_of>

l

Garages] and are <Type_of> (Divi ion_3 (Group_F)).

Superclass part.·This upper left field in Fig

6

contains the superclass <Part_ of> rela-tjons of concepts. Relations are established explicitly for the uperclass <Parts> by the person doing the classification. As with uperclass types, only an existing concept can be added to this field. There are no superclass <Parts> for [Storage_Garages] in Fig6.

Subclass type: For both the subclas <Parts> and <Type > , the relations are made by reference. Tbat is , the Superclass relation are ' tored on the concept record and the subclasses are derived (rom all concepts that have [Storage_ Garage ·] a a uperclass. These are calculated each time a concepti viewed . On a standard workstation, this calcuJation takes less than 10 seconds. In the example there are no subclass <Types> for fStorage_ Garages] .

Subclass Part: The example can be read as (Electrical_Outlets) are <Part_of> (Storage_ Garages] and (Motor_ Vehicles] are <Part_of> [Storage_ Garages].

Properties: Any concept can have any number of properties and each property can have any number of property values. ln the example in Fig 6, [Storage_ Garages] have . two properties [Storage_ Garages]Heating and [Storage_ Garages ]Attachment. The

respective property values are {Yes

I

No} and {Built_in

I

Attached

j

Detached}.

Inherited properties: Any concept can have any number of inherited properties and each inherited property can have any number of inherited property values. Concept properties a re normally inherited from <Type_of> relations and rarely fTom <Part_ of> relations. Fu1 ｾｸ｡ｲｮｰ ｬ ･Ｌ＠ [Storage_Garage. ] should logically inherit any properties from their supercla s <Types>. It would not be logical for [Motor_ Vehi-cles] to inherit ,ill properties from [Storage_ Garages]; in this example none would be remotely applicable.

Relations: In addition to the <Part> and <Type> relations, there are a number of others for (Storage_Garagesj uch a <Complie _ with> fParking_Structuresj, <May_ Contain> lFoundations] and < May_ Contain> [Tickct_and_ Atten-dant_Booths]. [Parking_Structures] is the name of a Canadian Standard Associa-tion (CSA) Standard.

<May_Contain> is the relation used to identify the fact that the relation is not man-datory, as in the case of the (Foundations] for the (Parking_ Structures].

Definitions: These provide the description of the domain for the concept. In the case of[Storage_Garages] this is a NBCCDefinition that means a parking structure. This . would be contained in the Definition field , in most cases it is the person doing the

clas-sification who establishes the Definition .

Storage garage means a building or part thereof intended for the storage or parking of motor vehicles and which contains no provision for the repair or servicing of such vehicles. ·

Associated Articles: The results for any search string are recorded in the file to indicate what has been found to date. This records the search terms used and the Articles meet-ing those criteria. With potentially thousands of concepts, it would be easy to forget what was the context of each search:

Search String: "garage,storage garage" in Article Field But Not: "repair garage" in Article Field

155166 Hits using Auto Expansion- Sentence Level Within 1 Word 2 NBC 1.1.3.2. Definitions of Words and Phrase-s (Definitions of 4NBC3.1.10.3.

2NBC3.2.1. Fire ...

2NBC3.:i.l.2.

Continuity of Firewalls (Firewalls)

General (Size and Occupancy Requirements for Storage Garage Considered as a Separate Building

Synonyms: The general principle i to record all the information used for the investiga-tion in the concept record . It is useful in classifying related concepts or explaining the reasoning behind the current classification. This field typically contains the synonyms identified in the thesaurus that were inve ligated.

automobile parking, garage, multistorey garages , parking facilities, parking garage, parking lots, parking structure repair garage, service station, storage garage, underground garages, traJfic engineering.

PILOT STUDY

The Pilot Study applies th principles of the Classification System, combine the e with the Concept ldentifir.flt ion Methodology , and identifies Classification System concepts for a representative small domain of the NBCC. A simplified version ol the NBCC Classification System is the Minicode Generator which is explained in detail in other technical publication (Vanier 1993).

Identification of concepts

It would be laborious and repetitive for the reader to follow the full methodology for identification of a concept. A representative sample is presented in this section. The steps identified in the Concept Identification Methodology have been followed: (a) Identify Domain: The example uses provisions dealing with earthquake

protec-tion, specifically with the concept [Live_Loads (Q)].

(b) Morphological Root: (Q OR ((Live AND Load*) AND Earthquake)) Occurrence Provision Provision Heading

s

2 3.2.2.49. Industrial Buildings, Division 1, up to 4 Storeys

3 3.2.3.14. Wall Exposed to Another Wall

1 4.1.2.1. Loads, Forces and Effects

(c) Proximity Terms: (Q OR (Live Load* AND Earthquake)) Provision Proximity Search

4.1.2.1. Q - live load due to wind or earthquake 4.1.3.1. D + Q

4.1.3.1. D + L + Q

4.1.3.1. Q is the specified wind load or two-thirds of the specified earthquake load

4.1.4.2. the factored load combinations shall be taken as

＼ｾｮｄ＠ + gy(a L + a0 Q + a, T)

4.1.4.2. ao

=

1.5 for wind or 1.0 for ea.rthquake 4.1.4.2. 1.0 when only one of the leads, L, Q and T in

Sentence 4.1.2.1. (1) acts 4.1.4.3. D +y[L + Q + T)

4.1.9.1. with a load factor aQ=l. 0

(d) Full NBCC Search: (Q OR (Live Load* AND Earthquake*) OR (Specif* AND Load*) OR (Factor* AND Load*)) identifies additional provisions.

Provision Proximity Search

4.1.9.1. The spec1fied loading due to earthquake motion 4.1.9.1. v minimum lateral seismic force at the base of the

structure, to be used with a load factor a Q =1.0.

(e) Create concept: [Live_Loads (Q)]

I <Part of> <Type of>

_I

I N/A Superclass (Loads]

_I

(Live Loads (Q)J

I

N/A subclass [Live_Load_Earthquak es]

I

[Live Loads Winds)

(f) Concept Details:

Definition Live load (Q) due to earthquakes means the load other than dead load to be assumed in the design of the structural members of a building.

(g) Thesaurus: The [Live_Load*] and [Earthquake*] search terms produces the fol-lowing results from the thesaurus search:

I

Who le Term Broader Term

'

I

N/ A loads

_I

live l oads

I Pa rt Term Nar rower Term _I

I N/ A N/A _I

Re l a ted Te rms st at i c loads

I Who l e Te rm Broader Term _I

I seismology natural disasters _I

earthquakes

I Par t Te rm Narrower Term _I

I

earthquake action N/A

I

faults (fractures) Related Terms seismic tests seismic waves soil mechanics

(h) Full broad search : Using Static OR Seismic OR Fault OR Disaster as new search terms in combination with the original search strategy produces alternative vocabulary.

Occurrence Provision Provision Heading s

2 4.1.9.1. c = s e ismi c coef fici ent f or me chan ic a l/ ･ｾ･｣ｴｲｩ｣｡ｬ＠ equipme n t

3 4.1.9.1. I - sei sm ic impor_t a nce factor o f the structure

1 4.1.9.1. _{za -} acceleration-related seismic zone 3 4.1.9 . 3 .

2 9. 20 .1. 3.

1 4.1.9.1.

_zv

- velocity-related seismic zone

3 4.1.9.3.

2 9.20.1.3.

1 4.1.9.1. equivalent lateral seismic force representing elastic response, v,. 2 4 . 1.9.1. seismic response factor, s

1 4.1.9.1. se ismi c p e r for mance o f a s tructura l syst em

2 4.1.9.1. seis.nic importance factor, I 4 4.1.9.1. total lateral seismic force, v

3 4.1.9.3. ve loc it y or acce ler a tion- r el ated seismi c

1 9.20.1.3. zones o f 2 and

3 4.1.9.3 . velocity - re lated seismic zones o f 4 and

1 9.20.1.3.

3 4.1.9.4 . ve l oc i t y-rel ated s eismi c Zon e 0

2 1.1.3.2. post-disaster buildings

1 4.1.8.1.

1 4.1.9.1.

1 4.1.9.2.

Fault is not a term used in the NBCC, Disaster is a word exclusively used in [Post-Dis-aster_ Building], Static is used in unrelated contexts, and Seismic is used principally for coefficients in equations. The relationship to [Post-Disaster_Buildings] is an

interesting discovery; associating earthquakes to the requirements of a specific class of buildings. The Seismic term introduces many of potential concepts including [Seis-mic_Response_Factor] and [Seismic_Zones

At this point it might be necessary to investigate these new terms before continuing to classify (Live_Loads (Q)]; as the investigation of [Seismic_Zones], (Post-disas-ter_Buildings] and the various seismic coefficients might assist the classification efforts.

(i) Identify relations: Two references identified in the search of [Live_Loads (Q)] are investigated to demonstrate the steps to qualify relations and the distinction from properties and their values. The following is examined as a new relation:

4.1.4.2. the factored load combinations shall be take n as a D + gy

r

a L + a Q + a T I

The following is examined as new properties and their values:

4.1.9.3. velocity- or acceleration-related seismic zones of 2 9 • 2 0 • 1. 3 . and

4.1.9.4. ve locity-related seismic Zone 0

(jj

Establish new relation:

Investigation of the relation between [Live_Loads (Q)] and [Load_Factor (a0 )] does not fall into the standard set of associated relations such as <Derived from> or <Determines>, which are used for formula derivation. The relation is more an associative relationship; that is, when Q is dealing with ･［ｾｲｴｨｱｵＱＱｫｾＬ＠ then a₀ = 1.0, otherwise for winds a_{0 =} 1.5. In this case a new relation must be defined and the related existing ones must be examined.

The result of this mini quest is that (Live_Loads (Q)] <Affect> (Load_Factor (a_{0 )]} and visa versa.

(k) Identify properties and property values: Two concepts already exist [Velocity-Related_Seismic_Zones (Zv)] and [Acceleration-Related_Seismic_Zones Za)]. Searching for only these individual concepts identifies the following proxim-ity words, aside from where Zv and Za were used as formula coefficients:

z - acceleration-related Zv - velocity-related seismic

a. .

SeJ..SmJ..C zone zone

acceleration-related seismic velocity-related seismic zone 0 zones of 2

acceleration-related seismic velocity-related seismic zones :z:ones of 2 and 3 0 and 1

acceleration-related seismic velocity-related seismic zones zones of 2 and higher of 4 and higher

acceleration-related seismic zones of 4 or greater

In this case a property and values are a logical cho.ice and <Type_of> relations would not be appropriate . By definition of the Classification System if there i only one fea-ture of one attribute that distinguishes a potential e ri es of subclass relations then this should be identified as a property. The results from furthe r investigation are :

[Acceleration-Related_Seismic_Zones (Za)]value ={ 0\ 1 \2\3 \4\5

i

6} [Velocity-Related_Seismic_Zones (Z3)]value ={ 0\ 1 \2\ 3

i

4 \5

i

6}

CONCLUSIONS

This paper fin alizes the research fi ndings for the NBCC Classification System pro-ject at IRC. It identi fies that building codes are complex docume nts that modelling techniques ca n be u ed to represent building code in formation a nd knowledge, th at thorough and rigorous investigation is required to ide ntify concepts in building codes and that data storage des ign mu t reflect tJ1e data to be collected . T he Pilot Study fo l-lows the development of the relation a nd prope rties for building code components related to only one concept. Identification of all the concepts and relations contained in the NBCC continues. It is hoped that new software for building code access will use information developed in this research project.

REFERENCES

Brodie, M.L. , Mylopoulos, J ., Levesque , H .J., 1984, An overview of knowledge rep-resentatio n, f rom Eds, J3rodie, M.L., Mylopoulos, J., Schmidt, J.W., Conceptual

Modelling: Perspectives from Artificial ln.telligence, Databases, and Programming Languages, Springer-Verlag. New York .

de Waard, M., 1992, Computer Aided Conformance Checking, Koninklujke Bib-liotheek, The Hague.

Fenves, S.J., Rankin, K., Tejuja, H.K., 1976, The Structure of Building

Specifica-tions, U.S. Department of Commerce, NBS Building Science Series, no. 90. Fe nves, S ., Wright , R.N ., Stahl F.l. , Reed, K.A ., 1987, Introduction to SASE:

Stan-dards A naLysis, Synthesis and Expression, NBSIR 87-3513, U.S . Department of Com-merce , National Bureau of Sta ndards.

Frye, M.J., Olynick, D.M ., Pinkney, R.B ., 1992, Development of an expert system for the fire protection requirements ofthe NBCC, to be published in Proceedings , CIB Joint Workshops on Computers in Construction, Montreal.

Heikkila, E.J. , Blewett, E.J., 1991, Using expert systems to check compliance with municipal building codes, Internal Report, Canada Mortgage and Housing Corpora-tion, Ottawa.

Marksjo, B.S., Hatjiandreou, M., 1985, De ve loping knowledge-based systems for building-design approval, Proceedings Natio nal E ngineering o nference: The Com-munity and Technology - Growing Togethe r T hrough E ngi neering.

Marksjo, ｾＮｓＮＬ＠ Sharpe, R., Holmes, J . , Fitchett, P., Ho, F., 1989, WindloaderKBS from prototype to the market, Proceedings of the Symposium on Knowledge Based Systems in Civil Engineering, Civ Engrg Sys, 6(1-2) .

Minsky, M.L., 1986, The Society of Mind, Simon and Schuster.

NBCC, 1990, National Building Code of Canada, Tenth edition, Associate Committee of the National Building Code, National Research Council Canada, Ottawa.

Nijssen, G.M., Halpin, T.A., 1989, Conceptual schema and relational database design:

a fact oriented approach, Prentice Hall, New York.

Ruge, G., Schwarz, C., 1991, Term Associations and Computational Linguistics, International Classification, 18(1).

Sharpe, R., 1991, BCAider: PC software to help building code users and developers,

Proceedings, Innovation and Economics in Building Conference, Brisbane.

TC/CS, 1978, Canadian thesaurus of construction science and technology, Industry, Science and Technology Canada (formerly Department of Industry Trade and Com-merce), Ottawa.

Vanier, D.J., 1991, A Parsimonious classification system to extract project-specific building codes, Computers and Building Regulations, VTT Symp Series 125, Espoo Finland, Jun .

. Vanier, D.J., 1992, Details of a classification system to extract project- specific build-ing Codes, Proceedbuild-ings, CIB Jt Int Wksp on Camp in Constrn, Montreal (in print) . Vanier, D.J., 1992a, Canadian Thesaurus of Construction Science and Technology: A HyperCard Stack, Proceedings, ClB Jt Int Wksp on Comp in Constrn, Montreal (in print).

Vanier, D.J., 1993, Minicode generator: a methodology to extract generic building codes, Proceedings, CAAD Futures '93, Pittsburgh.

A NEURAL NETWORK APPROACH FOR REPRESENTING

IMPLICIT KNOWLEDGE IN CONSTRUCTION

T Hegazy, 0 Mosel hi and P Fazio5

ABSTRACT: Neural networks are AI-based computational tools with powerful capabilities of effective cap-turing pnd re-U<;e of domain knowledge that are inherently implicit. This paper describes the modelling capabilities of ncurnl networks with respect to construction problem , ｣ｭｰ ｨ ｡Ｎｾｩｺｩｮｧ＠ the adva ntages a socia ted with thci( representation of implicit knowledge in the form or pnllern . Severn! nspects rein ted to proper pre-processing and post-proce.•;slng of knowledge are addressed for the purpose or developing practical and m re rcliahlc neural network models of complex construction problems. The$t: aspects include: I) problem struc-turing and formation of input and output patterns; 2) knowledge acquisition and data validation; 3) prepara-tion and transformaprepara-tion of acquired data; and 4) analysis and interpretaprepara-tion of network state of knowledge. Guidelines pertaining to these aspects o.rc provided along with considerations for modelling with noisy duta and a high degree of uncertainty. 111c issues discussed are 111ust rated through a· case snody of a neural nctwqrk for bidding decision support developed based on knowledge nc<tuircd from conlmctors in Canada und the U.S. The case study demonstrates ncuml network modelling and lUustrntcs the benefits gained through beucr management of acquired knowledge.

Keywords: Neural networks; knowledge acquisition; construction; information technology; bidding strategy.

PATTERN RECOGNITION IN CONSTRUCTION PRACTICE

Reasoning, deduction, and pattern recognition are among the fundamental aspects of human intelligence. Among those , human exhibit phenomenal abilities to recog-nize patterns of information in the environment and .respond to them in a speedy and effortless manner, even under extremely difficult conditions (Rothman, 1992). Obvi-ous human experience that involve patterns include the recognition of speech utter-ances and the understanding of images such as handwriting, despite major distortions or omissions. This outstanding ability of humans, observed also in the decision-making capability of domain experts, has stimulated growing research and developments in statistical pattern recognition and AI systems such as neural networks (NNs). The interest in these areas of research has several motivations, including: 1) capturing of scarce and implicit (difficult to explain) domain knowledge; 2) developing intelligent machines with human-like abilities; and 3) developing effective decision supports for complicated real-life problems. Background material regarding neural network varia-tions, characteristics, and mathematical formulations is documented elsewhere (Moselhi et al, 1991a; Pao, 1989) .

Recently , NN have been suggested for modelling a number of construction engineering and management problems that are solved in practice based primarily on holistic analogy and "gut feeling" rather than detailed deduction and rea oning (Moselhi el al, 199la, 1992). Some construction examples include the prediction of productivity level achievable under a particular job si te condition the assignment of a percent markup before submitting the bid price, and day-to-day deci ions regarding

5_{Dr Tarek Hegazy, Assistant Professor, Centre for Building Studies, Concordia University.}

0 Moselhi, Centre for Building Studies, Concordia University. P Fazio, Centre for Building Studies, Concordia University.

The International Journal of Construction Information Technology, 1993, Vol!, No 3, Page 73-86

Note: Discussion open until! June 1994. The manuscript for the paper was submitted for review and possible publi -cation on 28 June 1993. ©The University of Salford 1993.