The present document is a technical specification of SAREF4BLDG, an extension of the SAREF ontology [[1]](#[1]) that was created based on the Industry Foundation Classes (IFC) standard for building information. It should be noted that not the whole standard has been transformed since it exceeds the scope of this extension, which is limited to devices and appliances within the building domain.
The IFC specification is developed and maintained by buildingSMART International as its "Data standard" and, since its version IFC4, it is published as the ISO 16739 [[i.2]](#[i.2]) standard. SAREF4BLDG is meant to enable the (currently missing) interoperability among various actors (architects, engineers, consultants, contractors, and product component manufacturers, among others) and applications managing building information involved in the different phases of the building life cycle (Planning and Design, Construction, Commissioning, Operation, Retrofitting/Refurbishment/Reconfiguration, and Demolition/Recycling). By using SAREF4BLDG, smart appliances from manufacturers that support the IFC data model will easily communicate with each other. Towards this aim, SAREF4BLDG should be used to annotate (or generate) neutral device descriptions to be shared among various stakeholders.
# SAREF4BLDG ontology and semantics
SAREF4BLDG is an OWL-DL ontology that extends SAREF with 72 classes (67 defined in SAREF4BLDG and 5 reused from the SAREF and geo ontologies), 179 object properties (177 defined in SAREF4BLDG and 2 reused from the SAREF and geo ontologies), and 83 data type properties (82 defined in SAREF4BLDG and 1 reused from the SAREF ontology).
SAREF4BLDG focuses on extending the SAREF ontology to include those devices defined by the IFC version 4 - Addendum 1 [[i.3]](#[i.3]) and to enable the representation of such devices and other physical objects in building spaces.
## Introduction
The present document is a technical specification of SAREF4BLDG, an extension of the SAREF ontology [1] that was created based on the Industry Foundation Classes (IFC) standard for building information. It should be noted that not the whole standard has been transformed since it exceeds the scope of this extension, which is limited to devices and appliances within the building domain.
The IFC specification is developed and maintained by buildingSMART International as its "Data standard" and, since its version IFC4, it is published as the ISO 16739 [i.2] standard. SAREF4BLDG is meant to enable the (currently missing) interoperability among various actors (architects, engineers, consultants, contractors, and product component manufacturers, among others) and applications managing building information involved in the different phases of the building life cycle (Planning and Design, Construction, Commissioning, Operation, Retrofitting/Refurbishment/Reconfiguration, and Demolition/Recycling). By using SAREF4BLDG, smart appliances from manufacturers that support the IFC data model will easily communicate with each other. Towards this aim, SAREF4BLDG should be used to annotate (or generate) neutral device descriptions to be shared among various stakeholders.
SAREF4BLDG is an OWL-DL ontology that extends SAREF with 72 classes (67 defined in SAREF4EBLDG and 5 reused from the SAREF and geo ontologies), 179 object properties (177 defined in SAREF4EBLDG and 2 reused from the SAREF and geo ontologies), and 83 data type properties (82 defined in SAREF4EBLDG and 1 reused from the SAREF ontology).
SAREF4BLDG focuses on extending the SAREF ontology to include those devices defined by the IFC version 4 - Addendum 1 [i.3] and to enable the representation of such devices and other physical objects in building spaces.
The prefixes and namespaces used in SAREF4BLDG and along the present document are listed in Table 1.
During the development of this extension, the ontological requirements were directly extracted from the IFC specification. The reason for this is that no domain experts providing real uses cases were available, even though some conversations with experts in order to clarify doubts have taken place. However, the requirements have been aligned with the uses cases in the building sector that have been defined in the "W3C Linked Building Data Community Group" ([https://www.w3.org/community/lbd](https://www.w3.org/community/lbd/)/) and are publicly accessible ([https://www.w3.org/community/lbd/wiki/Seed_Use_Cases](https://www.w3.org/community/lbd/wiki/Seed_Use_Cases)).
The first step for developing this SAREF extension has been to extract ontological requirements taking the IFC specification [i.3] as a starting point. In order to select the subset of IFC that is relevant in the context of a SAREF extension, the boundaries of the concepts that have been included are delimited by the term "device", that is, every entity that can be classified as a device has been taken into account. The detailed process for extracting the requirements is provided in the technical report [i.1]. This step was crucial due to the fact that IFC is organized according to different architectural process views and it does not contain a clear classification of devices as they are distributed in different branches of a broader classification.
Once the concepts to be represented, their descriptions and their properties were extracted from IFC, a non-ontological resource reengineering process [i.4] was carried out. This process consisted in the transformation of the non-ontological resource, in this case the IFC documentation, into an ontological resource following a TBox transformation approach. That is, the original resource was transformed in the terminological box (TBox) of a knowledge base (i.e. the ontology).
IFC defines the concept "Element"; however, this concept is too broad to be reused since it refers to devices and any other element than can appear in a building. This issue also appears in other levels of the hierarchy; for example, IFC defines the concept "Distribution element" which contains devices but also many other elements that are not devices. In this case the class `s4bldg:DistributionDevice` has been created in order to restrict the use to devices. This decision has been taken for the following classes: `s4bldg:BuildingDevice`, `s4bldg:DistributionDevice`, `s4bldg:DistributionControlDevice`, and `s4bldg:DistributionFlowDevice`.
For each class, its associated properties described in IFC have been transformed into object or datatype properties. It is worth noting that not all the properties defined in the IFC standard have been transformed because, for example, in some cases the definition of the properties assigned to the classes included only the property identifier (which in RDF can be considered to be the URI of the given instance) and its status (which indicates whether the element previously existed or is a new item in a retrofitting project). An example can be seen in the concept "Controller" ([https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD1/HTML/schema/ifcbuildingcontrolsdomain/pset/pset_controllertypecommon.htm](https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD1/HTML/schema/ifcbuildingcontrolsdomain/pset/pset_controllertypecommon.htm)).
Furthermore, during the process, the datatypes associated in IFC to each property have been identified and analysed in order to transform them into OWL. That is, not all the properties defined in IFC have been transformed in the same way. Table A.1 details the decisions taken for each datatype appearing in IFC properties.
<tabledata-docx-preferred-width="6.33cm 9.89cm">
<caption>Table A.1: Property transformations from IFC to OWL</caption>
<tr>
<th>IFC datatype </th>
<th>Transformation to OWL</th>
</tr>
<tr>
<td>logical</td>
<td>Transform to datatype property with range xsd:boolean</td>
</tr>
<tr>
<td>boolean</td>
<td>Transform to datatype property with range xsd:boolean</td>
</tr>
<tr>
<td>natural</td>
<td>Transform to datatype property with range xsd:nonNegativeInteger</td>
</tr>
<tr>
<td>integer</td>
<td>Transform to datatype property with range xsd:integer</td>
</tr>
<tr>
<td>string</td>
<td>Transform to datatype property with range xsd:string</td>
</tr>
<tr>
<td>{string}</td>
<td>Transform to datatype property with range xsd:string</td>
</tr>
<tr>
<td><p>Real</p>
<p>(associated to a P_SINGLEVALUE)</p></td>
<td>Transform to object property that would be used to link to an instance of saref:Measurement</td>
</tr>
<tr>
<td><p>real </p>
<p>(associated to a P_BOUNDEDVALUE)</p></td>
<td>Transform to two object properties (one for maximum value and another for minimum value) that would be used to link to an instance of saref:Measurement</td>
</tr>
<tr>
<td>ratio</td>
<td>Transform to object property that would be used to link to an instance of saref:Measurement</td>
</tr>
<tr>
<td>real ratio</td>
<td>Transform to object property that would be used to link to an instance of saref:Measurement</td>
</tr>
<tr>
<td>normalized ratio</td>
<td>Transform to object property that would be used to link to an instance of saref:Measurement</td>
</tr>
<tr>
<td>positive ratio</td>
<td>Transform to object property that would be used to link to an instance of saref:Measurement</td>
</tr>
<tr>
<td>complex</td>
<td>Transform to object property with open range</td>
</tr>
</table>
Finally, local restrictions for each class have been added indicating the expected use of each of the properties that can be applied to a class.
As mentioned, SAREF concepts have been extended when they needed to be specialized and properties from SAREF have been reused. In addition, other ontologies have been reused following the SAREF practices. More precisely the following classes have been extended:
*`saref:Device with s4bldg:BuildingDevice, s4bldg:TransportElement and s4bldg:VibrationIsolation`
*`saref:Actuator with s4bldg:Actuator`
*`saref:Sensor with s4bldg:Sensor`
*`geo:SpatialThing with s4bldg:PhysicalObject`
The following classes and properties have also been directly reused:
*`saref:UnitOfMeasure`
*`saref:isMeasuredIn`
*`saref:hasValue`
*`geo:location`
As already commented some entities firstly defined in the SAREF4ENVI and SAREF4BLDG extensions have been included into SAREF2.0, and now are directly reused, namely:
*`saref:Measurement`
*`saref:makesMeasurement`
*`saref:measuresProperty`
*`saref:relatesToProperty`
# Bibliography
* ETSI TS 103 267: "SmartM2M; Smart Applications; Communication Framework".
* ETSI TS 102 689: "Machine-to-Machine communications (M2M); M2M Service Requirements".
* ETSI TS 118 101: "oneM2M, Functional Architecture (oneM2M TS-0001)".
* ETSI TS 118 102: "oneM2M; Requirements (oneM2M TS-0002)".
<p><ahref="#Figure_1">Figure 1</a> 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 <ahref="#s4bldg:Building">s4bldg:Building</a>, <ahref="#s4bldg:BuildingSpace">s4bldg:BuildingSpace</a> and <ahref="#s4bldg:PhysicalObject">s4bldg:PhysicalObject</a> 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 <ahref="https://saref.etsi.org/core/BuildingObject">saref:BuildingObject</a> and <ahref="https://saref.etsi.org/core/BuildingSpace">saref:BuildingSpace</a> classes. In addition, a new class has been created, the <ahref="#s4bldg:Building">s4bldg:Building</a> class, to represent buildings.</p>
<p>The concepts <ahref="#s4bldg:Building">s4bldg:Building</a> and <ahref="#s4bldg:BuildingSpace">s4bldg:BuildingSpace</a> are related to each other by means of the properties <ahref="#s4bldg:hasSpace">s4bldg:hasSpace</a> and <ahref="#s4bldg:isSpaceOf">s4bldg:isSpaceOf</a>; such properties are defined as inverse properties among them. These properties might also be used to declare that a <ahref="#s4bldg:BuildingSpace">s4bldg:BuildingSpace</a> has other spaces belonging to the class <ahref="#s4bldg:BuildingSpace">s4bldg:BuildingSpace</a>.</p>
<p>The relationship between building spaces and devices and building objects has also been transferred and generalized from the SAREF ontology. In this regard, a <ahref="#s4bldg:BuildingSpace">s4bldg:BuildingSpace</a> can contain (represented by the property <ahref="#s4bldg:contains">s4bldg:contains</a>) individuals belonging to the class <ahref="#s4bldg:PhysicalObject">s4bldg:PhysicalObject</a>. This generalization has been implemented in order to support building spaces to contain both building objects and devices. Accordingly, the classes <ahref="#s4bldg:BuildingObject">s4bldg:BuildingObject</a> and <ahref="https://saref.etsi.org/core/Device">saref:Device</a> are declared as subclasses of <ahref="#s4bldg:PhysicalObject">s4bldg:PhysicalObject</a>.</p>
<p>Finally, the class representing building devices, namely <ahref="#s4bldg:BuildingDevice">s4bldg:BuildingDevice</a>, is defined as a subclass of both <ahref="https://saref.etsi.org/core/Device">saref:Device</a> and <ahref="#s4bldg:BuildingObject">s4bldg:BuildingObject</a>. This class is a candidate for replacing the <ahref="https://saref.etsi.org/core/BuildingRelated">saref:BuildingRelated</a> class.</p>
<figure>
<ahref="diagrams/Overview.png"><imgsrc="diagrams/Overview.png"alt="General overview of the top levels of the SAREF4BLDG extension"/></a>
<figcaptionid="Figure_1">Figure 1: General overview of the top levels of the SAREF4BLDG extension</figcaption>
</figure>
<h3>Device Taxonomy</h3>
<p>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 (<ahref="https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD1/HTML/annex/annex-c/common-use-definitions/index.htm">https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD1/HTML/annex/annex-c/common-use-definitions/index.htm</a>), 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 <ahref="#Figure_2">Figure 2</a> and <ahref="#Figure_3">Figure 3</a>. </p>
<p><ahref="#Figure_2">Figure 2</a> shows the first five levels of the hierarchy. Since transport elements (<ahref="#s4bldg:TransportElement">s4bldg:TransportElement</a>) and vibration isolations (<ahref="#s4bldg:VibrationIsolation">s4bldg:VibrationIsolation</a>) are not classified under IFC elements, they belong directly to the class <ahref="#s4bldg:Device">s4bldg:Device</a>. The building elements are divided into <ahref="#s4bldg:ShadingDevice">s4bldg:ShadingDevice</a> and <ahref="#s4bldg:DistributionDevice">s4bldg:DistributionDevice</a>. In fact, most of the device types included in IFC belong to the distribution device category which contains the classes <ahref="#s4bldg:DistributionControlDevice">s4bldg:DistributionControlDevice</a> and <ahref="#s4bldg:DistributionFlowDevice">s4bldg:DistributionFlowDevice</a>. The hierarchy under the <ahref="#s4bldg:DistributionFlowDevice">s4bldg:DistributionFlowDevice</a> is depicted in <ahref="#Figure_3">Figure 3</a>.</p>
<p>As can be observed in <ahref="#Figure_2">Figure 2</a>, some classes defined in SAREF4BLDG are also defined in the SAREF ontology. More precisely, this occurs in the classes <ahref="#s4bldg:Actuator">s4bldg:Actuator</a> and <ahref="#s4bldg:Sensor">s4bldg:Sensor</a> that extend the classes <ahref="https://saref.etsi.org/core/Actuator">saref:Actuator</a> and <ahref="https://saref.etsi.org/core/Sensor">saref:Sensor</a>, 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. </p>
<figure>
<ahref="diagrams/Hierarchy1.png"><imgsrc="diagrams/Hierarchy1.png"alt="Device hierarchy in SAREF4BLDG (Part 1)"/></a>
<figcaptionid="Figure_2">Figure 2: Device hierarchy in SAREF4BLDG (Part 1)</figcaption>
</figure>
<figure>
<ahref="diagrams/Hierarchy2.png"><imgsrc="diagrams/Hierarchy2.png"alt="Device hierarchy in SAREF4BLDG (Part 2)"/></a>
<figcaptionid="Figure_3">Figure 3: Device hierarchy in SAREF4BLDG (Part 2)</figcaption>
</figure>
<p>For each class extracted from the IFC specification, <ahref="https://www.w3.org/TR/rdf-schema/#ch_label">rdfs:label</a> and <ahref="https://www.w3.org/TR/rdf-schema/#ch_comment">rdfs:comment</a> 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 (<ahref="https://www.w3.org/TR/prov-o/">https://www.w3.org/TR/prov-o/</a>), which has been published by the W3C as recommendation. In our case, the property prov:hadPrimarySource is used to link each class with:</p>
(a) the online document in IFC describing the concept; and
(b) the online document in IFC describing the properties defined for such concept.
<p>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: </p>
- <ahref="#s4bldg:EnergyConversionDevice">s4bldg:EnergyConversionDevice</a>, <ahref="#s4bldg:FlowController">s4bldg:FlowController</a>, <ahref="#s4bldg:FlowMovingDevice">s4bldg:FlowMovingDevice</a>, <ahref="#s4bldg:FlowStorageDevice">s4bldg:FlowStorageDevice</a>, <ahref="#s4bldg:FlowTerminal">s4bldg:FlowTerminal</a>, and <ahref="#s4bldg:FlowTreatmentDevice">s4bldg:FlowTreatmentDevice</a>.
<p>In addition, the classes created in this extension have been related to the ifcOWL ontology (<ahref="https://w3id.org/ifc/IFC4_ADD1">https://w3id.org/ifc/IFC4_ADD1</a>) when possible. This relation has been declared by means of the annotation property <ahref="https://www.w3.org/TR/rdf-schema/#ch_seealso">rdfs:seeAlso</a> from the SAREF4BLDG classes to the ifcOWL ones.</p>
<h3>Measurements</h3>
<p>Measurements are depicted in <ahref="#Figure_4">Figure 4</a>. 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 <ahref="https://saref.etsi.org/core/Measurement">saref:Measurement</a> class aims at describing a measurement of a physical quantity (using the <ahref="https://saref.etsi.org/core/hasValue">saref:hasValue</a> property) for a given <ahref="https://saref.etsi.org/core/Property">saref:Property</a> and according to a given <ahref="https://saref.etsi.org/core/UnitOfMeasure">saref:UnitOfMeasure</a>. </p>
<p>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.</p>
<p>Furthermore, it allows adding a timestamp (using the <ahref="https://saref.etsi.org/core/hasTimeStamp">saref:hasTimeStamp</a> 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).</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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 <ahref="https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD1/HTML/schema/ifchvacdomain/pset/pset_compressortypecommon.htm">https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD1/HTML/schema/ifchvacdomain/pset/pset_compressortypecommon.htm</a>) has been transformed into the object property <ahref="#s4bldg:idealShaftPower">s4bldg:idealShaftPower</a>.</p>
<h3>Observations about S4BLDG</h3>
<p>In the following, several observations about potential uses of the SAREF4BLDG ontology are listed.</p>
<p>It should be mentioned that the range of the <ahref="#s4bldg:shortCircuitVoltage">s4bldg:shortCircuitVoltage</a> 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.</p>
<p>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.</p>
<p>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 <ahref="#s4bldg:Boiler">s4bldg:Boiler</a> class).</p>
