Construction project management has improved in the last decades thanks to the Building Information Modeling paradigm (BIM), whose main principle is to use an exhaustive numerical representation of a building. In this paper, we focus on the application of Semantic Web technologies for checking building conformance to legal regulations. In our case, buildings are modeled using an ontology based RDF graph, and our goal is to check its conformity to accessibility regulations. We use the SHACL semantic data validation language, to perform this automated checking. We selected some relevant regulations to be modeled in SHACL and tested the method on a test building model. We were able to validate this method and and plan to develop a methodology aiming at producing a SHACL model for any kind of regulations. Using our approach makes it possible to check conformance of a building even before the building is constructed or at early stages of its construction, introducing a form of “Accessibility by design”.
Assessing building conformance to norms and regulation is tedious and prone to error due to the complexity of law texts or incompleteness of checking process. The assessment process requires a substantial amount of expertise. The target conformity standard takes the form of synoptic tables, timetables, global and detailed diagrams. Those documents summarizes the obligations and procedure: diagnosis, authorizations, certificates, technical inspection, possibilities of exemptions, etc. It also details the logical order of the chain of travel, the technical prescriptions to be observed for all types of buildings, including establishments open to the public, public facilities, collective residential buildings and individual houses.
The evolution of laws and regulations, requires conformance assessment professionals to regularly update their expertise. Besides, existing buildings structures and layout might evolve, to satisfy their occupants needs. Keeping the building respectful of the of current regulation and laws, is a challenging necessity.
In this paper we propose to automate this process using the following elements: • A digital model of the building based on a semantic model • A logical representation of the conformance regulation • A Digital Twin (DT) platform called Thing’In providing the above features • A proof mechanism for checking the conformance of the building to the conformance regulation Thus, complying to new regulation will simply amount to modify or add new conformance rules. Similarly if the building has been reworked, its model and associated conformity checking service, can easily be reused to check that the building still conforms to the regulation.
Using our approach makes it possible to check conformance of a building even before the building is constructed or at early stages of its construction, introducing a form of “Accessibility by design”. Taking all dimensions of the design space into account early, when an artifact has proved cost efective in many domains, as it is generally expensive to modify the artifact afterwards, if a wrong decision has been taken.
Not much work has addressed the objective described above. In the following, we describe bodies of work that are related to our topic and have partially addressed our target.
Josefiak and his team have developed the SWOP [
The Product Modelling Ontology (PMO) developed by SWOP has suficient power to make an end-user product ontology for any parametric/configurable product type. This ontology models the product from a solution perspective (‘what is possible’). The same ontology can be extended with an end-user rule set representing User Requirements (UR) like fixed single values, continuous or discrete ranges (logical OR-sense), including enumerations, regarding all relevant product/component datatype/object properties modelled taking into account their underlying datatypes/ranges.
Ontologies such as BOT [
In [
In [
In [
In [
In [
In [
From our first analysis of the works reported above, a common ground is to use Building Information Modelling (BIM) as a baseline. Since the early 2000s, the building industry has been steadily embracing the concept of BIM. Although Werbrouck and his team have successfully used SHACL to ensure a seamless modeling of a building over distributed pods, we believe that SHACL can also beneficially be used to overcome the limitations of tools such as mvdXML and rule based systems for automated building legalx regulations checking.
We have defined a small 3 storeys building, which plan is displayed on figure 1. Our building is ifctional but representative of a real one. Our motivation is to keep it simple enough to be used as a pedagogical tool that we will use to illustrate our solution.
The main entrance of the building is located at the ground floor. When entering the building you have on your left two staircases leading to the upper floors and an elevator in between. On the same floor you have a meeting room on the left. On the first floor you have two EAS on the right and the restrooms on the left. When arriving at the second floor from the stairs, you find the cafetaria in front and a third EAS on the left corner.
The traditional way of checking the building conformance to accessibility regulation is to request the assistance of a specialized agency. This agency will send an expert which will visit and carefully examine the building, to make sure that its infrastructure, facilities and equipments satisfy the rule in force in the building accessibility regulation.
In figure 4, we show such a rule (for now, just ignore the annotations made on the document, we will come to them later in section 5.3). In contrast to the simplicity of the building described above, here we have decided to choose one complex description. Our motivation is that if we are able to support a complex description we can handle simpler ones: as one says “who can do more can do less”
The description we have selected is drawn from a self-diagnostic tool called OCARA 1. OCARA connects to a web server which makes available the content used for audits in the form of benchmarks. A benchmark group together a set of questionnaires which present and control the rules that apply to a given building object (parking spaces, paths, barriers, inclined plane, intercoms, room, door, etc). With OCARA, the expert is guided through the diferent steps to follow to carry out an audit. The expert enters the route to be audited as an ordered list of building object to be checked. Each object encountered in during the route can be evaluated immediately or recorded to be evaluated later.
As a result of an audit, the expert has to fill an audit report which summarizes the obstacles encountered by type of disability and to provide an accessibility score. She/He has also to specify which accessibility faults she/he has encountered. With OCARA the expert can illustrate or comment his finding with texts, photos or audio recording.
In the following we explain how the diferent building objects mentioned above can be
formally described, using Building Information Models (BIM) and stored as a graph in the
Thing’In [
Thing’in [
One particular policy that Thing’In adopts is to ensure that the nodes and relations contained in its graph database comply to well defined ontologies.
As prescribed by cognitive engineering methodologies and good practices, we have looked up existing ontologies that cover our universe of discourse, i.e. the scope of concepts and issues that we need to model in our application. They include the following ontologies: IoTA 4 to model IoT devices and data measurements, SAREF 5 to model Smart appliances, DogOnt 6 and IFC 7.
We indirectly use some higher level ontologies such as the time ontology 8 and the WGS84 (positioning and geolocation) ontology 9, because they are themselves imported by the IoTA and SAREF ontologies.
Figure 2 displays the Thing’In knowledge graph which models the building introduced in section 3. Nodes of the graph represent components of the building. For example the node under focus on the right of the figure is a door and is an instance of the class “Door”. Each node of the graph is an instance of one class defined in the ontology. The classes required to represent the entire building are listed in the left legend box.
In order to discover more about the semantic of that door, we have to navigate around the neighbourhood of the node in the knowledge graph. By clicking on the node we can focus on its immediate vinicity and find out that this door gives access to “Room1” as shown in figure 3. This information is modeled as a link labeled “leadsTo” between the node representing the door and the node representing the door. The list of available link labels is given at the bottom of the left legend box in figure 2.
Such semantic modeling of the building makes it possible to apply other semantic web technologies such as SHACL, as will be shown in the following. 2NGSI-LD: https://www.etsi.org/deliver/etsi_gs/CIM/001_099/009/01.04.01_60/gs_cim009v010401p.pdf 3ETSI: https://www.etsi.org 4https://github.com/supdey/IoTA-ontologies 5https://saref.etsi.org/ 6http://iot-ontologies.github.io/dogont/ 7https://technical.buildingsmart.org/standards/ifc/ifc-formats/ifcowl/ 8https://www.w3.org/TR/owl-time/ 9https://www.w3.org/2003/01/geo/
We now describe our solution. As concluded in the state of the art section 2 we will define SHACL shapes for each of the chosen regulations, in order to check if the building model has the desired properties. To be able to assert some accessibility properties about the building. We thus added some accessibility modeling elements to our building ontology. We also introduce inference rules to infer implicit accessibility properties. The following paragraph describes these three elements of our implementation
Our accessibility ontology contains the elements described in table 1. This ontology introduces a class EAS for secured waiting areas (in French: “Espace d’Attente Sécurisé”), a class Service and a class ServiceType representing service type. The DataProperties introduced allow to set the accomodation capacity of a room, a storey or a building, and to assert that an element is compliant with accessibility regulation. It also introduce the concept of service in a wide sense and in particular services provided in buildings.
Classes EAS Service BuildingService ObjectProperties essentialService provideService provideAccessibleService accessibleWayTo accessibleEvacuationTo DataProperties storeyCapacity roomCapacity roomAccessibility doorAccessibility
Subclass of Room Service SubPropertyOf provideService accessibleWayTo SubPropertyOf
Comments Secured Waiting Area (Espace d’Attente Sécurisé) Domain Building Room or Door Room or Door Domain Storey Room Room Door
Range Service Service Service Room or Door Room or Door Range integer integer boolean boolean
OWL types Symmetric, Transitive Symmetric, Transitive OWL types Functional Functional Functional Functional The data properties allows to assert that a building should provide some essential service (essentialService), actually provides a service (provideService), and provides a service in an accessible manner (provideAccessibleService). The properties accessibleWayTo and accessibleEvacuationTo allows to assert that a disabled person is able move from one place to another. The diference is that elevators are not allowed for evacuation. These properties are not given in the model and should be inferred by some reasoning. The data properties storeyCapacity and roomCapacity allows to assert the accommodation capacity of a storey or a room. The data properties roomAccessibility and doorAccessibility allow to assert that a room or a door is accessible according to the corresponding regulations (these properties are given in our test case).
There are several properties that we want to infer from the given building model, before checking conformance using SHACL shapes. They should reassure with respect to the following questions: • Is it possible for a disabled person to move from one room to another room? • Is it possible for a disabled person to move from one room to another room in evacuation condition? • It is possible for a disabled person to use the essential services of the building, taking into account the path to access the service?
As it is not possible to answer these questions using OWL reasoning, we added some inference rules to the ontology. Three rules were defined for each of these questions. First, we know which rooms connect each door thanks to the leadsTo property. If a door leads to a room and both the room and the door are accessible, we consider that there is an accessibleEvacuationTo relation between the door and the room. The inverse (evacuation from the room to the door) can be inferred as the property is symmetric. Evacuation between distant rooms and doors can then be inferred thanks to the transitivity of the property. The AccessibleEvacuation rule can thus be written as follows: leadsTo(?d,?r) AND roomAccessibility(?r,true) AND doorAccessibility(?d, true) THEN accessibleEvacuationTo(?d,?r)
accessibleEvacuationTo is a sub-property of accessibleWayTo. Indeed, when a disabled person can evacuate from one place to another, it can also use the same path when not in evacuating. Additionally, it is possible to use elevators. We consider that there is an accessible path between two elevator shafts if they contains the same elevator and if the elevator is accessible. All accessible paths can then be inferred by transitivity. We thus write the Accessible Way rule as follows:
Elevator(?elev) AND ElevatorShaft(?shaft1) AND ElevatorShaft(?shaft2) AND roomAccessibility(?elev,true) AND contains(?shaft1,?elev) AND contains(?shaft2,?elev) THEN accessibleWayTo(?shaft1,?shaft2)
Finally we consider that a building provide an accessible service if it contains at least one room which provides the service in an accessible manner. The room should be accessible from at least one entrance. This Accessible Service rule can be written as the following inference rule:
Building(?b) AND room(?r) AND Storey(?st) AND Service(?s) AND Entrance(?e) AND provideAccessibleService(?r, ?s) AND contains(?b,?st) AND contains(?st,?e) AND accessibleWayTo(?e,?r) THEN provideAccessibleService(?b,?s)
In order to define SHACL shapes proceeded with a knowledge elicitation phase where we have
analyzed the regulations documents using a technique called “protocol analysis” [
This analysis provides a structured way to identify the constraints that will be formulated as SHACL shapes, and components such as the type of the target node as well as its relations with neighbor nodes that will be involved in the shape. These elements are detailed in paragraph 5.4.
SHACL shapes are designed to check if an RDF data satisfies some constraints. They can thus be used for our conformance checking problem. We implemented several shapes for each of the regulation item to be checked. Three such items are: The number of Secured Waiting Areas, the secured Waiting Areas’Capacity and the service accessibility. Due to space constraint, we will detail only the second item (Secured Waiting Areas’Capacity) here.
We defined the following SHACL Shapes to check the capacity of secured waiting areas: ex:EasCapacity a sh:NodeShape ; sh:targetClass access:EAS ; sh:property [
Its first constraint simply ensure that the storey capacity is known. The second constraint is a SPARQL constraint. The SPARQL request retrieve the capacity of the storey and the capacities of all secured waiting areas contained in this storey. The GROUP BY and HAVING commands allows to compute the sum of the secured waiting areas capacities and filter out the storeys having the desired property. If the request return a non-empty result, the shape raise an error.
To test our automated conformance checking method, we focus on French accessibility regulations. We selected some rules about emergency evacuation and essential service accessibility, which are rules that involve the global structure of the building and are thus not trivial to check. These global rules requires to check some local accessibility conformance, such as if a door or a room is accessible to a disable person. Here we simply assume that information about these local accessibility is given. The checking of these local accessibility conformance could be also automatically checked in a future work, or left to a human expert.
The rules we selected for automated conformance checking are the following : — Secured waiting area number : each level of a building should have a minimal number of secured waiting area. If the level has an accessible access to the outdoor, no secured waiting area is required. Otherwise, if the level is such that only one stair is required for evacuation, one secured waiting area is required. Otherwise two secured waiting area are required. — Secured waiting area capacity : The minimal capacity of a secured waiting area depends on the level accommodation capacity. This minimal capacity is 2 when the level capacity is less than 50. It is increased by one for each additional slot of 50 people in the level capacity. — Service accessibility : A building is intended to provided some essential service. These service should be accessible for disabled people. In particular, toilets should be accessible.
Our conformance-checking process using OWL, SWRL, and SHACL, was tested using both the Protégé software [14] and the Thing’In platform. Protégé provides a graphical interface to explore ontologies and RDF data. It also provide some OWL reasoners and plugins to handle SWRL rules and SHACL shapes. Using the method described in section 3.4, we were able to validate that the test building conforms to the regulations, and that the expected violations arise when it is modified in a certain way. Three diferent OWL reasoners were tested: Fact++, HermiT and Pellet. Pellet was the only reasoner able to infer all necessary information, combining OWL axioms and SWRL rules. We found that experimenting with Protégé is a convenient preliminary approach to test and compare diferent tools.
For a more streamline and industrial deployement of the process, we migrate the Protégé project to the Thing’In platform. Although Thing’In provides less semantic web tools, it provides the ones we needed and we could benefit from additional functions such as rich visualisation interfaces which enables a userfriendly navigation throughout knowledge graphs.
To our knowledge our approach is the first building compliance checking method using
exclusively standard semantic web technologies. Some other works such as Werbrouck et
al. [
Modeling a few regulations gave us some methodology elements to model more rules. Building regulations often state that an object in some context should satisfy some constraints. Our method to model such a rule was to implement an intermediate shape for the context in which the rule apply, and an intermediate shape for the constraints that have to be satisfied. We then implemented a validating shape, targeting the above-mentioned object, and declaring that if the focus node satisfies the context shape it should also satisfy the constraint shape.
So far our preliminary results are promising. However, future work has to be done to define a precise methodology, able to handle diferent kind of regulations, such as regulations involving numerical computations. It could also be interesting to implement a tool to assist non-SHACL experts in modeling regulations. Another weak point of this conformance-checking process is that it involves three diferent technologies. This causes some reasoners to fail to validate the data. It is also more dificult to define a clear method to create rules when diferent languages are combined. We plan to investigate the possibility to unify the rules modeling in a single language, which would improve the quality of the method.
Finally, it would be interesting to test the performance of this method on more realistic building models. For comparison, the model for the Orange building in Meylan, which can be found in Thing’In, contains about 6000 elements, amongst which about 800 rooms. Our test building contains only 40 elements and 17 rooms.
Wilson, S. Sharples (Eds.), Evaluation of Human Work, CRC Press, 2015, pp. 163–200. URL: https://eprints.soton.ac.uk/359638/. [14] M. A. Musen, The protégé project: a look back and a look forward, AI Matters 1 (2015) 4–12. URL: https://doi.org/10.1145/2757001.2757003. doi:10.1145/2757001.2757003.