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

Advanced Engineering Informatics xxx (2015) xxx–xxx

Contents lists available at ScienceDirect

Advanced Engineering Informatics journal homepage: www.elsevier.com/locate/aei

Requirements for computational rule checking of requests for proposals (RFPs) for building designs in South Korea Miyoung Uhm a, Ghang Lee a,⇑, Younghyn Park a, Sanghun Kim a, Jiwon Jung a, Jin-kook Lee b a b

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

a r t i c l e

i n f o

Article history: Received 9 September 2014 Accepted 22 May 2015 Available online xxxx Keywords: Request for proposal (RFP) Design rule checking Design compliance checking Building information modeling (BIM) Context-free grammar (CFG)

a b s t r a c t This study reports on the requirements for developing computer-interpretable rules for checking the compliance of a building design in a request for proposal (RFP), especially in the building information modeling (BIM) environment. It focuses on RFPs for large public buildings (over 5 million dollars) in South 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 RFP rules. Each RFP was composed of over 1800 sentences. Of these, only three to 366 sentences could be translated into a computer-interpretable sentence. For further analysis, this study deployed context-free grammar (CFG) in natural language processing, and classified morphemes into four categories: i.e., object (noun), method (verb), strictness (modal), and others. The subcategorized morphemes included three types of objects, twenty-nine types of methods, and five levels of strictness. The coverage applicability of the derived objects and methods was checked and validated against three additional RFP cases and then through a test case using a newly developed model checker system. The findings are expected to be useful as a guideline and basic data for system developers in the development of a generalized 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 then interprets the RFP into a physical form based on his experience and knowledge [1]. During this design phase, the RFP acts as a design guide throughout all design phases and establishes criteria for design assessment [2]. However, RFP-compliance checking is cognitively challenging for designers for several reasons. First, a building is composed of many pieces of elements, which are geometrically complex and interwoven [3], so manual design checking is error-prone and the results are unreliable [2]. Second, designers may misinterpret design requirements in an RFP due to the ambiguous nature of natural language or through human error [4,5]. Third, RFP-based design checking is very time consuming and labor intensive. According to a survey by McGraw Hill Construction Research and Analytics [6], nearly half of architects and owners spend more than 26 h on code checking on a typical ⇑ Corresponding author. E-mail addresses: [email protected] (M. Uhm), [email protected] (G. Lee), [email protected] (Y. Park), [email protected] (S. Kim), Gomtang15@ yonsei.ac.kr (J. Jung), [email protected] (J.-k. Lee).

project. Our own early survey shows that architects check their design against an RFP far more frequently than against building codes and other types of design references and they consider an RFP more important than building codes and regulations as a design reference, as shown in Fig. 1 [7]. Fourth, manual checking results in redundant data input, especially in a collaborative design environment, due to the difficulties in data and rule sharing [8]. These problems of complexity, ambiguity, inefficiency, and redundancy can be dramatically reduced by automating the design checking process. An example can be found from medical informatics, where physicians often make mistakes of omitting certain tests or treatments. These errors were reduced by developing an automated reminder for certain treatments and tests based on medical practice guidelines [9]. Interest has been increasing in automated design checking to improve 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 enabled automate checking of building codes and spatial requirements for notable examples such as the courthouse design guidelines of the U.S. General Services Administration (GSA), the International Building Code of International Code Council (ICC), and the Americans with Disabilities Act (ADA) standard for accessible

http://dx.doi.org/10.1016/j.aei.2015.05.006 1474-0346/Ó 2015 Elsevier Ltd. All rights reserved.

Please cite this article in press as: M. Uhm et al., Requirements for computational rule checking of requests for proposals (RFPs) for building designs in South Korea, Adv. Eng. Informat. (2015), http://dx.doi.org/10.1016/j.aei.2015.05.006

2

M. Uhm et al. / Advanced Engineering Informatics xxx (2015) xxx–xxx

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

design [2,12–14]. Although code-compliance checking has been the object of many studies for a long time [15], RFP-compliance checking has not been a major focus. Previous research topics have perhaps leaned towards code-checking rather than RFP-checking because building codes are the minimum legal requirements and strictly regulate design and construction submittals for permits. However, building codes do not describe an owner’s specific requirements; thus, improvements in the quality of a building and owner satisfaction require an understanding and proper reflection of the owner’s requirements in an RFP – one without errors or omissions on the design, especially in a competitive bid. The aim of this paper is to specify the computational requirements for developing computer-interpretable rules for checking the compliance of a building design in a request for proposal (RFP), especially in the building information modeling (BIM) environment. The paper is organized into eight sections. Following this introduction, the next section describes the research scope and method. The third section reviews existing work in the field of automated rule-based design checking. The fourth section briefly introduces the concept of context-free grammar (CFG) and describes how RFP sentences are parsed into a computer-interpretable form using the CFG approach. The fifth section reports the results of RFP sentence analysis and the objects and methods derived from RFPs. The sixth section validates the derived objects and methods using three RFP cases. The seventh section demonstrates the applicability of design rules created using the objects and methods derived in this study using a newly developed BIM model checker and a translator. Finally, the conclusion section discusses the contributions, limitations, and the future direction of this work.

2. Research scope and method RFPs may differ by building type, year, regions, and building size [2,8,15]. If a building is small or simple, the RFP may not contain many requirements. Hospitals may have different requirements from office buildings, but even if the building types are the same, requirements in the 1980s may differ from those in the 2000s. Requirements for a residential complex in South Korea may also differ from those for similar complexes in the US. This study limits its scope to the RFPs published for the past five years (2008–2012) for public buildings in South Korea with budgets over USD 5 million. The RFPs were collected from the South Korean on-line e-procurement system [16] called ‘Nara-jang-teo (national market)’. Nara-jang-teo is run by the Korean Public Procurement Service (PPS) to solicit bids for all kinds of goods and services that are ordered by the Korean government and public institutions. An RFP for buildings provides a summary of a project,

the project goal, a delivery method, and detailed project requirements. The research team collected and analyzed RFPs over the course of approximately 10 months (from 2013 to 2014) through the following steps:  Step 1 (Data collection and setup): RFPs for building projects from 2008 to 2012, which were over USD 5 million, were collected from Nara-jang-teo, the South Korean on-line e-procurement system. A total of 113 RFPs satisfied these criteria. However, among the 113 RFPs for building projects, a majority of the RFPs were for construction projects and only 27 RFPs were for building design projects. These 27 RFPs were associated with six types of buildings: residential complex, office building, exhibition facility, hospital, courthouse, and sports facility. Among these 27 RFPs, 23 RFPs were set as analysis data for deriving objects, methods, and the level of strictness required to develop computer-interpretable design rules for automated RFP-compliance checking and four RFPs, each from the residential complex, office, exhibition facility excluding courthouse and sports facility categories that had only one case per building type, as well one hospital RFP, were set as validation 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 each sentence into sentences that were equivalent to one rule. Then, each sentence in an RFP was examined and categorized into computer-interpretable and non-computer-interpretable sentences. Non-computer-interpretable sentences are those that are difficult for a machine to determine ‘‘satisfied’’ or ‘‘failed’’ without additional guidelines. Most of those sentences included qualitative expressions such as ‘high quality,’ ‘beautiful,’ and ‘proper’. Details are described in Section 4.2.  Step 3 (Sentence parsing): Each computer-interpretable sentence was broken down into morphemes. Each morpheme was then categorized into four types [object (noun), method (verb), strictness (modal such as ‘must’ and ‘should’), and others] deploying the context-free grammar (CFG) approach in natural language processing (NLP) [17]. The CFG is used in this study since it provides a widely accepted framework for analyzing and rebuilding well-formed machine-readable expressions (i.e., rules in this study) from natural language [18]. Details are described in Section 4.3.  Step 4 (Analysis – Derivation of objects and methods): All sentences were divided into morphemes using a simple automated word extractor developed by the research team, but each morpheme had to be manually classified into object (noun), method (verb), strictness (modal), and others by the researchers due to the general challenges in natural language processing, such as

Please cite this article in press as: M. Uhm et al., Requirements for computational rule checking of requests for proposals (RFPs) for building designs in South Korea, Adv. Eng. Informat. (2015), http://dx.doi.org/10.1016/j.aei.2015.05.006

M. Uhm et al. / Advanced Engineering Informatics xxx (2015) xxx–xxx

synonym and ambiguity issues. We developed a thesaurus to avoid redundancy between similar terms. The extracted objects, methods, and modals were examined and terms with similar meanings were merged. Modal auxiliaries were categorized into four levels to express the strictness of each rule [19]. Details are described in Sections 5.1–5.3.  Step 5 (Translation – Rule creation): The sentences were translated into computer-interpretable Semantic Web Rule Language (SWRL) rules [20] using the objects and methods derived from the previous steps. SWRL is a rule specification language based on the Web Ontology Language (OWL) and the Rule Markup Language (RuleML). Details and examples are described in Section 5.  Step 6 (Validation): The coverage and applicability of the objects and methods derived from previous steps were validated using four validation cases (RFPs). The list includes four types of facilities: residential complex, office building, exhibition facility, and hospital. After applying methods to the projects that were left out, methods were updated based on the validation results through steps 2–5. Details are described in Section 6.  Step 7 (Applicability test): As the final step, the applicability of specified rules was tested using ‘abimo Checker,’ a newly developed BIM model checker developed for this study. We also developed a SWRL-to-Python translator for the applicability test because ‘abimo Checker’ used Python as a rule-checking scripting language. Details are described in Section 7. The following section briefly reviews previous studies and their importance. 3. Previous studies In order to reduce design errors, a considerable number of studies have focused on the causes of design errors and effective methods to prevent them [21–23]. The theoretical background of error management studies is often grounded in quality control theories in manufacturing such as ‘six sigma’ [24]. The quality control theories stress the importance of understanding and analyzing customers’ needs and satisfaction in reducing errors and achieving the target quality of outcomes [25,26]. In the architecture, engineering, and construction (AEC) industry, a checklist is normally used for design quality management. A checklist is ‘a list of action items or criteria that allow the user to record the presence/absence of the individual items listed to ensure that all are considered or completed [27].’ However, the manual design checking method, whether a checklist is used or not, is very ineffective in detecting mistakes or omissions and also does not guarantee the accuracy of check results [10]. The use of an alternative – the BIM-based automated design error detection – is therefore increasing [28]. For example, Statsbygg, the Norwegian government agency in charge of construction and real estate matters, evaluated the compliance of a design with ISO 21542, the international standard that defines the accessibility and usability of the built environment [29], using a BIM model checker [30]. The U.S. General Services Administration (GSA) checked the circulation in a courthouse by different security levels specified in the courthouse design guide [31] using a BIM model checker [2]. These BIM implementation cases present the benefits of the accuracy of requirement checking and the efficiency of the work [28]. The use of computer-interpretable requirements by the AEC industry is rare when compared to other industries. In the field of medicine, the patient’s medical information is managed in a computer-interpretable form [32]. Requirements engineering (RE) also commonly uses computer tools such as IBM DOORS for requirements definition and management throughout a RE

3

lifecycle (i.e., requirement elicitation, identification, analysis, specification, modeling, validation, and management) [19,33]. However, as the number of BIM-assisted projects increases in the AEC industry, the use of computers in design and requirements management is also increasing. The method of design checking using BIM can be categorized into clash detection and rule-based design checking. Clash detection is a geometry-based checking method that detects the physical conflicts of objects in a BIM model. Rule-based checking is a method for checking the compliance of a design with rule sets based on the arithmetic operation and deduction of values set beforehand [34]. The clash detection approach is so generic that it can be applied to any models once the function is implemented in a BIM system. Naturally, clash detection has become the most popular way to use BIM currently [28,35]. However, the rule-based approach requires the development of rule sets for different design requirements and, even before that, the development of objects and functions (methods) required to specify the rules. If a model checker is a Compact Disc (CD) player, the rule sets are CDs. Thus, even if a well-developed model checker exists, a model cannot be checked without rule sets. For this reason, the implementation of rule-based design check is slow in practice, although several model checkers are already available in the market. Widely known automated rule-based model checkers include Revit [36], Navisworks [37], Solibri Model Check (SMC) [38], Express Data Manager (EDM) [39], and FORNAX [40]. Another reason for the slow adoption of automated rule-based design checking in the AEC industry is that each model checker specifies rules in its own format using different computer languages. Thus, the reuse or sharing of existing rule sets are impossible [34,41,42]. The development of rules in a sharable and reusable format is also critical for accelerating the adoption of automated design checking in the industry [42]. This study takes an approach of specifying rules in a standard rule description language, SWRL, and translating the rules specified in SWRL into a scripting language (e.g., Java and Python) that is used in a target model checker (e.g., Solibri). This strategy is based on an assumption that, in the future, a client will distribute an RFP with a separate design requirement rule set specified in SWRL and designers will automatically check their designs multiple times as the design develops by using any BIM model checker of their choice by importing the SWRL rules into the model checking system. However, the very first step is to understand the objects and methods required to specify requirements rules. The next section describes in detail how – and which – objects and methods required for automated design check of buildings in South Korea were derived. 4. Analysis of RFPs The RFPs collected and set up to develop methods were for building projects over USD five million within five years. A total of 27 RFPs were selected and they were composed of six types of facilities. From these RFPs, 1331 computer-interpretable sentences were collected from 9833 sentences written in natural languages and each was made into a single sentence that has a verb. We parsed the computer-interpretable sentence to develop the method and object. This section describes the RFP analysis methods and results in detail following the analysis steps described in the second section. 4.1. Data collection and setups As described earlier, the target of analysis was limited to RFPs that satisfied the following criteria based on an assumption that

Please cite this article in press as: M. Uhm et al., Requirements for computational rule checking of requests for proposals (RFPs) for building designs in South Korea, Adv. Eng. Informat. (2015), http://dx.doi.org/10.1016/j.aei.2015.05.006

4

M. Uhm et al. / Advanced Engineering Informatics xxx (2015) xxx–xxx

requirements in RFPs for small buildings can be covered by the objects and methods required by large buildings and that design requirements may vary by region and time: (a) RFPs for buildings with budgets over USD five million: In South Korea, buildings with budgets over USD five million are classified as large buildings and are subjected to additional requirements in the bidding process, such as pre-qualification (PQ) and value engineering (VE). A high standard for design quality is also required. (b) Buildings constructed within the recent five years, i.e., from 2008 to 2012: Requirements for space and building services change over time as residents’ needs, cultures, and technologies change. We collected RFPs within the recent five years so that we could derive objects and methods that reflected the latest design trend. RFPs between 2008 and 2012 were collected 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 in South Korea. The scope of this study was limited to the public buildings in South Korea because this study was conducted as one of preparation processes for the 2016 BIM initiative. A total of 27 RFPs satisfied these criteria. The collection was composed of 13 residential complexes, five office buildings, three hospitals, three exhibition facilities, a sports center, and a courthouse. Residential complexes and office buildings accounted for 66% of the RFP types. Courthouses and sports centers over USD five

million were rare. The project name, owner, gross floor area, and budget of each RFP are specified in Table 1. Ten of the thirteen residential complex projects were ordered by the Government Employees Pension Service. Six new office building projects were associated with the relocation of government ministries to Sejong from Seoul. Two of three hospitals projects were affiliated with universities. Before analysis, the 27 RFPs were divided into two groups. One group was for analyzing and deriving objects and methods required for developing design rules from RFPs. The other group was for validation of the derived objects and methods. The analysis case consisted of 23 RFPs and the validation case included four RFPs, one each from exhibition facilities, hospitals, office buildings, and residential complexes. No validation case could be set for the building types with just one RFP case such as sports center and courthouse. The validation cases were selected randomly. 4.2. Preprocessing The collected RFPs were analyzed from 2013 through 2014 for about 10 months. The sentences in RFPs were first decomposed into shorter sentences until each sentence indicated one design rule. As a general rule of thumb, a single sentence usually contains a single verb, except for the cases where a single rule is composed of several conditions. The composite rules were rare. Some rules were also expressed in a table format. The table, for example, specified how many spaces were required, how large the spaces should be, and which department was the owner of a space. These tables

Table 1 Projects overview of selected RFPs. Project name

Type of facility

Owner

1

Ulsan District Court

Courthouse

Supreme Court

39,470

68

2

Sports center in Seongnam

Sports center

The city of Seongnam

26,500

57

3 4

National Institute of Biological Resources Daegu National Science Museum

Exhibition facility

21,937 23,471

97 117

5

National Institute Of Ecology

Ministry of Environment Ministry of Science, ICT and Future Planning Ministry of Environment

43,430

335

6

Pusan National University Yang-san Hospital (expansion) Seoul National University Bun-dang Hospital Seoul Medical Center

Hospital

Pusan National University

144,929

243

Seoul National University The city of Seoul

63,530 47,164

212 95

Korea credit guarantee fund headquarter Korean film council headquarter Korea consumer agency headquarter Health insurance review & assessment service headquarter Korean gas corporation headquarter Korea occupational safety &health agency headquarter

Office building

Korea Credit Guarantee Fund Korean Film Council Korea Consumer Agency Health Insurance Review & Assessment Service Korean Gas Corporation Korea Occupational Safety & Health Agency

39,006 21,668 30,925 58,169

86 51 75 123

23,934 41,406

39 89

Sang-rok official apartment in Sejong Sang-rok official apartment in Goyang Public housing in Sun-un district 12 block apartment in Eun-pyeng newtown Sang-rok official apartment in Kimpo A6 block apartment in Goyang M2 block apartment in Sejong Sang-rok official apartment in Han-river new town Sang-rok official apartment in Namyangju Sang-rok official apartment in Inchon Apartment in Dae-yon district Sang-rok official apartment in Guangyo Sang-rok public apartment in Guangyo

Residential complex

118,866 95,819 75,069 67,518 68,921 64,829 64,215 68,921 96,106 80,333 421,456 149,900 70,473

130 122 87 78 65 64 70 156 126 105 406 157 73

7 8 9 10 11 12 13 14

15 16 17 18 19 20 21 22 23 24 25 26 27

Government Employees Pension Service Government Employees Pension Service Gwangju metropolitan City Corporation SH corporation Government Employees Pension Service Government Employees Pension Service Government Employees Pension Service Government Employees Pension Service Government Employees Pension Service Government Employees Pension Service Busan Metropolitan Corporation Government Employees Pension Service Government Employees Pension Service

Gross floor area (m2)

Budget (million USD)

Please cite this article in press as: M. Uhm et al., Requirements for computational rule checking of requests for proposals (RFPs) for building designs in South Korea, Adv. Eng. Informat. (2015), http://dx.doi.org/10.1016/j.aei.2015.05.006

5

M. Uhm et al. / Advanced Engineering Informatics xxx (2015) xxx–xxx

also had to be analyzed and translated into rules. About 9800 sentences and 7000 rules in a table form were extracted from 23 RFPs, as shown in Table 2. From the extracted 9833 sentences and 7040 rules in tables, only computer-interpretable sentences were chosen. The criteria for computer-interpretable sentences were (a) whether a sentence or data included quantitative or numerical values, (b) whether verbs could be translated into a computer-interpretable expression (function or method) and (c) whether a list of objects included in a sentence had a potential to be included in a BIM model. For example, the sentence stating that the height of the ceiling had to be ‘sufficient for the people’s residence’ could be translated differently depending on the interpreter and therefore could not be interpreted by a computer, while the sentence 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

non-computer-interpretable. The sentences that provided general descriptions rather than design rules were also eliminated. As summarized in Table 2 total of 1331 sentences was selected as computer-interpretable sentences according the above criteria. The ratio of computer-interpretable sentences to the total number of sentences differed depending on projects and ranged 2–55%. In the case of the courthouse, 91 sentences out of 166 were computer-interpretable (55%). This number was exceptionally higher than that of the other cases. Generally, the ratio of computer-interpretable sentences in an RFP was low, with an average was 14%, as shown in Table 2. On the other hand, all 7040 table rules could be translated into computer-interpretable sentences. However, differences existed between RFPs in terms of use of tables in design requirement specification. For example, RFPs for medical facilities expressed many design rules in a table format whereas RFPs for residential complexes did not.

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

Title

Number of sentences Number of natural languages sentences (A)

Table data Computer-interpretable sentences Number of sentences (B)

Ratio (%)

Number of rules (C)

Courthouse

Ulsan District Court

166

91

55

176

267

Sports center

Sports Center in Sungnam

102

11

11

29

40

Exhibition facility

National Institute of Biological Resourcesa Daegu National Science Museum National Institute of Ecology

301

37

12

151

188

113

25

22

63

88

Hospital

Office building

Residential complex

Pusan National University Yangsan Hospitala Seoul National University Bundang Hospital Seoul Medical Center

245

4

2

92

96

1865

366

20

2590

2956

1879

223

12

1133

1356

1746

270

16

2022

2292

Korea Credit Guarantee Funda Korean Film Council Korea Consumer Agency Health Insurance Review & Assessment Service Korean Gas Corporation Korea Occupational Safety & Health Agency

281 214 515 616

33 10 34 71

12 5 7 12

62 142 159 90

95 152 193 161

222 503

4 54

2 11

115 162

119 216

Sang-Rok Official Apartment in Sejonga Sang-Rok Official Apartment in Goyang Public Housing in Sunun District 12 block apartment in Eunpyeng newtown Sang-rok official apartment in Kimpo A6 block apartment in Goyang M2 block apartment in Sejong Sang-Rok Official Apartment in Hangang new town Sang-Rok Official Apartment in Namyangju Sang-rok Official Apartment in Inchon Apartment in Daeyon district Sang-rok Official Apartment in Guangyo Sang-rok Public Apartment in Guangyo

53

5

9

4

9

67

5

8

4

9

84

3

4

4

7

298

40

13

4

44

71

5

7

4

9

64 56 71

5 5 5

8 9 7

4 4 4

9 9 9

65

5

8

4

9

68

5

7

4

9

38 65

5 5

13 8

6 4

11 9

65

5

8

4

9

9833

1331

14

7040

8380

Total a

Total number of computer-interpretable sentences and table rules (B + C)

Validating group.

Please cite this article in press as: M. Uhm et al., Requirements for computational rule checking of requests for proposals (RFPs) for building designs in South Korea, Adv. Eng. Informat. (2015), http://dx.doi.org/10.1016/j.aei.2015.05.006

6

M. Uhm et al. / Advanced Engineering Informatics xxx (2015) xxx–xxx

A total of 8380 rule instances were collected. The number of rules extracted from tables outnumbered those from sentences: 1130 rules were collected from sentences and 7040 rules from tables. The number of rules also varied dramatically by building type. Hospitals requested from 1000 to 3000 design rules whereas other types of buildings had fewer than 300 rules. This explains why hospitals are generally regarded as one of the most challenging building types to design. 4.3. Parsing sentences using the CFG approach In order to derive objects and methods required to specify design rules, the individual sentences were parsed into morphemes following the CFG approach. In linguistics, a morpheme is the atomic morphological unit. We categorized morphemes into four types of grammatical elements (i.e., nouns, verbs, modals, and others) so that we could later translate them into objects, methods, the levels of strictness, and properties. Modifiers such as adjectives and adjective phrases were also analyzed and later translated into properties or methods of an object. Fig. 2 illustrates an example of a sentence that states that the area of a single patient room shall have a minimum clear floor area of 120 square meters. From this example, we can deduce that this rule requires two objects ‘room’ and ‘floor’ from two noun phrases and a method (function) ‘has’ from verb ‘have’. The verb ‘have’ defines the relationship between ‘room’ and ‘floor.’ This relationship 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-patient treatment room and the floor has a specific minimum floor area requirement. 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 is marked as ‘Pass.’ Judging by the modal verb ‘shall’, this rule also has high strictness; that is, if a design fails this rule, the design will

not be accepted by the client. Each sentence was analyzed and converted into rules through these steps. The analysis results are described in detail in the next section. 5. Analysis results From 1331 computer-interpretable sentences and 7040 table rules, we derived three types of objects, twenty-nine methods, and four levels of strictness. The following sections describe them in detail. 5.1. Nouns We categorized nouns into three types of objects: space, building element, and equipment. This classification was created considering the compatibility with OmniClass [42] and Industry Foundation Classes [43]. Space is equivalent to IfcSpace in IFC [43] and space in OmniClass [44]. Building element is equivalent to IfcBuildingElement in IFC [45] and Elements in OmniClass [42]. However, IFC and OmniClass does not have a single entity that can be directly mapped to equipment because some RFPs require a space to accommodate certain types of furniture and electrical equipment (e.g., special medical equipment), but IFC and OmniClass have relatively little emphasis on these types of requirements. We used the term equipment broadly to include mechanical, plumbing, and electrical (MEP) equipment, furniture, and electrical appliances. Equipment includes IfcDistributionElement (MEP elements) and IfcFurnishingElement (furniture and the like) in IFC and equipment and furnishings in OmniClass table 21 (Elements). Electrical appliances such as monitors and medical devices are not included in IFC and OmniClass. According to IFC, space is ‘an area or volume bounded actually or theoretically,’ and a building element is ‘a structural and space separating system of a building’ [43,45]. By equipment, we mean a non-building element that is a part of an air, water, or electric distribution system of a building, or essential furniture or an appliance that is required by a space to perform its target function. Synonyms and similar terms existed in RFPs. In order to avoid redundancy, we developed a thesaurus and analyzed nouns in RFP sentences. Table 3 summarizes the distribution of noun types in RFP types. As shown in Table 3, most design guidelines in RFPs focus on space. In particular, RFPs for the courthouse and office building

Fig. 2. An example of the RFP sentences analyzed in the form of a CFG tree. ⁄ Auxiliary verb (Aux), Adjective (Adj), Determiner (Det), Noun (N), Noun phrase (NP), Preposition (Prep), Sentence (S), Verb (V), Verb phrase (VP).

Please cite this article in press as: M. Uhm et al., Requirements for computational rule checking of requests for proposals (RFPs) for building designs in South Korea, Adv. Eng. Informat. (2015), http://dx.doi.org/10.1016/j.aei.2015.05.006

7

M. Uhm et al. / Advanced Engineering Informatics xxx (2015) xxx–xxx Table 3 Distribution of noun types in RFPs by facility type a. Type

Courthouse Freq.

a

Sports center %

Freq.

Hospital

%

Freq.

Exhibition facility %

Freq.

Office building %

Freq.

%

Residential complex Freq.

%

Space Building element Equipment

263 3 1

99 1 0

31 1 8

78 2 20

768 43 48

89 5 6

362 4 6

97 1 1

906 27 3

97 3 0

125 16 11

82 11 7

Total

267

100

40

100

859

100

372

100

936

100

152

100

Frequency (Freq.) and Ratio (%).

had a much larger number of design guidelines related to spatial requirements (space objects) than the other RFP types did. Compared to other facilities, RFPs for the sports center, the residential complex and the hospital included a relatively large number of design 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 translation of nouns. Human interpretation and intervention were unavoidable because of the ambiguity of a natural language. For example, design guidelines, ‘Two rooms must be placed closely,’ could mean the following three situations: (a) Two rooms must be located side by side, but may not be directly 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 grouped verbs by their role into object existence, quantity check, distance check, area, space location, circulation, window-wall ratio, and material property. The verbs in the eight groups were then translated into 29 methods. Fig. 4 illustrates the 29 methods grouped by object type and role. Table 4 lists their syntax, description, and example.

Similar to the translated sentence examples explained in Section 4.3, the final rules were specified in SWRL. About a half of 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 the condition is not met. The syntax, described in plain English, and an 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’,’Lecture Room’) = True

The other half of the methods is Long type. For example, when a designer needs to check how many rooms are required, the ‘getN umberOfSpace’ method makes this possible. It is able to count the number of rooms in specific area, in a specific building. The ‘getNumberOfSpace’ method returns true if the Patient room exists in ‘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’ on the ‘c’ story of the ‘d’ building. Example: getNumberOfSpace (‘Patient Room’,‘Ward’) = 4000

Fig. 3. An example of ‘isAdjacent’ and ‘isAccessible’.

Please cite this article in press as: M. Uhm et al., Requirements for computational rule checking of requests for proposals (RFPs) for building designs in South Korea, Adv. Eng. Informat. (2015), http://dx.doi.org/10.1016/j.aei.2015.05.006

8

M. Uhm et al. / Advanced Engineering Informatics xxx (2015) xxx–xxx

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

Some methods have option arguments. For example, the method ‘isVisibleFrom’ is used to check whether ‘Patient rooms’ are observable from the ‘Nurse station’. This visibility depends on the door type (with sight glass or not) and door status (open/closed). This door types are expressed as Type zero to two. Type zero means that nurses are able to see the inside space of a patient room through the opened door from the nurse station. This type is possible to apply to the nurse station in an emergency room that has no doors between stretchers. Type one means that nurses are able to see around the patient room because of a closed door. Type two means that nurses can look at the patient in the room through a window. Type two is utilized in infection zones or infant units. The method ‘isVisibleFrom’ returns true if the patient room and nurse station exists for all. This method returns true if the door type 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’ through door type ‘c’. Example: isVisibleFrom (‘Nurse Station’, ‘Patient Room’, 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 be adjacent’ was translated into ‘isAccessble’. In case (c), the two rooms must be adjacent and accessible. Some methods included options. For example, ‘getSpaceWidth’ included an option to choose 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 ‘checkSetBased Circulation’ method was defined based on the algorithm proposed by 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 the 29 methods followed by ‘getNumberOfSpace’ (28%), ‘isComposedOf’ (13%), ‘hasEquipment’ (8%), and ‘isAccessible’ (3%). If ‘getNumberOfEquipment’ (2%) is added to this list, these six methods cover 95% of the design guidelines. This analysis result clearly shows which method should be developed first when a new rule-based design checking system is developed. Even if only the three most frequently methods, ‘getFloorArea’, ‘getNumberOfSpac e’, and ‘isComposedOf’, are implemented, over 80% (82%) of the design guidelines can be checked. However, the remaining 23 methods should not be ignored although they cover only 5% of the design guidelines when the use of methods is analyzed without considering building type (Fig. 6). This is because each building type has special design requirements and the 23 methods play an important role in each RFP when the method use is analyzed by building type. For example, 12 of the methods were used only for a certain type of building: Nine methods were found only in hospital RFPs and three only in office building RFPs. Hospital-specific methods were mostly related to equipment and they were ‘getNumberOfEl ement’, ‘getNumberOfEquipment’, ‘getSpaceWidth’, ‘getEquipmen tWidth’, ‘getEquipmentHeight’, ‘getSpaceDistance’, ‘getElementDis tance’, ‘isConnectedTo’ and ‘isVisibleFrom’. This is because a hospital requires a large amount of medical equipment and the space should be large enough to accommodate it. Similarly, office buildings are generally sensitive to parking lot and energy-saving issues and had ‘getLandscapeArea’, ‘getParkingLotArea’ and ‘getWindow WallRatio’ as office-specific methods. Table 5 summarizes which

Please cite this article in press as: M. Uhm et al., Requirements for computational rule checking of requests for proposals (RFPs) for building designs in South Korea, Adv. Eng. Informat. (2015), http://dx.doi.org/10.1016/j.aei.2015.05.006

9

M. Uhm et al. / Advanced Engineering Informatics xxx (2015) xxx–xxx Table 4 Syntax, description, and examples of 29 methods. Syntax

Description

Example

Boolean isComposedOf (Space ‘a’, Space ‘b’, [Space ‘c’], . . .) Boolean hasElement (Space ‘a’, Equipment ‘b’, [Element ‘c’],. . .) Boolean hasEquipment (Space ‘a’, Equipment ‘b’, [Equipment ‘c’]. . .) Long getStoryOfSpace (SpaceType ‘a’)

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

Long getNumberOfSpace (Space Type ‘a’, [Zone ‘b’], [Story ‘c’], [Building ‘d’]) Long getNumberOfElement (Space ‘a’, Element ‘b’) Long getNumberOfEquipment (Space ‘a’, Equipment ‘b’) Long getNumberOfParkingSpace (ParkingLot ‘a’) Long getSpaceWidth (Space ‘a’, Type b)

There are several spaces ‘a’ in zone ‘b’ on ‘c’ floor in ‘d’ building

isComposedOf (‘Education’,’Lecture Room’) = True hasElement( ‘Operation Room’, ‘Column’) = True hasEquipment ( ‘Warehouse’, ‘Ventilation’) = True getStoryOfSpace (‘Chiller room’) = B1F getNumberOfSpace (‘Patient Room’) = 4000 getNumberOfElement (‘Patient Room’, ‘Window’) = 4 getNumberOfEquipment (‘Patient Room’, ‘Bed’) = 4 getNumberOfParkingSpace (‘Parking Lot’) = 300 getSpaceWidth (‘Living Room’, Type 0) = 3000 getElementWidth (‘Patient Room_door’, Type 0) = 1100 getEquipmentWidth (‘Bed’, Type 0) = 1200 getSpaceHeight (‘Intensive care unit’, Type 2) = 3500

Long getElementWidth (Element ‘a’, Type b) Long getEquipmentWidth (Equipment ‘a’,Type b) Long getSpaceHeight (Space ‘a’, Type b)

Long getElementHeight (Element ‘a’, Type b) Long getEquipmentHeight (Equipment ‘a’, Type b) Long getSpaceDistance (Space ‘a’, Space ‘b’, Type c) Long getElementDistance (Element ‘a’, Element ‘b’, Type c) Long getEquipmentDistance (Equipment ‘a’, Equipment ‘b’, Type c) Long getFloorArea (Space ‘a’, Type b) Long getLandscapeArea (LandScape ‘a’) Long getParkingLotArea (ParkingLotArea ‘a’) Boolean isAccessible (Space ‘a’, Space ‘b’, Type c, Direction d) Boolean isAdjacent (Space ‘a’, Space ‘b’, Direction c) Boolean isConnectedTo (Element ‘a’, Element ‘b’, [Element ‘c’]...) Boolean isVisibleFrom (Space ‘a’, Space ‘b’, Type c) Boolean isSeparatedFrom (Space ‘a’, Space ‘b’, MEP_Circulation ‘c’, MEP_Circulation ‘d’) Boolean isExternal (Element ‘a’) Boolean checkSetBasedCirculation (SpaceGroup ‘a’, SpaceGroup ‘b’) Long getWindowWallRatio (Element ‘a’, Element ‘b’, Orientation c) String getMaterialProperty(Element ‘a’)

Space ‘a’ has element ‘b’and other elements Space ‘a’ has Equipment ‘b’and the other Equipment Space ’a’ is located on floor

Space ‘a’ has a number of Element ‘b’ Space ‘a’ has a number of Equipment ‘b’ Space has a number of ParkingLot ‘b’ Space ‘a’ has a width. The width of the Space ‘a’ is measured by the measurement criteria types; Inner wall (Type 0), center (Type 1), and outer wall (Type 2) Element ‘a’ has a width. The width of the Element ‘a’ is measured by the measurement criteria types; inside dimension (Type 0), outside dimension (Type 1) Equipment ‘a’ has a width. The width of the Equipment ‘a’ is measured by the measurement criteria types; inside dimension (Type 0), outside dimension (Type 1) Space ‘a’ has a height. The height of the Space is measured by the measurement criteria types; Space height, floor to ceiling (Type 0), center to center (Type 1), floor to floor (Type 2) Element has a height. The height of the Element is measured by the measurement criteria types; inside dimension (Type 0), outside dimension (Type 1) Equipment has a height. The height of the Equipment is measured by the measurement criteria types; inside dimension (Type 0), outside dimension (Type 1) The distance between Space ‘a’ and ‘b’ is measured by the measurement types; door to door (Type 0), longest (Type 1), physical distance (Type 2) The distance between building element ‘a’ and ‘b’ is measured by the measurement types; inside (Type 0), centerline (Type 1) The distance between equipment ‘a’ and ‘b’ is measured by measurement criteria; outside dimension (Type 0), centerline (Type 1) Area of space ‘a’ is figured out using three measurement types; inside dimension (Type 0), center line (Type 1), outside wall (Type 2) There is the sum of Landscape area There is the sum of parking lot area 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) Space ‘a’ is adjacent Space ‘b’ in the horizontal (Direction 0) or vertical (Direction 1) directions Element ‘a’ is connected Element ‘b’ and other elements Space ‘b’ is visible from Space ‘a’ through observation route types; open door (Type 0), closed door (Type 1), window (Type 2) The MEP_Circulation ‘c’ of Space ‘a’ is separated from the MEP_Circulation ‘d’ of Space ‘b’ Element ‘a’ is an external building element The circulation of Space Group ‘a’ is distinguished from Space Group ‘b’ There is the ratio of Element ‘a’ and Element ‘b’ in the four cardinal orientation

Element gets material property

methods were used in which building type, focusing on which object type. 5.3. Modals In general, many RFP sentences included modal auxiliaries to express the strictness level of the owner’s requests. From the RFP sentences, we derived four levels of strictness of design guidelines, as listed in Table 6. The four levels were determined by the use of either must, should, might, or could. The term ‘must’ indicates that

getElementHeight (‘Patient Room_door’, Type 0) = 1800 getEquipmentHeight (‘Bed’, Type 1) = 900 getSpaceDistance (‘ICU’, ‘Operating Room’, Type 0) = 3500 getElementDistance (‘P_wall’, ‘P _wall, Type 0) = 2700 getEquipmentDistance (‘Bed 1’, ‘Bed 2’, Type 0) = 3300 getObjectArea (‘Veranda’, Type 0) = 5 m2 getLandScapeArea (‘Landscape’)=50 m2 getParkingLotArea (‘Parking Lot’) > 10,000 m2 isAccessible(‘Dock’, ‘Exhibition’, Type 0, Direction 0) = True isAdjacent(‘Nurse station’, ‘Treatment’, Direction 0) = True isConnectedTo (‘Girder’, ‘Column’) = True isVisibleFrom (‘Nurse Station’, ‘Patient Room’, Type 1) = True isSeparatedFrom (‘Operating’, ‘ICU’, R1’, ‘R2’) = True isExternal( ‘Wall 02’) = True checkSetBasedCirculation(‘Staff space’, ‘Guest space’) = True getWindowWallRatio(‘External Wall’,’Window’, Orientation ‘south’) = 40% getMaterialProperty (Element ‘External’) = CONC20MPA

a design guideline is mandatory without an exception. In some sentences, 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 recommendation and is often expressed with words such as ‘is considered,’ and ‘if possible.’ ‘Could’ is for optional cases and can also be expressed using ‘can’. Most design requirements (93%) were expressed using ‘should’. The other modal auxiliaries, i.e., ‘must’, ‘might,’ and ‘could,’ were very seldom used. Still, the result of the strictness level analysis

Please cite this article in press as: M. Uhm et al., Requirements for computational rule checking of requests for proposals (RFPs) for building designs in South Korea, Adv. Eng. Informat. (2015), http://dx.doi.org/10.1016/j.aei.2015.05.006

10

M. Uhm et al. / Advanced Engineering Informatics xxx (2015) xxx–xxx

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

can be used to express the weight of each design guideline and eventually, in the future, to quantify the overall compliance score of a design with a design guide. The objects and methods derived from 23 RFPs were validated using four validation cases. The next section reports the validation results in detail.

a hospital. The four RFPs were randomly selected when the collected 29 RFPs were categorized into the analysis group and the validation group. All the design requirements in the four RFPs could be expressed using the derived objects and methods and the sufficiency of the derived objects and methods was validated. All validation cases required all three object types. However, only some methods were used in the four cases: Among the 29 methods, the hospital RFP used 21 methods (72%), the office building RFP 13 methods (45%), the exhibition facility RFP 10 methods (35%), and the residential complex RFP only four methods (14%), as presented in Table 7. However, we do not rule out a possibility of having an RFP for a building with very exceptional design requirements such as a data center or a nuclear plant in the future. In such cases, additional objects and methods may need to be specified. And Table 7 compares which specific methods were required in the analysis cases and the validation cases by facility type. Differences appeared in the use of methods according to facility type, but not between the analysis case and the validation case. This means that if an RFP for a certain type of facility is newly created, it is likely that the same set of methods and objects used in existing RFPs will be required by the new RFP. This reconfirms that the objects and methods derived in this study are likely to be sufficient to develop computer-interpretable rules for new RFPs for, at least, hospitals, exhibition facilities, office buildings, residential complexes, sports centers, and courthouses in South Korea.

6. Validation

7. Applicability test

The sufficiency of the objects and methods derived from 23 RFPs as elements required to develop design rules for RPFs for buildings were validated by analyzing design guidelines described in four additional RFPs using the objects and methods and checking whether design guidelines existed that could not be expressed using the derived objects and methods. The four RFPs were for a residential complex, an exhibition facility, an office building, and

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

Fig. 6. The 23 rarely used methods and their use ratios among the 29 methods.

Please cite this article in press as: M. Uhm et al., Requirements for computational rule checking of requests for proposals (RFPs) for building designs in South Korea, Adv. Eng. Informat. (2015), http://dx.doi.org/10.1016/j.aei.2015.05.006

11

M. Uhm et al. / Advanced Engineering Informatics xxx (2015) xxx–xxx Table 5 The application of methods by facility and object types. Range of use

Type of methods

Focused object

Courthouse

Sports center

Hospital

Exhibition

Office

Residential complex

All of the useful

isComposedOf hasElement hasEquipment getStoryOfSpace getNumberOfSpace getFloorArea getMaterialProperty

Space Building element Equipment Space Space Space Equipment

      

      

      

      

      

      

Generally useful

isAccessible checkSetBasedCirculation getSpaceHeight isAdjacent

Space Space Space Space

 

 



   

   

  

getNumberOfParkingLotArea getElementWidth getElementHeight getEquipmentDistance isSeparatedFrom isExternal

Space Building element Building element Equipment Equipment Building element



    

Hospital specific

getNumberOfElement getNumberOfEquipment getSpaceWidth getEquipmentWidth getEquipmentHeight getSpaceDistance getElementDistance isConnectedTo isVisibleFrom

Building element Equipment Space Equipment Equipment Space Building element Building element Space

Office specific

getLandscapeArea getParkingLotArea getWindowWallRatio

Space Space Building element

Partially useful

Total

Type of facility





    

 



            11

Fig. 7 illustrates an example of testing the ‘getElementWidth’ method. This ‘getElementWidth’ returns the width of a building element. The example rule states that the width of a door should be larger than the width of a stretcher. These rules are found mostly in hospital facilities. The red-colored doors in Fig. 7 are the ones that failed the design-compliance check. During the implementation, some methods were divided into several methods due to the internal data structure of ‘abimo’ and for the programming efficiency of implementation. Below is the getElementWidth example specified in SWRL and Python: rehabilitation(?x) ^ door(?y) ^ hasElement(?x,?y) ^ hasWidth(?y,?a) ^ swrlb:greaterThanOrEqual(?a, 115) ! AccenptEntity(?x) Import kbCheckModule; Checker = kbCheckModeule.kbChecker() SpaceList = Checker.FindSpace(‘rehabilitation’)for space 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 checks whether 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:

8

25

10

19

13

Food depots (?x) ^ Kitchen (?y) ^ isAdjacent(?x, ?y) ! AcceptEntity(?x) 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 version of ‘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 buildings for deriving the objects and methods required to develop computer-interpretable rules for checking the compliance of RFPs in building design. RFP has received little attention in the automated rule-based BIM model checking field. However, many previous studies pointed out the inefficiency and unreliability of manual checking of the compliance of a design with an RFP and the efficiency of BIM-based automated design checking.

Please cite this article in press as: M. Uhm et al., Requirements for computational rule checking of requests for proposals (RFPs) for building designs in South Korea, Adv. Eng. Informat. (2015), http://dx.doi.org/10.1016/j.aei.2015.05.006

12

M. Uhm et al. / Advanced Engineering Informatics xxx (2015) xxx–xxx

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

a

Courthouse

Sports center

Hospital

N

N

%

N

%

N

%

N

%

N

%

N

%

– 100 – –

2 695 80 82

– 90 9 10

2 368 2 –

– 100 –

2 932 2 –

– 100 – –

– 148 3 1

– 97 2 1

6 2447 90 83

– 93 4 3

100

859

100

372

100

936

100.0

152

100

2626

100

%

Must Should Might Could

– 264 3 –

99 1

– 40 – –

Total

267

100

40

Exhibition facility

Office building

Residential complex

Total

Number (N) and Ratio (%). Table 7 Comparison of the use of methods in the analysis cases and the validation cases.

This paper collected and analyzed sentences from all the RFPs released for the past five years (2008–2012) for large public building designs in South Korea. A total of 27 RFPs for housing, office, exhibition, hospital, sports center, and courthouse projects were collected and separated into two groups; one for the analysis of objects and methods required to translate design requirements into computer-interpretable rules, and the other for validation of the analysis results. Hospitals had the largest number of sentences and included about 1800–1900 sentences per RFP. However, only 10–20% of sentences could be categorized into computer-interpretable sentences. On the other hand, in case of a courthouse RFP, over a half (55%) of 166 sentences could be categorized into computer-interpretable sentences. Some building types, such as hospitals and office buildings, also included many design rules specified in the form of tables rather than in natural language. In the case of hospitals, design rules specified in tables

ranged from 1000 to 2600. As the next step, the sentences, categorized as computer-interpretable, were broken down into morphemes using the CFG approach. The morphemes were classified into four types: namely, object (noun), method (verb), strictness (modal), and others. The object were subcategorized into three types (space, building element, and equipment), and the method into 29 types, and the strictness into four levels. The frequency of their use was analyzed. Spaces were the most commonly 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 ‘getNumberOfE quipment’ (2%). The top five frequently-used methods covered 93% of design guidelines and the top seven frequently-used methods, including the top five methods, covered 96% of design guidelines.

Please cite this article in press as: M. Uhm et al., Requirements for computational rule checking of requests for proposals (RFPs) for building designs in South Korea, Adv. Eng. Informat. (2015), http://dx.doi.org/10.1016/j.aei.2015.05.006

M. Uhm et al. / Advanced Engineering Informatics xxx (2015) xxx–xxx

However, the remaining 22 methods were also significant and some of them were essential in certain types of buildings depending on the special needs or regulations associated with a facility type. For example, hospital RFPs required certain types of equipment-related methods that were not required by other types of facilities. Only office buildings required methods associated with parking lots and landscape areas. The sufficiency of the derived objects and methods were validated using four validation RFP cases. All the computer-interpretable requirements in the four

13

RFPs could be covered by the objects and methods derived through the analysis process. We also found that RFPs for the same type of facility used the same set of methods. Thus, we can conclude that the objects and methods derived in this study are likely to support translation of future RFPs, at least for projects such as residential complexes, office buildings, exhibition facilities, hospitals, sports centers, and courthouses, into computer-interpretable rules. However, this study also leaves a limitation that special building types such as the data center and the digital library may require

Fig. 7. The application test result of ‘getElementWidth’ method in abimo.

Fig. 8. The application test result of ‘isAdjacent’ method in abimo.

Please cite this article in press as: M. Uhm et al., Requirements for computational rule checking of requests for proposals (RFPs) for building designs in South Korea, Adv. Eng. Informat. (2015), http://dx.doi.org/10.1016/j.aei.2015.05.006

14

M. Uhm et al. / Advanced Engineering Informatics xxx (2015) xxx–xxx

more objects and methods than the ones derived in this study. In addition, a set of sample rules was created using the derived objects and methods and the applicability was tested in a newly developed BIM model checker for this study. The results of this study are expected to be useful as a fundamental guide for model checker and rule developers who are interested in automating the compliance checking of a design with an RFP. The resultant automated design-compliance checking system and rules are expected to aid designers in effectively managing a design from frequent design change orders while keeping their clients’ requests. As a result, the designer can focus more on improving the quality of a design. These unambiguously defined design guidelines may also be used throughout the lifecycle of a facility when the design intents require reexamination. Acknowledgements This research was supported by a grant (14AUDP-C067817-02) from the Architecture & Urban Development Research Program funded by the Ministry of Land, Infrastructure and Transport of the Republic of Korea. References [1] K. Odusami, Perceptions of construction professionals concerning important skills 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 of building 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 management using an ontological framework, CIRP Ann. – Manuf. Technol. 54 (2005) 109– 112. [5] N.K. Acharya, Y. Lee, J. Kim, Design errors: inefficiency or carelessness of designer? J. Perform. Construct. Facilit. 20 (2006) 192–195. [6] McGrawHill Construction, Interoperability in the construction industry, SmartMarket Report, Interoperability Issue, 2007. Available at: . [7] M. Uhm, Y.-h. Park, J. Won, G. Lee, A study on the development direction and priority of the BIM-based hospital design validation technology, J. Architect. Inst. Korea Plann. Des. 29 (2013) 147–155. Available at: . [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 of corollary 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 without BIM, Architectural Engineering, Yonsei University, Master Degree, 2013. [11] S. Zhang, J. Teizer, J.-k. Lee, C.M. Eastman, M. Venugopal, Building information modeling (BIM) and safety: automatic safety checking of construction models and schedules, Autom. Construct. 29 (2013) 183–195. [12] C. Kam, 02- GSA (general services administration) BIM Guide for spatial Program validation, GSA buiding information modeling guide series, GSA, Washington D.C., 2006. Available at: . [13] ICC (International Code Council), 2012 International building code (formerly BOCA, ICBO and SBCCI), 2012. Available at: . [14] ADA, 2010 Americans with Disabilities Act (ADA) Standards for Accessible Design, Department of Justice, 2010. Available at: . [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: (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 specifying information for automated product data modeling, Adv. Eng. Inf. 20 (2006) 155–170.

[19] A. Sharma, D.S. Kushwaha, Natural language based component extraction from requirement engineering document and its complexity analysis, ACM SIGSOFT Softw. Eng. Notes 36 (2011) 1–14. [20] I. Horrocks, P.F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, M. Dean, SWRL: A semantic web rule language combining OWL and RuleML, W3C Member submission, 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 in construction industry, J. Construct. Eng. Manage. 117 (1991) 341–359. [25] D. Samson, M. Terziovski, The relationship between total quality management practices 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-theoretic perspective, J. Operat. Manage. 21 (2003) 193–203. [27] B.M. Hales, P.J. Pronovost, The checklist—a tool for error management and performance improvement, J. Crit. Care 21 (2006) 231–235. [28] McGrawHill Construction, SmartMarket Report, The business value of BIM for constrcution in major global markets: How contractors around the world are driving innovations with building information modeling, McGrawHill Construction, 2014. Available at: . [29] ISO/TC59/SC16, ISO 21542:2011 Building Construction-Accessibility and Usability of the Built Environment, ISO, Geneva, Switzerland, 2011. [30] J.-K. Lee, Y.-S. Jeong, J. Lee, A case study of the building information modeling enabled 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: .. [32] N. Mulyar, W.M.P. van der Aalst, M. Peleg, A pattern-based analysis of clinical computer-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 and electronics engineeriners) 28 (4) (2011) 86–91. [34] E. Hjelseth, N. Nisbet, Overview of concepts for model checking, Proceedings of the CIB W78, Cairo, Egypt, 2010. [35] R. Kreider, J. Messner, C. Dubler, Determining the frequency and impact of applying BIM for different purposes on building projects, in: 6th International Conference on Innovation in Architecture, Engineering and Construction (AEC), Penn State University, PA, USA, 2010. [36] Autodesk, Revit Webpage, 2014. Available at: . [37] Autodesk, Navisworks Webpage, 2010. Available at: . [38] GRAPHISOFT, Solibri Model Checker Webpage, 2011. Accessible at: . [39] Jotne IT, Express Data Manager Webpage, 2009. Accessible at: . [40] novaCITYNETS, FORNAX Webpage, 2003, Aaccessble at: . [41] N.O. Nawari, BIM-model checking in building design, Proceeding of 2012 Structural Congress (2012) 29–31. [42] O.C.C.S, OmniClass Construction Classification System, Table 21-Elements, 2012 Aaccessble at: . [43] buildingSMART, IFC 2  3, IfcSpace, International home of open BIM, 2013. Aaccessble at: (Accessed: 25. 04. 2014). [44] O.C.C.S, OmniClass Construction Classification System, 2006. Table 14-Spaces by Form, 2006. Aaccessble at: (Accessed: 25. 04. 2014). [45] buildingSMART, IFC 2  3, IfcBuildingElement, International home of open BIM, 2013. Aaccessble at: (Accessed : 25. 04. 2014). [46] R. Nordquist, Verb-Glossary of Grammatical and Rhetorical Terms, About.com, 2014. (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 circulation network, Environ. Plann. B: Plann. Des. 37 (2010) 628–645. [48] Virtualbuliders, abimo Webpage, Virtualbuliders, 2014. Available at: . (Accessed 02. 09. 2014).

Please cite this article in press as: M. Uhm et al., Requirements for computational rule checking of requests for proposals (RFPs) for building designs in South Korea, Adv. Eng. Informat. (2015), http://dx.doi.org/10.1016/j.aei.2015.05.006