A logic-based representation and tree-based visualization method for building regulatory requirements

Abstract

Background

Many research and development efforts have been made for automated compliance checking of building designs with regulatory requirements, but there is a lack of a non-proprietary and user-understandable representation of building regulations to support automated compliance checking in the construction domain that is experimentally tested for understandability and reading speed.

Methods

This research investigates a logic-based representation and tree-based visualization method for building regulatory requirements. The logic-based representation is based on classic logic programming language and can directly support automated compliance checking. The tree-based visualization is expected to improve the understandability and reading speed of the logic-based representation. Therefore, this method attempts to add to the limited research in non-proprietary and user-understandable representation of building regulations that is experimentally tested for understandability and reading speed. To test the understandability and reading speed of regulatory requirements using this representation and visualization method, a survey was conducted to compare different representations, namely, text, logic-based, and tree-based.

Results

Statistical analysis of the survey results shows that the proposed tree-based visualization method can significantly improve the understandability and reading speed of the logic-based regulatory requirement representation and this visualization method is at a comparable status with the original text representation of regulatory requirements in terms of understandability and reading speed.

Conclusions

(1) The investigated logic-based representation and tree-based visualization method for regulatory requirements serves as one potential non-proprietary and user-understandable representation of building regulations; (2) this research shows that computable representations of regulatory requirements can achieve understandability and reading speed that are comparable to the original text representation through tree-based visualization; and (3) this research reveals that the tree-based visualization of regulatory requirements improves the understandability and reading speed of regulatory requirements when such use is compared to the computable logic-based representation.

Background

The automation in building code compliance checking has a long history dating back to the 1960s when Fenves et al. (1969) digitized the American Institute of Steel Construction’s (AISC) specifications into decision tables. Since then, a number of efforts have been made to explore the automated compliance checking of building designs with various types of code requirements using various types of computable representations. For example, Garrett and Fenves (1987) presented the automated compliance checking of structural design with structural codes using decision tables and information network to represent structural requirements from design standards; Delis and Delis (1995) examined the automated compliance checking of building architectural features (e.g., space configuration) with fire codes using IF/THEN rules to represent fire code requirements; Han et al. (1997) discussed the automated compliance checking of building components with accessibility requirements using simple simulations and rules to represent accessibility requirements; and Tan et al. (2007, 2010) proposed automated compliance checking of building envelope design using decisions tables to represent building codes and design regulations.

Some commercial automated compliance checking systems were developed. As surveyed by Eastman et al. (2009), several automated compliance checking projects have utilized rule-based checking platforms such as the Solibri Model Checker (SMC), the Express Data Manager (EDM) Checker, and FORNAX. Research efforts have also been designated for the representation of regulatory requirements for automated compliance checking purposes. For example, Lau and Law (2004) described a representation of regulations, standards, and codes using eXtensible Markup Language (XML) as well as ontology; Yurchyshyna et al. (2008) used a representation of regulatory requirements in the form of SPARQL Protocol and RDF Query Language (SPARQL) queries; Pauwels et al. (2011) proposed a representation of regulatory requirements using Notation 3 (N3) Logic; Hjelseth and Nisbet (2011) developed a Requirement, Applies, Select, and Exception (RASE) method for marking up regulatory requirements to support further processing into computable representations; Beach et al. (2013; 2015) extended the RASE method to a regulatory information representation at both the paragraph level and the word group level that can be converted to Semantic Web Rule Language (SWRL) rules; Dimyadi et al. (2014) adopted a representation of regulatory requirements using the Drools Rule Language (DRL); and Zhang and El-Gohary (2016a) developed a representation of regulatory requirements using first order logic. Compared to the methods used in commercial systems, these research efforts strive for a more flexible representation that potentially can be used to represent a variety of code requirements.

The need of a non-proprietary and user-understandable rule representation in automated compliance checking

The need of a non-proprietary and user-understandable representation of building regulations to support automated compliance checking has been pointed out by Garrett et al. (2014). Without such a representation, “many of these computable versions of regulations might go unverified, assumptions will not be understood or managed, and ambiguities may lead to misinterpretations” (Garrett et al. 2014). The aforementioned research efforts facilitated the transparency and openness of such representations and therefore helped with addressing this need. Many of these research efforts used well-established standard language representations such as N3 logic and LegalRuleML and thereby alleviated the problem of proprietary representation in most commercial systems. Some of these methods could use graphical representations to facilitate readers’ understanding. For example, in the method proposed by Dimyadi et al. (2014, 2016), resource description framework (RDF) was used to represent regulatory information which can be visualized as diagrams consisting of nodes and directed-arcs, and Business Process Model and Notation (BPMN) diagrams were used at the compliant design procedure level. Both RDF and BPMN diagrams potentially facilitated reader’s understanding. However, in spite of the seemingly spontaneous choice towards computable representations that can be easily visualized, little has been found by the author in previous research that focused on experimentally testing or improving the user-understandability of regulatory requirements in the building and construction domain for the various computable rule representations.

To address this research gap, in this paper, I propose here the use of a Prolog-based representation of regulatory requirement which uses a tree structure for visualization, and an experimental testing of the effect of this visualization on the understandability and reading speed of the regulatory requirements. This representation was implemented as part of a larger automated compliance checking system, the Semantic Natural Language Processing-based Automated Compliance Checking (SNACC) system. The regulatory information representation and visualization method is built upon the classic logic programming language – Prolog, which is an approximate realization of the logic programming computational model on a sequential machine (Sterling and Shapiro 1986). Prolog is the most widely used logic programming language; it is well developed with multiple open and freely available implementations. The tree-based visualization method was further developed to provide a way to facilitate understandability of this Prolog-based rule representation. While there are other visualization methods such as RDF and BPMN diagrams, it is out of the scope of this paper to compare with them. The paper is organized as follows: the Method Overview section briefly introduces the SNACC system, and describes the logic-based representation and tree-based visualization method in detail; the Experimental Testing and Results section describes an experimental testing of the representation and visualization method in comparison to the normal text representation; the Conclusions section highlights the analysis results from the experiment and makes conclusions about such representations and visualizations based on the analysis.

Tree representation in natural language processing

Computational linguistics or natural language processing (NLP) emerged during the last century to enable computers to understand and process natural language (i.e., text and speech) in a human-like manner. Since the early phase of NLP research, visual representation methods have been utilized to help people analyze and understand the various natural language phenomena. A tree representation is one commonly used representation to fulfil such purpose; it was widely used in NLP contents especially for representing the structure of a sentence using phrase structure grammar. Phrase structure grammar (PSG), introduced by Noam Chomsky (Chomsky 1956), leveraged constituency relations to represent the structure of a sentence (Chomsky 1956). According to Chomsky (1956), “a phrase-structure grammar is defined by a finite vocabulary (alphabet) Vp, a finite set Σ of initial strings in Vp, and a finite set F of rules of the form: X → Y, where X and Y are strings in Vp.” In a PSG rule, a complex sequence of features on the right hand side of the rule can be represented by a smaller number of symbols or even just one symbol on the left hand side of the rule. Using a tree representation, the structure of a sentence can be clearly shown by applying PSG rules at each level of the tree to map sentence elements at the current level to the sentence elements at a higher level. For example, Fig. 1 shows the structure of the sentence “Bathrooms, toilet rooms, kitchens, storage rooms and laundry rooms shall be permitted to have a ceiling height of not less than 7 feet.” The tree representation provides a rich set of visual cues by leveraging both the horizontal dimension and the vertical dimension of a page in a well-structured way. For example, Fig. 2 shows the parenthesis representation of the same sentence structure as that in Fig. 1, generated using Stanford Parser (Klein and Manning 2003). The tree representation is clearly more understandable than the parenthesis representation. Because of the similarity between parenthesis representation and Prolog syntax, the use of a tree-based visualization may also make the Prolog-based regulatory requirement more understandable.

Fig. 1

An example tree representation of the structure of a sentence

Fig. 2

An example parenthesis representation of the structure of a sentence

Methods

Semantic natural language processing-based automated compliance checking (SNACC) system

The author developed a Semantic Natural Language Processing-based Automated Compliance Checking (SNACC) prototype system that allowed the checking of quantitative requirements from building codes; that prototype system involves three main processing steps (Fig. 3): (1) a regulatory information extraction and transformation step that automatically extracts regulatory requirements from building codes and other types of construction regulatory documents and transforms the requirements into logic clauses (i.e., logic rules); (2) a design information extraction and transformation step that automatically extracts building design information from an industry foundation classes (IFC) model [i.e., the ISO standard for building information modeling (BIM)] and transforms the information into logic clauses (i.e., logic facts); and (3) an automated reasoning step that automatically checks the logic facts with the logic rules and generates compliance checking reports. Despite the commonality of these three steps in almost all ACC systems, the major advantages of the SNACC system are: (1) the extraction and transformation of regulatory information is fully automated, by virtue of the underpinning semantic modeling and natural language processing technologies; (2) the design information is automatically aligned with the regulatory information, by virtue of semantic transformation rules encoded in logic clauses; (3) the representation of regulatory information and design information based on logic programming languages were designed to reflect the original meaning of each concept and relation thus making the concepts and relations easier to read and understand by humans. All these advantages were achieved without affecting the computability of the regulatory requirement representations in supporting automated compliance checking. For a detailed description of each component of the SNACC system, the reader is referred to Zhang and El-Gohary (2016b). The next subsection introduces the logic-based representation and tree-based visualization method in detail.

Fig. 3

The Main Processing Steps in the SNACC System

Regulatory information representation and visualization method

The regulatory information representation and visualization method is built upon the classic logic programming language – Prolog: more specifically, the syntax of B-Prolog (i.e., an extended Prolog platform for programming concurrency, constraints, and interactive graphics) (Zhou 2014) is used.

B-prolog syntax

In the syntax of B-Prolog, the logical conjunction operator is represented using a comma and the logical disjunction operator is represented using a semicolon. This explicit representation of logical disjunction in addition to logical conjunction is important to ensure a clear and concise representation of the disjunctive relation between concepts, namely, the relation between multiple concepts that share the same property or requirement. For example, in the requirement from Chapter 12 of the International Building Code (IBC) 2006 (International Code Council 2006) shown in Listing 1, “bathrooms,” “toilet rooms,” “kitchens,” “storage rooms,” and “laundry rooms” share the same requirement of “have a ceiling height of not less than 7 feet.” Therefore, they have a disjunctive relation.

“Bathrooms, toilet rooms, kitchens, storage rooms and laundry rooms shall be permitted to have a ceiling height of not less than 7 feet (2134 mm).” (Provision 1208.2 of the IBC 2006)

Listing 1: Example regulatory requirement

The implication operator is represented using the combination of a colon and a dash (i.e., “:-”). The implication operator is used to connect the conditions and conclusion of a rule, where the conditions appear to the right of the operator and the conclusion appear to the left of the operator. The negation operator is simply the lower-cased word “not.” In the B-Prolog environment and in any Prolog environment in general, every logic statement is universally quantified by default; therefore, there are no operators for universal quantification or existential quantification. In addition to the logical operators, constant, variable, predicate, and function are the four major building blocks of logic clauses in B-Prolog. A constant is represented as an alphanumeric string with the first letter lowercased. A variable is represented as an alphanumeric string with the first letter uppercased. A predicate is represented as a function that has arguments in parenthesis, with each argument being a constant, a variable, or a predicate. There are three main types of logic clauses in B-Prolog: rules, facts, and directives. A rule is a logic clause using the implication relationship to connect conditions and a conclusion; multiple conditions may exist, but there can be only one conclusion in a B-Prolog rule. A fact is a rule without conditions. A directive is a rule without conclusion. The basic syntax pattern for these three types of logic clauses are shown in the bullets below.

• Rule: p0 :- p1,p2,p3…,pn.

• Fact: p0.

• Directive: :- p1,p2,p3…,pn.

Regulatory information representation method

In the proposed regulatory information representation method, regulatory requirements are represented using the rule type of logic clause in B-Prolog. Each regulatory requirement is represented using one B-Prolog rule. For example, the logic clause in Listing 2 is a B-Prolog rule representing the regulatory requirement in Listing 1. In each B-Prolog rule, the condition part represents the compliance conditions as defined in the corresponding regulatory requirement, and the conclusion part specifies the compliant result. In the condition part in the B-Prolog rule in Listing 2, the first five predicates are conjoined using the disjunction operator “;” to represent their disjunctive relation, meaning the requirement applies to all these concepts. Moreover, the same argument (i.e., the variable “Rooms”) is used for all the five predicates. This arrangement attempts to ensure the computability of the B-Prolog rule, as the variable “Rooms” will be instantiated by the instances of all bathrooms, toilet_rooms, kitchens, storage_rooms, and laundry_rooms in the actual execution of the rule in supporting compliance reasoning. A predicate can represent a concept or a relation. The starting five predicates in disjunctive relation in the conditions of the rule in Listing 2 [i.e., (bathrooms(Rooms);toilet_rooms(Rooms);kitchens(Rooms);storage_rooms(Rooms);laundry_rooms(Rooms))] represent concepts for bathroom, toilet, kitchen, storage, and laundry rooms, whereas the next predicate “has(Rooms,Ceiling_height)” represents a relation between those rooms and the ceiling height. In other words, the “Ceiling_height” variable will be instantiated by a ceiling height instance that belongs to one of those types of rooms. As shown in the last predicate in the rule in Listing 2, a predicate can embed other predicates to show more complicated relations: the predicate “greater_than_or_equal(Ceiling_height,quantity(7,feet))” represents the quantitative relation between ceiling height and the quantity 7 feet, where the predicate “quantity(7,feet))” is embedded as an argument. The conclusion of a rule appears to the left of the implication operator “:-“. The conclusion in the rule in Listing 2 is “compliant_ceiling_height(Rooms),” which indicates the ceiling height for a bathroom, toilet room, kitchen, storage room, or laundry room is in compliance with the requirement defined in this regulatory requirement.

compliant_ceiling_height(Rooms) :-(bathrooms(Rooms);toilet_rooms(Rooms);kitchens(Rooms);storage_rooms(Rooms);laundry_rooms(Rooms)),has(Rooms,Ceiling_height),ceiling_height(Ceiling_height),greater_than_or_equal(Ceiling_height,quantity(7,feet)).

Listing 2: Example B-Prolog rule representing a regulatory requirement

Regulatory information visualization method

To facilitate the understandability of the regulatory requirements represented in B-Prolog rules, a tree structure was adopted to develop a visualization method for the conditions of the rules. This tree-shaped visualization is expected to enhance the representation of information in a regulatory requirement from one dimension (i.e., horizontal) to two dimensions (i.e., horizontal and vertical), and therefore provide more visual cues to the reader. In the developed regulatory information visualization method, the root node is used to represent a “seed concept,” which is typically the subject of the requirement. For example, in the regulatory requirement in Listing 3, the subject “courts” is the seed concept. The tree-shaped visualization of a requirement unfolds from the seed concept through relationships that connect the seed concept with other concepts. Each relation or related concept in the relation is represented at a different level of the tree, except for the disjunctive relation between concepts. The concepts that have disjunctive relation are represented at the same level of the tree using the disjunction operator “;”. The tree grows in this way until all the concepts and relations in the requirement have been represented. For example, Fig. 4 shows the tree-shaped visualization of the regulatory requirement in Listing 3. The visualization starts from the root node “courts” and connects to the concept “width” through a possessing relationship represented by “has;” then the concept “width” is connected to the quantity “3 feet” through a quantity comparative relation “greater_than_or_equal.” The quantity “3 feet” is broken into its value “3” and the unit “feet” and is represented as two leaf nodes of the tree because neither is further connected to other concepts in the requirement. Note that leaf nodes are represented in green color whereas other types of nodes (i.e., root node and branch node) are represented in blue color. This color coding can help user quickly identify the quantitative requirements because the quantities usually reside in leaf nodes.

Fig. 4

The tree-shaped visualization of a simple requirement from the IBC 2006

“Courts shall not be less than 3 feet (914 mm) in width.” (Provision 1206.3 from Chapter 12 of the IBC 2006)

Listing 3: Example regulatory requirement

The tree-shaped visualization for the regulatory requirement in Listing 1 is shown in Fig. 5. For processing, the first concept in the subject “bathrooms” was selected as the seed concept. But this was only an arbitrary choice, because all the concepts in the subject are in disjunctive relation which means any of them can be selected as the seed concept with no difference in the final visualization. As shown in Fig. 5, the disjunctive relation between these concepts in the subject are represented using the semicolon. This usage provides consistency with the B-Prolog rule representation for which the visualization was created. The root node is then connected with the concept “ceiling_height” through a possessing relationship represented by “has;” then the concept “ceiling_height” is connected to the quantity “7 feet” through a quantity comparative relation “greater_than_or_equal.” The quantity “7 feet” is broken into its value “7” and unit “feet” and is represented as the leaf nodes of the tree.

Fig. 5

The tree-shaped visualization of a requirement from the IBC 2006 with disjunctive relation

The examples in Figs. 4 and 5 show trees with one branch because the requirements that the figures were representing had only one path of relationships from the subject to the quantitative requirement. If there are multiple paths from the subject to leaf nodes, the corresponding tree-shaped visualization will have multiple branches. The multiple paths could be used to represent different conditions or different requirements enforced on the subject. Fig. 6 shows the tree-shaped visualization of the regulatory requirement in Listing 4, where the subject of the regulatory requirement has multiple conditions and a quantitative requirement. In the subject of the regulatory requirement in Listing 4, the concepts have the disjunctive relation as represented by the disjunction operator “;”. Compared to the visualization of requirements in Figs. 4 and 5, the visualization of the requirement in Fig. 6 better demonstrates the power of leveraging the vertical dimension in the tree-shaped visualization. This structure inherent in the tree-shaped representation is expected to provide more visual cues as a way to help people understand the concepts and their relationships in a regulatory requirement.

Fig. 6

The tree-shaped visualization of a requirement from the IBC 2009 with disjunctive relation and multiple branches

“Structural plain concrete basement, foundation or other walls below the base are permitted in detached one- and two-family dwellings three stories or less in height constructed with stud-bearing walls.” (Provision 1908.1.8 of the IBC 2009)

Listing 4: Example regulatory requirment

Results and discussion

Experimental setup

To test the proposed tree-shaped visualization method in terms of the understandability of the regulatory requirements represented using it, a survey was sent to 300 people with various backgrounds (e.g., student, researcher, engineer, entrepreneur, administrator) randomly. A brief explanation of the B-Prolog syntax was included at the beginning of the survey. Four major pieces of information were collected about the survey participants: sex, age, highest degree earned, and knowledge on building codes. The survey asked participants to compare the text, logic, and visual representations of regulatory requirements in Listing 1 and Listing 4, in terms of understandability and reading speed. The text representation of the regulatory requirement in Listing 1 is the original text of the regulatory requirement coming from the IBC 2006. The logic representation of the regulatory requirement in Listing 1 is shown in Listing 2. The visual representation of the logic requirement in Listing 1 is shown in Fig. 5. The text representation of the regulatory requirement in Listing 4 is the original text of the regulatory requirement coming from the IBC 2009. The logic representation of the regulatory requirement in Listing 4 is shown in Listing 5. The visual representation of the regulatory requirement in Listing 4 is shown in Fig. 6.

compliant_story_height :- ((structural_plain_concrete_basement(Structural_plain_concrete_basement);foundation(Structural_plain_concrete_basement);other_walls(Structural_plain_concrete_basement)),below(Structural_plain_concrete_basement,Base),base(Base),detached_one_and_two_family_dwellings(Detached_one_and_two_family_dwellings),permitted_in(Structural_plain_concrete_basement,Detached_one_and_two_family_dwellings),height(Height),has(Detached_one_and_two_family_dwellings,Height),less_than_or_equal(Height,quantity(3,stories)),constructed_with(Detached_one_and_two_family_dwellings,Stud_bearing_walls),stud_bearing_walls(Stud_bearing_walls).

Listing 5: Example logic representation

Experimental results and analysis

Among the 300 people contacted, 93 participated in the survey (i.e., 31% response rate). The distribution of the survey respondents in terms of sex, age, highest degree earned, and knowledge on building codes are shown in Figs. 7, 8, 9 and 10.

Fig. 7

Sex distribution of the survey respondents

Fig. 8

Age distribution of the survey respondents

Fig. 9

Degree earned distribution of the survey respondents

Fig. 10

Knowledge on building codes distribution of the survey respondents

To help with the statistical analysis on understandability and reading speed results, a scoring method was used: for each vote of a representation over another representation, the winning representation gets a score of 1.5 and the losing representation gets a score of 0.5; for each tie between two representations, both representations get a score of 1. The experimental results are shown in Table 1. Equivalent percentages for each score and their confidence intervals (CIs) at 99, 95 and 90% confidence levels were calculated. Equivalent percentages were defined by dividing each score by 279 (i.e., the score of a representation if it wins over both other representations from all the 93 respondents). The Wilson score method without continuity correction (Wilson 1927) was used to calculate the CIs. Table 1 shows that for both the simple regulatory requirement in Listing 1 and the complex regulatory requirement (i.e., including more concepts and relationships and therefore having more than one branches in the tree-based representation) in Listing 4: (1) the text representation was significantly more understandable than the logic representation at all the three confidence levels; (2) the visual representation was significantly more understandable than the logic representation at all the three confidence levels; (3) while the text representation had higher scores than the visual representation in terms of understandability, the differences were not necessarily significant. For the simple regulatory requirement, the difference was significant at the 90 and 95% confidence levels but not significant at the 99% confidence level. For the complex regulatory requirement, the difference was not significant at any of the three confidence levels; (4) the text representation was significantly faster to read than the logic representation at all the three confidence levels; (5) the visual representation was significantly faster to read than the logic representation at all the three confidence levels; and (6) while the text representation had higher scores than the visual representation in terms of reading speed, the difference was only significant at the 90% confidence level, but not significant at either the 95% or the 99% confidence level.

Table 1 Total score for the three types of representations

To explore if the level of knowledge on building codes affects the above results. A similar analysis was conducted on the four parts of collected data with four levels of knowledge on building codes. The results are shown in Tables 2, 3, 4 and 5. As shown in Tables 2, 3, 4 and 5 the score ranking in terms of understandability and reading speed among the three representations is always in the following order: text representation > visual representation > logic representation, whereas the differences in the scores may or may not be statistically significant. Table 6 summarizes the status of all differences in terms of their statistical significance. It shows that: (1) the difference between text and logic representations is almost always significant with the exception of three small cases (out of 48 cases) on complex requirement when the respondents’ level of knowledge on building codes were low; this can be explained by the fact that low level of knowledge on building codes could have led to more difficulty in reading and understanding the text representation of complex building code requirements; (2) the difference between visual and logic representations is almost always not significant at the 99% confidence level but always significant at the 95% and 90% confidence levels, except for four small cases (out of 48 cases) on the understandability of simple requirement when the respondents’ level of knowledge on building codes were high, or on the reading speed of complex requirement when the respondents’ level of knowledge on building codes were relatively high; this can be explained by the fact that high level of knowledge on building codes may have led to a better capability in understanding the logic representation of simple building code requirements and a faster reading speed of the logic representation of complex building code requirements; (3) the difference between text and visual representations is almost never significant except for one small case (out of 48 cases) on the reading speed of simple requirement when the respondents’ level of knowledge on building codes were relatively high; this can be explained by the fact that high level of knowledge on building codes may have enabled faster reading of the text representation.

Table 2 Results for respondents that “never read any codes”

Table 3 Results for respondents that “read codes before but not building codes”

Table 4 Results for respondents that “read building codes before”

Table 5 Results for respondents that “studied building codes before”

Table 6 Significant status of the difference between representations

Conclusions

Automated code compliance checking is an important application of modeling and computing technology in the architectural, engineering, and construction industry. Many efforts have been made in academia, government, and industry to develop automated compliance checking methods and systems. In spite of the many efforts in automated compliance checking research and development, there is still a lack of a non-proprietary and user-understandable representation of building regulations to support automated compliance checking. Little has been done toward testing or improving the user-understandability of regulatory requirements in the building and construction domain to support automated compliance checking. To address this research gap, this paper demonstrates a logic-based representation and tree-based visualization method for regulatory requirement. The method leveraged B-Prolog rules to represent regulatory requirements where the conditions of the B-Prolog rule represent the premises of the regulatory requirement, and the conclusion of the B-Prolog rule represents the compliance status with the regulatory requirement. Each concept or relation in a regulatory requirement is represented as a predicate in the B-Prolog rule, with the original names of the concepts and relationships used as the names and arguments of the predicates. This consistency in naming helps users understand the meanings of the concepts and relations simply by looking at the logic rule representation. In the tree-shaped visualization method, a tree structure is used to illustrate the concepts and relations. The tree representation used visual cues both in the horizontal dimension and the vertical dimension to provide a better visualization of the regulatory requirements compared to the pure logic-based representation.

To test the understandability and reading speed of the proposed visualization method and how it compares to the original text representation and the logic representation, a survey was conducted during which 300 people with various backgrounds were contacted and 93 of them participated. The survey collected background information of the respondents’ sex, age, education, and knowledge level on building codes, and tested the respondents’ understanding and reading speed of the different representations of two regulatory requirements. Between the two regulatory requirements one is relatively simple and the other is relatively complex. The testing results were statistically analyzed. Results showed that: (1) the visual representation of regulatory requirements using the tree-based visualization method was significantly better than the logic-based representation in terms of understandability and reading speed for both simple and complex regulatory requirements; (2) the original text representation of regulatory requirements was slightly better than the visual representation in understandability when the requirement was simple (i.e., significant at the 90% and 95% confidence levels but not significant at the 99% confidence level). the text representation was slightly better than the visual representation in understandability when the requirement was complex, and the text representation was slightly better than the visual representation in reading speed both for simple and complex requirements (i.e., only significant at the 90% confidence level, or at the 95% confidence level for simple regulatory requirement). But none of these differences were significant unless otherwise specified; (3) the original text representation of regulatory requirements was significantly better than the logic-based representation in terms of understandability; (4) the original text representation of regulatory requirements was significantly better than the logic-based representation in reading speed. This result shows that the proposed tree-based visualization method can significantly improve the understandability and reading speed of the logic-based regulatory requirement representation, and it is at a comparable status with the original text representation of regulatory requirements in terms of understandability and reading speed. Further analysis into the different levels of knowledge on building codes showed that high level of knowledge on building codes may help with the understanding (of simple regulatory requirement) and reading speed (of complex regulatory requirement) of the logic representation, but the difference between visual and logic representation is significant in most cases.

Contributions to the body of knowledge

This research contributes to the body of knowledge in three main ways: (1) before this research, little has been done for testing or improving the user-understandability of regulatory requirements in the building and construction domain to support automated compliance checking, as far as the author is aware. This research is among the first to experimentally compare the understandability and reading speed between different representations of building regulations in a quantitative manner; (2) there is a lack of a non-proprietary and user-understandable representation of building regulations to support automated compliance checking in the construction domain; the proposed logic-based representation and tree-based visualization method serves as one possible non-proprietary and user-understandable representation of building regulatory requirements; (3) this research shows that when given an effective visualization method, the computable representations of regulatory requirements can achieve understandability and reading speed that are comparable to the original text representation (i.e., with no significant difference); and (4) this research reveals that the tree-based representation of regulatory requirements improve the understandability and reading speed of regulatory requirements as compared to the computable logic-based representation.

Limitations and future work

Two main limitations of the current work are acknowledged. First, the work presented in this paper only serves as an initial investigation on the potential effects of visualization on computable regulatory representations in terms of understandability and reading speed, and this investigation focused on a specific type of computable regulatory information representation (i.e., Prolog-based representation) and a specific type of visualization technique (i.e., tree-based visualization). How the tree-based visualization performs for other types of computable regulatory information representations and how other types of visualization technics compare with the tree-based visualization can be conducted by follow-up research efforts. Second, there are regulatory requirements that are much more complex than the ones used in the experiment in this research; how the different types of representations perform on these significantly complex requirements still need to be investigated. In future work, the author plans to scale up the experiment to include other types of computable regulatory information representations and other types of visualization methods as well as incorporating the investigation of scalability of those methods to the much more complex regulatory requirements.