Regulatory compliance check in the building industry is a complex task that involves cross-domain national and international standards and regulations. This paper introduces a refined approach to extract SWRL rules from building accessibility regulatory texts and then to transform them into executable rules for semi-automatic compliance checking of Building Information Models. The domain ontology model is a key input to the approach and is enriched by new knowledge extracted from the regulatory text. This semantic technology enhanced rule extraction approach standardized the rule extraction process by covering the whole lifecycle from regulatory text to executable rules. It is based on the open standards and applies open source tools and thereby portable and extendable. It conforms to the open BIM principle to support knowledge sharing cross domains and disciplines. The approach is also adaptable to other types of regulatory rules in the building industry.
In today’s digital society Natural Language (NL) standards and regulations are still
widely used by the governments, companies and organizations. The building industry
needs to comply with cross-domain international and national standards and
regulations, which makes the regulatory compliance check a very complex task [
Natural language processing and automatic rule extraction from natural language
text have a long history. A process of generating automatically grammar rules from
ontologies for information extraction systems is described in [
This paper presents a refined approach based on existing rule extraction techniques and applies it to a real-world case in the building accessibility domain and at the same time tests the maturity and practicality of the rule extraction techniques. The rule extraction process in the building industry requires domain specific knowledge and has often been a closed non-standardized process. The refined approach enhanced by semantic technology helps to standardize and automate the rule extraction in a transparent process, and it simplifies rule comparison and cross-platform rule sharing.
The paper is organized as follows. Section 2 describes the case of building accessibility regulatory rules and introduces a rule extraction approach for this domain, Section 3 presents the implementation of the approach and Section 4 provides a summary and outlines potential further works.
Regulations of building accessibility cover various aspects of building accessibility. Statsbygg1 of Norway and Skanska of Finland2 have contributed to the development of rulesets in Solibri3 for checking accessibility according to ISO 21542:2011 Building construction - Accessibility and usability of the built environment4. The rulesets 1 http://www.statsbygg.no/System/Topp-menyvalg/English/ 2 http://www.skanska.fi/ 3 http://www.solibri.com/ 4 http://www.iso.org/iso/catalogue_detail?csnumber=50498 can be executed to check building information models’ compliance to the ISO standard on the fly. It simplifies the compliance check process which traditionally is a manual process. However, the rulesets covers only part of the ISO 21542:2011 regulatory text and need to be extended. The engineering process of converting the ISO standard to executable rulesets is not open and transparent for the public. It is therefore costly and difficult to customize, extend, share and build new rulesets using the Solibri tool.
Except for the ISO standard, the building industry needs to comply with other regulations or standards of building accessibility. For example, the Norwegian national building regulations TEK105 specify the outdoor accessibility requirements in Chapter 8 and indoor accessibility rules in Chapter 12. Some companies such as Statsbygg have their own internal text-based rules in addition to the international and national standards and regulations. We need to develop an open approach to extract rules from different regulatory text in a standardized and streamlined way. In addition, comparing rules from different standards or regulations is also a challenging task and may also benefit from the standardization of the rule extraction process. 2.2
This paper suggested a refined approach based on semantic technology for rule extraction from regulatory text in the building industry as illustrated in Fig. 1. Semantic annotation is the first step in this knowledge engineering process. Regulation text on building accessibility and a basic domain-specific ontology model are inputs, while the annotated text and an enriched ontology model are outputs from this step. It helps to bridge the ambiguity of the natural language when expressing notions and their computational representation in a formal language6.
The second step is extraction of normalized rules based on the analysis of the annotated text and the enriched ontology model. RuleML, SWRL, R2ML (Reverse Rule Markup Language) and F-logic (Frame Logic) are rule languages with different expressiveness and decidability. SWRL is chosen as the rule language because it covers the current needs in the case study. In addition, SWRL is tightly connected to the OWL ontology model. SWRL directly enriches the OWL ontology model which is 5 http://www.lovdata.no/cgi-wift/ldles?doc=/sf/sf/sf-20100326-0489.html 6 http://www.ontotext.com/kim/semantic-annotation the key input to the last step. Other normalized rule languages can be evaluated in the future depending on the needs of expressiveness, decidability and portability.
The third step is transforming normalized rules to executable rules such as MVDs7
and XSLTs for regulatory compliance checking in BIM. There have been several
initiatives to implement the checking rules, such as the Solibri rulesets and a Java
based model check plugin8, and open standards like MVDs, SEMs9 and XSLTs. In [
The TEK10 regulation text contains the accessibility requirements of stairs and their components so as the text from Chapter 13.2 of ISO 21542:2011. Both example texts are provided in the Appendix of this paper. The extracted SWRL rules from the two examples are afterwards compared and analyzed. At the end, examples of transforming SWRL rules to executable rules are presented. 3.1
This step implements and compares non-semantic and semantic annotation in Gate Developer10. Annotation using the standard ANNIE11 tool on the TEK10 regulation text of stairs returns the non-semantic annotation result as shown in Fig. 2. The unclassified proper name is annotated as unknown and the other standard annotation sets do not provide much information either. The semantic annotation however classifies more domain related information in the text. An OWL ontology stairs model based on an existing UML example12 and wiki-vocabulary definition13 is created in this case study as input to Step 1. Gate can be used to annotate ontology classes, properties and individual instances. Classes are typically used in the regulation text instead of individual instances. The result of the semantic annotation using GATE plugin OAT is shown in the Fig. 3. 7 http://www.buildingsmart.org/standards/mvd 8 http://bimserver.org/2014/04/28/release-1-3-0-final/ 9 http://www.dbl.gatech.edu/sem 10 http://gate.ac.uk/family/developer.html 11 http://gate.ac.uk/sale/tao/splitch6.html 12 http://www.redaktion.tu
berlin.de/fileadmin/fg227/Publications/schmittwilken_et_al_2007_semantic.pdf 13 http://en.wikipedia.org/wiki/Stairs In the above result some of the names, such as stairwells, are still not classified. Some of the data properties, such as clearance width and height of flights and whether flights are internal or straight do not exist in the ontology model. It indicates the need to extend the ontology model. The extended ontology model adds, e.g., Stairwell as a new class and adds the clearance width and height as data property to the class Flight. The enriched ontology model provides a refined annotation result in Gate.
Though Gate supports annotation of relationships such as object properties, it does not support data properties annotation which is a necessary building block in specifying the building accessibility rules related to the constructional properties such as maximum or minimum depth, width, length. The final output of Step 1 is an enriched ontology model and the annotated text, though not complete because of the limitation of the used tools. Other semantic annotation tools such as Ontotext KIM14 shall be evaluated in further work. 3.2
The annotation results and the enriched ontology model provide the foundation for
extracting normalized rules in Step 2. To assist the SWRL rules generation a new data
property named meetRequirement is added to the ontology and made accessible for
all the domain classes. SWRL rules have been manually created based on the
semantic annotation result. The SWRL generation process can be automated in the future by
implementing the rule extraction frameworks such as [
Below are SWRL rules extracted from the example text. TEK10_Stairs_§12_16_c rule shows that if the flight is straight, the minimum depth on threads is 0.25m, otherwise the requirement of Flight is not met.
TEK10_Stairs_§12_16_c Flight(?f) ∧ isStraight (?f,true) ∧ hasStep (?f,?s) ∧ hasTread(?s,?t) ∧ depth(?t, ?td) ∧ sqwrl:least(?td, 0.25) → meetRequirement (?f, true) TEK10_Stairs_§12_16_f1 rule describes that if a flight is internal, the minimum clearance width of a flight is 0.8m, and the minimum clearance height is 2m, otherwise the requirement of Flight is not met.
TEK10_Stairs_§12_16_f1 Flight(?f) ∧ isInternal(?f, true) ∧ clearancewidth(?f, ?fw) ∧ sqwrl:least(?fw, 0.8) ∧ clearanceheight(?f, ?fh) ∧ sqwrl:least(?fh, 2) → meetRequirement (?f, true) TEK10_Stairs_§12_16_f2 rule describes that if a flight is not internal, the minimum clearance width of a flight is 0.9m, and the minimum clearance height is 2.1m, otherwise the requirement of Flight is not met.
TEK10_Stairs_§12_16_f2 Flight(?f) ∧ isInternal(?f, false) ∧ clearancewidth(?f, ?fw) ∧ sqwrl:least(?fw, 0.9) ∧ clearanceheight(?f, ?fh) ∧ sqwrl:least(?fh, 2.1) → meetRequirement (?f, true) 3.3
Comparing the similar rules from different regulations or standards text against text is a difficult task and one of the challenges is lack of common terminology and ontology. Synonym identification is necessary to achieve the common understanding of terms. For example, in TEK10 the term “clearance width of flight” is used, and in ISO 21542:2011 both the terms “width of flight” and “width between handrails” are used. The domain knowledge is needed to identify that the “width between handrails” is a 14 http://www.ontotext.com/kim synonym to “clearance width of flight”. SWRL rules simplify the comparison by presenting the rules in a normalized format based on a common ontology model. Below is an example of SWRL rule extracted from the ISO 21542:2011 text that describes the requirements of minimum flight width.
ISO 21542_Stairs_§13_2a Flight(?f) ∧ width(?f, ?fw) ∧ sqwrl:least(?fw, 1.2) ∧ clearancewidth(?f, ?fcw) ∧ sqwrl:least(?fcw, 1) → meetRequirement (?f, true)
TEK10_Stairs_§12_16_f1 and TEK10_Stairs_§12_16_f2 from Section 3.2 also describe the requirements of minimum flight width. The comparison result shows that ISO 21542:2011 has a stricter requirement on flight clearance width than TEK10. 3.4
This step aims to generate executable rules based on normalized rules and apply them
on BIM models. Before the transformation we first make an ontology mapping
between the enriched ontology from Step 2 and the BIM schemas. The IFC Stair and
Flight concepts and attributes are described in MVC-56515 and IFC property set
definition reference16,17. The ontology class Stair is mapped to IfcStair and class Flight is
mapped to IfcStairFlight. The relationships between ontology classes such as the
aggregation relationship between Stair and Flight are also mapped to the corresponding
IfcRelAggregates relation in the BIM schema. Some properties in the ontology model
cannot find a direct matching property in BIM schema, e.g., a stair in BIM is not
marked as straight or not, but it can be calculated from the WalkingLine
GeometricSet. Below is an example result of transforming TEK10_Stairs_§12_16_c to XSLT
rules. The XSLT rules can be executed on a BIM model to check if the rule
TEK10_Stairs_§12_16_c is met.
<xsl:when test="($IfcElement='IfcStair')
and
(IfcProductDefinitionShape\IfcShapeRepresentation\IfcRepresentation.Items[
<xsl:text>TEK10_Stairs_§12_16_c VIOLATED</xsl:text> </xsl:when> </xsl:for-each> </xsl:when> 15 http://www.blis-project.org/IAI-MVD/Concepts/MVC-565.pdf 16 http://www.buildingsmart
tech.org/ifc/IFC2x4/alpha/html/psd/IfcSharedBldgElements/Pset_StairCommon.xml 17 http://www.buildingsmart
tech.org/ifc/IFC2x4/alpha/html/psd/IfcSharedBldgElements/Pset_StairFlightCommon.xml
We have presented a refined approach for extracting normalized rules from building accessibility regulatory text and transforming the rules to assist semi-automatic compliance checking in the building industry. The domain ontology model is a key input to all the steps and the quality of the domain ontology model are one of the main factors that influence the results of rule extraction. The basic domain ontology model can be created based on industrial standards and common knowledge and it is enriched in the rule extraction process. The ontology model is first extended in Step 1 by adding domain knowledge from regulatory text in the form of new classes, properties and relations; it is then enriched in Step 2 by adding SWRL rules extracted from the regulatory text. In Step 3, SWRL rules are transformed to executable BIM rules in XSLTs based on the mapping between the ontology model and the BIM schema. The approach covers the whole rule extraction lifecycle from regulatory text to executable rules instead of only from regulatory text to normalized rules, or only from normalized rules to executable rules. It is based on open standards and applies open source tools and thereby portable and extendable. The results from the approach, such as the enriched domain ontology model, the generated normalized rules and executable rules are also portable and extendable. This conforms to the open BIM principle to support rules and knowledge sharing cross domains and disciplines. The approach also simplifies comparison of rules from different sources as described in Section 3.3.
Currently the rule extraction process in Step 2 and the mapping is mostly manual
and could be automated by implementing existing frameworks such as [
Acknowledgements. The work in this paper is partly supported by the EC funded project proDataMarket (Grant number: 644497).
Stairs shall be easy and safe to navigate. The width and height of stairs shall be designed for the expected traffic and transport, including escaping in case of fire. The following shall, as a minimum, be complied with: Flights of stairs shall have safe edges and handrails on both sides. Flights of stairs shall have a regular incline and the risers shall be the same height for the entire length of the flight of stairs. Treads in straight flights of stairs shall be the same depth. Treads in the walking line shall be a minimum of 0.25 m. Landings shall be large enough to halt falls. Height differences of more than 3.3 m require a landing. Stairwells shall be well lit so that the steps are visible. Treads shall have a non-slip surface. Flights of stairs shall have a minimum clearance width of 0.9 m and minimum clearance height of 2.1 m. Internal flights of stairs in a dwelling unit shall have a minimum clearance width of 0.8 m and a minimum clearance height of 2.0 m. Treads in flights of stairs that are not straight shall have an effective width equivalent to straight flights of stairs. Along the inside walking line the treads of curved flights of stairs shall be a minimum of 0.15 m.
ISO21542
The minimum width of a flight of stairs shall be 1 200 mm. The minimum width between handrails shall be 1 000 mm. Exceptional considerations for existing buildings in developing countries. In some member states, the minimum width of a flight of