documentation conforms to SmartM2M(24)069014

The scope of the first release of SAREF was limited to an indoor managed domain, such as a building managed by a building manager or an apartment managed by a user. This scope also included the outdoor premises that belong to the considered indoor managed domain, in other words, a pergola that is part of the building is also within the scope, as well as a sensor located under that pergola. Note that the smart city domain was not originally considered, i.e. if the same sensor that is under the pergola is also in a street, then the sensor in the street was out of the scope of SAREF. After extending SAREF to different domains, it was clear the need for broadening the scope of SAREF from home appliances and buildings to any device that can be found in smart applications; this motivated the change of name of the ontology from "Smart Appliances REFerence ontology" to "Smart Applications REFerence ontology".

In June 2018, another STF started in SmartM2M with the goal (among others) of consolidating SAREF with new reference ontology patterns, based on the experience from the EUREKA ITEA SEAS project. As a result of this STF, 37 different issues were identified and discussed in ETSI TR 103 549  [[i.20]](#[i.20]), proposing and agreeing on resolutions for most of them. Furthermore, it was identified the need for moving some transversal terms used in several extensions of SAREF to the core SAREF ontology, because of the broad applicability of such terms. This led to the release of SAREF ETSI TS 103 264 V3.1.1  [[i.7]](#[i.7]).

In June 2018, another STF started in SmartM2M with the goal (among others) of consolidating SAREF with new reference ontology patterns, based on the experience from the EUREKA ITEA SEAS project. As a result of this STF, 37 different issues were identified and discussed in ETSI TR 103 549  [[i.21]](#[i.21]), proposing and agreeing on resolutions for most of them. Furthermore, it was identified the need for moving some transversal terms used in several extensions of SAREF to the core SAREF ontology, because of the broad applicability of such terms. This led to the release of SAREF ETSI TS 103 264 V3.1.1  [[i.7]](#[i.7]).

SAREF and its different extensions were developed quite independently by different teams of experts, sometimes in parallel. Sometimes different modelling decisions were made, with the result that SAREF extensions had important discrepancies. SmartM2M started to identify ontology patterns that may be used to homogenise the structure of SAREF extensions. In 2022, two new STFs started in SmartM2M with the goal to homogenise and facilitate the use of SAREF and existing 11 SAREF domain mapping by using common ontology patterns. A total of 91 different issues were identified and discussed in ETSI TR 103 781  [[i.21]](#[i.21]), and a set of SAREF Core reference ontology patterns was specified in ETSI TS 103 548  [[4]](#[4]).

SAREF and its different extensions were developed quite independently by different teams of experts, sometimes in parallel. Sometimes different modelling decisions were made, with the result that SAREF extensions had important discrepancies. SmartM2M started to identify ontology patterns that may be used to homogenise the structure of SAREF extensions. In 2022, two new STFs started in SmartM2M with the goal to homogenise and facilitate the use of SAREF and existing 11 SAREF domain mapping by using common ontology patterns. A total of 91 different issues were identified and discussed in ETSI TR 103 781  [[i.22]](#[i.22]), and a set of SAREF Core reference ontology patterns was specified in ETSI TS 103 548  [[4]](#[4]).

A summary of the most relevant changes made in SAREF ETSI TS 103 264 V2.1.1  [[i.6]](#[i.6]), V3.1.1  [[i.7]](#[i.7]) and V3.2.1 (the present version) is available in annex A of [[0]](#[0]).

A summary of the most relevant changes made in SAREF ETSI TS 103 264 V2.1.1  [[i.6]](#[i.6]), V3.1.1  [[i.7]](#[i.7]), V3.2.1  [[i.8]](#[i.8]), and V4.1.1 (the present version) is available in annex A of [[0]](#[0]).

### SAREF Design Principles

**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  [[i.4]](#[i.4]). 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. Each function has some associated commands, which can also be selected as building blocks from a list. 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. SAREF also provides a list of properties that can be used to further specialize the functioning of a device.

**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.8]](#[i.8]), SAREF4ENVI (environment domain)  [[i.9]](#[i.9]) and SAREF4BLDG (building domain)  [[i.10]](#[i.10]). SAREF and extensions are based on patterns that are used in different domains. SAREF extension developers should reuse SAREF reference ontology patterns as specified in ETSI TS 103 548  [[4]](#[4]).

**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.9]](#[i.9]), SAREF4ENVI (environment domain)  [[i.10]](#[i.10]) and SAREF4BLDG (building domain)  [[i.11]](#[i.11]). SAREF and extensions are based on patterns that are used in different domains. SAREF extension developers should reuse SAREF reference ontology patterns as specified in ETSI TS 103 548  [[4]](#[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. SAREF extension developers shall comply with the SAREF Development Framework and Workflow as specified in ETSI TS 103 673  [[3]](#[3]). For an initial strategy proposed in ETSI to extend, maintain and evolve SAREF (and its extensions), see ETSI TR 103 411  [[i.3]](#[i.3]).

SAREF is the reference ontology for smart applications and contains recurring concepts that are used in several domains. SAREF has a close relation with the oneM2M Base Ontology, for which a mapping is defined in clause 6. As smart applications are not restricted to only one domain, it is possible that specific concepts for a certain domain are not part of SAREF. To be able to handle these additional concepts and provide different domains with a proper ontology that reflects the specific needs of that domain, extensions to SAREF should be created. Figure 11 shows SAREF as the core model to be used as basis for creating extensions in different domains, which are represented as rectangles. Each domain can have one or more extensions, depending on the complexity of the domain and the different needs. Extensions of SAREF have been created for:

- SAREF4ENER for the Energy domain in ETSI TS 103 410-1  [[i.8]](#[i.8]).

- SAREF4ENVI for the Environment domain in ETSI TS 103 410 2  [[i.9]](#[i.9]).

- SAREF4BLDG for the Building domain in ETSI TS 103 410-3  [[i.10]](#[i.10]).

- SAREF4CITY for the Smart City domain in ETSI TS 103 410-4  [[i.11]](#[i.11]).

- SAREF4INMA for the Industry and Manufacturing domain in ETSI TS 103 410-5  [[i.12]](#[i.12]).

- SAREF4AGRI for the Agrifood domain in ETSI TS 103 410-6  [[i.13]](#[i.13]).

- SAREF4AUTO for the Automotive domain in ETSI TS 103 410-7  [[i.14]](#[i.14]).

- SAREF4EHAW for the eHealth and Ageing Well domain in ETSI TS 103 410-8  [[i.15]](#[i.15]).

- SAREF4WEAR for the Wearables domain in ETSI TS 103 410-9  [[i.16]](#[i.16]).

- SAREF4WATR for the Water domain in ETSI TS 103 410-10  [[i.17]](#[i.17]).

- SAREF4LIFT for the Smart Lifts domain in ETSI TS 103 410-11  [[i.18]](#[i.18]).

- SAREF4GRID for the Smart Grids domain in ETSI TS 103 410-12  [[i.19]](#[i.19]).

- SAREF4ENER for the Energy domain in ETSI TS 103 410-1  [[i.9]](#[i.9]).

- SAREF4ENVI for the Environment domain in ETSI TS 103 410 2  [[i.10]](#[i.10]).

- SAREF4BLDG for the Building domain in ETSI TS 103 410-3  [[i.11]](#[i.11]).

- SAREF4CITY for the Smart City domain in ETSI TS 103 410-4  [[i.12]](#[i.12]).

- SAREF4INMA for the Industry and Manufacturing domain in ETSI TS 103 410-5  [[i.13]](#[i.13]).

- SAREF4AGRI for the Agrifood domain in ETSI TS 103 410-6  [[i.14]](#[i.14]).

- SAREF4AUTO for the Automotive domain in ETSI TS 103 410-7  [[i.15]](#[i.15]).

- SAREF4EHAW for the eHealth and Ageing Well domain in ETSI TS 103 410-8  [[i.16]](#[i.16]).

- SAREF4WEAR for the Wearables domain in ETSI TS 103 410-9  [[i.17]](#[i.17]).

- SAREF4WATR for the Water domain in ETSI TS 103 410-10  [[i.18]](#[i.18]).

- SAREF4LIFT for the Smart Lifts domain in ETSI TS 103 410-11  [[i.19]](#[i.19]).

- SAREF4GRID for the Smart Grids domain in ETSI TS 103 410-12  [[i.20]](#[i.20]).

Other extensions can be created for new domains and, if needed, also for the same domains for which extensions already exist.

- **Provision 2**: Whenever appropriate, SAREF Extensions should reuse and extend SAREF Reference ontology patterns as specified in ETSI TS 103 548  [[4]](#[4]).

- **Provision 3**: SAREF shall use the SAREF Communication framework as defined in ETSI TS 103 267  [[2]](#[2]).

Some examples of device built using SAREF can be found in ETSI TR 103 411  [[i.3]](#[i.3]) and in the different SAREF extensions ( [[i.8]](#[i.8]) to  [[i.19]](#[i.19])).

Some examples of device built using SAREF can be found in ETSI TR 103 411  [[i.3]](#[i.3]) and in the different SAREF extensions ( [[i.9]](#[i.9]) to  [[i.20]](#[i.20])).

</div>

<div id="NOTE_1" class="alert-warning">NOTE 1: Until SAREF V3.1.1 <a href="#[i.7]">[i.7]</a>, there was an ambiguity between whether properties should be specific or generic to features of interest. This ambiguity has been solved in SAREF V3.2.1 (the present document), and the new modeling choice will be enforced in the next release of SAREF.

<div id="NOTE_1" class="alert-warning">NOTE 1: Until SAREF V3.1.1 <a href="#[i.7]">[i.7]</a>, there was an ambiguity between whether properties should be specific or generic to features of interest. This ambiguity has been solved in SAREF V3.2.1 <a href="#[i.8]">[i.8]</a>, and the new modeling choice has be enforced in SAREF V4.1.1 (the present document).

</div>

Properties can be organized in a taxonomy using properties skos:narrower and skos:broader.

<div id="NOTE_2" class="alert-warning">NOTE 2: Concepts from existing code lists, vocabularies, and taxonomies, may be used as instances of <a href="#saref:Property">saref:Property</a>. 

</div>

<div id="EXAMPLE_2" class="alert-info">EXAMPLE 2: Two examples using the QUDT Quantity Kind vocabulary <a href="#[i.22]">[i.22]</a>, and the British Oceanographic Data Centre Parameter Usage Vocabulary <a href="#[i.24]">[i.24]</a>.

<div id="EXAMPLE_2" class="alert-info">EXAMPLE 2: Two examples using the QUDT Quantity Kind vocabulary <a href="#[i.23]">[i.23]</a>, and the British Oceanographic Data Centre Parameter Usage Vocabulary <a href="#[i.25]">[i.25]</a>.

```

<https://qudt.org/2.1/vocab/quantitykind/ActiveEnergy> a saref:Property ;

The range of [saref:isMeasuredIn](#saref:isMeasuredIn) is defined as [saref:UnitOfMeasure](#saref:UnitOfMeasure).

<div id="NOTE_1" class="alert-warning">NOTE 1: Concepts from existing code lists, vocabularies, and taxonomies, may be used as instances of <a href="#saref:UnitOfMeasure">saref:UnitOfMeasure</a>. For example the QUDT Unit vocabulary <a href="#[i.23]">[i.23]</a>.

<div id="NOTE_1" class="alert-warning">NOTE 1: Concepts from existing code lists, vocabularies, and taxonomies, may be used as instances of <a href="#saref:UnitOfMeasure">saref:UnitOfMeasure</a>. For example the QUDT Unit vocabulary <a href="#[i.24]">[i.24]</a>.

</div>

The OP [saref:hasPropertyValue](#saref:hasPropertyValue) links a feature kind, a feature of interest, or a property of interest, to a property value.

<a href="#Figure_17">Figure 17</a> illustrates the main classes and properties for describing observations, measurements, and actuations.

<figure>

  <img src="diagrams/Observation.png" alt="Observations, measurements, and actuations"/>

  <img src="diagrams/Observation_v411.png" alt="Observations, measurements, and actuations"/>

  <figcaption id="Figure_17">Figure 17: Observations, measurements, and actuations</figcaption>

</figure>

```

</div>

<div id="NOTE_3" class="alert-warning">NOTE 3: <a href="#saref:Observation">saref:Observation</a> is more general than <a href="#saref:Measurement">saref:Measurement</a>, as it apply to states in addition to properties. The indirection <a href="#saref:hasResult">saref:hasResult</a> to a property value improves its semantic correctness. It also improves the alignment with the OGC® and W3C® SOSA/SSN ontology <a href="#[6]">[6]</a>. Therefore, <a href="#saref:Measurement">saref:Measurement</a> has been deprecated in the present document, and may be deleted in the next release of SAREF.

<div id="NOTE_3" class="alert-warning">NOTE 3: <a href="#saref:Observation">saref:Observation</a> is more general than <a href="#saref:Measurement">saref:Measurement</a>, as it apply to states in addition to properties. The indirection <a href="#saref:hasResult">saref:hasResult</a> to a property value improves its semantic correctness. It also improves the alignment with the OGC® and W3C® SOSA/SSN ontology <a href="#[6]">[6]</a>. Therefore, <a href="#saref:Measurement">saref:Measurement</a> has been deprecated in version V3.2.1 <a href="#[8]">[8]</a>, and has been deleted in the present document.

</div>

A [saref:Actuation](#saref:Actuation) is the act of carrying out a procedure to control the state of the world using an actuator. It links to an actuator to describe what made the actuation, and to the controlled feature, property, property of interest, state, or state of interest. Typically, its input is a property value or a state. An actuation of a state (OP [saref:controls](#saref:controls)) should have a state as input (OP [saref:hasInput](#saref:hasInput)). Respectively, an actuation of a property should have a property value as input.

```

</div>

A set of specializations of a Profile is given via the Flexibility Profile defined in the SAREF4ENER extension in ETSI TS 103 410-1 <a href="#[i.8]">[i.8]</a>. Each Flexibility Profile describes the ways in which a device can regulate its energy consumption and production. Therefore, the Flexibility Profile is a static set of options to choose from and a set of user preferences, instead of a pre-calculated energy usage time series. The details of each Flexibility Profile can be specified using the related extensions.

A set of specializations of a Profile is given via the Flexibility Profile defined in the SAREF4ENER extension in ETSI TS 103 410-1 <a href="#[i.9]">[i.9]</a>. Each Flexibility Profile describes the ways in which a device can regulate its energy consumption and production. Therefore, the Flexibility Profile is a static set of options to choose from and a set of user preferences, instead of a pre-calculated energy usage time series. The details of each Flexibility Profile can be specified using the related extensions.

A specialization of a Profile may additionally relate to other SAREF classes via properties defined in the extensions, including, but not limited to a state, property, property value, function, and command.

<div id="EXAMPLE_7" class="alert-info">EXAMPLE 7: