doc generated from pipeline

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

* DUL: DOLCE+DnS Ultralite

* HVAC: Heating, Ventilation and Air Conditioning

* OM: Ontology of units of Measure

* oneM2M: oneM2M Partnership Project

* OWL: Web Ontology Language

* SAREF: Smart Applications REFerence ontology

* SAREF4BLDG: SAREF for the Building domain

* SAREF4ENER: SAREF for the Energy domain

* SAREF4ENVI: SAREF for the Environment domain

* SAREF4CITY : SAREF for the Smart Cities domain

* SAREF4INMA : SAREF for the Industry and Manufacturing domain

* SAREF4AGRI : SAREF for the Smart Agriculture and Food Chain domain

* SEAS: Smart Energy Aware Systems

* SEP2: Smart Energy Profile 2.0

* SSN: Semantic Sensor Network

* STF: Specialist Task Force

* SUMO: Suggested Upper Merged Ontology

* TNO: Netherlands Organisation for Applied Scientific Research

* UPnP<sup>®</sup>: Universal Plug and Play

* W3C<sup>®</sup>: World Wide Web Consortium

* WGS84: World Geodetic System 1984

 No newline at end of file

# Smart Applications Reference Ontology and Semantics

## Introduction and Overview

The Smart Applications REFerence ontology (SAREF) is intended to enable interoperability between solutions from different providers and among various activity sectors in the Internet of Things (IoT), thus contributing to the development of the global digital market.

SAREF shall use the SAREF Communication framework as defined in [[5]](#[5]) (ETSI TS 103 267: "SmartM2M; Smart Appliances; Communication Framework”).

 No newline at end of file

SAREF shall use the SAREF Communication framework as defined in ETSI TS 103 267 [5].

The SAREF initiative started with a study on "Available Semantics Assets for the Interoperability of Smart Appliances: Mapping into a Common Ontology as a M2M Application Layer Semantics", which was tendered by the European Commission and was carried out by TNO. 

Such study acknowledged that the energy utilization of Smart Appliances can be reduced if they are managed and controlled on a system level. The system needs standardized interfaces to ensure interoperability. Many of the required standards already exist, but a common architecture does not, resulting in a market which is too fragmented and powerless. Therefore, a reference ontology of consensus was designed to cover the needs of all appliances relevant for energy efficiency.

The study consisted of three tasks:

* **Task 1**: Take stock of existing semantic assets and use case assets.

* **Task 2**: Perform a translation exercise of each model (or use case) to a common ontology language and a mapping or matching exercise between all the models.

* **Task 3**: Propose a reference ontology and document the ontology into the ETSI M2M architecture.

!!! alert alert-info "NOTE:"

    The ETSI M2M architecture has evolved into the oneM2M architecture, therefore the latter one is the one to be considered.

About 50 different semantic assets (i.e. standards, protocols, data models, ontologies) had been identified that describe various properties of Smart Appliances in residential environments. After translating half of these semantic assets into Web Ontology Language (OWL) ([https://sites.google.com/site/smartappliancesproject/ontologies](https://sites.google.com/site/smartappliancesproject/ontologies)), 20 recurring concepts were used as initial building blocks for creating the Smart Applications REFerence ontology (SAREF). For SAREF in OWL, see [2]. The concepts were mapped from the semantic assets to SAREF to allow for translations between different semantic assets. 

SAREF explicitly specifies the recurring core concepts in the Smart Applications domain, the main relationships between these concepts, and axioms to constrain the usage of these concepts and relationships. SAREF is based on the fundamental principles of **reuse** **and alignment** of concepts and relationships that are defined in existing assets, **modularity** to allow separation and recombination of different parts of the ontology depending on specific needs, **extensibility** to allow further growth of the ontology, and **maintainability** to facilitate the process of identifying and correcting defects, accommodate new requirements, and cope with changes in (parts of) SAREF.

Mappings to other concepts used by different semantic assets allow translation from the reference ontology to specific assets, reducing the effort of translating from one asset to another, since the reference ontology requires one set of mappings to each asset, instead of a dedicated set of mappings for each pair of assets. Figure 1 shows the role of the reference ontology in the mapping by means of sample assets. The mappings of SAREF to various assets are available in [3].

!!! alert alert-info "NOTE:"

    UPnP<sup>®</sup> and Z-Wave<sup>®</sup> are examples of suitable products available commercially. This information is given for the convenience of users of the present document and does not constitute an endorsement by ETSI of these products.

<figure>

    <img data-docx-width="14.42cm" src="diagrams/image2.png" alt="The role of SAREF in the mapping among different assets"/>

    <figcaption>Figure 1: The role of SAREF in the mapping among different assets</figcaption>

</figure>

SAREF is based on the following main concepts (in alphabetical order):

* Command (e.g. OnCommand, OffCommand, PauseCommand, GetCommand, NotifyCommand, SetLevelCommand).

* Commodity (e.g. Electricity, Gas, Water).

* Device (e.g. Switch, Meter, Sensor).

* FeatureOfInterest.

* Function (i.e. Actuating Function, Event Function, Metering Function, Sensing Function).

* Measurement.

* Profile.

* Property (e.g. Energy, Humidity, Light, Motion, Occupancy, Power, Pressure, Price, Smoke, Temperature, Time).

* Service (e.g. Switch On Service).

* State (e.g. On Off State, Open Close State, Start Stop State, Multi Level State).

* Task (e.g. Cleaning, Comfort, Lighting, Safety, Entertainment, Energy Efficiency).

* UnitOfMeasure (e.g. Currency, Energy Unit, Power Unit, Temperature Unit).

## Principles

The Smart Applications REFerence ontology (SAREF) is conceived as a shared model of consensus that facilitates the matching of existing semantic assets for building smart applications, reducing the effort of translating from one asset to another, since SAREF requires one set of mappings to each asset, instead of a dedicated set of mappings for each pair of assets.

Different semantic assets share some recurring, core concepts, but they often use different terminologies and adopt different data models to represent these concepts. Using SAREF, different assets can keep using their own terminology and data models, but still can relate to each other through their common semantics. In other words, SAREF enables semantic interoperability in smart applications through its shared, core concepts.

SAREF explicitly specifies recurring core concepts in smart applications, the main relationships between these concepts, and axioms to constrain the usage of these concepts and relationships. SAREF has been created based on the following fundamental principles:

* **Reuse** **and alignment** of concepts and relationships that are defined in existing assets. Since a large amount of work was already being done in the smart appliances and in the Internet of Things domains, nothing has been re-invented, but harmonized and aligned what was already there. SAREF is based on the core concepts that were identified as especially relevant to describe the existing semantic assets for smart applications and is aligned to the main classes and properties of the oneM2M base ontology [4] and of the W3C<sup>®</sup> Semantic Sensor Network (SSN) ontology.

!!! indent-1 ""

      SAREF reuses the following resources: 

    * based on 20 domain-specific ontologies, e.g. W3C<sup>®</sup> SSN ontology, Echonet, EnOcean<sup>®</sup>, SEP2, UPnP<sup>®</sup> ([https://sites.google.com/site/smartappliancesproject/ontologies](https://sites.google.com/site/smartappliancesproject/ontologies));

    * reuse of W3C<sup>®</sup> Time ontology;

    * reuse W3C<sup>®</sup> WGS84 geo positioning vocabulary (through the SAREF4BLDG extension in ETSI TS 103 410-3 [i.4]);

    * reuse of Ontology of units of Measure (OM) individuals.

* **Modularity** to allow separation and recombination of different parts of the ontology depending on specific needs. SAREF provides building blocks that can be combined to accommodate different needs and points of view. The starting point is the concept of **device**, which is actually common to all the semantic assets considered in the study, although some assets may refer to it with different names, such as **resource** or **product**, but mappings for that are provided in [3]. For example, a "switch" is a device. A device is always designed to perform one or more **functions**, therefore, SAREF offers a list of basic functions that can be eventually combined in order to have more complex functions in a single device. For example, the switch mentioned above offers an actuating function of type "on/off function". Each function has some associated **commands**, which can also be selected as building blocks from a list. For example, the "on/off function" is associated with the commands "on", "off" and "toggle". Depending on the function(s) it performs, a device can be found in some corresponding **states** that are also listed as building blocks, so that it is easy and intuitive to combine devices, functions and states. The switch considered in our example can be found in one of the two states "on" or "off". SAREF also provides a list of **properties** that can be used to further specialize the functioning of a device. For example, a "light switch" specializes the more general "switch" described above for the purpose of controlling the "light" property. An extensive explanation of SAREF, describing its classes and relationships, is presented in the next clause.

* **Extensibility** to allow further growth of the ontology. Different stakeholders can specialize the SAREF concepts according to their needs and points of view, add more specific relationships and axioms to refine the general (common) semantics expressed in the reference ontology, and create new concepts, as long as they explicitly link these extensions to at least one existing concept and/or relationship in SAREF. The minimum requirement is that any extension/specialization shall comply with SAREF. Examples of extensions of SAREF in different domains are SAREF4ENER (energy domain) [i.2], SAREF4ENVI (environment domain) [i.3] and SAREF4BLDG (building domain) [i.4]. 

* **Maintainability** to facilitate the process of identifying and correcting defects, accommodate new requirements, and cope with changes in (parts of) SAREF. According to the extensibility criterion mentioned above, a new module/ontology can be created to further extend/specialize concepts of SAREF. The party that creates the extension should also be responsible for the maintenance of this extension and its evolution over time. For the strategy proposed in ETSI to extend, maintain and evolve SAREF (and its extensions), see ETSI TR 103 411 [i.1].

The prefixes and namespaces used in SAREF and in the present document are listed in Table 1.

{{table_1}}

# Bibliography

* ETSI TR 101 584: "Machine-to-Machine communications (M2M); Study on Semantic support for M2M Data".

# Change History 

<table data-docx-preferred-width="2.99cm 2.50cm 11.49cm">

  <tr>

    <th>Date</th>

    <th>Version </th>

    <th>Information about changes (see note)</th>

  </tr>

  <tr>

    <td style="text-align:center">March 2017</td>

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

    <td><ul>

<li data-docx-pstyle="TB1">The classes and properties related to how to represent devices in building spaces (such as the <code>saref:BuildingSpace</code> class, <code>saref:BuildingObject</code> class and <code>saref:isLocatedIn</code> property) have been removed from SAREF and incorporated into the SAREF4BLDG extension related to buildings [i.4], including the reuse of the W3C<sup>®</sup> WGS84 geo positioning vocabulary.</li>

<li data-docx-pstyle="TB1">The <code>saref:DeviceCategory</code> and <code>saref:FunctionCategory</code> classes have been removed. Instead, the hierarchy of device categories has been implemented directly as subclasses of the <code>saref:Device</code> class. </li>

<li data-docx-pstyle="TB1">The information specific for energy efficiency has been moved to the SAREF4ENER extension. For example, the <code>saref:Profile</code> class has been redefined to accommodate only the properties that are general enough for any type of profile, not only for energy and power. Details on how to specifically model a power profile can be found in the SAREF4ENER extension [i.2].</li>

<li data-docx-pstyle="TB1">The subclasses of the <code>saref:Energy</code> class have been removed (i.e. Average Energy, Maximum Energy, Minimum Energy, Total Energy, HVAC Energy, Hot Water Energy and Lighting Energy).</li>

<li data-docx-pstyle="TB1">The <code>saref:Property</code> class has been split into two classes (<code>saref:Property</code> and <code>saref:Measurement</code>), as it is done in the SAREF4ENVI extension in [i.3], in order to properly accommodate the distinction between the concept of property (an observable quality of something) and the concept of measurement (a concrete value observed for a property).</li>

<li data-docx-pstyle="TB1">Too restrictive cardinality restrictions have been revised, sometimes making them optional rather than mandatory (better to make properties mandatory in the extensions that specialize SAREF for a specific purpose, rather than restricting SAREF, whose purpose is more general). For example, definitions of units of measurement using an enumeration (<code>owl:oneOf</code>) were too restrictive because they did not allow using other units than those enumerated. Therefore, the individuals of each class are still there, but the <code>owl:oneOf</code> enumeration has been removed. </li>

<li data-docx-pstyle="TB1">The <code>saref:UnitOfMeasure</code> subclasses use individuals from the OM ontology for unit of measures (<a href="http://www.wurvoc.org/vocabularies/om-1.6/">http://www.wurvoc.org/vocabularies/om-1.6</a>/), but this is not the only solution. It has been clarified in the comments that the OM ontology is an example, but other ontologies can be used.</li>

<li data-docx-pstyle="TB1">The global restrictions (<code>rdfs:domain</code> and <code>rdfs:range</code>) in object properties have been completely removed not to hinder interoperability. Object properties are now only restricted locally in the classes. </li>

<li data-docx-pstyle="TB1">The subclasses of <code>saref:Task</code> have been transformed in individuals.</li>

<li data-docx-pstyle="TB1">The saref:hasTask property has been removed from the saref:Profile class to resolve an ambiguity with the saref:Task class.</li>

</ul></td>

  </tr>

  <tr>

    <td style="text-align:center">January 2020</td>

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

    <td><ul>

<li data-docx-pstyle="TB1">Added the <code>saref:FeatureOfInterest</code> class and the properties used to relate it to <code>saref:Measurement</code> (<code>saref:hasMeasurement</code> and <code>saref:isMeasurementOf</code>) and to <code>saref:Property</code> (<code>saref:hasProperty</code> and <code>saref:isPropertyOf</code>) (#40).</li>

<li data-docx-pstyle="TB1">Added the <code>saref:measurementMadeBy</code> property as inverse of <code>saref:makesMeasurement</code> (#40).</li>

<li data-docx-pstyle="TB1">The <code>saref:relatesToProperty</code> and <code>saref:relatesToMeasurement</code> properties are now inverse of each other (#21).</li>

<li data-docx-pstyle="TB1">The range of <code>saref:hasValue</code>, which was defined as <code>xsd:float</code>, has been removed to support other datatypes for measurements (#24).</li>

<li data-docx-pstyle="TB1">The range of datatype properties, which was defined as <code>xsd:string</code>, has been removed in order to support strings with language tags (<code>rdf:langString</code>). This affects <code>saref:hasDescription</code>, <code>saref:hasManufacturer</code>, <code>saref:hasModel</code> and <code>saref:hasName</code>, which now have implicitly a range of <code>rdfs:Literal</code> (#1).</li>

<li data-docx-pstyle="TB1">The <code>saref:hasName</code> property has been removed and the use of <code>rdfs:label</code> is recommended (#3). </li>

<li data-docx-pstyle="TB1">The <code>saref:hasDescription</code> property has been deprecated and the use of <code>rdfs:comment</code> is recommended (#6). </li>

<li data-docx-pstyle="TB1">Too restrictive restrictions have been removed and in some cases the ontology documentation has been updated to reflect this: a <code>saref:Command</code> having at most one <code>saref:hasDescription</code> (#2); a <code>saref:Task</code> being accomplished by at least one <code>saref:Device</code> (#14); a <code>saref:Device</code> having a typical consumption of only energy or power (#19); a <code>saref:Commodity</code> being measured in units of measure (#20); restrictions on the values of <code>saref:accomplishes</code> that only covered specific use cases (#13); universal restrictions on the <code>saref:actsUpon</code> property have been changed to existential ones (#31); restrictions on the commands that a <code>saref:Function</code> may have, since there could be others not included in the defined enumerations (#28); restrictive documentation of <code>saref:EventFunction</code> and <code>saref:SmokeSensor</code> (#18).</li>

<li data-docx-pstyle="TB1">Bugs have been fixed: some devices (<code>saref:DoorSwitch</code>, <code>saref:EnergyMeter</code>, <code>saref:LigthSwitch</code>, <code>saref:SmokeSensor</code>, and <code>saref:TemperatureSensor</code>) were defined as subclass of a device and at the same time as consisting of such device (#11); a <code>saref:LightSwitch</code> controls light and does not measure light, since it is an actuator (#12); incorrect documentation of <code>saref:OnState</code> and <code>saref:OffState</code> (#39).</li>

<li data-docx-pstyle="TB1">The <code>saref:BuildingRelated</code>, <code>saref:EnergyRelated</code> and <code>saref:FunctionRelated</code> classes have been removed, since the different extensions already classify the device types (#3).</li>

<li data-docx-pstyle="TB1">The instances of the subclasses of <code>saref:Command</code> have been removed, since they represent examples (#32).</li>

<li data-docx-pstyle="TB1">The instances of <code>saref:UnitOfMeasure</code> have been moved to examples (#22).</li>

<li data-docx-pstyle="TB1">The classes related to the SAREF4ENER extension have been removed: <code>saref:Generator</code>, <code>saref:Storage</code>, <code>saref:Load</code> and <code>saref:EnergyMeter</code> (#3).</li>

<li data-docx-pstyle="TB1">Some instances of <code>saref:Device</code> have been moved to examples: <code>saref:WashingMachine</code>, <code>saref:LightingDevice</code>, <code>saref:MicroRenewable</code>, <code>saref:Multimedia</code>, and <code>saref:Network</code> (#23).</li>

<li data-docx-pstyle="TB1">Added domain and range axioms wherever the definition of a property unambiguously identifies the domain or the range of the property (#15).</li>

<li data-docx-pstyle="TB1">The OWL Time ontology is not imported anymore (#36).</li>

<li data-docx-pstyle="TB1">The documentation of some ontology terms has been updated for clarification (#5).</li>

<li data-docx-pstyle="TB1">Language tags have been added to all labels and comments (#7).</li>

</ul></td>

  </tr>

  <tr>

    <td colspan="3">

<li data-docx-pstyle="TAN">NOTE:	In some cases, references have been added to indicate the issue in the ETSI Forge (<a href="https://forge.etsi.org/rep/SAREF/saref-core/issues">https://forge.etsi.org/rep/SAREF/saref-core/issues</a>) where the change was discussed and implemented.</li></td>

  </tr>

</table>