In recent years increased attention in the built environment research community has been given to the implementation of automatic compliance checking systems. Specifying, managing and subsequently executing these regulations is a challenging task, with a wide variety of experts involved. These experts range from experts in the regulations themselves, to specialists in BIM data formats and software engineers, all of whom are required to manage the automatic execute of a single regulation set. This paper demonstrates how an ontology can be used to encode construction regulations, acting as the single source for both human and machine readable regulations. The structure of the ontology will be described, along with how regulations can be encoded, and subsequently executed. This will be demonstrated on case studies using a proof-of-concept user interface that has been developed to abstract the generation of the ontological encoding.
While the use of ICT to automate compliance checking has become common [
The adoption of semantic approaches to storage of built environment data [
In the remainder of this paper, Section 2 will describe relevant related work, Section 3 will describe our approach to semantically encoding construction regulations, Section 4 will demonstrate this approach through two case studies and, finally, Section 5 will conclude the paper. 2
There have been several examples of automated compliance checking in the
construction sector. One of the earliest successful examples was targeted at Singapore's Building
Regulations [
Figure 1 shows the overall architecture of our approach to managing construction regulations using semantics. The process of automating a construction regulation consists of several phases; (a) encoding the regulations – populating the regulation ontology with data representing the encoding of the construction regulation being considered (based on the semantics within the regulation structure ontology), (b) alignment – populating the data mappings ontology, this is deliberately separate from the regulation ontology to promote re-use between different regulations as applicable, (c) execution of regulations, (d) modification of regulations/mappings, (e) generation of human readable documentation.
Based on these phases three distinct user interfaces have been developed to enable the complexities of semantic modelling to be abstracted; (a) rule specification, (b) data mapping and (c) rule execution. Each of these will be described in more detail in the following subsection, along with how encoded regulations can be utilized to generate human readable documents will also be described. Encoding construction regulations involves transforming human readable regulations into a semantic model, based on the semantics defined in the regulation structure ontology. The process of encoding requires regulations authors to use user interface shown in Figure 2, this process is described below:
regulations into a series of hierarchical paragraphs – normally in line with the original document structure. As part of this process authors must define whether each paragraph should produce a true/false result (i.e. if the individual regulations within it are met). If a paragraph does have a true/false result, it should be defined how a set of sub-paragraphs contribute to the result of its parent paragraph (i.e. or/and).
been created each individual regulation is tagged using RASE [
Additionally, when adding RASE tags the user-interface will prompt the author to specify metadata; (a) object i.e Fire Door, External Door, (b) property i.e. type, width, height, (c) comparison i.e. =, > , <, (d) value to be compared against and (e) unit i.e m, cm, litres. This metadata will be used to automatically build an ontology, that models explicitly the semantics utilized within the regulation being considered. This phase deliberately does not follow any existing building ontology, but rather lets the regulation author specify the semantics explicitly through the interface. This is because we have found that many regulations utilize subtly different semantics and, thus, the only way to be sure of getting these semantics correct is to make the regulation author specify them.
The result of this process will be an ontology fully populated with data regarding the regulation being considered. This ontology will utilize the semantics defined in the regulation structure ontology, (extracts of the semantics of which are shown in Figure 3, please note that for brevity data properties and inverse relationships are not shown). Secondly, this process will result in a fully populated ontology encoding the regulations along with the ontology explicitly defining the semantics of the regulation.
It should be noted that the user interface is equally suited for the encoding of a new regulation (one that has not previously been automated) and for modifying a previous encoded regulation. This enables the scalable introduction of additional regulations as standards and legislation changes. Additionally, this encoding process could easily be extended to support language localization, where each paragraph shares the same RASE encoding, but has versions of its text available in multiple languages. This allows the support for regulations from other countries and multi-national regulations. The process of aligning the semantics of a regulation to a BIM data format is performed by mapping how data from the BIM data format can be translated into an ontology based on the semantic of the given regulation. This is done using a user interface that guides the user in mapping each object and property defined in the encoded regulation ontology to the BIM data format. This process firstly consists of performing class level mappings that specify a one to one relationship between a class in the regulation ontology and a class in the data format ontology. In many cases the class in the data format ontology will be less specific than is required (i.e. IfcDoor as opposed to a specific type of door). To overcome this, the interface possesses functionality to allow this relationship to be restricted with filters, limitation the relationship to only certain instances of this class in the data format domain. The second stage is the specification of property level mappings. This process maps properties from the regulation ontology onto properties in the data format ontology. In this case, the user interface has been designed with convenience functionality for the use of ifcOWL (i.e. abstracting the complexity of property and quantity sets) but the use of any target data format is possible.
These mapping are subsequently stored in the data mappings ontology, the semantics
of which are illustrated in Figure 4. These semantics, based on [
Once the ontologies have been populated, the regulations are able to be executed. Firstly, a set of simple SWRL rules are generated automatically from the regulation ontology. Then, the SPARQL queries modeled in the alignment ontology are executed to load data from the BIM into an ontology that represents this data in the semantics of the regulation being executed. This is done in a just in time fashion, so that a query is only invoked when a rule needing specific data is executed. An example of rule execution is shown in Figure 5. This rule execution follows a bottom up approach taking each encoded regulation paragraph in turn. For each paragraph, the Application, Exception and Selection encoding is firstly evaluated, to determine if the paragraph is in scope (i.e. if a paragraph only applies to a hospital, do not apply this paragraph to an office building). For all paragraphs that are in scope, the requirement encoding is then evaluated, determining if the paragraph has passed or failed. The results of these paragraphs are subsequently utilized to determine results for the rest of the regulation hierarchy.
In addition to rule execution, human readable regulation documents can also be
generated, by outputting latex that can then be compiled into a PDF. An example of this is
shown in Figure 6.
Our approach has so far been tested on two exemplar regulations, the UK Building
Regulations Part L [
Finally, the generation of human readable documents was also tested and reviewed by the students who encoded the regulations, an example of a human readable document for secured by design was shown in Figure 6.
In conclusion, while each of these were successfully executed, it was found that the characteristics of these two regulations were slightly different, thus presenting different challenges. The secured by design regulation contains many more prescriptive regulations (i.e. widths of doors), meaning that more of the data required was present in the BIM model. However, Part L has many less prescriptive regulations. These regulations often do not have the required data present within BIM models. This means, that for Part L, there was a far greater need to specify functions to calculate needed results, or to ask for user input. 5
This paper has presented how an ontology can be used to encode construction regulations, acting as the single source for both human and machine readable regulations, and, based on this, how a management system for regulatory compliance can be created around this ontology. This has been demonstrated through two case studies that, while in the early stages and utilizing student users, have shown that users with no expertise in rule languages, programming or semantics are able to, specify and manage regulations. Additionally, this trial has shown that this ontology can also be used as a basis for executing regulations, and generating human readable documents.
This approach has the potential to overcome the key issue of the scalability of automating regulations, which is caused by the required close co-operation between domain experts with building regulation expertise, software developers and those experienced in BIM data storage. Thus, it is our view that, in the future, having a single source from which both human readable, and computer executable code can be generated is the best way to create and, perhaps more importantly, maintain automated regulations checking in the construction sector.