Advanced Engineering Informatics 29 (2015) 602–615

Contents lists available at ScienceDirect

Advanced Engineering Informatics

journal homepage: www.elsevier .com/ locate /ae i

Requirements for computational rule checking of requests for proposals(RFPs) for building designs in South Korea

http://dx.doi.org/10.1016/j.aei.2015.05.0061474-0346/� 2015 Elsevier Ltd. All rights reserved.

⇑ Corresponding author.E-mail addresses: aha0810@naver.com (M. Uhm), glee@yonsei.ac.kr (G. Lee),

nuyhyun@yonsei.ac.kr (Y. Park), un401017@naver.com (S. Kim), Gomtang15@yonsei.ac.kr (J. Jung), designit@hanyang.ac.kr (J.-k. Lee).

Miyoung Uhm a, Ghang Lee a,⇑, Younghyn Park a, Sanghun Kim a, Jiwon Jung a, Jin-kook Lee b

a Department of Architectural Engineering, Yonsei University, South Koreab Department of Interior Architecture Design, Hanyang University, South Korea

a r t i c l e i n f o a b s t r a c t

Article history:Received 9 September 2014Accepted 22 May 2015Available online 13 June 2015

Keywords:Request for proposal (RFP)Design rule checkingDesign compliance checkingBuilding information modeling (BIM)Context-free grammar (CFG)

This study reports on the requirements for developing computer-interpretable rules for checking thecompliance of a building design in a request for proposal (RFP), especially in the building informationmodeling (BIM) environment. It focuses on RFPs for large public buildings (over 5 million dollars) inSouth Korea, which generally entail complex designs. A total of 27 RFPs for housing, office, exhibition,hospital, sports center, and courthouse projects were analyzed to develop computer-interpreted RFPrules. Each RFP was composed of over 1800 sentences. Of these, only three to 366 sentences could betranslated into a computer-interpretable sentence. For further analysis, this study deployedcontext-free grammar (CFG) in natural language processing, and classified morphemes into four cate-gories: i.e., object (noun), method (verb), strictness (modal), and others. The subcategorized morphemesincluded three types of objects, twenty-nine types of methods, and five levels of strictness. The coverageapplicability of the derived objects and methods was checked and validated against three additional RFPcases and then through a test case using a newly developed model checker system. The findings areexpected to be useful as a guideline and basic data for system developers in the development of a gen-eralized automated design checking system for South Korea.

� 2015 Elsevier Ltd. All rights reserved.

1. Introduction

A request for proposal (RFP) lists the main function, form,usability, and other requirements of a building. A designer theninterprets the RFP into a physical form based on his experienceand knowledge [1]. During this design phase, the RFP acts as adesign guide throughout all design phases and establishes criteriafor design assessment [2]. However, RFP-compliance checking iscognitively challenging for designers for several reasons. First, abuilding is composed of many pieces of elements, which are geo-metrically complex and interwoven [3], so manual design checkingis error-prone and the results are unreliable [2]. Second, designersmay misinterpret design requirements in an RFP due to theambiguous nature of natural language or through human error[4,5]. Third, RFP-based design checking is very time consumingand labor intensive. According to a survey by McGraw HillConstruction Research and Analytics [6], nearly half of architectsand owners spend more than 26 h on code checking on a typical

project. Our own early survey shows that architects check theirdesign against an RFP far more frequently than against buildingcodes and other types of design references and they consider anRFP more important than building codes and regulations as adesign reference, as shown in Fig. 1 [7]. Fourth, manual checkingresults in redundant data input, especially in a collaborative designenvironment, due to the difficulties in data and rule sharing [8].

These problems of complexity, ambiguity, inefficiency, andredundancy can be dramatically reduced by automating the designchecking process. An example can be found from medical infor-matics, where physicians often make mistakes of omitting certaintests or treatments. These errors were reduced by developing anautomated reminder for certain treatments and tests based onmedical practice guidelines [9].

Interest has been increasing in automated design checking toimprove the efficiency of labor and safety at construction sites[10,11]. The advent of advanced data-rich computer aided design,referred to as building information modeling (BIM), has enabledautomate checking of building codes and spatial requirements fornotable examples such as the courthouse design guidelines of theU.S. General Services Administration (GSA), the InternationalBuilding Code of International Code Council (ICC), and theAmericans with Disabilities Act (ADA) standard for accessible

Fig. 1. The priority and frequency of using certain types of design references for design validation.

M. Uhm et al. / Advanced Engineering Informatics 29 (2015) 602–615 603

design [2,12–14]. Although code-compliance checking has beenthe object of many studies for a long time [15], RFP-compliancechecking has not been a major focus. Previous research topics haveperhaps leaned towards code-checking rather than RFP-checkingbecause building codes are the minimum legal requirements andstrictly regulate design and construction submittals for permits.However, building codes do not describe an owner’s specificrequirements; thus, improvements in the quality of a buildingand owner satisfaction require an understanding and proper reflec-tion of the owner’s requirements in an RFP – one without errors oromissions on the design, especially in a competitive bid.

The aim of this paper is to specify the computational require-ments for developing computer-interpretable rules for checkingthe compliance of a building design in a request for proposal(RFP), especially in the building information modeling (BIM) envi-ronment. The paper is organized into eight sections. Following thisintroduction, the next section describes the research scope andmethod. The third section reviews existing work in the field of auto-mated rule-based design checking. The fourth section briefly intro-duces the concept of context-free grammar (CFG) and describeshow RFP sentences are parsed into a computer-interpretable formusing the CFG approach. The fifth section reports the results ofRFP sentence analysis and the objects and methods derived fromRFPs. The sixth section validates the derived objects and methodsusing three RFP cases. The seventh section demonstrates the appli-cability of design rules created using the objects and methodsderived in this study using a newly developed BIM model checkerand a translator. Finally, the conclusion section discusses the con-tributions, limitations, and the future direction of this work.

2. Research scope and method

RFPs may differ by building type, year, regions, and buildingsize [2,8,15]. If a building is small or simple, the RFP may not con-tain many requirements. Hospitals may have different require-ments from office buildings, but even if the building types arethe same, requirements in the 1980s may differ from those inthe 2000s. Requirements for a residential complex in South Koreamay also differ from those for similar complexes in the US.

This study limits its scope to the RFPs published for the past fiveyears (2008–2012) for public buildings in South Korea with bud-gets over USD 5 million. The RFPs were collected from the SouthKorean on-line e-procurement system [16] called ‘Nara-jang-teo(national market)’. Nara-jang-teo is run by the Korean PublicProcurement Service (PPS) to solicit bids for all kinds of goodsand services that are ordered by the Korean government and publicinstitutions. An RFP for buildings provides a summary of a project,

the project goal, a delivery method, and detailed project require-ments. The research team collected and analyzed RFPs over thecourse of approximately 10 months (from 2013 to 2014) throughthe following steps:

� Step 1 (Data collection and setup): RFPs for building projectsfrom 2008 to 2012, which were over USD 5 million, were col-lected from Nara-jang-teo, the South Korean on-linee-procurement system. A total of 113 RFPs satisfied these crite-ria. However, among the 113 RFPs for building projects, amajority of the RFPs were for construction projects and only27 RFPs were for building design projects. These 27 RFPs wereassociated with six types of buildings: residential complex,office building, exhibition facility, hospital, courthouse, andsports facility. Among these 27 RFPs, 23 RFPs were set as anal-ysis data for deriving objects, methods, and the level of strict-ness required to develop computer-interpretable design rulesfor automated RFP-compliance checking and four RFPs, eachfrom the residential complex, office, exhibition facility exclud-ing courthouse and sports facility categories that had only onecase per building type, as well one hospital RFP, were set as val-idation cases. Details are described in Section 4.1.� Step 2 (Preprocessing): Some sentences included more than one

rule. Thus, the first step of preprocessing was to divide eachsentence into sentences that were equivalent to one rule.Then, each sentence in an RFP was examined and categorizedinto computer-interpretable and non-computer-interpretablesentences. Non-computer-interpretable sentences are thosethat are difficult for a machine to determine ‘‘satisfied’’ or‘‘failed’’ without additional guidelines. Most of those sentencesincluded qualitative expressions such as ‘high quality,’ ‘beauti-ful,’ and ‘proper’. Details are described in Section 4.2.� Step 3 (Sentence parsing): Each computer-interpretable sen-

tence was broken down into morphemes. Each morphemewas then categorized into four types [object (noun), method(verb), strictness (modal such as ‘must’ and ‘should’), andothers] deploying the context-free grammar (CFG) approach innatural language processing (NLP) [17]. The CFG is used in thisstudy since it provides a widely accepted framework for analyz-ing and rebuilding well-formed machine-readable expressions(i.e., rules in this study) from natural language [18]. Detailsare described in Section 4.3.� Step 4 (Analysis – Derivation of objects and methods): All sen-

tences were divided into morphemes using a simple automatedword extractor developed by the research team, but each mor-pheme had to be manually classified into object (noun), method(verb), strictness (modal), and others by the researchers due tothe general challenges in natural language processing, such as

604 M. Uhm et al. / Advanced Engineering Informatics 29 (2015) 602–615

synonym and ambiguity issues. We developed a thesaurus toavoid redundancy between similar terms. The extracted objects,methods, and modals were examined and terms with similarmeanings were merged. Modal auxiliaries were categorized intofour levels to express the strictness of each rule [19]. Details aredescribed in Sections 5.1–5.3.� Step 5 (Translation – Rule creation): The sentences were trans-

lated into computer-interpretable Semantic Web Rule Language(SWRL) rules [20] using the objects and methods derived fromthe previous steps. SWRL is a rule specification language basedon the Web Ontology Language (OWL) and the Rule MarkupLanguage (RuleML). Details and examples are described inSection 5.� Step 6 (Validation): The coverage and applicability of the

objects and methods derived from previous steps were vali-dated using four validation cases (RFPs). The list includes fourtypes of facilities: residential complex, office building, exhibi-tion facility, and hospital. After applying methods to the pro-jects that were left out, methods were updated based on thevalidation results through steps 2–5. Details are described inSection 6.� Step 7 (Applicability test): As the final step, the applicability of

specified rules was tested using ‘abimo Checker,’ a newly devel-oped BIM model checker developed for this study. We alsodeveloped a SWRL-to-Python translator for the applicability testbecause ‘abimo Checker’ used Python as a rule-checking script-ing language. Details are described in Section 7.

The following section briefly reviews previous studies and theirimportance.

3. Previous studies

In order to reduce design errors, a considerable number of stud-ies have focused on the causes of design errors and effective meth-ods to prevent them [21–23]. The theoretical background of errormanagement studies is often grounded in quality control theoriesin manufacturing such as ‘six sigma’ [24]. The quality control the-ories stress the importance of understanding and analyzing cus-tomers’ needs and satisfaction in reducing errors and achievingthe target quality of outcomes [25,26].

In the architecture, engineering, and construction (AEC) indus-try, a checklist is normally used for design quality management.A checklist is ‘a list of action items or criteria that allow the userto record the presence/absence of the individual items listed toensure that all are considered or completed [27].’ However, themanual design checking method, whether a checklist is used ornot, is very ineffective in detecting mistakes or omissions and alsodoes not guarantee the accuracy of check results [10]. The use of analternative – the BIM-based automated design error detection – istherefore increasing [28]. For example, Statsbygg, the Norwegiangovernment agency in charge of construction and real estate mat-ters, evaluated the compliance of a design with ISO 21542, theinternational standard that defines the accessibility and usabilityof the built environment [29], using a BIM model checker [30].The U.S. General Services Administration (GSA) checked the circu-lation in a courthouse by different security levels specified in thecourthouse design guide [31] using a BIM model checker [2].These BIM implementation cases present the benefits of the accu-racy of requirement checking and the efficiency of the work [28].

The use of computer-interpretable requirements by the AECindustry is rare when compared to other industries. In the fieldof medicine, the patient’s medical information is managed in acomputer-interpretable form [32]. Requirements engineering (RE)also commonly uses computer tools such as IBM DOORS forrequirements definition and management throughout a RE

lifecycle (i.e., requirement elicitation, identification, analysis, spec-ification, modeling, validation, and management) [19,33].However, as the number of BIM-assisted projects increases in theAEC industry, the use of computers in design and requirementsmanagement is also increasing.

The method of design checking using BIM can be categorizedinto clash detection and rule-based design checking. Clash detec-tion is a geometry-based checking method that detects the physi-cal conflicts of objects in a BIM model. Rule-based checking is amethod for checking the compliance of a design with rule setsbased on the arithmetic operation and deduction of values setbeforehand [34]. The clash detection approach is so generic thatit can be applied to any models once the function is implementedin a BIM system. Naturally, clash detection has become the mostpopular way to use BIM currently [28,35]. However, therule-based approach requires the development of rule sets for dif-ferent design requirements and, even before that, the developmentof objects and functions (methods) required to specify the rules. Ifa model checker is a Compact Disc (CD) player, the rule sets areCDs. Thus, even if a well-developed model checker exists, a modelcannot be checked without rule sets. For this reason, the imple-mentation of rule-based design check is slow in practice, althoughseveral model checkers are already available in the market. Widelyknown automated rule-based model checkers include Revit [36],Navisworks [37], Solibri Model Check (SMC) [38], Express DataManager (EDM) [39], and FORNAX [40].

Another reason for the slow adoption of automated rule-baseddesign checking in the AEC industry is that each model checkerspecifies rules in its own format using different computer lan-guages. Thus, the reuse or sharing of existing rule sets are impos-sible [34,41,42]. The development of rules in a sharable andreusable format is also critical for accelerating the adoption ofautomated design checking in the industry [42].

This study takes an approach of specifying rules in a standardrule description language, SWRL, and translating the rules specifiedin SWRL into a scripting language (e.g., Java and Python) that isused in a target model checker (e.g., Solibri). This strategy is basedon an assumption that, in the future, a client will distribute an RFPwith a separate design requirement rule set specified in SWRL anddesigners will automatically check their designs multiple times asthe design develops by using any BIM model checker of theirchoice by importing the SWRL rules into the model checking sys-tem. However, the very first step is to understand the objectsand methods required to specify requirements rules. The next sec-tion describes in detail how – and which – objects and methodsrequired for automated design check of buildings in South Koreawere derived.

4. Analysis of RFPs

The RFPs collected and set up to develop methods were forbuilding projects over USD five million within five years. A totalof 27 RFPs were selected and they were composed of six types offacilities. From these RFPs, 1331 computer-interpretable sentenceswere collected from 9833 sentences written in natural languagesand each was made into a single sentence that has a verb. Weparsed the computer-interpretable sentence to develop themethod and object. This section describes the RFP analysis meth-ods and results in detail following the analysis steps described inthe second section.

4.1. Data collection and setups

As described earlier, the target of analysis was limited to RFPsthat satisfied the following criteria based on an assumption that

M. Uhm et al. / Advanced Engineering Informatics 29 (2015) 602–615 605

requirements in RFPs for small buildings can be covered by theobjects and methods required by large buildings and that designrequirements may vary by region and time:

(a) RFPs for buildings with budgets over USD five million: InSouth Korea, buildings with budgets over USD five millionare classified as large buildings and are subjected to addi-tional requirements in the bidding process, such aspre-qualification (PQ) and value engineering (VE). A highstandard for design quality is also required.

(b) Buildings constructed within the recent five years, i.e., from2008 to 2012: Requirements for space and building serviceschange over time as residents’ needs, cultures, and technolo-gies change. We collected RFPs within the recent five yearsso that we could derive objects and methods that reflectedthe latest design trend. RFPs between 2008 and 2012 werecollected because the analysis began in 2013.

(c) Public buildings in South Korea: Beginning in the year 2016,PPS mandates the use of BIM in all public building projects inSouth Korea. The scope of this study was limited to the pub-lic buildings in South Korea because this study was con-ducted as one of preparation processes for the 2016 BIMinitiative.

A total of 27 RFPs satisfied these criteria. The collection wascomposed of 13 residential complexes, five office buildings, threehospitals, three exhibition facilities, a sports center, and a court-house. Residential complexes and office buildings accounted for66% of the RFP types. Courthouses and sports centers over USD five

Table 1Projects overview of selected RFPs.

Project name Type of facility Own

1 Ulsan District Court Courthouse Supr

2 Sports center in Seongnam Sports center The

3 National Institute of Biological Resources Exhibition facility Min4 Daegu National Science Museum Min

Plan5 National Institute Of Ecology Min

6 Pusan National University Yang-san Hospital(expansion)

Hospital Pusa

7 Seoul National University Bun-dang Hospital Seou8 Seoul Medical Center The

9 Korea credit guarantee fund headquarter Office building Kore10 Korean film council headquarter Kore11 Korea consumer agency headquarter Kore12 Health insurance review & assessment service

headquarterHealServ

13 Korean gas corporation headquarter Kore14 Korea occupational safety &health agency

headquarterKoreAgen

15 Sang-rok official apartment in Sejong Residentialcomplex

Gove16 Sang-rok official apartment in Goyang Gove17 Public housing in Sun-un district Gwa18 12 block apartment in Eun-pyeng newtown SH c19 Sang-rok official apartment in Kimpo Gove20 A6 block apartment in Goyang Gove21 M2 block apartment in Sejong Gove22 Sang-rok official apartment in Han-river new town Gove23 Sang-rok official apartment in Namyangju Gove24 Sang-rok official apartment in Inchon Gove25 Apartment in Dae-yon district Busa26 Sang-rok official apartment in Guangyo Gove27 Sang-rok public apartment in Guangyo Gove

million were rare. The project name, owner, gross floor area, andbudget of each RFP are specified in Table 1. Ten of the thirteen res-idential complex projects were ordered by the GovernmentEmployees Pension Service. Six new office building projects wereassociated with the relocation of government ministries toSejong from Seoul. Two of three hospitals projects were affiliatedwith universities.

Before analysis, the 27 RFPs were divided into two groups.One group was for analyzing and deriving objects and methodsrequired for developing design rules from RFPs. The other groupwas for validation of the derived objects and methods. The anal-ysis case consisted of 23 RFPs and the validation case includedfour RFPs, one each from exhibition facilities, hospitals, officebuildings, and residential complexes. No validation case couldbe set for the building types with just one RFP case such assports center and courthouse. The validation cases were selectedrandomly.

4.2. Preprocessing

The collected RFPs were analyzed from 2013 through 2014 forabout 10 months. The sentences in RFPs were first decomposedinto shorter sentences until each sentence indicated one designrule. As a general rule of thumb, a single sentence usually containsa single verb, except for the cases where a single rule is composedof several conditions. The composite rules were rare. Some ruleswere also expressed in a table format. The table, for example, spec-ified how many spaces were required, how large the spaces shouldbe, and which department was the owner of a space. These tables

er Gross floor area(m2)

Budget (millionUSD)

eme Court 39,470 68

city of Seongnam 26,500 57

istry of Environment 21,937 97istry of Science, ICT and Futurening

23,471 117

istry of Environment 43,430 335

n National University 144,929 243

l National University 63,530 212city of Seoul 47,164 95

a Credit Guarantee Fund 39,006 86an Film Council 21,668 51a Consumer Agency 30,925 75th Insurance Review & Assessmentice

58,169 123

an Gas Corporation 23,934 39a Occupational Safety & Healthcy

41,406 89

rnment Employees Pension Service 118,866 130rnment Employees Pension Service 95,819 122ngju metropolitan City Corporation 75,069 87orporation 67,518 78rnment Employees Pension Service 68,921 65rnment Employees Pension Service 64,829 64rnment Employees Pension Service 64,215 70rnment Employees Pension Service 68,921 156rnment Employees Pension Service 96,106 126rnment Employees Pension Service 80,333 105n Metropolitan Corporation 421,456 406rnment Employees Pension Service 149,900 157rnment Employees Pension Service 70,473 73

606 M. Uhm et al. / Advanced Engineering Informatics 29 (2015) 602–615

also had to be analyzed and translated into rules. About 9800 sen-tences and 7000 rules in a table form were extracted from 23 RFPs,as shown in Table 2. From the extracted 9833 sentences and 7040rules in tables, only computer-interpretable sentences were cho-sen. The criteria for computer-interpretable sentences were (a)whether a sentence or data included quantitative or numerical val-ues, (b) whether verbs could be translated into acomputer-interpretable expression (function or method) and (c)whether a list of objects included in a sentence had a potential tobe included in a BIM model. For example, the sentence stating thatthe height of the ceiling had to be ‘sufficient for the people’s resi-dence’ could be translated differently depending on the interpreterand therefore could not be interpreted by a computer, while thesentence stating that the height of the ceiling had to be ‘five meters’could be interpreted by a computer. Sentences with verbs such as‘describe’ and objects such as ‘mood’ were also categorized as

Table 2The number and percentage of computer-interpretable sentences and table data in RFPs.

Facility type Title Number of sentences

Number of naturallanguages sentences (A)

Compusenten

Numbsenten

Courthouse Ulsan District Court 166 91

Sportscenter

Sports Center in Sungnam 102 11

Exhibitionfacility

National Institute of BiologicalResourcesa

301 37

Daegu National ScienceMuseum

113 25

National Institute of Ecology 245 4

Hospital Pusan National UniversityYangsan Hospitala

1865 366

Seoul National UniversityBundang Hospital

1879 223

Seoul Medical Center 1746 270

Officebuilding

Korea Credit Guarantee Funda 281 33Korean Film Council 214 10Korea Consumer Agency 515 34Health Insurance Review &Assessment Service

616 71

Korean Gas Corporation 222 4Korea Occupational Safety &Health Agency

503 54

Residentialcomplex

Sang-Rok Official Apartment inSejonga

53 5

Sang-Rok Official Apartment inGoyang

67 5

Public Housing in SununDistrict

84 3

12 block apartment in Eun-pyeng newtown

298 40

Sang-rok official apartment inKimpo

71 5

A6 block apartment in Goyang 64 5M2 block apartment in Sejong 56 5Sang-Rok Official Apartment inHangang new town

71 5

Sang-Rok Official Apartment inNamyangju

65 5

Sang-rok Official Apartment inInchon

68 5

Apartment in Daeyon district 38 5Sang-rok Official Apartment inGuangyo

65 5

Sang-rok Public Apartment inGuangyo

65 5

Total 9833 1331

a Validating group.

non-computer-interpretable. The sentences that provided generaldescriptions rather than design rules were also eliminated. Assummarized in Table 2 total of 1331 sentences was selected ascomputer-interpretable sentences according the above criteria.The ratio of computer-interpretable sentences to the total numberof sentences differed depending on projects and ranged 2–55%. Inthe case of the courthouse, 91 sentences out of 166 werecomputer-interpretable (55%). This number was exceptionallyhigher than that of the other cases. Generally, the ratio ofcomputer-interpretable sentences in an RFP was low, with an aver-age was 14%, as shown in Table 2. On the other hand, all 7040 tablerules could be translated into computer-interpretable sentences.However, differences existed between RFPs in terms of use oftables in design requirement specification. For example, RFPs formedical facilities expressed many design rules in a table formatwhereas RFPs for residential complexes did not.

Table data Total number of computer-interpretablesentences and table rules (B + C)

ter-interpretableces

er ofces (B)

Ratio(%)

Number ofrules (C)

55 176 267

11 29 40

12 151 188

22 63 88

2 92 96

20 2590 2956

12 1133 1356

16 2022 2292

12 62 955 142 1527 159 193

12 90 161

2 115 11911 162 216

9 4 9

8 4 9

4 4 7

13 4 44

7 4 9

8 4 99 4 97 4 9

8 4 9

7 4 9

13 6 118 4 9

8 4 9

14 7040 8380

M. Uhm et al. / Advanced Engineering Informatics 29 (2015) 602–615 607

A total of 8380 rule instances were collected. The number ofrules extracted from tables outnumbered those from sentences:1130 rules were collected from sentences and 7040 rules fromtables. The number of rules also varied dramatically by buildingtype. Hospitals requested from 1000 to 3000 design rules whereasother types of buildings had fewer than 300 rules. This explainswhy hospitals are generally regarded as one of the most challeng-ing building types to design.

4.3. Parsing sentences using the CFG approach

In order to derive objects and methods required to specifydesign rules, the individual sentences were parsed into mor-phemes following the CFG approach. In linguistics, a morphemeis the atomic morphological unit. We categorized morphemes intofour types of grammatical elements (i.e., nouns, verbs, modals, andothers) so that we could later translate them into objects, methods,the levels of strictness, and properties. Modifiers such as adjectivesand adjective phrases were also analyzed and later translated intoproperties or methods of an object.

Fig. 2 illustrates an example of a sentence that states that thearea of a single patient room shall have a minimum clear floor areaof 120 square meters. From this example, we can deduce that thisrule requires two objects ‘room’ and ‘floor’ from two noun phrasesand a method (function) ‘has’ from verb ‘have’. The verb ‘have’defines the relationship between ‘room’ and ‘floor.’ This relation-ship can be translated in a function-argument form shown below.This function returns ‘True’ if a room has a floor.

Boolean has(room, floor);

However, the room is not any room, but the single-patienttreatment room and the floor has a specific minimum floor arearequirement. Thus, two rules should be added.

Boolean room(type, ‘single-patient treatment room’);Boolean (area(floor) > 120 m2);

When all three of these rules are satisfied, this design rule ismarked as ‘Pass.’ Judging by the modal verb ‘shall’, this rule alsohas high strictness; that is, if a design fails this rule, the design will

Fig. 2. An example of the RFP sentences analyzed in the form of a CFG tree. ⁄ Auxiliary ve(Prep), Sentence (S), Verb (V), Verb phrase (VP).

not be accepted by the client. Each sentence was analyzed and con-verted into rules through these steps. The analysis results aredescribed in detail in the next section.

5. Analysis results

From 1331 computer-interpretable sentences and 7040 tablerules, we derived three types of objects, twenty-nine methods,and four levels of strictness. The following sections describe themin detail.

5.1. Nouns

We categorized nouns into three types of objects: space, build-ing element, and equipment. This classification was created consid-ering the compatibility with OmniClass [42] and IndustryFoundation Classes [43]. Space is equivalent to IfcSpace in IFC[43] and space in OmniClass [44]. Building element is equivalentto IfcBuildingElement in IFC [45] and Elements in OmniClass [42].However, IFC and OmniClass does not have a single entity thatcan be directly mapped to equipment because some RFPs requirea space to accommodate certain types of furniture and electricalequipment (e.g., special medical equipment), but IFC andOmniClass have relatively little emphasis on these types of require-ments. We used the term equipment broadly to include mechanical,plumbing, and electrical (MEP) equipment, furniture, and electricalappliances. Equipment includes IfcDistributionElement (MEP ele-ments) and IfcFurnishingElement (furniture and the like) in IFCand equipment and furnishings in OmniClass table 21 (Elements).Electrical appliances such as monitors and medical devices arenot included in IFC and OmniClass.

According to IFC, space is ‘an area or volume bounded actuallyor theoretically,’ and a building element is ‘a structural and spaceseparating system of a building’ [43,45]. By equipment, we meana non-building element that is a part of an air, water, or electricdistribution system of a building, or essential furniture or an appli-ance that is required by a space to perform its target function.

Synonyms and similar terms existed in RFPs. In order to avoidredundancy, we developed a thesaurus and analyzed nouns inRFP sentences. Table 3 summarizes the distribution of noun typesin RFP types.

As shown in Table 3, most design guidelines in RFPs focus onspace. In particular, RFPs for the courthouse and office building

rb (Aux), Adjective (Adj), Determiner (Det), Noun (N), Noun phrase (NP), Preposition

Table 3Distribution of noun types in RFPs by facility type a.

Type Courthouse Sports center Hospital Exhibitionfacility

Office building Residentialcomplex

Freq. % Freq. % Freq. % Freq. % Freq. % Freq. %

Space 263 99 31 78 768 89 362 97 906 97 125 82Building element 3 1 1 2 43 5 4 1 27 3 16 11Equipment 1 0 8 20 48 6 6 1 3 0 11 7

Total 267 100 40 100 859 100 372 100 936 100 152 100

a Frequency (Freq.) and Ratio (%).

608 M. Uhm et al. / Advanced Engineering Informatics 29 (2015) 602–615

had a much larger number of design guidelines related to spatialrequirements (space objects) than the other RFP types did.Compared to other facilities, RFPs for the sports center, the residen-tial complex and the hospital included a relatively large number ofdesign guidelines related to building elements or equipment.

5.2. Verbs

Verb is an action or occurrence that indicates a state of being[46]. Verbs in RFPs were translated into methods (functions).Translation of verbs to methods was less direct than translationof nouns. Human interpretation and intervention were unavoid-able because of the ambiguity of a natural language. For example,design guidelines, ‘Two rooms must be placed closely,’ could meanthe following three situations:

(a) Two rooms must be located side by side, but may not bedirectly accessible. (Room ‘c’ and ‘d’ in Fig. 3).

(b) Two rooms are accessible, but may not be adjacent. (Room‘a’ and ‘c’ in Fig. 3).

(c) Two rooms are placed side by side and accessible. (Room ‘a’and ‘b’ in Fig. 3).

To derive a method from RFP sentences, we first groupedverbs by their role into object existence, quantity check, distancecheck, area, space location, circulation, window-wall ratio, andmaterial property. The verbs in the eight groups were thentranslated into 29 methods. Fig. 4 illustrates the 29 methodsgrouped by object type and role. Table 4 lists their syntax,description, and example.

Fig. 3. An example of ‘isAdja

Similar to the translated sentence examples explained inSection 4.3, the final rules were specified in SWRL. About a halfof the methods is Boolean type. For example, whether ‘Education’space includes ‘Lecture Room’ space can be checked using the‘isComposedOf’ method. This ‘isComposedOf’ returns True if‘Lecture Room’ exists in ‘Education’ space, and returns False if thecondition is not met. The syntax, described in plain English, andan example of the ‘isComposedOf’ method is as follows:

Syntax: Boolean isComposedOf (Space ‘a’, Space ‘b’,[Space ‘c’], . . .)

Description: Space ‘a’ is composed of Space ‘b’, Space ‘c’,and other spaces.

Example: isComposedOf (‘Education’,’LectureRoom’) = True

The other half of the methods is Long type. For example, when adesigner needs to check how many rooms are required, the ‘getNumberOfSpace’ method makes this possible. It is able to countthe number of rooms in specific area, in a specific building. The‘getNumberOfSpace’ method returns true if the Patient room existsin ‘Ward’, or returns false or error.

Syntax: Long getNumberOfSpace (spaceType ‘a’, [zone‘b’], [story ‘c’], [building ‘d’])

Description: There are several spaces ‘a’ in zone ‘b’ onthe ‘c’ story of the ‘d’ building.

Example: getNumberOfSpace (‘Patient Room’,‘Ward’) =4000

cent’ and ‘isAccessible’.

Fig. 4. 29 Methods grouped by object type and role.

M. Uhm et al. / Advanced Engineering Informatics 29 (2015) 602–615 609

Some methods have option arguments. For example, themethod ‘isVisibleFrom’ is used to check whether ‘Patient rooms’are observable from the ‘Nurse station’. This visibility depends onthe door type (with sight glass or not) and door status (open/-closed). This door types are expressed as Type zero to two. Typezero means that nurses are able to see the inside space of a patientroom through the opened door from the nurse station. This type ispossible to apply to the nurse station in an emergency room thathas no doors between stretchers. Type one means that nurses areable to see around the patient room because of a closed door.Type two means that nurses can look at the patient in the roomthrough a window. Type two is utilized in infection zones or infantunits. The method ‘isVisibleFrom’ returns true if the patient roomand nurse station exists for all. This method returns true if the doortype of the patient room fits well, otherwise it returns false.

Syntax: Boolean isVisibleFrom (Space ‘a’, Space ‘b’,Type ‘c’)

Description: space ‘a’ is visible from space ‘b’ throughdoor type ‘c’.

Example: isVisibleFrom (‘Nurse Station’, ‘PatientRoom’, Type 1) = True

In the above two room example, ‘(a) Two rooms must be placed

side by side, but may not be directly accessible’ was translated into‘isAdjacent’ and ‘(b) Two rooms must be accessible, but may not beadjacent’ was translated into ‘isAccessble’. In case (c), the tworooms must be adjacent and accessible. Some methods includedoptions. For example, ‘getSpaceWidth’ included an option tochoose the distance between interior walls, between centerlines,or between the external surfaces of two opposite walls. The‘getSpaceHight’ method included an option for ceiling-to-ceiling

height and floor-to-floor, and floor-to-ceiling. The ‘checkSetBasedCirculation’ method was defined based on the algorithm proposedby Lee et al. [47].

Fig. 5 illustrates the frequency of use of 29 methods in RFPs. The‘getFloorArea’ method (41%) is the most frequently used among the29 methods followed by ‘getNumberOfSpace’ (28%),‘isComposedOf’ (13%), ‘hasEquipment’ (8%), and ‘isAccessible’(3%). If ‘getNumberOfEquipment’ (2%) is added to this list, thesesix methods cover 95% of the design guidelines. This analysis resultclearly shows which method should be developed first when a newrule-based design checking system is developed. Even if only thethree most frequently methods, ‘getFloorArea’, ‘getNumberOfSpace’, and ‘isComposedOf’, are implemented, over 80% (82%) of thedesign guidelines can be checked.

However, the remaining 23 methods should not be ignoredalthough they cover only 5% of the design guidelines when theuse of methods is analyzed without considering building type(Fig. 6). This is because each building type has special designrequirements and the 23 methods play an important role in eachRFP when the method use is analyzed by building type.

For example, 12 of the methods were used only for a certaintype of building: Nine methods were found only in hospital RFPsand three only in office building RFPs. Hospital-specific methodswere mostly related to equipment and they were ‘getNumberOfElement’, ‘getNumberOfEquipment’, ‘getSpaceWidth’, ‘getEquipmentWidth’, ‘getEquipmentHeight’, ‘getSpaceDistance’, ‘getElementDistance’, ‘isConnectedTo’ and ‘isVisibleFrom’. This is because a hospi-tal requires a large amount of medical equipment and the spaceshould be large enough to accommodate it. Similarly, office build-ings are generally sensitive to parking lot and energy-saving issuesand had ‘getLandscapeArea’, ‘getParkingLotArea’ and ‘getWindowWallRatio’ as office-specific methods. Table 5 summarizes which

Table 4Syntax, description, and examples of 29 methods.

Syntax Description Example

Boolean isComposedOf (Space ‘a’, Space‘b’, [Space ‘c’], . . .)

Space ‘a’ is composed of Space ‘b’, Space ‘c’, and other spaces isComposedOf (‘Education’,’LectureRoom’) = True

Boolean hasElement (Space ‘a’, Equipment‘b’, [Element ‘c’],. . .)

Space ‘a’ has element ‘b’and other elements hasElement( ‘Operation Room’,‘Column’) = True

Boolean hasEquipment (Space ‘a’,Equipment ‘b’, [Equipment ‘c’]. . .)

Space ‘a’ has Equipment ‘b’and the other Equipment hasEquipment ( ‘Warehouse’,‘Ventilation’) = True

Long getStoryOfSpace (SpaceType ‘a’) Space ’a’ is located on floor getStoryOfSpace (‘Chillerroom’) = B1F

Long getNumberOfSpace (Space Type ‘a’,[Zone ‘b’], [Story ‘c’], [Building ‘d’])

There are several spaces ‘a’ in zone ‘b’ on ‘c’ floor in ‘d’ building getNumberOfSpace (‘PatientRoom’) = 4000

Long getNumberOfElement (Space ‘a’,Element ‘b’)

Space ‘a’ has a number of Element ‘b’ getNumberOfElement (‘PatientRoom’, ‘Window’) = 4

Long getNumberOfEquipment (Space ‘a’,Equipment ‘b’)

Space ‘a’ has a number of Equipment ‘b’ getNumberOfEquipment (‘PatientRoom’, ‘Bed’) = 4

Long getNumberOfParkingSpace(ParkingLot ‘a’)

Space has a number of ParkingLot ‘b’ getNumberOfParkingSpace(‘Parking Lot’) = 300

Long getSpaceWidth (Space ‘a’, Type b) Space ‘a’ has a width. The width of the Space ‘a’ is measured by the measurementcriteria types; Inner wall (Type 0), center (Type 1), and outer wall (Type 2)

getSpaceWidth (‘Living Room’, Type0) = 3000

Long getElementWidth (Element ‘a’, Typeb)

Element ‘a’ has a width. The width of the Element ‘a’ is measured by themeasurement criteria types; inside dimension (Type 0), outside dimension (Type 1)

getElementWidth (‘PatientRoom_door’, Type 0) = 1100

Long getEquipmentWidth (Equipment‘a’,Type b)

Equipment ‘a’ has a width. The width of the Equipment ‘a’ is measured by themeasurement criteria types; inside dimension (Type 0), outside dimension (Type 1)

getEquipmentWidth (‘Bed’, Type0) = 1200

Long getSpaceHeight (Space ‘a’, Type b) Space ‘a’ has a height. The height of the Space is measured by the measurementcriteria types; Space height, floor to ceiling (Type 0), center to center (Type 1), floorto floor (Type 2)

getSpaceHeight (‘Intensive careunit’, Type 2) = 3500

Long getElementHeight (Element ‘a’, Typeb)

Element has a height. The height of the Element is measured by the measurementcriteria types; inside dimension (Type 0), outside dimension (Type 1)

getElementHeight (‘PatientRoom_door’, Type 0) = 1800

Long getEquipmentHeight (Equipment ‘a’,Type b)

Equipment has a height. The height of the Equipment is measured by themeasurement criteria types; inside dimension (Type 0), outside dimension (Type 1)

getEquipmentHeight (‘Bed’, Type1) = 900

Long getSpaceDistance (Space ‘a’, Space‘b’, Type c)

The distance between Space ‘a’ and ‘b’ is measured by the measurement types; doorto door (Type 0), longest (Type 1), physical distance (Type 2)

getSpaceDistance (‘ICU’, ‘OperatingRoom’, Type 0) = 3500

Long getElementDistance (Element ‘a’,Element ‘b’, Type c)

The distance between building element ‘a’ and ‘b’ is measured by the measurementtypes; inside (Type 0), centerline (Type 1)

getElementDistance (‘P_wall’, ‘P_wall, Type 0) = 2700

Long getEquipmentDistance (Equipment‘a’, Equipment ‘b’, Type c)

The distance between equipment ‘a’ and ‘b’ is measured by measurement criteria;outside dimension (Type 0), centerline (Type 1)

getEquipmentDistance (‘Bed 1’,‘Bed 2’, Type 0) = 3300

Long getFloorArea (Space ‘a’, Type b) Area of space ‘a’ is figured out using three measurement types; inside dimension(Type 0), center line (Type 1), outside wall (Type 2)

getObjectArea (‘Veranda’, Type0) = 5 m2

Long getLandscapeArea (LandScape ‘a’) There is the sum of Landscape area getLandScapeArea(‘Landscape’)=50 m2

Long getParkingLotArea (ParkingLotArea‘a’)

There is the sum of parking lot area getParkingLotArea (‘ParkingLot’) > 10,000 m2

Boolean isAccessible (Space ‘a’, Space ‘b’,Type c, Direction d)

Space ‘a’ is able to move to Space ‘b’ through moving route types and directions;door to door (Type 0), corner to door (Type 1), horizontal direction (Direction 0),vertical direction (Direction 1)

isAccessible(‘Dock’, ‘Exhibition’,Type 0, Direction 0) = True

Boolean isAdjacent (Space ‘a’, Space ‘b’,Direction c)

Space ‘a’ is adjacent Space ‘b’ in the horizontal (Direction 0) or vertical (Direction 1)directions

isAdjacent(‘Nurse station’,‘Treatment’, Direction 0) = True

Boolean isConnectedTo (Element ‘a’,Element ‘b’, [Element ‘c’]...)

Element ‘a’ is connected Element ‘b’ and other elements isConnectedTo (‘Girder’,‘Column’) = True

Boolean isVisibleFrom (Space ‘a’, Space ‘b’,Type c)

Space ‘b’ is visible from Space ‘a’ through observation route types; open door (Type0), closed door (Type 1), window (Type 2)

isVisibleFrom (‘Nurse Station’,‘Patient Room’, Type 1) = True

Boolean isSeparatedFrom (Space ‘a’, Space‘b’, MEP_Circulation ‘c’,MEP_Circulation ‘d’)

The MEP_Circulation ‘c’ of Space ‘a’ is separated from the MEP_Circulation ‘d’ ofSpace ‘b’

isSeparatedFrom (‘Operating’, ‘ICU’,R1’, ‘R2’) = True

Boolean isExternal (Element ‘a’) Element ‘a’ is an external building element isExternal( ‘Wall 02’) = TrueBoolean checkSetBasedCirculation

(SpaceGroup ‘a’, SpaceGroup ‘b’)The circulation of Space Group ‘a’ is distinguished from Space Group ‘b’ checkSetBasedCirculation(‘Staff

space’, ‘Guest space’) = TrueLong getWindowWallRatio (Element ‘a’,

Element ‘b’, Orientation c)There is the ratio of Element ‘a’ and Element ‘b’ in the four cardinal orientation getWindowWallRatio(‘External

Wall’,’Window’, Orientation‘south’) = 40%

String getMaterialProperty(Element ‘a’) Element gets material property getMaterialProperty (Element‘External’) = CONC20MPA

610 M. Uhm et al. / Advanced Engineering Informatics 29 (2015) 602–615

methods were used in which building type, focusing on whichobject type.

5.3. Modals

In general, many RFP sentences included modal auxiliaries toexpress the strictness level of the owner’s requests. From the RFPsentences, we derived four levels of strictness of design guidelines,as listed in Table 6. The four levels were determined by the use ofeither must, should, might, or could. The term ‘must’ indicates that

a design guideline is mandatory without an exception. In somesentences, this was expressed using terms such as ‘essentially’ or‘absolutely.’ The term ‘should’ is still mandatory, but weaker than‘must’; i.e., a minor exception might be allowed. ‘Might’ is a recom-mendation and is often expressed with words such as ‘is consid-ered,’ and ‘if possible.’ ‘Could’ is for optional cases and can alsobe expressed using ‘can’.

Most design requirements (93%) were expressed using ‘should’.The other modal auxiliaries, i.e., ‘must’, ‘might,’ and ‘could,’ werevery seldom used. Still, the result of the strictness level analysis

Fig. 5. Six most frequently used methods and their use ratios among the 29methods.

M. Uhm et al. / Advanced Engineering Informatics 29 (2015) 602–615 611

can be used to express the weight of each design guideline andeventually, in the future, to quantify the overall compliance scoreof a design with a design guide. The objects and methods derivedfrom 23 RFPs were validated using four validation cases. The nextsection reports the validation results in detail.

6. Validation

The sufficiency of the objects and methods derived from 23RFPs as elements required to develop design rules for RPFs forbuildings were validated by analyzing design guidelines describedin four additional RFPs using the objects and methods and checkingwhether design guidelines existed that could not be expressedusing the derived objects and methods. The four RFPs were for aresidential complex, an exhibition facility, an office building, and

Fig. 6. The 23 rarely used methods and th

a hospital. The four RFPs were randomly selected when the col-lected 29 RFPs were categorized into the analysis group and thevalidation group.

All the design requirements in the four RFPs could be expressedusing the derived objects and methods and the sufficiency of thederived objects and methods was validated. All validation casesrequired all three object types. However, only some methods wereused in the four cases: Among the 29 methods, the hospital RFPused 21 methods (72%), the office building RFP 13 methods(45%), the exhibition facility RFP 10 methods (35%), and the resi-dential complex RFP only four methods (14%), as presented inTable 7. However, we do not rule out a possibility of having anRFP for a building with very exceptional design requirements suchas a data center or a nuclear plant in the future. In such cases, addi-tional objects and methods may need to be specified.

And Table 7 compares which specific methods were required inthe analysis cases and the validation cases by facility type.Differences appeared in the use of methods according to facilitytype, but not between the analysis case and the validation case.This means that if an RFP for a certain type of facility is newly cre-ated, it is likely that the same set of methods and objects used inexisting RFPs will be required by the new RFP. This reconfirms thatthe objects and methods derived in this study are likely to be suf-ficient to develop computer-interpretable rules for new RFPs for, atleast, hospitals, exhibition facilities, office buildings, residentialcomplexes, sports centers, and courthouses in South Korea.

7. Applicability test

The objects and methods derived from the RFP analysis wereimplemented in a new BIM model checker, ‘abimo’ [48]. We spec-ified a set of sample rules in SWRL using the objects and methodsderived from the analysis and translated the SWRL rules to Pythonscripts using the SWRL-to-Python translator that we developedbecause ‘abimo’ uses Python as a rule description language.Translated rules were tested for the reliability and validity.

eir use ratios among the 29 methods.

Table 5The application of methods by facility and object types.

Range of use Type of methods Focused object Type of facility

Courthouse Sports center Hospital Exhibition Office Residential complex

All of the useful isComposedOf Space � � � � � �hasElement Building element � � � � � �hasEquipment Equipment � � � � � �getStoryOfSpace Space � � � � � �getNumberOfSpace Space � � � � � �getFloorArea Space � � � � � �getMaterialProperty Equipment � � � � � �

Generally useful isAccessible Space � � � �checkSetBasedCirculation Space � � � � �getSpaceHeight Space � � � �isAdjacent Space � � � �

Partially useful getNumberOfParkingLotArea Space � �getElementWidth Building element � � �getElementHeight Building element � �getEquipmentDistance Equipment � �isSeparatedFrom Equipment � � �isExternal Building element � � �

Hospital specific getNumberOfElement Building element �getNumberOfEquipment Equipment �getSpaceWidth Space �getEquipmentWidth Equipment �getEquipmentHeight Equipment �getSpaceDistance Space �getElementDistance Building element �isConnectedTo Building element �isVisibleFrom Space �

Office specific getLandscapeArea Space �getParkingLotArea Space �getWindowWallRatio Building element �

Total 11 8 25 10 19 13

612 M. Uhm et al. / Advanced Engineering Informatics 29 (2015) 602–615

Fig. 7 illustrates an example of testing the ‘getElementWidth’method. This ‘getElementWidth’ returns the width of a buildingelement. The example rule states that the width of a door shouldbe larger than the width of a stretcher. These rules are foundmostly in hospital facilities. The red-colored doors in Fig. 7 arethe ones that failed the design-compliance check. During theimplementation, some methods were divided into several methodsdue to the internal data structure of ‘abimo’ and for the program-ming efficiency of implementation. Below is the getElementWidthexample specified in SWRL and Python:

<SWRL>rehabilitation(?x) ^ door(?y) ^ hasElement(?x,?y) ^hasWidth(?y,?a) ^ swrlb:greaterThanOrEqual(?a, 115)! AccenptEntity(?x)

<Python>Import kbCheckModule;Checker = kbCheckModeule.kbChecker()SpaceList = Checker.FindSpace(‘rehabilitation’)forspace in Spacelist

Result = 1

ElementList = space.GetElement(‘Door’) for element

in ElementList

if element WidthGreatOrEqual(115) == 0;Check.SetErrorResult(1)

Else Checker.SetErrorResult(0)

Another test case was the ‘isAdjacent’ method, which checkswhether two spaces are located sharing a wall or a ceiling/slab.Fig. 8 shows two spaces that are adjacent. Below is the‘isAdjacent’ example specified in SWRL and Python:

<SWRL>Food depots (?x) ^ Kitchen (?y) ^ isAdjacent(?x, ?y) !AcceptEntity(?x)

<Python>Import kbCheckModule;

Checker = kbCheckModule.kbChecker()

SpaceListA = Checker.FindSpace(‘food depot’)

SpaceListB = Checker.FindSpace(‘kitchen’)

for spaceA in SpaceListA:

for spaceB in SpaceListB:

IF Checker. IsAdjacent(spaceA,spaceB) ==1:

Checker.SetErrorResult(1)

Else: Checker.SetErrorResult(0)

Many more test cases were developed and tested. A trial versionof ‘abimo’ can be downloaded from a website (http://www.abimo.co.kr/) and tested.

8. Discussion and conclusion

This study reported the analysis results of RFPs for buildingsfor deriving the objects and methods required to developcomputer-interpretable rules for checking the compliance ofRFPs in building design. RFP has received little attention inthe automated rule-based BIM model checking field. However,many previous studies pointed out the inefficiency and unreli-ability of manual checking of the compliance of a design withan RFP and the efficiency of BIM-based automated designchecking.

Table 6The distribution of the strict levels of expressions by facility type a.

Strictness Courthouse Sports center Hospital Exhibitionfacility

Office building Residentialcomplex

Total

N % N % N % N % N % N % N %

Must – – – 2 – 2 – 2 – – – 6 –Should 264 99 40 100 695 90 368 100 932 100 148 97 2447 93Might 3 1 – – 80 9 2 – 2 – 3 2 90 4Could – – – 82 10 – – – 1 1 83 3

Total 267 100 40 100 859 100 372 100 936 100.0 152 100 2626 100

a Number (N) and Ratio (%).

Table 7Comparison of the use of methods in the analysis cases and the validation cases.

M. Uhm et al. / Advanced Engineering Informatics 29 (2015) 602–615 613

This paper collected and analyzed sentences from all the RFPsreleased for the past five years (2008–2012) for large publicbuilding designs in South Korea. A total of 27 RFPs for housing,office, exhibition, hospital, sports center, and courthouse projectswere collected and separated into two groups; one for the analy-sis of objects and methods required to translate design require-ments into computer-interpretable rules, and the other forvalidation of the analysis results. Hospitals had the largest num-ber of sentences and included about 1800–1900 sentences perRFP. However, only 10–20% of sentences could be categorized intocomputer-interpretable sentences. On the other hand, in case of acourthouse RFP, over a half (55%) of 166 sentences could be cat-egorized into computer-interpretable sentences. Some buildingtypes, such as hospitals and office buildings, also included manydesign rules specified in the form of tables rather than in naturallanguage. In the case of hospitals, design rules specified in tables

ranged from 1000 to 2600. As the next step, the sentences, cate-gorized as computer-interpretable, were broken down into mor-phemes using the CFG approach. The morphemes wereclassified into four types: namely, object (noun), method (verb),strictness (modal), and others. The object were subcategorizedinto three types (space, building element, and equipment), andthe method into 29 types, and the strictness into four levels.The frequency of their use was analyzed. Spaces were the mostcommonly appeared object in design rules. The ‘getFloorArea’(41%) was the most frequently used method among 29 methods,followed by ‘getNumberOfSpace’ (28%), ‘isComposedOf’ (13%),‘hasEquipment’ (8%), and ‘isAccessible’ (3%), and ‘getNumberOfEquipment’ (2%). The top five frequently-used methods covered93% of design guidelines and the top seven frequently-used meth-ods, including the top five methods, covered 96% of designguidelines.

614 M. Uhm et al. / Advanced Engineering Informatics 29 (2015) 602–615

However, the remaining 22 methods were also significant andsome of them were essential in certain types of buildings depend-ing on the special needs or regulations associated with a facilitytype. For example, hospital RFPs required certain types ofequipment-related methods that were not required by other typesof facilities. Only office buildings required methods associated withparking lots and landscape areas. The sufficiency of the derivedobjects and methods were validated using four validation RFPcases. All the computer-interpretable requirements in the four

Fig. 7. The application test result of ‘ge

Fig. 8. The application test result of

RFPs could be covered by the objects and methods derived throughthe analysis process. We also found that RFPs for the same type offacility used the same set of methods. Thus, we can conclude thatthe objects and methods derived in this study are likely to supporttranslation of future RFPs, at least for projects such as residentialcomplexes, office buildings, exhibition facilities, hospitals, sportscenters, and courthouses, into computer-interpretable rules.However, this study also leaves a limitation that special buildingtypes such as the data center and the digital library may require

tElementWidth’ method in abimo.

‘isAdjacent’ method in abimo.

M. Uhm et al. / Advanced Engineering Informatics 29 (2015) 602–615 615

more objects and methods than the ones derived in this study. Inaddition, a set of sample rules was created using the derivedobjects and methods and the applicability was tested in a newlydeveloped BIM model checker for this study.

The results of this study are expected to be useful as a funda-mental guide for model checker and rule developers who are inter-ested in automating the compliance checking of a design with anRFP. The resultant automated design-compliance checking systemand rules are expected to aid designers in effectively managing adesign from frequent design change orders while keeping their cli-ents’ requests. As a result, the designer can focus more on improv-ing the quality of a design. These unambiguously defined designguidelines may also be used throughout the lifecycle of a facilitywhen the design intents require reexamination.

Acknowledgements

This research was supported by a grant (14AUDP-C067817-02)from the Architecture & Urban Development Research Programfunded by the Ministry of Land, Infrastructure and Transport ofthe Republic of Korea.

References

[1] K. Odusami, Perceptions of construction professionals concerning importantskills of effective project leaders, J. Manage. Eng. 18 (2002) 61–67.

[2] C. Eastman, J. Lee, Y.-s. Jeong, J.-k. Lee, Automatic rule-based checking ofbuilding designs, Autom. Construct. 18 (2009) 1011–1033.

[3] G. Lee, J.W. Kim, Parallel vs. sequential cascading MEP coordination strategies:a pharmaceutical building case study, Autom. Construct. 43 (2014) 170–179.

[4] R. Roy, C.I.V. Kerr, P.J. Sackett, J. Corbett, Design requirements managementusing an ontological framework, CIRP Ann. – Manuf. Technol. 54 (2005) 109–112.

[5] N.K. Acharya, Y. Lee, J. Kim, Design errors: inefficiency or carelessness ofdesigner? J. Perform. Construct. Facilit. 20 (2006) 192–195.

[6] McGrawHill Construction, Interoperability in the construction industry,SmartMarket Report, Interoperability Issue, 2007. Available at: <http://www.aia.org/aiaucmp/groups/aia/documents/pdf/aias077485.pdf>.

[7] M. Uhm, Y.-h. Park, J. Won, G. Lee, A study on the development direction andpriority of the BIM-based hospital design validation technology, J. Architect.Inst. Korea Plann. Des. 29 (2013) 147–155. Available at: <http://www.dbpia.co.kr/Article/3200258>.

[8] J. Wix, D. Conover, BIM automated code checking based on SMART codes,buildingSMART Forum 2008, Seoul, Korea. 2008.

[9] J.M. Overhage, W.M. Tierney, X.-H. Zhou, C.J. McDonald, A randomized trial ofcorollary orders to prevent errors of omission, J. Am. Med. Inf. Assoc. 4 (1997)364–375.

[10] Y.H. Lee, A Comparative analysis of detected design errors with and withoutBIM, Architectural Engineering, Yonsei University, Master Degree, 2013.

[11] S. Zhang, J. Teizer, J.-k. Lee, C.M. Eastman, M. Venugopal, Building informationmodeling (BIM) and safety: automatic safety checking of construction modelsand schedules, Autom. Construct. 29 (2013) 183–195.

[12] C. Kam, 02- GSA (general services administration) BIM Guide for spatialProgram validation, GSA buiding information modeling guide series, GSA,Washington D.C., 2006. Available at: <http://www.gsa.gov/graphics/pbs/BIM_Guide_Series_02_v096.pdf>.

[13] ICC (International Code Council), 2012 International building code (formerlyBOCA, ICBO and SBCCI), 2012. Available at: <http://shop.iccsafe.org/media/wysiwyg/material/3000S12-toc.pdf>.

[14] ADA, 2010 Americans with Disabilities Act (ADA) Standards for AccessibleDesign, Department of Justice, 2010. Available at: <http://www.ada.gov/regs2010/2010ADAStandards/2010ADAStandards_prt.pdf>.

[15] N.O. Nawari, Automating codes conformance in structural domain, Comput.Civil Eng. (2011) 569–577.

[16] Public Procurements Service, Korean On-line E-Procurement System Webpage,2013 Available at: <http://www.g2b.go.kr/index.jsp> (Accessed: 10. 03. 2012).

[17] G.G. Chowdhury, Natural language processing, Annu. Rev. Inform. Sci. 37(2003) 51–89.

[18] G. Lee, C.M. Eastman, R. Sacks, S.B. Navathe, Grammatical rules for specifyinginformation for automated product data modeling, Adv. Eng. Inf. 20 (2006)155–170.

[19] A. Sharma, D.S. Kushwaha, Natural language based component extraction fromrequirement engineering document and its complexity analysis, ACM SIGSOFTSoftw. Eng. Notes 36 (2011) 1–14.

[20] I. Horrocks, P.F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, M. Dean, SWRL: Asemantic web rule language combining OWL and RuleML, W3C Membersubmission, 21 (2004) 1–31.

[21] R. Lopez, P.E. Love, D.J. Edwards, P.R. Davis, Design error classification,causation, and prevention in construction engineering, J. Perform. Construct.Facilit. 24 (2010) 399–408.

[22] J. Reason, Human error: models and management, Brit. Med. J. 320 (7237)(2000) 768–770.

[23] L.P. Chao, K. Ishii, Design error classification and knowledge management, J.Knowl. Manage. Pract. 5 (2004) 1705–9232.

[24] J.L. Burati Jr., M.F. Matthews, S.N. Kalidindi, Quality management inconstruction industry, J. Construct. Eng. Manage. 117 (1991) 341–359.

[25] D. Samson, M. Terziovski, The relationship between total quality managementpractices and operational performance, J. Operat. Manage. 17 (1999) 393–409.

[26] K. Linderman, R.G. Schroeder, S. Zaheer, A.S. Choo, Six sigma: a goal-theoreticperspective, J. Operat. Manage. 21 (2003) 193–203.

[27] B.M. Hales, P.J. Pronovost, The checklist—a tool for error management andperformance improvement, J. Crit. Care 21 (2006) 231–235.

[28] McGrawHill Construction, SmartMarket Report, The business value of BIM forconstrcution in major global markets: How contractors around the world aredriving innovations with building information modeling, McGrawHillConstruction, 2014. Available at: <http://www.abc.org/Portals/1/Documents/Newsline/2014/BIM%20SmartMarket%20Report%202014.pdf>.

[29] ISO/TC59/SC16, ISO 21542:2011 Building Construction-Accessibility andUsability of the Built Environment, ISO, Geneva, Switzerland, 2011.

[30] J.-K. Lee, Y.-S. Jeong, J. Lee, A case study of the building information modelingenabled universal design evaluation methods and applications, Soc. Des.Converg. 13 (2008) 17–29.

[31] GSA, U.S. Courthouse design guide, GAS, Washington D.C., 2007. Avaiable at:<http://www.gsa.gov/graphics/pbs/Courts_Design_Guide_07.pdf>..

[32] N. Mulyar, W.M.P. van der Aalst, M. Peleg, A pattern-based analysis of clinicalcomputer-interpretable guideline modeling languages, J. Am. Med. Inf. Assoc.14 (2007) 781–787.

[33] J.M. Carrillo de Gea, J. Nicolas, J.L.F. Aleman, A. Toval, C. Ebert, A. Vizcaino,Requirements engineering tools, Software, IEEE (International of electrical andelectronics engineeriners) 28 (4) (2011) 86–91.

[34] E. Hjelseth, N. Nisbet, Overview of concepts for model checking, Proceedings ofthe CIB W78, Cairo, Egypt, 2010.

[35] R. Kreider, J. Messner, C. Dubler, Determining the frequency and impact ofapplying BIM for different purposes on building projects, in: 6th InternationalConference on Innovation in Architecture, Engineering and Construction (AEC),Penn State University, PA, USA, 2010.

[36] Autodesk, Revit Webpage, 2014. Available at: <http://www.autodesk.com/education/free-software/revit>.

[37] Autodesk, Navisworks Webpage, 2010. Available at: <http://www.autodesk.com/products/navisworks/autodesk-navisworks-freedom>.

[38] GRAPHISOFT, Solibri Model Checker Webpage, 2011. Accessible at: <http://www.graphisoft.com/archicad/partner_solutions/solibri_model_checker/>.

[39] Jotne IT, Express Data Manager Webpage, 2009. Accessible at: <http://www.jotneit.no/products/express-data-manager-edm>.

[40] novaCITYNETS, FORNAX Webpage, 2003, Aaccessble at: <http://www.jotneit.no/products/express-data-manager-edm>.

[41] N.O. Nawari, BIM-model checking in building design, Proceeding of 2012Structural Congress (2012) 29–31.

[42] O.C.C.S, OmniClass Construction Classification System, Table 21-Elements,2012 Aaccessble at: <http://www.omniclass.org/pdf.asp?id=6&table=Table%2021>.

[43] buildingSMART, IFC 2 � 3, IfcSpace, International home of open BIM, 2013.Aaccessble at: <http://www.buildingsmart-tech.org/ifc/IFC2x3/TC1/html/ifcproductextension/lexical/ifcspace.htm> (Accessed: 25. 04. 2014).

[44] O.C.C.S, OmniClass Construction Classification System, 2006. Table 14-Spacesby Form, 2006. Aaccessble at: <http://www.omniclass.org/tables/OmniClass_14_2006-03-28.pdf> (Accessed: 25. 04. 2014).

[45] buildingSMART, IFC 2 � 3, IfcBuildingElement, International home of openBIM, 2013. Aaccessble at: <http://www.buildingsmart-tech.org/ifc/IFC2x3/TC1/html/ifcproductextension/lexical/ifcbuildingelement.htm> (Accessed :25. 04. 2014).

[46] R. Nordquist, Verb-Glossary of Grammatical and Rhetorical Terms, About.com,2014. <http://grammar.about.com/od/tz/g/verbterm.htm> (Accessed 03. 10.2014).

[47] Jin-kook Lee, Charles M. Eastman, Jaemin Lee, Matti Kannalaô, Y.-s. Jeong,Computing walking distances within buildings using the universal circulationnetwork, Environ. Plann. B: Plann. Des. 37 (2010) 628–645.

[48] Virtualbuliders, abimo Webpage, Virtualbuliders, 2014. Available at: <http://www.abimo.co.kr>. (Accessed 02. 09. 2014).