doc generated from pipeline

target

scripts

ts

documentation/ts_*

For the purposes of the present document, the following abbreviations apply:

* HTML: Hyper Text Markup Language

* IFC: Industry Foundation Classes

* ISO: International Standardization Organization

* OWL: Web Ontology Language

* OWL-DL: Web Ontology Language Description Logic

* PROV-O: The PROV Ontology 

* RDF: Resource Description Format

* SAREF: Smart Applications REFerence ontology

* TR: Technical Report

* TS: Technical Specification

* URI: Uniform Resource Identifier

* W3C®: World Wide Web Consortium

 No newline at end of file

<div class="alert-warning">NOTE: The text in this section is extracted from ETSI TS 103 410-3 (V2.1.1) <a href="#[0]">[0]</a>, and therefore falls inside the <a href="https://www.etsi.org/intellectual-property-rights">ETSI IPR Policy</a></div>

[The technical specification ETSI TS 103 410-3](#[0]) 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. 

# SAREF4BLDG ontology and semantics

[The technical specification ETSI TS 103 410-3](#[0]) is a major revision of SAREF4BLDG ontology extension, developed in the context of the STF 653 (<a href="https://portal.etsi.org/xtfs/">https://portal.etsi.org/xtfs/#/xTF/653/</a>), using updated reference ontology patterns specified in ETSI TS 103 548 [[2]](#[2]) to solve the harmonization needs identified in ETSI TR 103 781 [[i.6]](#[i.6]), with updated development framework and tools defined in ETSI TS 103 673 [[i.7]](#[i.7]).

ETSI TS 103 410-3 [[i.5]](#[i.5]) has been developed in the context of the STF 513, an ETSI specialists task force that was established with the goal to deliver the SAREF Core V2 and to extend SAREF id for the domains of Environment, Buildings and Energy (see <a href="https://portal.etsi.org/STF/STFs/STF-HomePages/STF513">https://portal.etsi.org/STF/STFs/STF-HomePages/STF513</a>). The IFC specification is developed and maintained by buildingSMART International as its "Data standard" and, since its version IFC4, it is published as ISO 16739 [[i.2]](#[i.2]). 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. 

## 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 present document is a major revision of SAREF4BLDG ontology extension, developed in the context of the STF 653 ([https://portal.etsi.org/xtfs/#/xTF/653](https://portal.etsi.org/xtfs/#/xTF/653/)/), using updated reference ontology patterns specified in ETSI TS 103 548 [2] to solve the harmonization needs identified in ETSI TR 103 781 [i.6], with updated development framework and tools defined in ETSI TS 103 673 [i.7].

ETSI TS 103 410-3 [i.5] has been developed in the context of the STF 513, an ETSI specialists task force that was established with the goal to deliver the SAREF Core V2 and to extend SAREF id for the domains of Environment, Buildings and Energy (see [https://portal.etsi.org/STF/STFs/STF-HomePages/STF513](https://portal.etsi.org/STF/STFs/STF-HomePages/STF513)). The IFC specification is developed and maintained by buildingSMART International as its "Data standard" and, since its version IFC4, it is published as ISO 16739 [i.2]. 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), and 77 data type properties (76 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]](#[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 technical specification ETSI TS 103 410-3](#[0]) are listed in [the Namespace Declarations section](#namespacedeclarations).

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.

{{table_1}}

# Approach

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 ETSI TR 103 411 [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).

For each concept selected from the IFC documentation a class together with its additional information was created, as shown in Listing 1. Each class was then classified under the reused class `saref:Device` and according to the hierarchy proposed in IFC [i.3] ([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)). 

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.

<table data-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:hasValue`

As already commented some entities firstly defined in the SAREF4ENVI and SAREF4BLDG extensions have been included into SAREF3.1.1, and now are directly reused, namely:

* `saref:Observation`

* `saref:makesObservation`

* `saref:hasProperty`

* `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)".

# Change history

<table data-docx-preferred-width="2.76cm 1.43cm 12.69cm">

  <tr>

    <th>Date</th>

    <th>Version</th>

    <th>Information about changes</th>

  </tr>

  <tr>

    <td>10.12.2023</td>

    <td style="text-align:center">V1.1.3</td>

    <td>Mauro: published version V1.1.2 taken as basis and change version to V1.1.3</td>

  </tr>

  <tr>

    <td>16.12.2023</td>

    <td style="text-align:center">V2.0.1</td>

    <td>Joachim: Version number set to V2.0.1, Annex Change History added</td>

  </tr>

  <tr>

    <td>01.10.2024</td>

    <td style="text-align:center">V2.1.1</td>

    <td>Technical Officer review before publication pre-processing after TB approval</td>

  </tr>

</table>