M Fahad

N Bus

B Fies

Semantic BIM Reasoner for the verification of IFC Models

Recent years have witnessed the development of various techniques and tools for the building code-compliance of IFC models. Indeed these are great efforts, but, still there is a gap for the fully automatic building code-compliance. This paper presents our research and development of Semantic BIM Reasoner (SBIM-Reasoner) which employs semantic technologies to meet the requirements of semantic verification of an IFC model. SBIM-Reasoner employs several preprocessors (IFC to RDF converter, Geometry Extractor) to build the semantic repository from the input IFC model. Once all the triples are generated from the initial data (.ifc file), Stardog is used to build a knowledge graph for the semantic verification. All types of inference and reasoning mechanisms for the semantic verification are applied over this knowledge graph to meet the requirements of verification. Knowledge graph over triplets enables freedom of extending RDF based Semantic IFC model, creation of newer vocabulary and formation of newer rules, concatenation of triplets to build rules with condition and constraints over IFC data, dynamic reasoning over the triplets based on the initial data of IFC model, etc. Finally, we tested our prototype by using several online IFC models. We conclude that semantic technologies provide more rich mechanisms and answer vast types of queries for the verification of IFC models. It provides powerful features based on SPARQL libraries and serves best for the automated code compliance and verification of IFC models.

INTRODUCTION

Building Information Modeling 1 (BIM) is to understand a building through the usage of a digital model which draws on a range of data assembled collaboratively before, during and after construction [START_REF] Rebekka | Building Information Modeling (BIM) for existing buildings-Literature review and future needs[END_REF]. BIM with its interoperability properties is intended to facilitate exchanges and handovers between different stakeholders. Whereas the visualization and geometric representation are intrinsic to the digital building model, the fields of quality requirements, evaluation and regulatory contextualization (destination, named areas, threshold values, certified data, evidence of compliance, etc.) need higher level of maturity [START_REF] Eastman | BIM Handbook: A Guide to Building Information Modeling for Owners, Managers, Designers, Engineers, and Contractors[END_REF]. Industry Foundation Classes (IFC), based on a neutral format, is a complete and fully stable open and international standard for exchanging BIM data [START_REF] Thein | Industry Foundation Classes (IFC), BIM Interoperability Through a Vendor-Independent File Format[END_REF]. Code Compliance checking of BIM is necessary in order to provide stake-holders a high quality IFC model 1 Open BIM, http://www.buildingsmart.org/openbim/ that ensures accurate, consistent and reliable results in the entire life-cycle of BIM. Verification of IFC models for the code compliance checking is one of the hot challenges of the present decade. Different approaches and tools are already contributed for the automated code compliance checking [START_REF] Ismail | A Review on BIM-based automated code compliance checking system[END_REF]. Our enterprise, CSTB, through its research aims at automating French Building Code Compliance as much as possible, or at least improves the control of regulations from a digital model design phase. Its goal is to provide automatic requirements verification to warn the non-conformities with the associated 3D visualization, or to provide access to the technical documentation for a given digital model based on its sophisticated contextual information. This paper presents our several contributions towards this research. First, we analyze literature review regarding verification of IFC models and conclude that there are vast research works in this field, but still there are many open challenges to address. Therefore, we present a need of an approach that can easily be extended, configured and deployed for the dynamic and changing environment having broad spectrum of functionalities for the verification of IFC models. The main contribution of this paper is about the development of Semantic BIM Reasoner (SBIM-Reasoner) which employs semantic technologies to meet the requirements of semantic verification of an IFC model. SBIM-Reasoner employs several preprocessors (elaborated in next sections) to build the semantic repository based on RDF [START_REF] Brickley | RDF vocabulary description language 1.0: RDF Schema[END_REF] from the input IFC model. Once all the triples are generated from the initial data (.ifc file), it uses Stardog 2 to build a knowledge graph for the semantic verification. All types of inference and reasoning mechanisms for the semantic verification are applied over this knowledge graph to meet the requirements of verification, and in addition to discover additional information that is not explicitly stated in the initial data of the IFC model. Our semantic preprocessor uses both forward chaining and backward chaining mechanisms (where appropriate) to build the semantic repository. SPARQL 3 rules (statements and materialization) are applied to enrich the underlying semantic repository with several newer and high level concepts as per demand of regulation texts and verification rules by the endusers. Finally, SPARQL queries are performed over the semantic repository for the verification and code compliance of an IFC model. Once, SBIM-Reasoner finds non-compliant objects in the IFC model, it presents them to the end-user. Later in this paper, we also present our analytical results on several online IFC models 4 and also on four IFC models developed at our enterprise. We discuss our experimental finding on different analysis parameters such as number of triplets in the RDF (turtle file) equivalent to IFC model, number of triplets in the semantic model (filtered turtle file) in the Stardog, estimated time taken by the conversion and geometric preprocessor, etc. On the basis of analysis from these parameters, we show encouraging results by several tests on the knowledge graph from the initial version of SBIM-Reasoner. The rest of paper is organized as follows. Section 2 discusses related work. Section 3 presents our 2 Stardog triplestore: https://www.stardog.com/ 3 SPARQL http://www.w3.org/TR/rdf-SPARQL-query/ SBIM-Reasoner, its architecture, subcomponents, and as a semantic service to end-users. This section also presents our statistical analysis of our implemented prototype, empirical results based on various IFC models and highlights various important points. Section 4 concludes the paper and presents future directions

RELATED WORK

Over the last few years, many methods and techniques have been proposed for the verification of IFC models. There are three ways for the conformance checking of IFC models as discussed by Pauwels and Zhang [START_REF] Pauwels | Semantic Rule-Checking for regulation compliance checking: An overview of strategies and approaches[END_REF]. The subsections elaborate each of them.

Hard Coded Rule Checking

First, we have the hard coded rule checking mechanism for the verification of IFC models, which is similar to the approach adopted by Solibri Model Checker [START_REF] Khemlani | Solibri model checker[END_REF]. This tool loads a BIM model, considers rules stored natively in the application and performs rule checking against the BIM for the architectural design validations. This approach is fast as rules are integrated inside the application, but there is no flexibility or customization possible as rules are not available outside the actual application. The traditional approach of compliance checking is with the IfcDoc tool [START_REF]IfcDoc Tool[END_REF] developed by buildingSMART International for generating MvdXML rules through a graphical interface. It is based on the MvdXML specification [START_REF] Chipman | mvdXML specification of a standardized format to define and exchange MVD with exchange requirements and validation Rules[END_REF] to improve the consistent and computerinterpretable definition of Model View Definitions as true subsets of the IFC Specification with enhanced definition of concepts. This tool is widely used as AEC specific platform in the construction industry. MvdXML Checker [START_REF] Mvdxmlchecker | [END_REF] is a great contribution for the automatic verification of IFC models and to detect the non-conformities with the associated 3D visualization, or to provide access to the technical documentation for a given digital model based on its sophisticated contextual information. At our enterprise, we proposed several extensions and implemented those into a new research prototype. But after these extensions, still we analyze that this traditional approach of verification by the use of MvdXML is very limited and has narrow scope for the verification of IFC models. There are many drawbacks of MVDXML for extracting building views such as: lack of logical formalisms, solely consideration of IFC schema and MVD-based view constructors are not very flexible and dynamic [START_REF] Mendes De Farias | A Semantic Web Approach for defining Building Views[END_REF]. In addition, major limitations exists such as restricted scope of applying conditions and constraints on several branches of an IFC model, poor geometric analysis of an IFC model, lack of mathematical calculations, support of only static verification of a model, etc. On the other hand, when we practice semantic technologies such as SPARQL, we think their suitability due to wide range of functions, intermediate calculations, and support of dynamic creation of verification rules at ease.

Query based Rule Checking

The second approach is 'query based rule checking' of an IFC model. In this approach, BIM is interrogated by rules, which are formalized directly into SPARQL queries. As an example, Bouzidi et al. [START_REF] Bouzidi | Semantic Web Approach to Ease Regulation Compliance Checking in Construction Industry[END_REF] proposed this approach to ease regulation compliance checking in the construction industry. They reformulated the regulatory requirements written in the natural language via SBVR, and then, SPARQL queries perform the conformance checking of IFC models.

Semantic Rule Checking Approach

The third is a semantic rule checking approach with dedicated rule languages such as SWRL [START_REF] Horrocks | SWRL: A Semantic Web Rule Language Combining OWL and RuleML[END_REF], Jess [START_REF] Friedman-Hill | Jess in Action: Rule Based Systems in Java[END_REF] or N3Logic [START_REF] Berners-Lee | N3Logic: A logical framework for the World Wide Web[END_REF]. There are few projects in AEC industries that use this approach for the formal rule-checking, job hazard analysis and regulation compliance checking. Wicaksono et al. [START_REF] Wicaksono | Ontology development towards expressive and reasoning-enabled building information model for an intelligent energy management system[END_REF] built an intelligent energy management system for the building domain by using RDF representation of a construction model. Then, they formulated SWRL rules to infer anomalies over the ontological model. Later, they also developed SPARQL interface to query the results of rules. Pauwels et al. built acoustic regulation compliance checking for BIM models based on N3Logic rules [START_REF] Pauwels | A semantic rule checking environment for building performance checking[END_REF]. They use N3logic rules with an ontology to reason whether a construction model is compliant or not with the European acoustic regulations. Another project that was built on the ontological framework for the rule-based inspection of eeBIM-systems was developed by Kadolsky et al. [START_REF] Kadolsky | An ontology framework for rule-based inspection of eeBIM-systems[END_REF]. They used rules to query an IFCOWL ontology that captured a building. Besides these projects that build an ontology for the IFC, recent years revealed some contributions based on Semantic Web Technologies. SWOP-PMO project is one of recent contributions that uses formal methodology based on the Semantic Web standards and technologies [START_REF] Josefiak | Semantic product modelling with SWOP's PMO, eWork and eBusiness in AEC[END_REF]. It uses OWL/RDF to represent the knowledge, and SPARQL queries and Rule Interchange Format (RIF) to represent the rules. The RDF/OWL representation is not derived from the written knowledge but has to be remodeled in accordance with the rules of OWL/RDF. There are some other works for the semantic enrichment of ontologies in the construction and building domain. Emani et al. proposed a framework for generating an OWL Description Logic (DL) expression of a given concept from its natural language definition automatically [START_REF] Emani | Automated Semantic Enrichment of Ontologies in the Construction Domain[END_REF]. Their framework also takes into account an IFC ontology and the resultant DL expression is built by using the existing IFC entities. Fahad et al. have contributed a framework for mapping certification rules over BIM to enable the compliance checking of the repository through the digital building model [START_REF] Fahad | Towards Mapping Certification Rules over BIM[END_REF]. They aimed to align several specialized indexations of building components at both sides, by extending IfcOWL ontology with bSDD vocabulary (i.e., synonyms and description) as enriched IfcOWL ontology to deal with the same abstract concepts or physical objects. Fahad et al. also investigated semantic web approach by using SWRL and traditional approach by the use of IfcDoc tool and analyzed that the semantic web technique represents more global scope with larger visibility of querying for the validation of IFC models [START_REF] Fahad | SWRL Towards Mapping Certification Rules over BIM[END_REF]. Ontologies play a vital role for the rule based semantic checking, therefore in the next subsection to mention some of the important ontologies in the IFC domain.

Ontologies in the IFC domain

To achieve the benefits of ontologies, there are many efforts to build an ontology for the IFC construction industry. One of the outcomes can be seen as an IFC-based Construction Industry Ontology and Semantic web services framework [START_REF] Zhang | Development of IFCbased Construction Industry Ontology for Information Retrieval from IFC Models[END_REF]. With simple reasoning built over the ontology, their information retrieval system could query the IFC model into XML format directly. The BuildingSMART Linked Data Working Group has developed IfcOWL ontology to allow ex-tensions towards other structured data sets that are made available using semantic web technologies [START_REF] Terkaj | IfcOWL ontology file for IFC4[END_REF]. There are many versions of IfcOWL ontology since the work has been started. We have been working on an ontology IFC4_ADD1.owl that came on 25 Sept. 2015. We have enriched this ontology with English-French and IFC vocabulary (synonyms, descriptions, etc.) from bSDD semantic data dictionary in our research project where we map regulatory text and certification rules over BIM [START_REF] Fahad | Towards Mapping Certification Rules over BIM[END_REF]. In addition, we assigned concepts of IfcOWL ontology with Global Unique Identifier (GUID) to serve as a unique languagedependent serial number from the bSDD. There are some other ontologies as well such as the ontology defining the core concepts of a building named Building Topology Ontology (BOT) [START_REF] Rasmussen | Building Topology Ontology (BOT)[END_REF] and the ontology for CAD Data and Geometric Constraints named OntoBREP [START_REF] Perzylo | An ontology for CAD data and geometric constraints as a link between product models and semantic robot task descriptions[END_REF].

SEMANTIC BIM REASONER

This section presents our research and development towards building Semantic BIM Reasoner. The following subsections elaborate it's various aspects.

SBIM-Reasoner Architecture

Semantic BIM Reasoner (SBIM-Reasoner) deploys many preprocessors for building semantic repository for the verification of IFC models (see Figure 1). Primarily it has three pre-processors, i.e., IFC to RDF Converter, Geometry Extractor, and Semantic Preprocessor which has further subcomponents named IFCOWL Ontology sub-graph, SPARQL Rules, SPARQL Queries and TripleStore.

IFC-to-RDF Converter+Filter

It is necessary for the semantic reasoner to convert IFC into RDF for building the semantic repository. IFC-to-RDF is a set of reusable Java component that allows parsing IFC files and converts them into RDF graphs. Our system deploys modified version of IFC-to-RDF conversion plug-in provided by Pauwels & Oraskari [START_REF] Pauwels | IFC-to-RDF Converter[END_REF]. After conversion, underly-ing RDF acts as a foundation stone to execute all the verification rules. Therefore, we did filtration to get only relevant triplets from the IFC model. Generally there are two ways to get filtered model. First to get full RDF equivalent of IFC model and then apply SPARQL Construct query to get small graph of only wanted IFC classes. In this approach we found over-head of creating full graph and then extracting a subgraph. Second, which we adopted is to integrate IF-Then-Else statements inside the code of Pauwels to filter unwanted elements like IFC classes {Person, Address, MaterialList, SwitchingDeviceType, ColourRgb, etc.}. By this filtration, we have noted that we got filtered RDF model which is 10 times smaller in size as compared to full RDF (equivalent IFC) model. Table 1 shows the comparison between RDF files, i.e., RDF equivalent IFC and Filtered RDF.

Geometry Preprocessor

There are two geometry render engine plugins available with the BIM Server named IFCOPENSHELL and IFC Engine DLL. These are helpful to extract geometry data about the IFC objects. The outputs of this preprocessor are the RDF triplets which are formed from the extracted geometry data of relevant IFC objects. Table 2 shows the statistics of IFC objects present in the IFC models. Table 1. Comparison between RDF Files (Equivalent IFC vs. Filtered RDF) Table 2. Statistics of IFC objects in IFC models

IFCOWL ontology sub-graph

As the standard IFCOWL ontology has a very large set of IFC elements, therefore, we deal with the sub-graph to achieve better processing and querying performance.

SPARQL Rules -Statements

We have created a large set of SPARQL rules, i.e., statements. In fact, these statements are shortcuts overs the long chain of triplets to enable simplicity. For instance, we created In_Storey shortcut over the RDF triplets via relatedObjects and relatingObjects between IFC elements (see Figure 2). Likewise Boundary statement is created as a shortcut over the RDF triplets via relatingSpace and relat-edBuildingElement. These statements promote readability, understandability and enable simplicity when creating SPARQL rules and queries. Otherwise the chain of triplets makes things complex and ambiguous.

Figure 2. Examples of Statements over triplets

SPARQL Queries -Materialization

During the analysis of rules specification, we come across various types of vocabulary (introduced by regulatory texts) during building code compliance application. This vocabulary is composed of high level concepts present in business rules and regulation texts which are familiar by the stakeholders of BIM. There are two methods to build such vocabulary of newer high-level concepts, i.e.; via forwarding chaining and/or backward chaining. Based on the SPARQL rules, we have built SPARQL queries to introduce high level concepts based on the primary IFC vocabulary by using both forward and backward chaining where applicable. Figure 3 shows high level concepts 'circulationHorizontale' and 'Degagement' in our case study of building French code compliance via forward chaining. In these examples we have used our defined inStorey and boundry concepts along with the pre-defined IFC owl terminologies such as IfcOpeningElement, IfcSpace.

Figure 3. Examples of Forward Chaining SPARQL Queries

Backward chaining consists of ontology statements that align IFC concepts with regulatory concepts, whereas forward chaining consists of insert statements that create supplementary triplets. Forward chaining is a good at an implementation stage to save memory and CPU resources. From the ma-chine point of view, backward chaining is processed each time a semantic query is submitted whereas forward chaining is executed each time the data changes. At this stage, this choice is a compromise between effective queries (forward chaining is more appropriate for complex and numerous queries) and model update frequency (backward chaining is more appropriate when data changes frequently). We can even say that it is a compromise between the amount of triplet (considering triplet generated by forward chaining statements) and the ontology complexity. Therefore, we have mixed both approaches Backward and Forward chaining to provide the optimal setting that minimizes response time and maximizes ontology consistence. With the help of these techniques, we have simplified several IFC patterns such as classifications, predefined types, properties, geometry, topology, etc.

TripleStore -Stardog

Although IFC is an open standard; its complex nature makes information retrieval difficult from an IFC model as the size of IFC model grows. Stardog provides fast access to triplets to fetch data to validate IFC models. All the end-user verification queries are executed on the top of final stardog triple store which is built successively by our reasoner. For example if an end-user needs to check whether a Room in the IFC model is accessible by a wheelchair, then it can be done easily by using above explained construct_degagement where the value of IfcDoor must be equal or greater than 90 cm. An end-user may apply SPARQL ASK and DESCRIBE queries to retrieve relevant information regarding the verification rules. Instead of using IfcDoc tool where there is no intermediate state and no explanation for the reason of non-compliance, we use SPARQL DESCRIBE Queries. The SPARQL DESCRIBE query does not actually return resources matched by the graph pattern of the query, but an RDF graph that "describes" those resources. It is up to the SPARQL query service to choose what triples are included to describe a resource. Therefore, SPARQL queries serve best by concatenating desired triplets for building verification rules to check the code compliance.

SBIM-Reasoner as a semantic service

We have developed SBIM-Reasoner as a semantic service inside a KROQI platform 5 . As it is developed especially for the French building code compliance, therefore our web interface is also in French targeting French community. When the application starts, an end-user has to configure IFC input model by clicking under the synchronization button on the very first tab 'Maquette'. Then an end-user selects the set of rules to be verified on this input model by selecting/browsing their set of rules on the second tab 'Protocoles'. Then our web service starts by calling semantic reasoner which computes the set of rules and redirects to the result page 'Résultats'. Each of the rule is highlighted as green or red color depending on its status of compliance (see Figure 5).

Testing IFC Models

We have used several IFC models from the online repository (see url above) to test our Semantic BIM Reasoner. These IFC models vary in size, number of IFC objects, free spaces, etc. We have also used four IFC models developed at our CSTB enterprise named Bat_CSTB (14.9 MB), HAixFlowCtrl (13.1 MB), Maquette Test Checker (11.2 MB) and Liberty (12.2 Mb). Above in Tables 1 and2 we have shown statistics about these IFC models. We have also measured time taken by the Converter Preprocessor that does conversion and filtration to produce the initial RDF semantic model on a 'quad core i5 CPU at 2,5Ghz' machine.

In addition, we have also measure time taken by the Geometry Preprocessor that extracts geometry data of our desired IFC elements (ref.

Table 2) from the IFC models. Figure 7 shows the estimated time taken by the conversion and geometry preprocessors. When we see the time graph, we observe that SBIM-Reasoner took less than a minute by both the preprocessors to achieve their objectives when the size of IFC model is under 15 MB. But when the size of IFC model is 62 MB (in case of huge IFC model Hitos) then it took almost 3.4 minutes to convert and filter, and more than 5 minutes to extract geometry data. Here, we also mention that although preprocessors took time to build semantic model at the first time, but querying for the verification of IFC models are processed fast and a good runtime is achieved. On the other hand on traditional IFC model, it takes much time to verify each of the individual rule. In addition, we are not able to execute all types of rules as per our desire due to narrow scope of IFC tools available online. This is only with the semantic model that we are flexible enough to fetch any triplets and build rules according to our will for the verification of IFC models. On the basis of this analysis, we conclude that semantic model serves best for the verification of IFC models. We also revealed encouraging results via several tests from the initial version of SBIM-Reasoner.

CONCLUSIONS

There are many techniques for the automatic verification of IFC models, but, still there are many open challenges. In this paper, we have presented a semantic approach that can easily be extended, configured and deployed for the dynamic and changing environment having broad spectrum of functionalities for the verification of IFC models. We presented SBIM-Reasoner that builds semantic model by con-verting IFC model into RDF and also extracting geometry data as a set of triplets. Then, it loads this semantic RDF data into Stardog triplestore, and enriches the primary semantic model with our defined SPARQL Rules (shortcuts overs long chain of triplets) and Queries (regulation and business rules). End-user queries are formalized as SPARQL queries which are executed on the top of this final triplestore. SBIM-Reasoner responds their status of compliance along with the BCF representation of noncompliant IFC objects. We demonstrated several test models on SBIM-Reasoner and presented its efficiency and efficacy with empirical results. We conclude that the semantic model based on the semantic web technology is a good compromise between development efforts and opportunities. The graphical representation of RDF allows rules to be more intuitive and more efficient to reason and execute. Concatenation of triplets allows flexibility of making wide range of verification rules with condition and constraints at ease. SPARQL has a global scope with larger visibility of querying with the built-in functions and support of intermediate calculations for the validation of IFC models.

Figure 1 .

 1 Figure 1. Top level Architecture of SBIM-Reasoner

  Therefore, we have used Stardog as a triplestore to build our semantic model. Querying semantic model is faster and gives a good runtime. When the application starts, an end-user provides an IFC model and the set of SPARQL queries which are the verification rules for checking code compliance of desired IFC model. As a result, our system converts IFC file into filtered RDF model. It loads that converted-filtered IFC equivalent RDF into stardog. After triplets concerning geometry are added to capture geometrical information in the triplestore. Then the semantic model is enriched with IFCOWL basic vocabulary, i.e., subgraph of IFC ontology. Then, it adds SPARQL rules into the triplestore. Finally, it executes our project specific forward chaining SPARQL queries which creates high level vocabulary and builds further RDF graphs over the existing triplets. With reference to above examples, our semantic preprocessor is illustrated in Figure 4 based on the basic IFC vocabulary, shortcuts and constructs.

Figure 4 .

 4 Figure 4. Example of Construction of Semantic Preprocessor

Figure 5 .

 5 Figure 5. Result Page containing status of Verification Rules When SBIM-Reasoner has detected non-compliant objects (in case of red status), an end-user can further analyze them by clicking on the corresponding row. It fetches and displays the list of IFC non-compliant objects containing Name, GUID and Type of each IFC object (see Figure 6). One can also export PDF and BCF files to analyze their results in detail.

Figure 6 .

 6 Figure 6. List of non-compliant IFC objects

Figure 7 .

 7 Figure 7. Time taken by preprocessors (Converter and Geometry Extractor)

IFC test Data https://github.com/opensourceBIM/TestFiles/tree/master/T estData/data

https://svc-bimsemchecker.dev.coplus.fr/CheckerService-/v2/ui?file_id=test_20180302_NR_LibertyLoft_OK


N Bus

F Muhammad

B Fies

Semantic topological querying for compliance checking

Architects and construction engineers needs services to check their designs against specific standards, regulations and policies. Many works have been done during the last years to develop checking software. French National project "Digitizing building regulations" aims at formalizing regulation for automatic compliance checking purposes. Our approach is cloud ready, opened, extensible and based on international standard. In this paper we focus on semantic topological aspects to show gains, limits and perspectives of this approach.

INTRODUCTION

In a world where industrial operations are increasingly complex and globalized, there is a growing need for delivering services informing the users about the levels of "safety" and compliance of a given building. While technical experts and audit specialists are moving towards BIM (Building Information Modeling), model-checking software allow to control building operations and processes, starting from the first lifecycle phasebuilding design. This improves project standard compliance while ensuring related costs remain affordable. In this study, we will focus on how geometrical and semantic constraints can simultaneously be computed in a compliance checking context. This work is part of the French national project "Digitizing building regulations" (« Numérisation des règles ») which aims at converting existing AEC laws and regulations into logic rules.

RELATED WORK

Model checking solutions

The traditional approach of verification using MVDXML [START_REF]MVDXML specification and support implementation[END_REF] [START_REF] Zhang | Model view checking: automated validation for IFC building models[END_REF] is very limited. Major limitations have been identified such as restricted scope of applying conditions and constraints on several branches of an IFC model; poor geometric analysis of an IFC model; lack of mathematical calculations; support of only static verification of a model, etc. Several works introduced a semantic rule engine oriented [START_REF] Fahad | Towards Validation of IFC Models with IfcDoc and SWRL A Comparative Study[END_REF] approach as a viable alternative.

Semantic approach

In the context of BIM (Building Information Modelling), modelling building elements as resources has been identified as an interesting approach for achieving information interoperability (Pauwels, et al., 2011 andFarias, et al., 2014). Existing IFCrelated ontologies were conceived as direct syntax mappings be-tween EXPRESS and OWL languages (Beetz, et al., 2009 andPauwels, et al., 2011). One of the latest and the most solid implementations of an IFC ontology is IfcOWL proposed in (W3C Linked Building Data Community Group, 2014). This version of IfcOWL is also a Candidate Standard (buildingSMART, 2017) for buildingSMART (meaning it is considered as an activity in the process of acquiring international consensus before being submitted to the Standards Committee for a final vote). In the last years, several initiatives were proposed by the research community, most of them relying on Semantic Web technologies for addressing the issues that appear when relying solely on IFC models. Based on these, buildingSMART International accepted ifcOWL (OWL serialization of the IFC standard) as a candidate standard. Indeed, ifcOWL and its sub-related graph structure allow solving some issues regarding data partitioning, querying and reasoning. By doing so, buildingSMART International (notably its Linked Data Working Group -LDWG) have opened the road to expert model-checking solutions. Still, at this stage, several questions remain unanswered. Most requirements address simultaneously geometrical and semantics aspects. Taking IFCOWL and IFC to RDF converter as a starting point, we have built transformation services and a methodology that is described in detail in the following chapters.

Collaborative BIM platform

In March 2018, the KROQI platform has been officially launched. It is a collaborative cloud platform for construction SMEs available free of charge to all construction stakeholders including SMEs and VSEs. It provides document management functionalities, collaborative services, and innovative business services all along the building life cycle. The MVDXML technology is deployed on the KROQI platform to check the quality of the IFC files that are uploaded by the users. It checks if the structure of the IFC files is compliant with project policies. The semantic checker to be developed in the frame of the « Numérisation des règles » project will complement this first checker. It will be integrated to the KROQI platform and provides extended rule checking capabilities such as checking topology.

METHOD

Validating modeling options

The Building Executive Plan (BEP) describes how construction project stakeholders agree to model and share information. This document describes data exchange processes, modelling best practices, exports parameters, nomenclatures and classifications to be used. Most of the time the document references international classification frameworks like Uniformat or Omniclass. Having all actors of the project share the same modeling rules drastically decrease the number of models' variants. The BEP is also used to extend IFC properties with ad-hoc property sets dedicated to specific topics, such as certification level, equipment performances or environmental impact of product. CSTB aims at providing a national modeling charter core to be used as a common starting point when engineering the modeling plan of a project. We are working together with architects, building owners, engineers, audit experts, building quality control agencies and government to reach this goal.

Enriching model with semantic inferences

The semantic approach allows to describe a building as well as a requirement by using the same atomic fact formalism called triplet. The IFC and so ifcOWL standard vocabulary includes hundreds of classes and properties representing the building physical layer. This vocabulary is not natively designed to deal with national considerations, building performances, requirements and building functionalities. During the first phase of the « Numérisation des règles » project, a first regulation vocabulary has been extracted from a set of regulatory documents. While trying to align IFC vocabulary with regulatory vocabulary we showed that this alignment cannot be based on a simple bijective relation. Indeed, some regulatory concepts can only be defined with a logical statement aggregating various IFC classes. For instance, in our regulation ontology, a simple regulatory concept like "highest storey" is inferred by comparing the "elevation" (ifcOWL property) values of the all "IfcBuildingStorey" (ifcOWL class) for a given building. The Regulatory ontology is composed by complex regulatory concepts defined on top of ifcOWL. Regulatory concepts are organized in layers. The ifcOWL vocabulary is the ground layer of a vocabulary pyramid. At the very top of the pyramid (see figure 1), we find the very regulatoryspecific vocabulary. A term of a specific layer is defined by using terms belonging to the lower layer. This layered approach is flexible as it keeps high-level definitions simple by increasing the number of terms.

Figure 1. Regulation vocabulary layers

The whole process that provides a semantic regulatory view from the IFC source model works as follows: firstly, we convert IFC model into an ifcOWL triplet database by using the IFC-to-RDF-converter [START_REF] Pauwels | IFC-to-RDF Converter[END_REF] provided by BuildingSmart-; A custom class and relations filter is used to remove non-significant information (concepts not involved in any rule). This operation can be compared to a MVD -Model View Definitiondedicated to regulation. As some IFC terms are almost never addressed by regulatory texts -such as high-level geometry, element history or sensor states, they can be filtered from the model to reduce the amount of data. Then a "geometrical preprocessor" renders and computes additional geometry aspects. This preprocessor is detailed in the following chapters. Eventually a "semantic preprocessor" infers the model according to the regulatory ontology. As a major advantage, this last transformation step offers a simplified graph from ifcOWL model [START_REF] Pauwels | SimpleBIM: from full ifcOWL graphs to simplified building graphs, Ework and ebusiness in architecture, engineering and construction[END_REF]. For instance, referencing to classification (e.g. Uniformat) takes at least ten triplets with ifcOWL vocabulary whereas one triplet is sufficient with the regulatory ontology.

Geometrical preprocessor

The regulation describes constraints that involve topological relations between objects such as: is below, is inside, is adjacent to. IFC allows to describe elements with various representation models: extrusion, BREP, boolean operations. To compute topological relations a low-level geometry such as bounding boxes is sufficient. The building boxes are described by using only 6 semantic relations from the regulation ontology: Xmin, Xmax, Ymin, Ymax, Zmin and Zmax (see figure 2).

Figure 2. Bounding box corresponding to geometry of a chair

The geometric preprocessor infers on geometry to compute triplets materializing bounding box representation of building objects (e.g. furniture20 xMin 50.12). According to ours tests reasoning on the bounding box representation instead of BREP or geometrical operations representation are reliable and low CPU consuming.

Formalizing regulatory requirements

This section provides details on the methodology used to transform the regulatory constraints, expressed in natural language, into processable queries.

Firstly, regulatory texts are prepared and interpreted by working groups. Experts use a text editor with autocompletion and syntax highlighting capabilities to re-write regulatory texts into semi-formal rules [START_REF] Wieringa | Integrating semiformal and formal requirements[END_REF]. Each semi-formal rule is supposed to detect non-compliant building elements concerning a very specific aspect. Depending on its complexity, a regulatory rule, in texts, can be divided into several atomic semiformal rules dealing with complementary aspects. The idea is to keep each semi-formal rule as simple as possible. As a guideline, we suggested that each semi-formal rule begin with "IF" followed by a condition on specific elements and ends with "THEN NON-COMPLIANT".

The second step of this transformation brings the regulatory constraints from the semi-formal to the formal stage. This step is performed by computer scientists familiar with the BIM and with semantic technologies. The semi-formal stage makes it convenient to build formal rules. Each semi-formal rule is translated to a SPARQL query using the same level of vocabulary coming from the regulatory ontology. The direct use of the regulatory controlled vocabulary within the constraint-queries keeps them understandable for construction experts. Geometrical constraints are described by using the geoSPARQL (OGC standard) relations covering all the possible topological relations between two geometries as introduced by the Trinity College of Dublin [START_REF] Mcglinn | Integrating Ireland's Geospatial Information to Provide Authoritative Building Information Models[END_REF]. Geometry simplification makes it easier to deal with geometry coordinates. This approach could be extended if needed by using functional extensions [START_REF] Zhang | Querying Linked Building Data Using SPARQL with Functional Extensions 7[END_REF].

Checking regulatory requirements as a KROQI service

Automating code-compliance checking consists of chaining conversion algorithm with geometrical and semantic preprocessors introduced in §3.3.

Each time new IFC model is submitted to the semantic checker this chain is triggered so that we obtain a triplet database with the right level of details, aligned with the regulatory ontology. The geometrical preprocessor consists of a java code that returns geometrical triplets from IFC. The code executes a sequence of semantic forward chaining operations that filters useless information or enhances model with high level vocabulary. Ontology alignment and extensions to IFCOWL are declared in the regulation ontology. Constraint-queries are organized by regulatory topics so that the KROQI user can select a set of constraints corresponding to his specific needs (fire safety, accessibility, ventilation, acoustics…).

SYSTEM ARCHITECTURE

Technically, the checking service is hosted by a microservice architecture among other BIM service like account manager, document sharing, annotations, instant messaging, BIM viewer. Each service is pro-grammatically independent but can communicate with others through synchronous HTTP/REST queries or through an asynchronous messages queue. The checking service is developed according to the SaaS pattern. This service can be executed locally or integrated to any collaborative BIM platform. The service (see Figure 3) can be executed through its own user interface that provides a list of rule set to check or silently. The REST API published by the service is simple. It consists of a unique method "check" and two parameters. The first parameter defines the path to the IFC or IFCZIP model. Constraint-queries are packed as SPARQL files in a ZIP archive. The archive also contains the metadata for end-user's information purpose. The second parameter defines the path to the ZIP file corresponding to the Constraint-queries set.

Figure 3. Checking Service Architecture

Next step of the automation algorithm consists of executing, one by one, each formal constraintquery corresponding to the chosen topic.

The result can be returned as XML, BCF, PDF or JSON format according to the accept requestheader defined by the REST specification. PDF is used for user display, JSON allow to chain services and BCF can interoperate with BIM-native tools. Whatever the format asked, the result contains for each constraint-query a list of non-compliant building elements identified by their GUID. The BCF format [START_REF] Buidlingsmart | BCF specification[END_REF] is simple and easy to implement [START_REF] Mahdavi | eWork and eBusiness in Architecture, Engineering and Con-struction[END_REF]. The basic content is an issue with comments and references to affected objects (using IFC mechanisms for Global Unique ID's). The format also supports status-information, since issues may be discussed by different users during the workflow. The BCF file makes it convenient to display within a standard IFC viewer, on top of a graphical representation of a building element the results of the evaluation. The BCF format is independent of the IFC schema version, so it can be used with IFC2x3 and IFC4.

RESULTS

We applied this approach on several constraints of the French regulation on both fire safety and accessibility domains. A first version of a French regulation ontology based on previous CSTB research works has been adapted [7]. A group of domain experts had analyzed, interpreted and finally converted a dozen of regulation texts into about one hundred semi-formal constraints implementing concepts of the regulatory ontology vocabulary. The regulation ontology was then extended with experts' new concepts suggestions.

The following paragraphs illustrate in detail two specific use cases.

Checking fire safety requirements

The fire safety domain regulation put some constraint on structure element performances. Indeed, from the fire safety perspective, the structure elements of the building must bear load during at least one hour in case of fire. This constraint differs according to the building height. On a fire safety point of view, the building height is measured from the ground up to the floor of the latest storey. Translated as a SPARQL query, this constraint implies various high-level concepts such as: highest level (storey with highest elevation), storey floor (lower slab of a storey), structure element (building element that bear load), loadbearing duration in case of fire. The following sequence is triggered by the constraintquery:

1. The building height according to the fire safety standard is calculated on the fly 2. The material performance threshold is determined according to the building height 3. All structure elements are retrieved and their performances are checked 4. Finally, the query returns all structure elements with fire resistance below than the threshold.

Fire safety regulation needs a circulation graph to be checked (see figure 4).

Figure 4. Circulation graph inferred for IFC model

This circulation graph can be inferred from the IFC model by using the IfcRelSpaceBoundary relation between spaces and openings. Sometime some expected relations are missing in the IFC model. To complete information we also infer spaces adjacencies with a fuzzy intersection rule. The fuzzy intersection is a clash detection rule with tolerance on boundary boxes. This architecture has been implemented on the KROQI platform providing a full automated checking process on various fire safety and accessibility topics.

Checking accessibility requirements

According to French building regulation, an accessible WC seat (water closet seat) must have a free space of 0.8 x 1 meter on its left OR on its right side. The WC is a high level regulatory concept corresponding to an IfcFlowTerminal [START_REF]IFC 2x3, Specification[END_REF] with a predefined type equal to WCSEAT [START_REF]IFC 2x3, Specification[END_REF]. Each free space is classified by using the high level regulatory concept FreeSpace (see figure 5). It represents a virtual object (not physical) with three dimensions (bounding box). According to the regulation, this object must not intersect with any other physical element of the building.

Figure 5. Materialized free space required around WC seat

The checking process of this constraint is detailed by the following sequence: 1. For each WC (water closet seat), two FreeSpace elements -and their bounding box-are created onthe-fly. One on the left and one on the right. 2. For each FreeSpace, the query retrieves all building elements that intersect.

3. Finally, the query returns all WC with at least one FreeSpace intersecting at least one physical building element. In this use case, a bounding box representation of a building element is accurate enough to detect clashes with the WC. Yet, the bounding box must be oriented to be able to locate left and right sides.

This orientation can either be explicit or inferred be comparing dimensions.

In addition to the list of elements that break rules, an explanation query displays the list of elements that intersects with a FreeSpace. During our test we manage to detect a handrail that was settled in a wrong location.

Test set

This approach has been validated on various IFC models from the simpliest to the heaviest by using a widely used triplestore implemented in Java with forward and backward chaining capabilities.

CONCLUSION

We showed that our semantic topological approach allows addressing significant issues raised by the computation of building regulation requirements. We've built, explained and executed queries validating the approach by using portable SPARQL syntax and a triple store implementing W3C recommendations.

Obviously, this approach does not address all constraints defined in the regulations. For instance, when considering a complex corridor with multiples aisles -and their different related widths -the bounding box approximation will output erroneous results while computing intersection between spaces.

DISCUSSION AND FUTUR WORK

Enriching the regulatory ontology

Web semantic technologies bring a powerful formalism to express terminology and constraints. Yet many BIM platform practitioners do not have full understanding of web semantic technics which limit the number of contributors to a regulation ontology. We believe that it is possible to design tools that support visual query building and enable quick, easy and reusable presentation of terminologies and constraints.

Explaining results

Assigning an object to a rule to point out noncompliance can be insufficient to explain complex cases. The EXPLAIN capabilities of SPARQL could be used to give information on contexts and causes, other elements, properties and relation involved in the computation. Ideally the system should give advices on how to solve compliance issues. Topological requirement could be visualized within the model to point out obstructions, clashing or wrong dimensions. We could materialize those requirement as extra elements and then use the BIM-Snippet [START_REF] Buidlingsmart | BCF specification[END_REF] brought by BCF 2.0 to return those small partial models in a standard way.

In addition, as each BCF-issue can carry a camera/viewport and even a screenshot of the situation those elements could be generated by the checker itself to illustrate the issue.

Expressing compliance on partial elements

For complex elements we note that compliance should be expressed on a single part of the element. For instance, a specific aisle of a complex corridor could be less large than required. As the corridor is generally described as a single space we need a new formalism to assign the issue to a specific part of the space.

Improving topological treatments

Next, we should improve the geometrical preprocessor to compute and reason on topological quantities such as intersection volume, distance between elements or projection surfaces. A full integration of geoSPARQL using WKT [START_REF]Open Geospatial Consortium[END_REF] description of geometric could help.

Standardizing regulation ontology

To reinforce domain interoperability and build solutions on international and acknowledged standards, we envision to improve the regulation ontology by considering the latest works done in the Linked Building Data Community group such as the Building Topology Ontology (BOT) [START_REF] Rasmussen | Building Topology Ontology (BOT)[END_REF], the ontology defining the core concepts of a building and OntoBREP [START_REF] Perzylo | An ontology for CAD data and geometric constraints as a link between product models and semantic robot task descriptions[END_REF] -ontology for CAD Data and Geometric Constraints.

Figure 6 .

 6 Figure 6. The "Liberty" model displayed in a IFC viewer

Table 1 .

 1 Models tested


Nicolas Moreau
email: nicolas.moreau@univ-reunion.fr

A SAS macro to perform Abadie's "Bootstrap tests for Distributional Treatment Effects in Instrumental Variable Models" (2002)

Keywords:

This paper presents a SAS macro to implement Abadie's "Bootstrap tests for Distributional Treatment Effects in Instrumental Variable Models" (2002).

Introduction

We introduce the SAS macro TestDistrib written to perform Abadie's "Bootstrap tests for Distributional Treatment Effects in Instrumental Variable Models" (2002). The complete SAS/IML code is available at http://cemoi.univ-reunion.fr/econometrie-avec-r-et-sas/.

A brief presentation of [START_REF] Abadie | Bootstrap Tests for Distributional Treatment Effects in Instrumental variable Models[END_REF] bootstrap tests for distributional treatment effects [START_REF] Abadie | Bootstrap Tests for Distributional Treatment Effects in Instrumental variable Models[END_REF], "considers the problem of assessing the distributional consequences of a treatment on some variable of interest when treatment intake is (possibly) nonrandomized, but there is a binary instrument available for the researcher" (page 284). Let 𝑌 𝑖 (0) be the potential outcome for individual i without treatment, and 𝑌 𝑖 (1) be the potential outcome for the same individual with treatment, 𝑖 = 1, … , 𝑛. Let 𝐷 𝑖 be the observed treatment indicator. It equals one when individual i is treated, and zero otherwise. Let the instrumental variable 𝑍 𝑖 take on the values 0 and 1. Denote 𝐷 𝑖 (0) the value that 𝐷 𝑖 would have taken if 𝑍 𝑖 = 0, and 𝐷 𝑖 (1) the value that 𝐷 𝑖 would have taken if 𝑍 𝑖 = 1. Just one of these two potential treatment indicators is realized (observed). Also, we just have one realized potential outcome for each unit i. The other one is missing. [START_REF] Abadie | Bootstrap Tests for Distributional Treatment Effects in Instrumental variable Models[END_REF] proposes to assess the causal effect of the treatment by comparing the distributions of potential outcomes 𝑌 𝑖 (1) and 𝑌 𝑖 (0) for compliers. Specifically, equality of distributions, first-order and second-order stochastic dominance hypothesis are considered. Three test statistics are then provided.2 Let the empirical cumulative distributions functions be:

Ϝ 1,𝑛 1 (𝑦) = 1 𝑛 1 ∑ 1{𝑌 1,𝑖 ≤ 𝑦} 𝑛 1 𝑖=1 and Ϝ 0,𝑛 0 (𝑦) = 1 𝑛 0 ∑ 1{𝑌 0,𝑖 ≤ 𝑦} 𝑛 0 𝑖=1
, where (𝑌 1,1 , … , 𝑌 1,𝑛 1 ) are those observations with 𝑍 𝑖 = 1, and (𝑌 0,1 , … , 𝑌 0,𝑛 0 ) are those with 𝑍 𝑖 = 0. We have that 𝑛 0 + 𝑛 1 = 𝑛.

The test statistic to test the null hypothesis of equality of distributions for compliers is:

𝑇 𝑛 𝑒q = ( 𝑛 1 𝑛 0 𝑛 ) 1/2 sup 𝑦∈ℝ |Ϝ 1,𝑛 1 (𝑦) -Ϝ 0,𝑛 0 (𝑦)|.
The test statistic to test the null hypothesis of first-order stochastic dominance (for the distribution of 𝑌 𝑖 (1) dominating the distribution of 𝑌 𝑖 (0) for compliers) is:

𝑇 𝑛 fsd = ( 𝑛 1 𝑛 0 𝑛 ) 1/2 sup 𝑦∈ℝ (Ϝ 1,𝑛 1 (𝑦) -Ϝ 0,𝑛 0 (𝑦)).
The test statistic to test the null hypothesis of second-order stochastic dominance (for the distribution of 𝑌 𝑖 (1) dominating the distribution of 𝑌 𝑖 (0) for compliers) is:

𝑇 𝑛 fsd = ( 𝑛 1 𝑛 0 𝑛 ) 1/2 sup 𝑦∈ℝ ∫ (Ϝ 1,𝑛 1 (𝑥) -Ϝ 0,𝑛 0 (𝑥)) 𝑑𝑥 𝑦 -∞ .
Finally, statistical inference for the test statistics is provided with bootstrapping.

Syntax of the SAS macro TestDistrib

The syntax is %TestDistrib (data=, outcome=, treatment=, instrument=, Breps=, graph=); Data specifies the data set. outcome is the outcome variable. treatment is the treatment indicator. instrument specifies the binary variable used as instrument. If instrument is empty, test statistics and inference are computed under the hypothesis of perfect random assignment of the treatment, in which 𝐷 𝑖 = 𝑍 𝑖 for all i (see Abadie (2002, page 287).

Note that all variables in outcome, treatment, and instrument must be numeric. Also, the variables in treatment and instrument must be binary variables that take on the values 0 and 1. Breps is the number of bootstrapped samples drawn with replacement to approximate the P-values of the observed test statistics. No statistical inference is produced if Breps is not specified be the user.

With the parameter graph, users visualize the empirical cumulative distribution functions of the outcome variable for treated and controls and the estimated cumulative distribution functions of the potential outcomes for compliers. The default is to plot these two graphs if Breps is not specified by the user. If Breps=no, Breps=0, or Breps=none (or whatever character/value except a blank), not any graph is displayed.

Note that TestDistrib will automatically delete observations with missing values and will stop executing if:

-the dependent variable or the treatment variable are not specified -the dependent variable is not numeric -the treatment variable is not binary 0 and 1 -the instrumental variable is not binary 0 and 1.

Results presentation and output data file

A first table provides the number of observations in the original data set, the number of observations without missing values, the number of observations with 𝑍 𝑖 = 1, the number of observations with 𝑍 𝑖 = 0, the number of treated units, and the number of controls.

A second table includes the observed test statistics with corresponding P-values. The first row corresponds to the test statistic 𝑇 𝑛 𝑒q , the second one to 𝑇 𝑛 fsd , and the third one to 𝑇 𝑛 ssd .

One temporary output data file named Tnboot is created. It includes the bootstrap test statistics obtained on each bootstrap sample. Tnboot needs to be stored in a specific folder with a libname statement to become permanent.

An example

We use the particular data set from [START_REF] Abadie | Bootstrap Tests for Distributional Treatment Effects in Instrumental variable Models[END_REF] to examine the effect of participation in the military service during the Vietnam war on individuals' annual earnings. Following [START_REF] Abadie | Bootstrap Tests for Distributional Treatment Effects in Instrumental variable Models[END_REF], the stochastic dominance tests are for earnings for nonvetarans dominating earnings for veterans.

annwage: individual annual earnings noveteran = 1 if the individual is not a veteran, 0 otherwise nocoarse1a = 1 if the individual is not draft-eligible, 0 otherwise.

number of observations: 11637 Number of observations without missing values: 11637 Number of observations with Z=1: 8403 Number of observations with Z=0: 3234 Number of treated units: 9176 Number of control units: 2461

	Tests for Distributional Treatment Effects
	Outcome variable: annwage
	Treatment variable: noveteran
	Instrumental variable (Z): nocoarse1a
	Total Test statistic P-value
	Equality in distributions	1.1633049 0.1225
	First-order stochastic dominance	0.4552777 0.6275
	Second-order stochastic dominance	0 0.7475
	The macro statement:
	"% TestDistrib (data=Abadie, outcome=annwage, treatment=noveteran, instrument=nocoarse1a,
	Breps=2000, graph=);"
	replicates Abadie (2002)'s results with a slight variation in P-values. This is due to the use of different
	random draws to compute the bootstrap statistics. When the random draws are the same, the results
	are identical. The results are presented below.

We refer the reader to[START_REF] Abadie | Bootstrap Tests for Distributional Treatment Effects in Instrumental variable Models[END_REF] for a clear and comprehensive presentation of the methodology at stake.