The W3C Linked Building Data on the Web community group is studying modeling approaches for the built environment using semantic web technologies. One outcome of this effort is a set of proposed ontologies together providing necessary terminology for the Architecture, Engineering, Construction and Operation (AECO) domains. In this paper, we demonstrate an integration between different datasets described using these ontologies in combination with the standard ontology for representing Sensors, Observations, Sampling, Actuation, and Sensor Networks (SSN/SOSA). In combination, the datasets cover the building's overall topology, 2D plan geometry, sensor and actuator locations and a log of their observations. We further suggest an integrated design approach that enables the designers to explicitly express the semantics of the sensors and actuators from the early stages of the project such that they can be carried on to construction and operation.
plan geometry described using Open Geospatial Consortium (OGC) Well Known Text (WKT) formatted literals (2) containment-relationships between building spaces and sensors/actuators and (3) actual observations from a building in operation. Dataset (2) was established in post-processing by mapping datasets (1) and (3) programmatically, but the ambition is that a semantic web-based BIM can enable the designers to describe the sensor and actuator semantics as part of the design material. Section 4 illustrates an integrated design workflow that supports this goal. Lastly we discuss the potential of a semantic web-based BIM for future smart buildings. 2
There exists numerous ontologies aimed at the AECO industry and ifcOWL1 by Pauwels
& Terkaj, 2016 [
BOT was proposed as a central AEC ontology that provides generic terms for
specifying any feature of interest in the context of its location in a building [
In the context of sensors and actuators bot:containsElement is a useful term to
describe the location in relation to the building in which they operate.
The sosa:hosts-relationship between a sosa:Platform and a sosa:Platform, sosa:Sensor,
sosa:Actuator or sosa:Sampler can be used for describing a similar relationship [
The case model, Navitas, is an educational facility in Aarhus, Denmark. It was completed in 2014, has a footprint of approximately 38,000 m2 above ground and the BIM model 1 http://www.buildingsmart-tech.org/ifcOWL/IFC4# 2 https://w3id.org/bot# 3 https://github.com/w3c-lbd-cg/product 4 https://github.com/w3c-lbd-cg/props has a total of 1392 spaces. A data dump from the Building Management System (BMS) provides a dataset consisting of observations from sensors and actuators for 301 of the building's spaces. The number of observations from the different spaces varies from 7294 to 13855 and are from the period April 18, 2017 - March 4, 2018. Table 1 is illustrating an example measurement.
Item Time Room status Regulator status Holding time Air quality Actual temp.
Setpoint temp. (calculated) Setpoint temp. (comfort) Setpoint temp. (standby) Hysteresis temp. (heat) Hysteresis temp. (ventilation) User temp. (maximum) User temp. (minimum) Radiator opening Ventilation flow Ventilation unit Minimum ventilation (comfort) Minimum ventilation (standby) Minimum ventilation (night) Boot ventilation Actual LUX Desired LUX Light 1 Light 2
Besides from the BMS data, the architectural model in the proprietary format of the Revit BIM authoring tool was available. The space numbers used in the Revit model and the BMS system were assumed to match.
The data was parsed to RDF to create a knowledge graph described with terminology from BOT, PROPS, CDT, SOSA and GEO (Fig. 1). 4
During the design of a building, the low voltage engineer must develop specifications for the BMS. The system must comply with the client's monitoring demands, the capabilities of the HVAC system and the control strategy defined by the indoor climate engineer. Further, it must be aligned with the architectural design. During the design stages these boundary conditions change occasionally, and having a clear up-to-date overview of the design is therefore crucial.
TBox ABox bot:Building bot:Storey bot:Space bot:Element sosa:Observation rdf:type rdf:type bot:hasStorey
rdf:type bot:hasSpace bot:containsZone bot:containsZone bot:containsElement boEtl:ecomnetantins rdf:type sosa:hosts sosa:observes rdf:type
rdf:type sosa:madeBySensor inst:bldg inst:lvl inst:sp inst:sensor inst:temp
inst:obs sosa:hasFeatureOfInterest sosa:hasResult props:spaceBoundary sosa:resultTime “22.4 Cel”^^cdt:temperature “POLYGON(0 0, 0 6500, 6500 4700, 0 4700, 0 0)”^^geo:wktLiteral “2017-11-11T23:47:44+01:00”^^xsd:dateTime
Establishing a Linked Building Data (LBD) compliant architectural model from the
proprietary BIM format was achieved by using the Revit-BOT-exporter5 described
in [
Units are described using the CDT Datatypes that leverage the Unified Code of
Units of Measures UCUM [
Listing 1: Subset of Architect's model # BUILDING TOPOLOGY (MODELLED BY ARCHITECT) inst:level_57d0ded0-4341-4dba-8f32-8dbdcaa9877c-0004879d a bot:Storey ;
bot:hasSpace inst:room_4b80808e-2f04-46a0-b84d-0ad6ee9d6b1b-0012a494 . inst:room_4b80808e-2f04-46a0-b84d-0ad6ee9d6b1b-0012a494 a bot:Space ; props:identityDataNumber "04.196" ; props:dimensionsArea "13.78 m2"^^cdt:area ; props:identityDataName "Gr. rum 04.196" ; props:spaceBoundary "POLYGON((-3319 14852, -8040 16954, -8226 17037, -8077 13710, -4529 12131, -3319 14852))"^^geo:wktLiteral .
Since the sensor data was already available (Sec. 3), establishing a SSN/SOSA compliant dataset with mappings to the architectural spaces was just a matter of writing a parser. The mapping table between Uniform Resource Identifiers (URI) of architectural spaces and their room number was created from a simple SPARQL query returning all bot:Space instances and their props:identityData-Number. Listing 2 shows an example of the output. In the example, the dog:TemperatureSensor is used to specify that it is a temperature sensor. An alternative solution to determining the kind of sensor could be to use a generic property inst:Temperature instead of the location-specific inst:room_04.196-Temp like illustrated in Fig. 1. 5 https://github.com/MadsHolten/revit-bot-exporter
When clicking a space, a line chart view of the sensor data is presented (Fig. 5). A drop-down list is populated with the dcterms:identifier of each sensor and when selecting from this list all the available observations are retrieved and visualized. A slider allows the user to restrict the time range of the observations. 5
The illustrated workflow shows how a BIM model can be enriched with sensors and actuators described with SSN/SOSA. In this work, the sensors and actuators were related to the building in which they operate using BOT semantics, but they could additionally be described in the context of the systems on which they operate. These opportunities bring a new incentive for the engineer to engage in BIM, which is often mistakenly comprehended as only 3D models. Establishing a semantic model of a BMS in the design stages and relating it to the features of interest on which they operate will further provide documentation which is crucial for the overall design overview.
Having the semantics of the BMS available in an open format when the building is put into operation allows for interpreting the observations of the sensors out of the box without the need for an integrated BMS solution. This interpretation separates the devices from the software applications and marks the first step in democratizing the market for BMS. It enables building owners to freely choose devices without being tied to one particular manufacturer for the full life cycle of the building and further makes it possible for a new industry to arise as universal, versatile software solutions can be developed.
Designing systems for building automation typically undergoes several stages. Initially, an Indoor Climate and Energy (ICE) engineer simulates the spaces - often only the critical ones regarding internal and solar heat gains, but in some cases also the whole building. When doing such simulations, a control strategy for heating, cooling, and ventilation is applied, and this should be reflected in the actual systems of the building. The capacity of the systems used in the simulation should match the ones described by the HVAC engineer, and the control strategy should be reflected in the description of the low voltage engineer. Installed systems in the building must further be programmed in order to comply with these specifications. The physical design of the spaces often change during the design stages, and this might influence the technical systems. It is therefore crucial that changes are carried on all the way from the ICE engineer to the contractor. Being able to specify the control strategy in an explicit format could significantly reduce the risks in this supply chain.
The implementation consisted of a 20M triples graph of which the observations were the primary component. Some of the more resource intensive queries like getting the maximum temperature of all spaces at a storey took up to 3.5 seconds, thereby devoting the user experience slightly (query performed on local Stardog triplestore served on a Lenovo P50 laptop with Intel Core i7-6820HQ 2.70 GHz CPU and 32 GB 2133 MHz DDR ram). This could be solved by doing some pre-processing on the server to infer hourly, daily, weekly, monthly and annual maximum temperatures explicitly. Most queries, however, like getting all observations (5000) from a server ordered by time can be accomplished in less than 500 ms. With this work, we present an integration between a building dataset described using proposed Linked Building Data (LBD) ontologies and an SSN/SOSA compliant dataset with sensor and actuator observations. Sensors and actuators are typically not part of the BIM model as it provides only little profit for the overall project. With the showcased integration between the BIM model and the observations, however, there is an incentive for the engineer to model sensors and actuators conceptually. Dedicated tools for assisting in modeling the sensors and actuators in their context of the building, the control strategies, thermal simulations etc. is a future research topic of interest.
The simple demo application serves as a proof of concept for integrating data from different sources in a web of data based viewer application and although the functionality is limited it showcases the potential.
Special thanks to the NIRAS ALECTIA Foundation and Innovation Fund Denmark for funding and to Michael K. Therkildsen, Aarhus University, for providing the Navitas dataset.