BOTSH: Towards aligning semantic web of things with building ontologies

Abstract

The W3C linked building data group is working on modeling the information for integrating building information with building life cycle data using Semantic Web technologies. The community has proposed a set of semantic models such as ifcOWL and Building Topology Ontology (BOT), to model various applications across Architecture, Engineering, Construction, and Operation (AECO) domain. On the other hand, the Semantic Web of Things (SWoT) group proposed standard semantic models such as M3-lite and BOSH ontologies for describing the sensor networks, observations, and sensor measurements. Both the aforementioned domains have their own siloed applications and with the evolution of the smart home domain, there is a need to combine the knowledge of building information with the sensor knowledge to develop cross-domain applications. However, in order to develop such downstream applications leveraging advantages from both domains requires interoperable knowledge. This paper proposes an interoperable ontology, Building Topology Ontology for Smart Homes (BOTSH), with the aim of aligning the building domain with sensors domain semantic models. The BOTSH ontology facilitates capturing knowledge from both domains and helps in developing cross-domain applications. The potential of the proposed model was demonstrated using a real-life building model based on the competency questions framed by the domain experts.

Keywords

Semantic web of things building information models building topology sensors and observations smart homes knowledge graphs semantic applications

1 Introduction

The Architecture, Engineering, Construction and Operation (AECO) industry is one of the fastest-growing industries and involves rapid disruption. The AECO comprises both small and large-scale enterprises related to the operations and maintenance of buildings and infrastructures. In these industries making business decisions is a cumbersome process as many of the companies have fragmented structure and involves their own proprietary data formats, tools, and software. In addition, during the life cycle of a building, a massive amount of data is generated, exchanged, and processed at different ends. This requires a smooth exchange of information over the different phases of the building life cycle with interdisciplinary stakeholders.

Building Information Modelling (BIM) is a standard process that supports data exchange in the building industry to minimize information loss. BIM facilitates modeling the building data using tools and technologies and helps transform the building industry towards complete digitization. A shift towards BIM happens at four different maturity levels, as shown in Fig. 1 [2]. In level 0, stakeholders exchange building drawings in paper-based records drawn using Computer-Aided Design (CAD) software. Level 1 represents the partial collaboration where the drawings are represented in simple 2D and 3D geometry as digital files and shared with the stack holders. Level 2 represents a full collaboration among the stakeholders; the BIM models have been used at this stage, and the exchange of information happens through common interchangeable data formats such as IFC. But, in this stage, there is a chance that the stakeholders may work in different files rather than working on a common shared file. Level 3 represents the development of fully integrated building models using a cloud environment. In this stage, all the stakeholders work on a common shared file to improve productivity and adhere to the open standards to support interoperability. The current work focuses on the industry open standards and how they can be leveraged to develop interoperable applications in the space of BIM.

Fig. 1

Overview of BIM maturity levels.

The buildingSMART is an international organization working towards creating standards with the aim of providing interoperable solutions among building and infrastructure industries. This organization has developed an Industry Foundation Classes (IFC) [14], which provides a rich set of terminologies to describe building models. The World Wide Web Consortium Linked Building Data Community Group (W3C LBD CG) engages semantic web developers and domain experts in designing ontologies to help represent IFC data in machine-understandable format. The ifcOWL is an initiative by Pieter Pauwels [23] for serializing the IFC data in Web Ontology Language (OWL). This ontology is backward compatible with the previous version of the IFC schema, EXPRESS, which resulted in a complex structure and large size. For instance, the ifcOWL for IFC4ADD2 [16] consists of 1331 classes and 1599 properties which is very large and may not be required for all the semantic web applications. To address these drawbacks, the W3C LBD CG has proposed a lightweight ontology Building Topology Ontology (BOT) [25]. This provides a high-level description of the topology of buildings, including storeys, spaces, building elements, and geometry. The current version of BOT V.0.3.2 contains seven classes and fourteen object properties. The BOT is recognised as a central AEC ontology and provides generic concepts for specifying any feature of interest in the context of a building.

On the other hand, the Semantic Web of Things (SWoT) group works on proposing interoperable ontologies for various domains such as smart homes, transportation, healthcare, food, and weather [LOV4IoT] [9]. This paper focuses on the ontologies published in the smart home and building domain. Many notable ontologies have been proposed in the smart homes domain, such as SSN [4], FIESTA-IoT [27], M3-lite [1] and BOSH ontologies. These ontologies focus on representing the information related to sensors, actuators, observations, and measurements. The ontologies like DUL [12], DogOnt [3], ThinkHome [26] and SAREF4BLDG [24] contain concepts related to electronic devices and appliances as well as building topology.

The Smart Home and Building Ontology (BOSH) [21] covers most of the popular concepts used across the smart homes and building domain. This ontology covers concepts related to sensors, actuators, observations, measurements, devices, and appliances. Combining the BOSH with BOT will pave the way for new applications leveraging the advantages of combining sensor-related knowledge with the building topology. For instance, an intelligent system can help in the emergency evacuation of buildings during accidents by combining the knowledge of sensing devices present in the building with the knowledge of building topology. This paper presents a new ontology called Building Topology Ontology for Smart Homes (BOTSH), which is developed based on the BOT and customised to the domain of smart homes.

To evaluate the intended purpose and completeness of the BOTSH ontology, Competency Questions (CQ) have been framed by the domain experts to cover generic to specific requirements.

CQ1 - What are the different spaces present at each storey of the building? CQ2 - What are the tangible building elements and sub-elements present in the building? CQ3 - What are the adjacent and intersecting elements within the building? CQ4 - What are all the distinct types of sensors in the building? CQ5 - What are the room temperatures pertaining to a particular storey of the building? CQ5 - What are the fundamental or base quantities that can be measured pertaining to a particular storey of the building?

The rest of the article is organized as follows. Section 2 discusses the related work done in the area of BIM and SWoT. Section 3 presents the proposed ontology BOTSH. Section 4 demonstrates the necessary ontology alignments between BOTSH and other smart-home related ontologies. Section 5 showcases the application of BOTSH using a case study. Finally, Section 6 highlights some of the assumptions and limitations of the work, and Section 7 concludes the paper and provides possible directions for future work.

2 Related work

Semantic Web researchers have done extensive work to motivate the AECO industry to adopt the Web of data. Similarly, they have also proposed interoperable ontologies in the IoT domain that can help semantic web developers propose cross-domain applications. This section discusses some notable works from building topology and smart home domains and highlights possible directions to bridge the gap between these domains.

One of the pioneering initiatives by the industry practitioners in achieving BIM maturity level 3 is done by integrating the IFC with OWL, named ifcOWL. This initiative is the first step in making the IFC data interoperable and moving towards the Semantic Web. The IFC data model is represented using the EXPRESS schema, which has a strong focus on representing the 3D geometry structures [15]. The IfcOWL has two significant drawbacks one is the size of ifcOWL, and the second one is its complex structure. These limitations make it difficult to understand and adopt the IFC models directly by semantic web developers. The BIM researchers have proposed many alternatives addressing the above drawbacks, such as SimpleBIM [22] and IFC Web of Data (IFCWoD) [7]. These models particularly eliminate the complex geometric representations of the building elements and intermediate EXPRESS-derived relationships between objects.

Though these approaches are proven to be successful, they still rely heavily on the IFC EXPRESS Schema making them difficult to interpret.

The Building Topology Ontology (BOT), is a simple and developer-friendly ontology. It describes tangible and spatial elements of buildings in their topological context. This ontology is an initiative by W3C LBD CG and other initiatives, such as PRODUCT and PROPS ontologies which define building-related products and properties, respectively. BOT is a simple and easily understandable ontology with a limited set of classes and object properties, containing seven classes and fourteen object properties. It is developed with the aim to decouple the description of building data from different interdependent aspects such as the topology of buildings, geometry, properties (e.g., room temperature, wall thickness, wall thermal conductivity), and products (eg., doors, windows, beams, ducts, pipes). There are a few core concepts that are not defined as part of the BOT ontology but may be required from the application’s standpoint. To bridge this gap, the BOT facilitates extending required concepts from other standard ontologies such as SSN, SAREF, and DogOnt. The necessary alignments between BOT and other standard ontologies like SAREF4BLDG, BRICK, DogOnt, IFC4 Add2, and ThinkHome are proposed by the community, which will facilitate in describing the concepts related to building topology as well as other products and properties related to the building. The concepts defined in BOT are sufficient to apply in the smart homes domain. But, some of the concepts are highly generic and may not capture the right semantics especially when used with sensors, observations, appliances and measurements in the context of smart homes. For instance, the concept bot:Element and its corresponding object property bot:hasElement are more generic and requires some specialized concepts to precisely describe the entities. To bridge this gap, the BOTSH proposes additional concepts and object properties that are necessary and sufficient for representing smart homes data. In addition, the alignments with other smart home ontologies, such as M3-lite and BOSH, are proposed to cover application requirements.

SAREF, a REFerence ontology for Smart Appliances [4] developed with the support of the European Commission, follows a modular approach in representing the devices within a smart home environment. This includes commands, states, and functions that can be combined to create complex functionality in a single device. SAREF is a widely adopted ontology in the smart industries domain and has an extension SAREF4BLDG [24] related to the buildings domain. The extension is proposed to separate building-specific information from the generic domain information of SAREF. It is created based on the BIM IFC standard and the scope is limited to the devices and appliances within the building domain. SAREF4BLDG enables interoperability among various actors and applications managing building information. It enables seamless communication between appliances from different manufacturers that support the IFC data model.

Machine-to-Machine Measurement (M3) is a unified taxonomy that defines concepts integrated from various IoT ontologies facilitating interoperability [10]. It describes concepts such as Domain of Interest, Physical Phenomena, and Measurements. M3 is considered to be a heavy ontology due to its vast coverage of concepts, and to overcome this, a lighter version of the same ontology, M3-lite has been proposed [11]. The M3-lite ontology extends the SSN ontology by providing a unified taxonomy for ssn:Device concept. In M3-lite, ssn:SensingDevice has its own taxonomy and defines sixty top-level types of Sensors, the concept m3-lite:QuantityKind defines seventy-eight top-level physical phenomena, and m3-lite:Unit defines sixty-four top-level units of measures. The M3-lite is further adopted in FIESTA-IoT [27], a unified ontology that reuses the concepts from standard ontologies like SSN, IoT-lite, DUL, and WGS84.

Smart Home and Building Ontology (BOSH) [21] is a recent advancement in the smart homes domain. This ontology is developed by extracting the most popular concepts from more than sixteen IoT ontologies. This ontology covers all the necessary concepts that are sufficient to represent the data within a smart home context. The BOSH covers classes related to building, sensors, actuators, tagging devices, appliances, observations, and measurements. The current version of BOSH contains around three hundred classes with ten object properties and is still undergoing revisions to accommodate suggestions provided by the community. BOSH is developed with the aim of helping semantic web developers easily describe and annotate the sensor data within the context of smart homes. The proposed work BOTSH is completely aligned with the BOSH so as to leverage the advantages of combining the knowledge from both the smart home and the building domains.

Integrating BIM with IoT domain is important for the AECO industry to enable smartness in the context of building. domOS [19] is one such work where the researchers have integrated the WoT Thing Description with IoT devices and building topology. However, this work focuses only on WoT Discovery and will not provide any alignments to existing IoT ontologies with concrete case study. Another work in the similar lines by Liu Jiang [17] focuses on intelligent fire protection system by using IoT ontologies and BoT. This work is confined to a specific use case and will use digital twins and semantics rule-based models to make intelligent decisions. This work did not provide any alignments to widely adopted ontologies in the context of IoT, which is very much essential when the same work is applied to broader range of applications.

The advantages of combining the annotated sensor knowledge with the building topology data are enormous and can help developers to design solutions for a wide variety of use cases. One such use case is demonstrated by [13], where they have integrated BIM with sensor observations using the semantic web. In this case study, they have considered Navita’s educational facility in Denmark to demonstrate the advantage of combining BOT and SSN ontology. The BIM model of the facility is converted to BOT-compliant format using Revit-BOT exporter [13] and combined with the Building Management System (BMS). The knowledge thus obtained can address a wide variety of complex queries, such as getting a consolidated view of sensor observations measured from the facility. Integrating BIM with IoT using open standards can pave the path to developing applications that can help people in day to day lives as well as answer research questions, one such application is demonstrated in [6], where the researchers integrated the knowledge from the university’s BIM model and IoT sensors to develop an android application that can help in booking spaces and measure environment parameters within the campus.

The BOTSH ontology proposed in this paper is aligned with the most popular ontologies in the IoT domain and will facilitate the development of cross-domain applications by combining the data from the smart homes (sensors and actuators) with the building topology.

3 Building topology ontology for smart homes (BOTSH)

Building Topology Ontology (BOT) ontology provides a core vocabulary for representing structural, spatial components, and other related elements of buildings. For instance, any product or device that is part of a building such as a wall, furniture, and sensor can be described using a generic concept named Element. This generic representation of BOT might defeat its intended purpose of resource description, specifically when applied to smart home and smart building domains. Though the existing popular ontologies are aligned with many other ontologies in the smart home domain, concepts such as Technical System, Equipment, Construction material, Surface, Wall, Door and Windows are commonly aligned as a subclass of the concept Element. These generic concepts such as Element might defeat their intended purpose when applied to domains like smart home and smart buildings. The BOTSH ontology is developed explicitly for the smart home domain and provides resources to represent sensors, actuators, observations, equipment, and other building-related elements in the view of enabling interoperability across the domains. Also, the ontology is constructed by leveraging various concepts from BOSH and BOT ontologies.

The current version of BOTSH ontology contains eight classes and fifteen object properties. The high-level concepts of the BOTSH ontology are depicted in Fig. 2. BOTSH has four main classes Zone, Building Element, Thing, and Building Interface. The zone is typically a space within a building that is an air-encapsulated area with elements. Building Element represents tangible objects that are part of the building, such as doors, windows, and furniture. The class Thing refers to electronic objects mounted to the building that can share data and communicate with other devices over the internet. The Building Interface is that part of the construction process, and it represents the boundary of at least one of the specific Zone and Building Elements. Other classes like Site, Building, Building Storey, and Space are sub-classes of Zone. The Site is a physical space that can contain one or more buildings. A Building is a spatial structure that is contained in a site and can contain one or more storeys connected vertically. A Building Storey encompasses multiple spaces connected horizontally within a storey. A Space is a physical space that is used for a specific function within a zone. The object properties containsElement, and containsThing are subproperties of hasElement and hasThing, respectively. The property chain axioms defined in the ontology formalize the facts, such as if a zone contains a Building Element and a Building Element has a Thing, then the zone has the Thing. These classes and properties defined in the ontology are sufficient to annotate the smart home data semantically and address all the competency questions.

Fig. 2

Illustration of BOTSH main concepts and properties.

The BOTSH ontology is inspired by BOT, though there are a few concepts that are analogous, BOTSH bridges the gap between the BOT and smart home domain by introducing the concept of "Thing" and its related properties. This new additional concept opens new possibilities for aligning BOTSH with other sensor ontologies and thus scaling it for smart home-based applications. BOTSH makes a clear distinction between the tangible objects that exist within a building like furniture from electronic entities. The botsh:BuildingElement is a class that disjoints with Zone, Building Interface, and Thing, which makes the Building Element semantically different from the electronic entity defined in the building. The botsh:BuildingElement includes household goods and products that do not perform any electronic function but optionally can host another electronic entity. For example, a door that is a botsh:BuildingElement can host an electronic digital locking system.

The concept “Things” in the Internet of Things (IoT) refers to any physical entity that is embedded with sensors/actuators, software/firmware, and other technologies with the purpose of connecting and exchanging data with other devices over the internet. By considering this, the entity “Thing” is defined as part of BOTSH, which represents the IoT objects installed on the building elements. The IoT objects include sensing, actuating, and tagging devices; they also represent other electronic devices and appliances, such as refrigerators and simple thermostats. It is considered that the “Thing” is always hosted on a building element such as a wall or a door. This relationship is modeled using an object property botsh:hasThing which primarily defines the connection between the concepts BuildingElement and Thing. The object property botsh:isPartOf defines a relationship between the concepts Thing and BuildingElement, and it is associated with the property botsh:hasThing through inverse relation. Further, the concept botsh:Thing is aligned to other ontologies from the Smart Home domain, which in turn facilitates in describing the devices and appliances precisely.

3.1 Property chain axioms

The property chain of OWL 2 is an expression, this allows us to derive new object property facts by combining two or more object properties in a sequence. The property chain axioms are used in the BOTSH to formalize facts. For instance, if a zone contains a zone that contains a building element and it contains a thing, then we can derive that zone contains the thing.

Similarly, if a zone contains a zone that either contains, adjacent or intersects a building element and hosts a thing, then we can derive that the zone has the thing.

These property chain axioms allow us to establish the hierarchical relationship between zones, building elements, and things.

4 Ontology alignments

The ontology alignment process enables the interoperability and integration of ontologies to increase the scope of the applications. Smart homes is a rapidly growing domain with numerous ontologies being added to the Semantic Web of Things space in recent years. The BOTSH ontology is created with a specific focus on the smart home domain. This demands the BOTSH to be aligned with other related ontologies to facilitate creating cross-domain knowledge. This section details the alignment of BOTSH ontology with other popular ontologies in the smart homes domain, such as ifcOWL, SAREF4BLDG, DogOnt, and ThinkHome.

4.1 SAREF4BLDG alignment

Table 1
Proposed alignment of BOTSH and SAREF4BLDG

Subject Predicate Object

saref4bldg:Building owl:equivalentClass botsh:Building.

saref4bldg:PhysicalObject owl:equivalentClass botsh:BuildingElement.

saref4bldg:Sensor rdfs:subClassOf botsh:Thing.

saref4bldg:Actuator rdfs:subClassOf botsh:Thing.

saref4bldg:BuildingSpace owl:equivalentClass botsh:Space.

saref4bldg:hasSpace rdfs:subPropertyOf botsh:containsZone.

saref4bldg:contains owl:equivalentProperty botsh:containsThing.

Subject	Predicate	Object
saref4bldg:Building	owl:equivalentClass	botsh:Building.
saref4bldg:PhysicalObject	owl:equivalentClass	botsh:BuildingElement.
saref4bldg:Sensor	rdfs:subClassOf	botsh:Thing.
saref4bldg:Actuator	rdfs:subClassOf	botsh:Thing.
saref4bldg:BuildingSpace	owl:equivalentClass	botsh:Space.
saref4bldg:hasSpace	rdfs:subPropertyOf	botsh:containsZone.
saref4bldg:contains	owl:equivalentProperty	botsh:containsThing.

The SAREF extension for building devices (S4BLDG) ontology [24] is an extension of the Smart Appliances REFerences ontology (SAREF) [5] designed based on the Industry Foundation Classes (IFC). This extended ontology is proposed with the aim of including devices defined in version 4 of the IFC standard and enables the representation of these devices in the building space.

The BOTSH to SAREF4BLDG alignments are presented in Table 1. The concepts saref4bldg:Building, saref4bldg:PhysicalObject, and saref4bldg:BuildingSpace are aligned directly with the classes defined in the BOTSH ontology. The concepts saref4bldg:Sensor and saref4bldg:Actuator are aligned as the specialized concepts of botsh:Thing. The object properties saref4bldg:hasSpace, and saref4bldg:contains are aligned appropriately with the BOTSH ontology.

4.2 DogOnt alignment

DogOnt is designed for intelligent environments such as smart homes and defines the basic IoT entities present within a smart environment. This ontology primarily focuses on device modeling and aspects that are needed to abstract the device’s capabilities.

The defined alignments from DogOnt to BOTSH are summarised in Table 2. The dogont:BuildingThing represents architectural elements that create the building like architectural elements and furniture. This is directly mapped to botsh:BuildingElement, as both concepts share similar semantics. The concepts dogont:Room, dogont:Garage, dogont:Garden, dogont: Balcony, and dogont:Terrace are aligned as a specialization of the concept botsh:Space. The electronic entities such as dogont:Controllable, and dogont:Device are defined as specialization of botsh:Thing. Other building entities such as dogont:Vertical, dogont: Furniture, dogont:Floor, dogont:Ceiling, and dogont: TechnicalSystem are mapped to botsh:BuildingElement using subclasses relationship. The object properties dogont:contains, dogont:belongsTo, dogont:floorOf, dogont:ceilingOf, dogont:hasWall, and dogont: hasWallOpening are mapped to appropriate object properties in the BOTSH using the sub-property relationship.

Table 2
Proposed alignment of BOTSH and DogOnt

Subject Predicate Object

dogont:Building owl:equivalentClass botsh:Building.

dogont:BuildingThing owl:equivalentClass botsh:BuildingElement.

dogont:Storey owl:equivalentClass botsh:BuildingStorey.

dogont:Flat rdfs:subClassOf botsh:Building.

dogont:Room rdfs:subClassOf botsh:Space.

dogont:Garage rdfs:subClassOf botsh:Space.

dogont:Garden rdfs:subClassOf botsh:Space.

dogont:Balcony rdfs:subClassOf botsh:Space.

dogont:Terrace rdfs:subClassOf botsh:Space.

botsh:Zone rdfs:subClassOf dogont:Environment.

dogont:BuildingEnvironment rdfs:subClassOf botsh:Zone.

dogont:Controllable rdfs:subClassOf botsh:Thing.

dogont:Device rdfs:subClassOf botsh:Thing.

dogont:TechnicalSystem rdfs:subClassOf botsh:BuildingElement.

dogont:Vertical rdfs:subClassOf botsh:BuildingElement.

dogont:Furniture rdfs:subClassOf botsh:BuildingElement.

dogont:Ceiling rdfs:subClassOf botsh:BuildingInterface.

dogont:Floor rdfs:subClassOf botsh:BuildingInterface.

dogont:contains rdfs:subPropertyOf botsh:containsElement.

dogont:belongsTo rdfs:subPropertyOf [owl:inverseOf botsh:hasSubElement].

dogont:floorOf rdfs:subPropertyOf botsh:interfaceOf.

dogont:ceilingOf rdfs:subPropertyOf botsh:interfaceOf.

dogont:hasWall rdfs:subPropertyOf botsh:adjacentElement.

dogont:hasWallOpening rdfs:subPropertyOf botsh:hasSubElement.

Subject	Predicate	Object
dogont:Building	owl:equivalentClass	botsh:Building.
dogont:BuildingThing	owl:equivalentClass	botsh:BuildingElement.
dogont:Storey	owl:equivalentClass	botsh:BuildingStorey.
dogont:Flat	rdfs:subClassOf	botsh:Building.
dogont:Room	rdfs:subClassOf	botsh:Space.
dogont:Garage	rdfs:subClassOf	botsh:Space.
dogont:Garden	rdfs:subClassOf	botsh:Space.
dogont:Balcony	rdfs:subClassOf	botsh:Space.
dogont:Terrace	rdfs:subClassOf	botsh:Space.
botsh:Zone	rdfs:subClassOf	dogont:Environment.
dogont:BuildingEnvironment	rdfs:subClassOf	botsh:Zone.
dogont:Controllable	rdfs:subClassOf	botsh:Thing.
dogont:Device	rdfs:subClassOf	botsh:Thing.
dogont:TechnicalSystem	rdfs:subClassOf	botsh:BuildingElement.
dogont:Vertical	rdfs:subClassOf	botsh:BuildingElement.
dogont:Furniture	rdfs:subClassOf	botsh:BuildingElement.
dogont:Ceiling	rdfs:subClassOf	botsh:BuildingInterface.
dogont:Floor	rdfs:subClassOf	botsh:BuildingInterface.
dogont:contains	rdfs:subPropertyOf	botsh:containsElement.
dogont:belongsTo	rdfs:subPropertyOf	[owl:inverseOf botsh:hasSubElement].
dogont:floorOf	rdfs:subPropertyOf	botsh:interfaceOf.
dogont:ceilingOf	rdfs:subPropertyOf	botsh:interfaceOf.
dogont:hasWall	rdfs:subPropertyOf	botsh:adjacentElement.
dogont:hasWallOpening	rdfs:subPropertyOf	botsh:hasSubElement.

4.3 M3-lite alignment

The M3-lite is a lite version of the M3 ontology designed initially as part of FIESTA-IoT project. M3-Lite provides semantic annotation of IoT data produced by diverse devices specifically defining taxonomies to annotate the Quantity Kinds, Units of measurement, and domain of interest.

The defined alignments from M3-lite to BOTSH are given in Table 3. There are no equivalent classes between both ontologies. The concepts, m3lite: ActuatingDevice, m3lite:SensingDevice, m3lite:TagDevice are defined as subclasses of botsh:Thing. The m3lite: SoundSource is a source that produces sound which includes the people present in the building, traffic, or construction work. This understanding helps us to represent the concept m3lite:SoundSource as a subclass of botsh:BuildingElement. Similarly, m3lite:Crowd can be directly defined as a subclass of botsh: BuildingElement. The object property m3lite:hasSoundSource is defined as a sub-property of botsh:hasSubElement as the domain and range of hasSubElement property is botsh:BuildingElement.

Table 3
Proposed alignment of BOTSH and M3-lite

Subject Predicate Object

m3lite:ActuatingDevice rdfs:subClassOf botsh:Thing.

m3lite:SensingDevice rdfs:subClassOf botsh:Thing.

m3lite:TagDevice rdfs:subClassOf botsh:Thing.

m3lite:SoundSource rdfs:subClassOf botsh:BuildingElement.

m3lite:Crowd rdfs:subClassOf botsh:BuildingElement.

m3lite:hasSoundSource rdfs:subPropertyOf botsh:hasSubElement.

Subject	Predicate	Object
m3lite:ActuatingDevice	rdfs:subClassOf	botsh:Thing.
m3lite:SensingDevice	rdfs:subClassOf	botsh:Thing.
m3lite:TagDevice	rdfs:subClassOf	botsh:Thing.
m3lite:SoundSource	rdfs:subClassOf	botsh:BuildingElement.
m3lite:Crowd	rdfs:subClassOf	botsh:BuildingElement.
m3lite:hasSoundSource	rdfs:subPropertyOf	botsh:hasSubElement.

4.4 BOSH alignment

BOSH ontology [21] was developed based on the semantic similarity of concepts present in the popular ontologies that belong to smart home and smart buildings domains such as SAREF, DOLCE, M3 and DogOnt. This ontology covers a rich set of concepts such as home appliances, physical/ambient parameters, measurements and networks. In addition, the ontology contains concepts related to sensors, actuators, measurements, electrical and electronic appliances, and the building environment. The defined alignments from BOSH to BOTSH are given in Table 4. The classes such as bosh:Appliance, bosh:Control, bosh:Device, bosh:SecuritySystem are defined as the specialization of botsh:Thing. The concept bosh:Building is directly mapped as an equivalent to the concept botsh:Building. The concept bosh:Surface captures entities like ceilings, floors, and walls of the building, and it is aligned as a subclass of botsh:BuildingElement. The BOSH’s Flat, Room and Balcony concepts are defined as subclasses of botsh:Space. The object properties bosh:contains,bosh:belongsTo,bosh:hasActuator are directly mapped to botsh:containsThing, botsh:hasSubElement, and botsh:hasThing properties.

Table 4
Proposed alignment of BOTSH and BOSH

Subject Predicate Object

bosh:Appliance rdfs:subClassOf botsh:Thing.

bosh:Control rdfs:subClassOf botsh:Thing.

bosh:Device rdfs:subClassOf botsh:Thing.

bosh:SecuritySystem rdfs:subClassOf botsh:Thing.

bosh:Building owl:equivalentClass botsh:Building.

bosh:BuildingEnvironment rdfs:subClassOf botsh:Zone.

bosh:Surface rdfs:subClassOf botsh:BuildingElement.

bosh:Flat rdfs:subClassOf botsh:Space.

bosh:Room rdfs:subClassOf botsh:Space.

bosh:Balcony rdfs:subClassOf botsh:Space.

bosh:contains owl:equivalentProperty botsh:containsThing.

bosh:belongsTo rdfs:subPropertyOf [owl:inverseOf botsh:hasSubElement].

bosh:hasActuator rdfs:subPropertyOf botsh:hasThing.

bosh:hasSensor rdfs:subPropertyOf botsh:hasThing.

Subject	Predicate	Object
bosh:Appliance	rdfs:subClassOf	botsh:Thing.
bosh:Control	rdfs:subClassOf	botsh:Thing.
bosh:Device	rdfs:subClassOf	botsh:Thing.
bosh:SecuritySystem	rdfs:subClassOf	botsh:Thing.
bosh:Building	owl:equivalentClass	botsh:Building.
bosh:BuildingEnvironment	rdfs:subClassOf	botsh:Zone.
bosh:Surface	rdfs:subClassOf	botsh:BuildingElement.
bosh:Flat	rdfs:subClassOf	botsh:Space.
bosh:Room	rdfs:subClassOf	botsh:Space.
bosh:Balcony	rdfs:subClassOf	botsh:Space.
bosh:contains	owl:equivalentProperty	botsh:containsThing.
bosh:belongsTo	rdfs:subPropertyOf	[owl:inverseOf botsh:hasSubElement].
bosh:hasActuator	rdfs:subPropertyOf	botsh:hasThing.
bosh:hasSensor	rdfs:subPropertyOf	botsh:hasThing.

5 Case study

To evaluate the sufficiency of the classes and object properties defined in BOTSH, we have considered an open BIM model of a Duplex house [20], as shown in Fig. 3. The total area of this duplex house is 490m² and it does not contain any information related to either the sensors or devices mounted on the building. To demonstrate the capability of the BOTSH we have imported the BIM model to the Revit, and sensor placement information is manually added. Further, the new BIM model is converted to BOT-compliant format using the Revit-BoT exporter plugin mentioned in [13], which now contains triples related to the building topology and sensor information. The sensor observations and other instances are modeled using RDFLIB [18] and the corresponding triples are added to the model. The T-Box and A-Box assertions of the building model are stored in GraphDB [8]. Figure 4 shows an overview of T-Box and A-Box representations of the duplex house designed based on the BOTSH and BOSH terminologies. The ontology is published at http://purl.org/botsh. The ontology’s documentation, alignments, and the working demo of the duplex house are published online¹.

Fig. 3

Duplex house model.

Fig. 4

Sample graph view of T-Box and A-Box triples using BOTSH and BOSH aligned ontology.

A user interface is designed using Python Django and it uses necessary APIs and connectors to fetch data and run queries on GraphDB’s SPARQL endpoint to address the competency questions. These competency questions and the corresponding results will help us to understand the completeness and sufficiency of the concepts defined in the ontology. All the SPARQL queries given below use two prefixes, and are executed on GraphDB.

botsh: < http://purl.org/botsh# >

and bosh: < http://purl.org/bosh# >

CQ1 - What are the different spaces at each storey present in the building? The below query returns the list of storeys, and spaces present within each storey.

select ? storey ? space where {

? storey a botsh:BuildingStorey.

? storey botsh:hasSpace ? space.

}

CQ2 - What are the tangible building elements and sub-elements present in the building? The below query returns the building elements and sub-elements such as walls that have windows/doors in the spaces within each storey.

select ? storey ? space ? element

? subelement where {

? storey a botsh:BuildingStorey.

? storey botsh:hasSpace ? space.

optional

{? space botsh:hasElement ? element.}

optional

{? element botsh:hasSubElement

? subelement.}}

CQ3 - What are the adjacent and intersecting elements within the building? The below query returns the adjacent and intersecting elements within the spaces if they are present.

select ? space ? adjelement ? intelement

where {

? space a botsh:Space.

optional

{? space botsh:adjacentElement

? adjelement.}

optional

{? space botsh:intersectingElement

? intelement.}}

CQ4 - What are the distinct types of sensors present within the building? The below query returns all the ’Things’ present in the building, where each ’Thing’ is a BOSH:SensingDevice.

select distinct ? thing

where {? thing a botsh:Thing.

? thing a bosh:SensingDevice.}

CQ5 - What are the room temperatures pertaining to a particular storey of the building? The below query returns all the temperature sensor readings along with the units, that are part of building elements within the spaces for a particular storey.

select ? storey ? space ? element

? thing ? value ? unit where {

? storey a botsh:BuildingStorey.

? storey botsh:hasSpace ? space.

? space botsh:hasElement ? element.

? element botsh:hasThing ? thing.

? thing a bosh:TemperatureSensor.

? thing bosh:measuresQuantity ? q.

? q bosh:hasValue ? value.

? q bosh:hasUnitOfMeasure ? u.

? u bosh:hasUnitValue ? unit.

filter(? storey= < http://purl.org/

botsh/p1#level_1xS3BCk291Uvhg >)}

6 Discussion

This research work focuses on integrating the BOTSH ontology with the most popular IoT ontologies making it interoperable and allowing the semantic application developers to answer a wide range of business questions. However, if the users want to align any other IoT ontology that is not covered in this work, it can still be carried out by using the BOTSH and BOSH [21] ontologies alignment as they cover a wide variety of concepts related to both the building domain and sensor domain. To demonstrate the same, we have aligned the BOTSH with BOSH ontology and developed a use case which is detailed in the case study section (section 5) of this paper. If the users want to add context related to energy systems, then alignments need to be defined to include the relevant concepts from energy domain ontologies. The case study duplex house considered here is an open BIM dataset and not related to any specific building or facility in the real world. The sole intention of the work is to prove that the approach mentioned in this paper is complete and sufficient enough to model the information related to any building and will help the developers to answer a variety of business questions.

7 Conclusion

In this paper, we proposed an interoperable building topology ontology for the smart home domain that can be easily aligned with other IoT domain ontologies. The alignments discussed in this paper are modeled as separate ontologies and found to be consistent upon reasoning. The proposed alignments mainly consist of equivalences (owl:equivalentClass) or subsumption (rdfs:subClassOf) on the class level. This paper presents the idea of integrating building topology knowledge with sensor observations and measurements to create cross-domain knowledge. The proposed approach can be used to develop cross-domain applications which can facilitate in solving complex business problems. In order to evaluate the proposed ontology, a simple case study was presented on the duplex house BIM model. This model was, in turn, used to address the competency questions framed by the domain experts using appropriate queries. The results obtained will act as a proof of concept to demonstrate the potential of the proposed BOTSH ontology. In future work, the proposed solution can be applied to other complex BIM models like a commercial building or a university. This work can be further extended by integrating the BOTSH with ontologies for telecommunication networks, energy, and machine learning. This will add further context to the message passing between IoT devices, energy systems, and ML models being used for decision intelligence.

Footnotes

References

Agarwal

Fernandez

D.G.

Elsaleh

Gyrard

Lanza

Sanchez

Georgantas

Issarny

, Unified iot ontology to enable interoperability and federation of testbeds, in: 2016 IEEE 3rd World Forum on Internet of Things (WF-IoT), IEEE 2016, pp. 70–75.

Bew

, Bew-richards bim maturity model, in: BuildingSMART Construct IT Autumn Members Meeting, Brighton, 2008.

Bonino

Corno

, Dogont-ontology modeling for intelligent domotic environments, in: International Semantic Web Conference, Springer. 2008, pp. 790–803.

Compton

Barnaghi

Bermudez

Garcia-Castro

Cox

Graybeal

Hauswirth

Henson

Herzog

, et al., TheSSN ontology of the w3c semantic sensor network incubator group, Journal of Web Semantics 17 (2012), 25–32.

Daniele

Hartog

F.D.

Roes

, Created in close interaction with the industry: the smart appliances reference (saref) ontology, in: International Workshop Formal Ontologies Meet Industries, Springer, 2015, pp. 100–112.

Dave

Buda

Nurminen

Främling

, A framework forintegrating BIM and IoT through open standards, Automation inConstruction 95 (2018), 35–45.

De Farias

T.M.

Roxin

Nicolle

, IfcWoD, semantically adapting IFC model relations into owl properties. arXiv preprint arXiv:1511.03897, 2015.

GraphDB

, Ontotext graphdb –graph database.https://ontotext.com/products/graphdb.

Gyrard

Bonnet

Boudaoud

Serrano

, Lov4iot: A second life for ontology-based domain knowledge to build semantic web of things applications, in: 2016 IEEE 4th International Conference on Future Internet of Things and Cloud (FiCloud), IEEE. 2016, pp. 254–261.

10.

Gyrard

Datta

S.K.

Bonnet

Boudaoud

, Crossdomain internet of things application development: M3 framework and evaluation, in: 2015 3rd International Conference on Future Internet of Things and Cloud, IEEE. 2015a, pp. 9–16.

11.

Gyrard

Serrano

Atemezing

G.A.

, Atemezing, Semantic web methodologies, best practices and ontology engineering applied to internet of things, in: 2015 IEEE 2nd World Forum on Internet of Things (WF-IoT), IEEE. 2015b, pp. 412–417.

12.

Hitzler

Gangemi

Janowicz

Krisnadhi

A.A.

Presutti

, Towards a simple but useful ontology design pattern representation language, in: WOP@ ISWC, 2017.

13.

Holten

Rasmussen

C.A.F.

Hviid

C.A.

KarlshøIntegrating

, Integrating building information modeling and sensor observations using semantic web, In 9th International Semantic Sensor Networks Workshop (2018), 1–9.

14.

ISO, 2013. 16739: 2013 industry foundation classes (ifc) for data sharing in the construction and facility management industries. International Organization for Standardization, 31.

15.

ISO, I., 2004. 10303-11: 2004 industrial automation systems and integration–product data representation and exchange–part 11: Description methods: The express language reference manual. ISO/TC 184.

16.

ISO 16739-1:2018 –Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries –Part 1: Data schema.

17.

Jiang

Shi

Wang

Pan

, Intelligent control ofbuilding fire protection system using digital twins and semantic webtechnologies, Automation in Construction 147 (2023), 104728.

18.

Krech

, Rdflib: A python library for working with rdf. Online https://github.com/RDFLib/rdflib (2006).

19.

Laadhar

Thomsen

Pedersen

T.B.

, domOS Common Ontology: Web of Things Discovery in Smart Buildings, In European Semantic Web Conference (pp. 95–100). Cham: Springer International Publishing (2022).

20.

MadsHolten, Duplex house model, A BOT-compliant version of CommonBuilding Information Model File: Duplex Apartment.https://github.com/MadsHolten/BOTDuplex-house..

21.

Muppavarapu

Ramesh

Gyrard

Noura

, Knowledgeextraction using semantic similarity of concepts from web of thingsknowledge bases, Data and Knowledge Engineering 135(2021), 101923.

22.

Pauwels

Roxin

, Simplebim: From full ifcowl graphs to simplified building graphs, in: eWork and eBusiness in Architecture, Engineering and Construction. CRC Press, 2017, pp. 11–18.

23.

Pauwels

Terkaj

, Express to owl for construction industry:Towards a recommendable and usable ifcowl ontology, Automationin Construction 63 (2016), 100–133.

24.

Poveda-Villalón

Garcıa-Castro

, Extending the saref ontology for building devices and topology, in: Proceedings of the 6th Linked Data in Architecture and Construction Workshop (LDAC 2018), Vol. CEUR-WS, 2018, pp. 16–23.

25.

Rasmussen

M.H.

Lefrançois

Schneider

G.F.

, Pauwels

, the building topology ontology of the w3c linked building datagroup, Semantic Web 12 (2021), 143–161.

26.

Reinisch

Kofler

Iglesias

Kastner

, Thinkhome energyefficiency in future smart homes, EURASIP Journal on EmbeddedSystems 2011 (2011), 1–18.

27.

Serrano

Gyrard

Tragos

Nguyen

, Fiestaiot project:federated interoperable semantic iot/cloud testbeds and applications, in: Companion Proceedings of the The Web Conference 2018 (2018), 425–426.