General Overview

Figure 1 presents an overview of the classes (only the top levels of the hierarchy) and the properties included in the SAREF4BLDG extension. As it can be observed the classes s4bldg:Building, s4bldg:BuildingSpace and s4bldg:PhysicalObject have been declared as subclasses of the class geo:SpatialThing in order to reuse the conceptualization for locations already proposed by the geo ontology. The modelling of building objects and building spaces has been adapted from the SAREF ontology; in this sense, the new classes deprecate the saref:BuildingObject and saref:BuildingSpace classes. In addition, a new class has been created, the s4bldg:Building class, to represent buildings.

The concepts s4bldg:Building and s4bldg:BuildingSpace are related to each other by means of the properties s4bldg:hasSpace and s4bldg:isSpaceOf; such properties are defined as inverse properties among them. These properties might also be used to declare that a s4bldg:BuildingSpace has other spaces belonging to the class s4bldg:BuildingSpace.

The relationship between building spaces and devices and building objects has also been transferred and generalized from the SAREF ontology. In this regard, a s4bldg:BuildingSpace can contain (represented by the property s4bldg:contains) individuals belonging to the class s4bldg:PhysicalObject. This generalization has been implemented in order to support building spaces to contain both building objects and devices. Accordingly, the classes s4bldg:BuildingObject and saref:Device are declared as subclasses of s4bldg:PhysicalObject.

Finally, the class representing building devices, namely s4bldg:BuildingDevice, is defined as a subclass of both saref:Device and s4bldg:BuildingObject. This class is a candidate for replacing the saref:BuildingRelated class.

General overview of the top levels of the SAREF4BLDG extension
Figure 1: General overview of the top levels of the SAREF4BLDG extension

Device Taxonomy

The main contribution of this extension is the representation of the devices defined in the IFC standard and their connections to SAREF. In this sense, a hierarchy consisting in 62 classes has been created taking into account the subset of the IFC hierarchy related to devices, as defined in the buildingSMART documentation (https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD1/HTML/annex/annex-c/common-use-definitions/index.htm), and adding several classes to clarify its categorization. The device classes are organized into 6 hierarchical levels that, for the sake of clarity, will be displayed in Figure 2 and Figure 3.

Figure 2 shows the first five levels of the hierarchy. Since transport elements (s4bldg:TransportElement) and vibration isolations (s4bldg:VibrationIsolation) are not classified under IFC elements, they belong directly to the class s4bldg:Device. The building elements are divided into s4bldg:ShadingDevice and s4bldg:DistributionDevice. In fact, most of the device types included in IFC belong to the distribution device category which contains the classes s4bldg:DistributionControlDevice and s4bldg:DistributionFlowDevice. The hierarchy under the s4bldg:DistributionFlowDevice is depicted in Figure 3.

As can be observed in Figure 2, some classes defined in SAREF4BLDG are also defined in the SAREF ontology. More precisely, this occurs in the classes s4bldg:Actuator and s4bldg:Sensor that extend the classes saref:Actuator and saref:Sensor, respectively. This decision has been taken because in the SAREF4BLDG extension these concepts refer to specific sensors and actuators that are placed in or related to buildings.

Device hierarchy in SAREF4BLDG (Part 1)
Figure 2: Device hierarchy in SAREF4BLDG (Part 1)
Device hierarchy in SAREF4BLDG (Part 2)
Figure 3: Device hierarchy in SAREF4BLDG (Part 2)

For each class extracted from the IFC specification, rdfs:label and rdfs:comment annotations have been generated including the identifier and an excerpt of the definition provided in the IFC online documentation. In addition, provenance information has been included using the PROV-O ontology (https://www.w3.org/TR/prov-o/), which has been published by the W3C as recommendation. In our case, the property prov:hadPrimarySource is used to link each class with:

(a) the online document in IFC describing the concept; and (b) the online document in IFC describing the properties defined for such concept.

It should be noted that properties are not specified in IFC for all the concepts but just for those representing particular devices. That is, there is no description of properties for the following general classes:

- s4bldg:EnergyConversionDevice, s4bldg:FlowController, s4bldg:FlowMovingDevice, s4bldg:FlowStorageDevice, s4bldg:FlowTerminal, and s4bldg:FlowTreatmentDevice.

In addition, the classes created in this extension have been related to the ifcOWL ontology (https://w3id.org/ifc/IFC4_ADD1) when possible. This relation has been declared by means of the annotation property rdfs:seeAlso from the SAREF4BLDG classes to the ifcOWL ones.

Measurements

Measurements are depicted in Figure 4. This model represents an n-ary pattern that allows users to relate measurements for different properties that are measured in different units. That is, the saref:Measurement class aims at describing a measurement of a physical quantity (using the saref:hasValue property) for a given saref:Property and according to a given saref:UnitOfMeasure.

This pattern enables to differentiate between properties and the measurements made for such properties and to store measurements for a concrete property in different units of measurement.

Furthermore, it allows adding a timestamp (using the saref:hasTimeStamp property) to identify when the measurement applies to the property, which can be used either for single measurements or for series of measurements (e.g. measurement streams).

It is worth noting that this modelling was included in SAREF2.0 after the SAREF4BLDG extension was developed. This pattern was first included in the SAREF4ENVI and SAREF4BLDG extensions and then proposed to be extrapolated to SAREF 2.0; this explains why the prefix used for this part of the model refers to SAREF instead of to SAREF4BLDG. However, as its origin is the SAREF4ENVI and SAREF4BLDG extensions requirements and modellings, the explanations are kept in the present document.

Measurement model
Figure 4: Measurement model

Device Properties

In the SAREF4BLDG extension 179 object properties (177 defined in SAREF4BLDG and 2 reused from the SAREF and geo ontologies) and 83 datatype properties (82 defined in SAREF4BLDG and 1 reused from the SAREF ontology) have been included. 172 out the 179 object properties and 81 out of the 83 datatype properties have been created according to the IFC specification of properties for devices.

For each of the created object and datatype properties, their documentation from IFC has been attached as documentation, including information about their use, such as the expected units of measurement.

The naming of the created object and datatype properties is consistent with the naming used in IFC. More precisely, the names of the properties in the ontology are the names assigned in IFC transformed into Camel Case starting with lowercase. For example, the property "IdealShaftPower" (extracted from https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD1/HTML/schema/ifchvacdomain/pset/pset_compressortypecommon.htm) has been transformed into the object property s4bldg:idealShaftPower.

Observations about S4BLDG

In the following, several observations about potential uses of the SAREF4BLDG ontology are listed.

It should be mentioned that the range of the s4bldg:shortCircuitVoltage object property is open to different representations of complex numbers. In this sense, when reusing the ontology users should define the class to be used to represent complex numbers or reuse an existing one.

In addition, the list of building devices should not be considered exhaustive, the current classification represents those devices described in IFC. It might be needed to extend the hierarchy in the case of new devices related to buildings are described in new versions of IFC or are needed for a particular use case.

Furthermore, it is expected that concrete use cases will either reuse the existing classes to represent their devices or specialize some of these classes to cover specific device types (e.g. by creating a hierarchy of boiler devices under the s4bldg:Boiler class).