<div class="alert-warning">NOTE: The text in this section is extracted from ETSI TS 103 264 (V3.2.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> 

### A Brief History of SAREF

The SAREF initiative started in 2014/2015 with a study requested by the European Commission on "Available Semantics Assets for the Interoperability of Smart Appliances: Mapping into a Common Ontology as a M2M Application Layer Semantics" [i.1]. 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.

<div class="alert-info">NOTE: The ETSI M2M architecture has evolved into the oneM2M architecture, therefore the latter one was considered.</div> 


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. The concepts were mapped from the semantic assets to SAREF to allow for translations between different semantic assets [i.4].

In November 2015, SAREF was transformed into a Technical Specification and published by ETSI SmartM2M as ETSI TS 103 264 [i.5].

In 2016, ETSI SmartM2M requested a Specialist Task Force (STF) to identify and create possible extensions of SAREF, and provide input to update SAREF according to the requirements collected from the stakeholders that have used SAREF since its first release in April 2015. This led to a new release SAREF V2.1.1 [i.6], which incorporated the feedback both from the STF that created the first SAREF extensions, and from the stakeholders that provided their input for improving SAREF. This feedback can be found in ETSI TR 103 411 [i.3] and was used to create SAREF V2.1.1.

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.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].

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], and a set of SAREF Core reference ontology patterns was specified in ETSI TS 103 548 [5]. Many terms were deprecated in V3.2.1 [i.8], and have been deleted in V4.1.1 (the present document). One notable addition to V4.1.1 is that SAREF explicitly targets two main types of usage: 

1. SAREF in online taxonomies, vocabularies, and catalogues, can be used identify and describe generic or prototypical entities than can then be reused in many verticals and applications, thus facilitating semantic interoperability.
2. SAREF in smart application, can be used to identify and describe specific entities of the real world for a specific application.

In October 2024, the first ETSI EN about SAREF has been published. ETSI EN 303 760 [1] gives guidance and provisions for making IoT smart applications and products interoperable at the semantic level in compliance to the SAREF framework. It contains provisions about how to use SAREF, and specifies a methodology to follow for showing SAREF compliance. Further on, it describes how to contribute optionally to a new SAREF extension.


Annex A of of [0] contains a summary of the most relevant changes made in SAREF V2.1.1 [i.6], V3.1.1 [i.7], V3.2.1 [i.8], and V4.1.1 [0]. Annex B of [0] contains a migration guide from SAREF V3.1.1 to V4.1.1.

### SAREF Design 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 [2]. SAREF reuses the following resources:

- oneM2M base ontology [2];
-	W3C® SKOS ontology [6];
-	OGC® and W3C® SOSA/SSN ontology [7];
-	OGC® and W3C® Time ontology [8];
-	OGC® GeoSPARQL vocabulary [9].

SAREF currently does not contain explicit references to upper ontologies such as DUL or SUMO. The use of upper ontologies is a best practice in ontology engineering, but the industrial world - main user of SAREF - is very pragmatic and is not acquainted with high-level upper ontologies. Introducing DUL would have unnecessarily complicated the understanding and, consequently, the adoption of SAREF by the industry. Anyway, SAREF has been built on a solid ontological foundation and can be related to DUL, but this was not explicitly done in order not to confuse industry users. Furthermore, SAREF currently has mappings to the OGC® and W3C® SOSA/SSN ontology, which is in turn related to DUL. Therefore, SAREF currently includes an indirect reference to DUL through the OGC® and W3C® SOSA/SSN ontology.

**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]. 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.9], SAREF4ENVI (environment domain) [i.10] and SAREF4BLDG (building domain) [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 [5].

**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 [4]. For an initial strategy proposed in ETSI to extend, maintain and evolve SAREF (and its extensions), see ETSI TR 103 411 [i.3].

**Generic versus specific entity distinction**. SAREF is designed to model both generic and specific entities. Firstly, it provides a standardized way to define generic or prototypical entities in taxonomies, vocabularies, and catalogues, ensuring broad semantic interoperability across domains. Secondly, it enables the description of real-world specific entities within smart applications, ensuring precise and context-aware implementation. This dual-purpose approach enhances SAREF's adaptability across different levels of abstraction and application scenarios. Online catalogue and taxonomy editors will populate classes such as **DeviceKind**, **FeatureKind**, **Property**, **State**, **Function**, **Command**, while application developers will instantiate classes such as **Device** and **FeatureOfInterest**.

### SAREF Extensions

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 2 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.9].
-	SAREF4ENVI for the Environment domain in ETSI TS 103 410 2 [i.10].
-	SAREF4BLDG for the Building domain in ETSI TS 103 410-3 [i.11].
-	SAREF4CITY for the Smart City domain in ETSI TS 103 410-4 [i.12].
-	SAREF4INMA for the Industry and Manufacturing domain in ETSI TS 103 410-5 [i.13].
-	SAREF4AGRI for the Agrifood domain in ETSI TS 103 410-6 [i.14].
-	SAREF4AUTO for the Automotive domain in ETSI TS 103 410-7 [i.15].
-	SAREF4EHAW for the eHealth and Ageing Well domain in ETSI TS 103 410-8 [i.16].
-	SAREF4WEAR for the Wearables domain in ETSI TS 103 410-9 [i.17].
-	SAREF4WATR for the Water domain in ETSI TS 103 410-10 [i.18].
-	SAREF4LIFT for the Smart Lifts domain in ETSI TS 103 410-11 [i.19].
-	SAREF4GRID for the Smart Grids domain in ETSI TS 103 410-12 [i.20].

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

<figure>
  <img src="diagrams/Modules.png" alt="SAREF and its extensions"/>
  <figcaption id="Figure_2">Figure 2: SAREF and its extensions</figcaption>
</figure>


### Develop, apply and evolve SAREF ontologies

The provisions given in ETSI EN 303 760 [1] and the following apply to SAREF:

**Provision 1**: SAREF Core and SAREF Extension development shall conform to ETSI TS 103 673 [4].

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

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

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

### <a id="5.1"></a>General Overview

#### <a id="5.1.1"></a>Main classes and properties of SAREF Core

SAREF is designed to model both generic and specific entities.

[Figure 3](#Figure_3) shows an overview of some of the main classes and properties of SAREF Core. 

A detailed explanation of each class is presented in clause 5.2 to clause 5.14.


<figure>
  <img src="diagrams/Overview_canonical.png" alt="Overview of the main classes and properties of SAREF Core"/>
  <figcaption id="Figure_3">Figure 3: Overview of the main classes and properties of SAREF Core</figcaption>
</figure>

<div class="alert-warning">NOTE: Classes represented in yellow should be instantiated only in taxonomies, vocabularies, and catalogues. <br/>
Classes represented in blue should be instantiated only in smart applications. <br/>
Classes represented in light grey can be instantiated in either type of usage of SAREF. <br/>
An instance of any class from which originates the red lines can be linked to an instance of any class where the red lines end.</div> 

#### <a id="5.1.2"></a>Classes and properties for generic entities

SAREF provides a standardized way to define generic or prototypical entities in taxonomies, vocabularies, and catalogues, ensuring broad semantic interoperability across domains.

[Figure 4](#Figure_4) shows an overview of the classes and properties for generic entities.

<figure>
  <img src="diagrams/Overview_catalogues.png" alt="Classes and properties for generic entities"/>
  <figcaption id="Figure_4">Figure 4: Classes and properties for generic entities</figcaption>
</figure>

<div class="alert-warning">NOTE: Classes represented in yellow should be instantiated only in taxonomies, vocabularies, and catalogues. <br/>
An instance of any class from which originates the red lines can be linked to an instance of any class where the red lines end.</div> 


#### <a id="5.1.3"></a>Classes and properties for specific entities

SAREF also enables the description of real-world specific entities within smart applications, ensuring precise and context-aware implementation.

[Figure 5](#Figure_5) shows an overview of the classes and properties for specific entities.

<figure>
  <img src="diagrams/Overview_applications.png" alt="Classes and properties for specific entities"/>
  <figcaption id="Figure_5">Figure 5: Classes and properties for specific entities</figcaption>
</figure>

<div class="alert-warning">NOTE: Classes represented in blue should be instantiated only in smart applications. <br/>
An instance of any class from which originates the red lines can be linked to an instance of any class where the red lines end.</div> 


#### <a id="5.1.4"></a>Relation to other documents

ETSI EN 303 760 [[1]](#[1]) provides guidelines to apply, extend, and contribute to the evolution of SAREF Core. The SAREF Communication framework as defined in ETSI TS 103 267 [[3]](#[3]). SAREF Core development conforms to ETSI TS 103 673 [[4]](#[4]). SAREF Core reuses and extends SAREF Reference ontology patterns as specified in ETSI TS 103 548 [[5]](#[5]).

### <a id="5.2"></a>Device kinds and devices

[Figure 6](#Figure_6) illustrates the main classes and properties for devices. SAREF extensions and applications may create, specialize, and categorize devices as specified in ETSI TS 103 548 [[5]](#[5]).

<div class="alert-warning">NOTE 1: SAREF V4.1.1 introduced the class <a href="#saref:DeviceKind">saref:DeviceKind</a> for the prototypical description of devices that can populate online taxonomies, vocabularies, and catalogues. Considering <a href="#saref:Device">saref:Device</a> was mostly instantiated for smart applications, it was decided to keep this identifier for the specific class (instead of introducing some class like "DeviceOfInterest"), and introduce <a href="#saref:DeviceKind">saref:DeviceKind</a>.</div>

<figure>
  <img src="diagrams/Devices.png" alt="Devices"/>
  <figcaption id="Figure_6">Figure 6: Devices</figcaption>
</figure>

Class [saref:Device](#saref:Device) represents any tangible object designed to accomplish a particular task by performing one or more functions. An instance of [saref:Device](#saref:Device) represents one specific real world entity.

<div class="alert-info">EXAMPLE 1: Examples of devices are a light switch, a temperature sensor, an energy meter, a water flow meter, and a laundry dryer. A laundry dryer is designed to dry laundry, and to accomplish this task it has a start/stop function.
</div>

<div class="alert-info">EXAMPLE 2:

```
ex:Meter4837QW123 a saref:Device ;
		rdfs:label "Meter 4837QW123"@en ;
		rdfs:comment """The meter that measures the incoming water flow of the Computer Science school."""@en .
```
</div>

<div class="alert-info">EXAMPLE 3:

```
ex:Dryer354A1E08FA a saref:Device ;
		rdfs:label "Dryer 354A1E08FA"@en ;
		rdfs:comment "The laundry dryer with serial number 354A1E08FA"@en.
```
</div>

Devices are also systems ([s4syst:System](https://saref.etsi.org/saref4syst/System), see [[5]](#[5])) and features of interest ([saref:FeatureOfInterest](#saref:FeatureOfInterest)).

Class [saref:DeviceKind](#saref:DeviceKind) allows to describe kinds of devices, with common properties and common states having the same value, and with common functions and services. Devices kinds may be used to describe models of devices in online catalogues. 

A device can be linked to its device kinds using OP [saref:hasDeviceKind](#saref:hasDeviceKind). 

<div class="alert-info">EXAMPLE 4:

```
s4abcd:SmartWaterMeterABC123 a saref:DeviceKind ;
	rdfs:label "Smart Water Meter ABC123"@en ;
	rdfs:comment """The smart water meter ABC123 of manufacturer ABC. A device kind."""@en .
ex:Meter4837QW123 saref:hasDeviceKind s4abcd:SmartWaterMeterABC123 .
```
</div>

A device can act upon (OP [saref:actsUpon](#saref:actsUpon)) features, properties, or states. SAREF Core defines different sub properties of [saref:actsUpon](#saref:actsUpon):

- [saref:observes](#saref:observes) for when a device observes a feature of interest, or property or state of that feature.
- [saref:controls](#saref:controls) for when a device controls a feature of interest, or property or state of that feature.

<div class="alert-warning">NOTE 2: Property <a href="#saref:actsUpon">saref:actsUpon</a> also applies to functions, commands, and procedure executions.
</div>

<div class="alert-info">EXAMPLE 5:

```
s4abcd:AAHeatPumpDryer a saref:DeviceKind ;
	saref:controls s4abcd:DryerRotationalSpeed ;
	saref:controls s4abcd:DryerTemperature ;
	saref:observes s4abcd:LaudryBatchHumidity .
```
</div>

As shown in [Figure 6](#Figure_6), SAREF Core provides some examples of classes of devices including appliances, sensors, actuators, and meters. Their definitions are the following:

-	[saref:Appliance](#saref:Appliance): The class of devices designed to accomplish a particular task for occupant use. It consumes, produces, or stores, some commodity.
-	[saref:Sensor](#saref:Sensor): A device designed to observe and measure one or more properties or states of one or more features of interest.
-	[saref:Actuator](#saref:Actuator): A device designed to control one or more properties or states of one or more features of interest.
-	[saref:Meter](#saref:Meter): A device designed to observe and additionally do some computation and/or display one or more properties or states of one or more features of interest.
 
The manufacturer and model of a [saref:DeviceKind](#saref:DeviceKind) or a [saref:Device](#saref:Device) can be statedd using DPs [saref:hasManufacturer](#saref:hasManufacturer) and [saref:hasModel](#saref:hasModel), respectively. 

<div class="alert-info">EXAMPLE 6:

```
ex:Meter4837QW123 a saref:Device ;
	saref:hasManufacturer "ABC"@en ;
	saref:hasModel "4837QW123"@en .
```
</div>

### <a id="5.3"></a>Feature kinds and features of interest

[Figure 7](#Figure_7) illustrates the main classes and properties for feature kinds and features of interest. SAREF extensions and applications may create, specialize, and categorize feature kinds and features of interest as specified in ETSI TS 103 548 [[5]](#[5]).

<div class="alert-warning">NOTE 1: Class <a href="#saref:FeatureKind">saref:FeatureKind</a> has been introduced in SAREF V3.2.1 for the prototypical description of features of interest that can populate online taxonomies, vocabularies, and catalogues.</div>

<figure>
  <img src="diagrams/FeatureOfInterest.png" alt="Feature kinds and features of interest"/>
  <figcaption id="Figure_7">Figure 7: Feature kinds and features of interest</figcaption>
</figure>

Class [saref:FeatureOfInterest](#saref:FeatureOfInterest) represents any real world entity from which a property or a state may be acted upon, such as observed and controlled. An instance of [saref:FeatureOfInterest](#saref:FeatureOfInterest) represents one specific real world entity.

<div class="alert-info">EXAMPLE 1:

```
<etsi_premises/athena> a saref:FeatureOfInterest ;
  rdfs:label "ATHENA amphitheatre"@en ;
  rdfs:comment "The ATHENA amphitheatre in the ETSI premises."@en .

<etsi_premises/athena/window5> a saref:FeatureOfInterest ;
  rdfs:label "ATHENA Window 5"@en ;
  rdfs:comment "Window 5 of ATHENA amphitheatre"@en .
```
</div>

Class [saref:Device](#saref:Device) is a subclass of [saref:FeatureOfInterest](#saref:FeatureOfInterest).

Class [saref:FeatureKind](#saref:FeatureKind) allows to describe kinds of features of interest, with common properties and common states having the same value. An instance of [saref:FeatureKind](#saref:FeatureKind) represents an archetype of real world entities, for example to populate product catalogues.

<div class="alert-info">EXAMPLE 2:

```
<1000x2000mmWindowOrientedNorth> a saref:FeatureKind ;
  rdfs:label "1000x2000mm window oriented north"@en ;
  rdfs:comment "The kind of windows with dimensions 1000x2000mm and oriented north."@en .
```
</div>

Class [saref:DeviceKind](#saref:DeviceKind) is a subclass of [saref:FeatureKind](#saref:FeatureKind).

Feature kinds can be organized in a taxonomy using OPs [skos:narrower](http://www.w3.org/2004/02/skos/core#narrower) and [skos:broader](http://www.w3.org/2004/02/skos/core#broader).

<div class="alert-info">EXAMPLE 3:

```
<1000x2000mmWindowOrientedNorth> a saref:FeatureKind ;
  skos:broader <1000x2000mmWindow> ;
  skos:broader <WindowOrientedNorth> .
```
</div>

A feature of interest can be linked to its kind(s) using OP [saref:hasFeatureKind](#saref:hasFeatureKind). OP [saref:hasDeviceKind](#saref:hasDeviceKind) is a sub-property of OP [saref:hasFeatureKind](#saref:hasFeatureKind).

<div class="alert-info">EXAMPLE 4:

```
<etsi_premises/athena/window5>
  saref:hasFeatureKind <1000x2000mmWindowOrientedNorth> .
```
</div>

<div class="alert-warning">NOTE: Feature of interest inherit broader feature kinds.

```
saref:hasFeatureKind o skos:broader ⊑ saref:hasFeatureKind
```
</div>

<div class="alert-info">EXAMPLE 5:

```
<etsi_premises/athena/window5>
    saref:hasFeatureKind <1000x2000mmWindow> ;
    saref:hasFeatureKind <WindowOrientedNorth> .
```
</div>

A feature kind (respectively a feature of interest) may consist of (OP [saref:consistsOf](#saref:consistsOf)) other feature kinds (respectively feature kinds or features of interest).

<div class="alert-info">EXAMPLE 6:

```
s4abcd:AAHeatPumpDryer a saref:FeatureKind ;
  saref:consistsOf s4abcd:HeatPump , s4abcd:AirCyclingCircuit , s4abcd:Dryer .
```
</div>

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

```
<etsi_premises/athena> a saref:FeatureOfInterest ;
	saref:consistsOf <etsi_premises/stage> ;
	saref:consistsOf <etsi_premises/athena/window5> .
```
</div>

Whenever appropriate, SAREF extensions and applications should also use the classes from SAREF4SYST [[5]](#[5]) to specify if a [saref:FeatureKind](#saref:FeatureKind) or a [saref:FeatureOfInterest](#saref:FeatureOfInterest) is a system ([s4syst:System](https://saref.etsi.org/saref4syst/System)), a Connection between systems ([s4syst:Connection](https://saref.etsi.org/saref4syst/Connection)), or a connection point of a system ([s4syst:ConnectionPoint](https://saref.etsi.org/saref4syst/ConnectionPoint)).

The model and the manufacturer of a [saref:FeatureKind](#saref:FeatureKind) or a [saref:FeatureOfInterest](#saref:FeatureOfInterest) can be explicited using DPs [saref:hasModel](#saref:hasModel) and [saref:hasManufacturer](#saref:hasManufacturer), respectively. 

<div class="alert-info">EXAMPLE 8:

```
<ball-bearing-xsd215sd7f> a saref:FeatureOfInterest , s4syst:System ;
	saref:hasManufacturer "Company X"@en ;
	saref:hasModel "6000-2RZ1 "@en .
```
</div>

### <a id="5.4"></a>Tasks

Class [saref:Task](#saref:Task) represents goals for which a device is designed, from a user perspective.

SAREF extensions and applications may create, specialize, and categorize tasks as specified in ETSI TS 103 548 [[5]](#[5]), and illustrated on [Figure 8](#Figure_8).

<figure>
  <img src="diagrams/Tasks.png" alt="Taxonomy of tasks, grouped by categories"/>
  <figcaption id="Figure_8">Figure 8: Taxonomy of tasks, grouped by categories</figcaption>
</figure>

Tasks can be organized in a taxonomy using OPs [skos:narrower](http://www.w3.org/2004/02/skos/core#narrower) and [skos:broader](http://www.w3.org/2004/02/skos/core#broader).

<div class="alert-info">EXAMPLE 1: Example of tasks are cleaning, drying, and lighting.

```
saref:Drying a saref:Task ;
  rdfs:label "Drying"@en ;
  rdfs:comment "A type of task for which a device is designed."@en .
```
</div>

Device kinds and devices can be linked to the one or more tasks they are designed to accomplish with OP [saref:accomplishes](#saref:accomplishes). 

<div class="alert-info">EXAMPLE 2:

```
s4abcd:AAHeatPumpDryer a saref:FeatureKind ;
  saref:accomplishes s4abcd:DryingLaundry .
```
</div>

<div class="alert-info">EXAMPLE 3:

```
ex:switch21354 a saref:Device ;
  saref:hasDeviceKind s4abcd:Switch ;
  saref:accomplishes s4abcd:Lighting .
```
</div>

<div class="alert-warning">NOTE 1: Property <a href="#saref:accomplishes">saref:accomplishes</a> can also apply to other classes such as functions, commands, and procedure executions.</div>

<div class="alert-warning">NOTE 2: External ontologies can be used to further describe tasks.</div>

### <a id="5.5"></a>Commodities

Class [saref:Commodity](#saref:Commodity) represents marketable items which may be supplied without qualitative differentiation. Commodities may be consumed, produced, or stored, by some feature of interest or device.

SAREF extensions and applications may create, specialize, and categorize commodities as specified in ETSI TS 103 548 [[5]](#[5]), and illustrated on [Figure 9](#Figure_9).

<figure>
  <img src="diagrams/Commodities.png" alt="Taxonomy of commodities, grouped by categories"/>
  <figcaption id="Figure_9">Figure 9: Taxonomy of commodities, grouped by categories</figcaption>
</figure>

Commodities can be organized in a taxonomy using OPs [skos:narrower](http://www.w3.org/2004/02/skos/core#narrower) and [skos:broader](http://www.w3.org/2004/02/skos/core#broader).

<div class="alert-warning">NOTE: Concepts from existing code lists, vocabularies, and taxonomies, may be used as instances of <a href="#saref:Commodity">saref:Commodity</a>, for example from the ISDA taxonomy of commodities <a href="#[i.23]">[i.23]</a>, the Standard International Energy product Classification (SIEC) <a href="#[i.24]">[i.24]</a>, the IRENA Energy Taxonomy <a href="#[i.25]">[i.25]</a> or Wikidata <a href="#[i.26]">[i.26]</a>.</div>

<div class="alert-info">EXAMPLE 1:

```
ex:Electricity a ex:EnergyCommodity ;
  rdfs:label "Electricity"@en ;
  rdfs:comment "The electricity energy commodity."@en ;
  rdfs:isDefinedBy "The IDSA taxonomy of energy commodities" .
```
</div>

A feature kind, feature of interest, or device, can consume (OP [saref:consumes](#saref:consumes)), produce (OP [saref:produces](#saref:produces)), or store (OP [saref:stores](#saref:stores)), a certain commodity.

<div class="alert-info">EXAMPLE 2:

```
s4abcd:AAHeatPumpDryer a saref:FeatureKind ;
  saref:consumes ex:Electricity ;
  saref:produces <http://www.wikidata.org/entity/Q7892> .
```
</div>

### <a id="5.6"></a>Properties, properties of interest, and property values

#### <a id="5.6.1"></a>Introduction

In SAREF, properties refer to the identifiable qualities of features of interest that can be acted upon by devices, such as observed or controlled. While properties can apply to different features of interest, properties of interest are specific to a feature of interest. Property values describe the value for a property.

<div class="alert-info">NOTE: SAREF V3.2.1 introduced the class <a href="#saref:PropertyOfInterest">saref:PropertyOfInterest</a> for identifying the association between a feature of interest and a property in some smart application. Considering <a href="#saref:Property">saref:Property</a> was mostly instantiated in online taxonomies and vocabularies, it was decided to keep this identifier for the generic class (instead of introducing some class like "PropertyKind"), and introduce <a href="#saref:PropertyOfInterest">saref:PropertyOfInterest</a>.</div>

[Figure 10](#Figure_10) illustrates the main classes and properties for describing properties, properties of interest, and property values.

SAREF extensions and applications may create, specialize, and categorize properties as specified in ETSI TS 103 548 [[5]](#[5]).

<figure>
  <img src="diagrams/Properties.png" alt="Properties, properties of interest, and property values"/>
  <figcaption id="Figure_10">Figure 10: Properties, properties of interest, and property values</figcaption>
</figure>

#### <a id="5.6.2"></a>Properties

An instance of [saref:Property](#saref:Property) can apply to different features of interest. 

<div class="alert-info">EXAMPLE 1: Air temperature, pressure, luminosity, etc. are all properties.

```
s4abcd:Temperature a saref:Property ;
 	rdfs:label "Temperature"@en ;
 	rdfs:comment "The temperature property kind."@en . 
s4abcd:Pressure a saref:Property ;
 	rdfs:label "Pressure"@en ;
 	rdfs:comment "The pressure property kind."@en .
s4abcd:Luminosity a saref:Property ;
 	rdfs:label "Temperature"@en ;
 	rdfs:comment "The luminosity property kind."@en .
```
</div>

<div 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 modelling choice has been enforced in SAREF V4.1.1 <a href="#[0]">[0]</a>.
</div>

Properties can be organized in a taxonomy using properties [skos:narrower](http://www.w3.org/2004/02/skos/core#narrower) and [skos:broader](http://www.w3.org/2004/02/skos/core#broader).

<div 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>.</a>. 
</div>

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

```
<https://qudt.org/2.1/vocab/quantitykind/ActiveEnergy> a saref:Property ;
  rdfs:label "Active Energy"@en ;
  rdfs:comment """"Active Energy" is the electrical energy  transformable into some other form of energy."""@en .

<http://vocab.nerc.ac.uk/collection/P01/current/CDTSZZ01/> a saref:Property ;
  skos:prefLabel """Absolute temperature standard deviation of the atmosphere by dry bulb thermometer"""@en .

```
</div>

The OP [saref:hasProperty](#saref:hasProperty) may be used to link a feature kind or feature of interest to its properties. Its inverse is [saref:isPropertyOf](#saref:isPropertyOf).

<div class="alert-info">EXAMPLE 3:

```
s4abcd:AAHeatPumpDryer a saref:FeatureKind ;
 	saref:hasProperty s4abcd:DryerRotationalSpeed ;
 	saref:hasProperty s4abcd:DryerTemperature .
```
</div>

<div class="alert-warning">NOTE 3: Feature kinds inherit the properties of their broader feature kinds.

```	
skos:broader o saref:hasProperty ⊑ saref:hasProperty
```
</div>

<div class="alert-warning">NOTE 4: Features of interest inherit the properties of their feature kinds.

```	
saref:hasFeatureKind o saref:hasProperty ⊑ saref:hasProperty
```
</div>

#### <a id="5.6.3"></a>Properties of interest

An instance of [saref:PropertyOfInterest](#saref:PropertyOfInterest) is specific to a feature of interest. It is inherent to and cannot exist without that feature of interest.

<div class="alert-info">EXAMPLE 1: The air temperature of the atmosphere sample at a certain location and altitude, the received signal strength indicator of a wireless IoT connection, the luminosity of the ETSI ATHENA amphitheatre.
</div>

The OP [saref:hasPropertyOfInterest](#saref:hasPropertyOfInterest) may be used to link a feature of interest to its properties of interest. Its inverse is [saref:isPropertyOfInterestOf](#saref:isPropertyOfInterestOf) and is functional.

A property of interest is the property of (OP [saref:isPropertyOfInterestOf](#saref:isPropertyOfInterestOf)) exactly one feature of interest.

<div class="alert-warning">NOTE 1: Properties of interest need not always be explicited. It depends on the use case. Typically, properties of interest are useful in applications, where the association between a feature of interest and a property (i.e. the property of interest) needs to be identified and related to other entities.
</div>

Given a property of interest belongs to exactly one feature of interest, it is recommended that its identifier consists of the identifier of the feature of interest, followed by character '#' and a fragment identifier. The fragment identifier part of the IRI of a property of interest should not contain "property".

A property of interest can be linked to its kind(s) using OP [saref:hasPropertyKind](#saref:hasPropertyKind).

<div class="alert-info">EXAMPLE 2: The luminosity of the ETSI ATHENA amphitheatre belongs to the ETSI ATHENA amphitheatre.

```
<etsi_premises/athena#luminosity> a saref:PropertyOfInterest ;
  saref:hasPropertyKind s4abcd:Luminosity ;
  saref:isPropertyOfInterestOf <etsi_premises/athena> ;
  rdfs:comment "The luminosity of amphitheatre ATHENA"@en .
```
</div>

<div class="alert-warning">NOTE 2: Properties of interest inherit broader properties.

```	
saref:hasPropertyKind o skos:broader ⊑ saref:hasPropertyKind
```
</div>

<div class="alert-warning">NOTE 3: Features of interest inherit the property kinds of their properties of interest.

```	
saref:hasPropertyOfInterest o saref:hasPropertyKind ⊑ saref:hasProperty
```
</div>

<div class="alert-info">EXAMPLE 3: The ETSI ATHENA amphitheatre has a property luminosity.

```
<etsi_premises/athena> a saref:FeatureOfInterest ;
  saref:hasPropertyOfInterest <etsi_premises/athena#luminosity> ;
  saref:hasProperty saref:Luminosity .
```
</div>


#### <a id="5.6.4"></a>Property Values

Class [saref:PropertyValue](#saref:PropertyValue) describes the value for a property. The property value is optionally linked to its value expressed as an RDF literal (DP [saref:hasValue](#saref:hasValue)), optionally to the unit of measurement (OP [saref:isMeasuredIn](#saref:isMeasuredIn)), and optionally to the properties or properties of interest it is a value of (OP [saref:isValueOfProperty](#saref:isValueOfProperty)).

<div class="alert-info">EXAMPLE 1:

```
[] a saref:PropertyValue ;
  saref:hasValue 22.7 ;
  saref:isMeasuredIn <https://qudt.org/2.1/vocab/unit/DEG_C> .
```
</div>


<div class="alert-info">EXAMPLE 2:

```
[] a saref:PropertyValue ;
  a <http://www.ontology-of-units-of-measure.org/resource/om-2/Temperature> ;
  saref:hasValue 22.7 ;
  saref:isMeasuredIn <http://www.ontology-of-units-of-	measure.org/resource/om-2/degreeCelsius> .
```
</div>

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

<div class="alert-warning">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.28]">[i.28]</a> or the OM vocabulary <a href="#[i.29]">[i.29]</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.

<div class="alert-info">EXAMPLE 2:

```
<etsi_premises/athena#size> a saref:PropertyOfInterest ;
	saref:isPropertyOf <etsi_premises/athena> ;
	saref:hasPropertyValue [
		a saref:PropertyValue ;
		saref:hasValue 105.0 ;
		saref:isMeasuredIn <https://qudt.org/2.1/vocab/unit/M2> ] .
```
</div>

<div class="alert-warning">NOTE 2: The property values are inherited in the hierarchy of feature kinds. This enables to incrementally construct prototypical descriptions of features of interest.

```
skos:broader saref:hasPropertyValue ⊑ saref:hasPropertyValue
```
</div>

<div class="alert-warning">NOTE 3: A feature of interest does not inherit the property values of its kinds. There may be multiple reasons why the property value of a feature of interest is different from that of its prototypical descriptions. For example, it may be caused by a defect, a deterioration, or a customization.</div>

The OP [saref:isValueOfProperty](#saref:isValueOfProperty) links a property value to the properties and properties of interest it is a value of.

<div class="alert-info">EXAMPLE 4:

```
<1000x2000mmWindowOrientedNorth> a saref:FeatureKind ;
  saref:hasProperty <WindowArea> ;
  saref:hasPropertyValue [
    a saref:PropertyValue ;
    saref:hasValue 2.0 ;
    saref:isMeasuredIn <https://qudt.org/2.1/vocab/unit/M2> ;
    saref:isValueOfProperty <WindowArea> ] .
```
</div>

<div class="alert-warning">NOTE 4: A property value about a property of interest is also a property value of its property kinds.

```
saref:isValueOfProperty o saref:hasPropertyKind ⊑ saref:isValueOfProperty
```
</div>


<div class="alert-warning">NOTE 5: <a href="#saref:hasPropertyValue">saref:hasPropertyValue</a> and <a href="#saref:isValueOfProperty">saref:isValueOfProperty</a> are not inverse properties.</div>

### <a id="5.7"></a>States, states of interest, and state values

#### <a id="5.7.1"></a>Introduction

In SAREF, states refer to the identifiable conditions that features of interest are or may be in, and that can be acted upon by devices, such as observed and controlled. While states can apply to different features of interest, states of interest are specific to a feature of interest. State values describe the value for a state.

<div class="alert-warning">NOTE 1: SAREF V3.2.1 introduced the class <a href="#saref:StateOfInterest">saref:StateOfInterest</a> for identifying the association between a feature of interest and a state in some smart application. Considering <a href="#saref:State">saref:State</a> was mostly instantiated in online taxonomies and vocabularies, it was decided to keep this identifier for the generic class (instead of introducing some class like "StateKind"), and introduce <a href="#saref:StateOfInterest">saref:StateOfInterest</a>.</div>

[Figure 11](#Figure_11) illustrates the main classes and properties for describing states, states of interest, and state values.

SAREF extensions and applications may create, specialize, and categorize states as specified in ETSI TS 103 548 [[5]](#[5]).

<div class="alert-warning">NOTE 2: States and Properties are parallel, distinct, but not disjoint. Users can chose whichever seems to best fit their needs. Clause 5.14 discusses Composite Properties, that help to combine properties, states and features of interest in one composite property.</div>

<figure>
  <img src="diagrams/States.png" alt="States, states of interest, and state values"/>
  <figcaption id="Figure_11">Figure 11: States, states of interest, and state values</figcaption>
</figure>

#### <a id="5.7.2"></a>States

An instance of [saref:State](#saref:State) can apply to different features of interest.

<div class="alert-info">EXAMPLE 1: A switch can be found in the <a href="#saref:OnOffState">saref:OnOffState</a>.

```
ex:OnOffState a saref:State .
	
ex:Switch a saref:FeatureKind ;
  saref:hasState ex:OnOffState .
```
</div>

<div class="alert-warning">SAREF is not restricted to binary states such as the ex:OnOffState, but allows to define also enumerated states.</div>

States can be organized in a taxonomy using properties [skos:narrower](http://www.w3.org/2004/02/skos/core#narrower) and [skos:broader](http://www.w3.org/2004/02/skos/core#broader).

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

The OP [saref:hasState](#saref:hasState) may be used to link a feature kind to its states. Its inverse is [saref:isStateOf](#saref:isStateOf).

<div class="alert-info">EXAMPLE 2:

```
s4abcd:TwoButtonsOneWaySwitch a saref:FeatureKind ;
  saref:hasState s4abcd:Button1UpDownState , s4abcd:Button2UpDownState .

s4abcd:Button1UpDownState a saref:State ;
  skos:broader s4abcd:ButtonUpDownState .

s4abcd:Button2UpDownState a saref:State ;
  skos:broader s4abcd:ButtonUpDownState .
```
</div>

<div class="alert-warning">NOTE 3: Feature kinds inherit the states of their broader feature kinds.

```
skos:broader o saref:hasState ⊑ saref:hasState
```
</div>


<div class="alert-warning">NOTE 4: Features of interest inherit the states of their feature kinds.

```
saref:hasFeatureKind o saref:hasState ⊑ saref:hasState
```
</div>

#### <a id="5.7.3"></a>States of Interest

An instance of [saref:StateOfInterest](#saref:StateOfInterest) is specific to a feature of interest. It is inherent to and cannot exist without that feature of interest.

The OP [saref:hasStateOfInterest](#saref:hasStateOfInterest) may be used to link a feature of interest to its states of interest. Its inverse is [saref:isStateOfInterestOf](#saref:isStateOfInterestOf) and is functional.

A state of interest is the state of (OP [saref:isStateOfInterestOf](#saref:isStateOfInterestOf)) exactly one feature of interest.

<div class="alert-warning">NOTE 1: States of interest need not always be explicited. It depends on the use case. Typically, states of interest are useful in applications where the association between a feature of interest and a state (i.e. the state of interest) needs to be identified and related to other entities.</div>

Given a state of interest belongs to exactly one feature of interest, it is recommended that its identifier consists of the identifier of the feature of interest, followed by character '#' and a fragment identifier. The fragment identifier part of the IRI of a state of interest should not contain "state".

<div class="alert-info">EXAMPLE 1: Switch <switch_sdf5ze4fz3> has two up/down states of interest.

```
<switch_sdf5ze4fz3> a saref:Device ;
	saref:hasDeviceKind s4abcd:TwoButtonsOneWaySwitch ; 
	saref:hasStateOfInterest <switch_sdf5ze4fz3#btn1> ;
	saref:hasStateOfInterest <switch_sdf5ze4fz3#btn2> .
<switch_sdf5ze4fz3#btn1> a saref:StateOfInterest ;
 	saref:hasStateKind s4abcd:Button1UpDownState .
<switch_sdf5ze4fz3#btn2> a saref:StateOfInterest ;
 	saref:hasStateKind s4abcd:Button2UpDownState .
```
</div>

A state of interest can be linked to its kind(s) using OP [saref:hasStateKind](#saref:hasStateKind).

<div class="alert-warning">NOTE 2: States of interest inherit broader states.

```
saref:hasStateKind o skos:broader ⊑ saref:hasStateKind
```
</div>

<div class="alert-warning">NOTE 3: Features of interest inherit the state kinds of their states of interest.

```
saref:hasStateOfInterest o saref:hasStateKind ⊑ saref:hasState
```
</div>


As the narrowest states of the taxonomy of states can be thought of as the state values, it is possible to assign a stable value to a state as follows:

#### <a id="5.7.4"></a>State Values

Class [saref:StateValue](#saref:StateValue) describes the value for a state. The state value is optionally linked the states or states of interest it is a value of (OP [saref:isValueOfState](#saref:isValueOfState)). 

<div class="alert-info">EXAMPLE 1: 
```
saref:OnState a saref:StateValue ; 
  saref:isValueOfState saref:OnOffState .
saref:OffState a saref:StateValue ;
  saref:isValueOfState saref:OnOffState.
```
</div>

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

<div class="alert-info">EXAMPLE 2: 

```
<switch_sdf5ze4fz3#btn1> a saref:StateOfInterest ;
  saref:isStateOf <switch_sdf5ze4fz3> ;
  saref:hasStateValue saref:OnState .
```
</div>

<div class="alert-info">NOTE 1: The state values are inherited in the hierarchy of feature kinds. This enables to incrementally construct prototypical descriptions of features of interest.

```
skos:broader saref:hasStateValue ⊑ saref:hasStateValue
```
</div>

<div class="alert-info">NOTE 2: A feature of interest does not inherit the state values of its kinds. There may be multiple reasons why the state value of a feature of interest is different from that of its prototypical descriptions. For example, it may be caused by a defect, a deterioration, or a customization.</div>

The OP [saref:isValueOfState](#saref:isValueOfState) links a state value to the states and states of interest it is a value of.

<div class="alert-info">NOTE 3: A state value about a state of interest is also a state value of its state kinds.

```
saref:isValueOfState o saref:hasStateKind ⊑ saref:isValueOfState
```
</div>

<div class="alert-info">NOTE 4: <a href="#saref:hasStateValue">saref:hasStateValue</a> and <a href="#saref:isValueOfState">saref:isValueOfState</a> are not inverse properties.</div>

### <a id="5.8"></a>Functions and functions of interest

#### <a id="5.8.1"></a>Introduction

In SAREF, functions are logical groups of commands that devices support to accomplish their tasks. Function can act upon (OP [saref:actsUpon](#saref:actsUpon) and its sub-properties) features, properties, or states. While functions are independent of any devices, functions of interest are functions actually supported by a device.

<div class="alert-info">NOTE: SAREF V3.2.1 introduced the class <a href="#saref:FunctionOfInterest">saref:FunctionOfInterest</a> for specifying which command is actually exposed, and which actual property of interest or state of interest it acts upon. Considering <a href="#saref:Function">saref:Function</a> was mostly instantiated in online taxonomies and vocabularies, it was decided to keep this identifier for the generic class (instead of introducing some class like "FunctionKind"), and introduce <a href="#saref:FunctionOfInterest">saref:FunctionOfInterest</a>.</div>

[Figure 12](#Figure_12) illustrates the main classes and properties for describing functions and functions of interest.

SAREF extensions and applications may create, specialize, and categorize functions as specified in ETSI TS 103 548 [[5]](#[5]).

<figure>
  <img src="diagrams/Functions.png" alt="Functions and functions of interest"/>
  <figcaption id="Figure_12">Figure 12: Functions and functions of interest</figcaption>
</figure>

#### <a id="5.8.2"></a>Functions

An instance of [saref:Function](#saref:Function) can apply to different devices.

<div class="alert-info">EXAMPLE 1: To accomplish the task of controlling the light, a smart light switch may have a function for turning on and off the light, and another to set the luminosity of the light.
</div>

<div class="alert-info">EXAMPLE 2: To accomplish the task of sensing the temperature, a temperature sensor should have a sensing function.
</div>

<div class="alert-info">EXAMPLE 3: To accomplish the task of washing clothes, a washing machine should have a function for washing.
</div>

Functions can be organized in a taxonomy using properties [skos:narrower](http://www.w3.org/2004/02/skos/core#narrower) and [skos:broader](http://www.w3.org/2004/02/skos/core#broader).

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

Kinds of devices can be defined from pre-defined building blocks, based on the functions they have.

<div class="alert-info">EXAMPLE 4:

```
s4abcd:AAHeatPumpDryer a saref:DeviceKind ;
  saref:hasFunction s4acd:WashingFunction .
```
</div>

The OP [saref:hasFunction](#saref:hasFunction) may be used to link a device kind or device to its functions. Its inverse is [saref:isFunctionOf](#saref:isFunctionOf).

<div class="alert-warning">NOTE 2: Device kinds inherit the functions of their broader device kinds.

```
skos:broader o saref:hasFunction ⊑ saref:hasFunction
```
</div>

<div class="alert-warning">NOTE 3: Devices inherit the functions of their device kinds.

```
saref:hasDeviceKind o saref:hasFunction ⊑ saref:hasFunction
```
</div>

<div class="alert-warning">NOTE 4: No just devices can have functions. OP <a href="#saref:hasFunction">saref:hasFunction</a> can link other entities to functions. For example, software applications may have functions. 
</div>

#### <a id="5.8.3"></a>Functions of Interest

An instance of [saref:FunctionOfInterest](#saref:FunctionOfInterest) is supported by exactly one device.

The OP [saref:hasFunctionOfInterest](#saref:hasFunctionOfInterest) may be used to link a device to its functions of interest. Its inverse is [saref:isFunctionOfInterestOf](#saref:isFunctionOfInterestOf) and is functional.

A function of interest is the function of (OP [saref:isFunctionOfInterestOf](#saref:isFunctionOfInterestOf)) exactly one device.

<div class="alert-warning">NOTE 1: Functions of interest need not always be explicited. It depends on the use case. Typically, functions of interest are useful to specify which command is actually exposed, and which actual property of interest or state of interest it acts upon.</div>

A function of interest can be linked to its kind(s) using OP [saref:hasFunctionKind](#saref:hasFunctionKind).

<div class="alert-warning">NOTE 2: Functions of interest inherit broader functions.

```
saref:hasFunctionKind o skos:broader ⊑ saref:hasFunctionKind
```
</div>

<div class="alert-warning">NOTE 3: Devices inherit the function kinds of their functions of interest.

```
saref:hasFunctionOfInterest o saref:hasFunctionKind ⊑ saref:hasFunction
```
</div>

### <a id="5.9"></a>Commands and commands of interest

#### <a id="5.9.1"></a>Introduction

In SAREF, commands represent the lowest-level directives a device supports and exposes to some network. Commands can act upon (OP [saref:actsUpon](#saref:actsUpon) and its sub-properties) features, properties, or states. While commands are independent of any function, commands of interest are commands actually supported by a function of interest.

<div class="alert-info">NOTE: SAREF V3.2.1 introduced the class <a href="#saref:CommandOfInterest">saref:CommandOfInterest</a> for specifying which actual property of interest or state of interest it acts upon. Considering <a href="#saref:Command">saref:Command</a> was mostly instantiated in online taxonomies and vocabularies, it was decided to keep this identifier for the generic class (instead of introducing some class like "CommandKind"), and introduce <a href="#saref:CommandOfInterest">saref:CommandOfInterest</a>.</div>

[Figure 13](#Figure_13) illustrates the main classes and properties for describing commands and device commands.

SAREF extensions and applications may create, specialize, and categorize commands as specified in ETSI TS 103 548 [[5]](#[5]).

<figure>
  <img src="diagrams/Commands.png" alt="Commands and commands of interest"/>
  <figcaption id="Figure_13">Figure 13: Commands and commands of interest</figcaption>
</figure>

#### <a id="5.9.2"></a>Commands

An instance of [saref:Command](#saref:Command) is independent of any device.

<div class="alert-info">EXAMPLE 1: Observe property, control property, observe state, control state, invoke action, cancel action, turn on or off, change colour, subscribe, publish, etc. are all commands.
</div>

Commands can be organized in a taxonomy using OPs [skos:narrower](http://www.w3.org/2004/02/skos/core#narrower) and [skos:broader](http://www.w3.org/2004/02/skos/core#broader).

Functions can be defined from pre-defined building blocks, based on the commands they have. 

The OP [saref:hasCommand](#saref:hasCommand) may be used to link a function or function of interest to its commands. Its inverse is [saref:isCommandOf](#saref:isCommandOf). SAREF Core defines two sub-properties of [saref:hasCommand](#saref:hasCommand), that only apply to functions:

- [saref:hasMandatoryCommand](#saref:hasMandatoryCommand) for when the command is mandatory to the function;
- [saref:hasOptionalCommand](#saref:hasOptionalCommand) for when the command is optional to the function

<div class="alert-warning">NOTE 1: Functions inherit the mandatory commands of their broader functions.

```
skos:broader o saref:hasMandatoryCommand ⊑ saref:hasMandatoryCommand
```
</div>

<div class="alert-warning">NOTE 2: Functions of interest inherit the mandatory commands of their function kinds.

```
saref:hasFunctionKind o saref:hasMandatoryCommand ⊑ saref:hasCommand
```
</div>

A command may be described in terms of its input parameters using OP [saref:hasInput](#saref:hasInput). Typically, input parameters are feature kinds, properties, or states.

<div class="alert-info">EXAMPLE 2: Different complementary commands can be defined for controlling a light. Turn on or off the light based on a desired state value, toggle the light status of a specific light, set the luminosity level with a transition time, set the default transition time.</div>

A command may be described in terms of its outputs using OP [saref:hasOutput](#saref:hasOutput). Typically, outputs are properties or states.

<div class="alert-info">EXAMPLE 3: Different complementary commands can be defined for observing a smart home. Observe the temperature will output the indoor temperature property value; observe status of the entry door will output an open/close state.</div>

A command may be described in terms of the properties or states it acts upon, such as observe, or control.

#### <a id="5.9.3"></a>Commands of Interest

A [saref:CommandOfInterest](#saref:CommandOfInterest) is a directive actually supported by a device and exposed to some network.

Like for commands, commands of interest may be described in terms of their input parameters, outputs, and of which properties or states they act upon.

The OP [saref:hasCommandOfInterest](#saref:hasCommandOfInterest) may be used to link a function of interest to its command of interest. Its inverse is [saref:isCommandOfInterestOf](#saref:isCommandOfInterestOf) and is functional.

A command of interest is the command of (OP [saref:isCommandOfInterestOf](#saref:isCommandOfInterestOf)) exactly one function.

<div class="alert-warning">NOTE 1: Commands of interest need not always be explicited. It depends on the use case. Typically, commands of interest are useful to specify the actual property of interest or state of interest that is expected as input parameter, output, or that will be observed or controlled.</div>

<div class="alert-info">EXAMPLE 1: The corridor smart light switch supports a command of kind "turn on/off", which controls the state of the outdoor light.</div>

<div class="alert-info">EXAMPLE 2: The smart fridge supports a command of kind "observes temperature", which observes the temperature inside the fridge.</div>

A command of interest can be linked to its kind(s) using OP [saref:hasCommandKind](#saref:hasCommandKind).

<div class="alert-warning">NOTE 2: Commands of interest inherit broader commands.

```
saref:hasCommandKind o skos:broader ⊑ saref:hasCommandKind
```
</div>

<div class="alert-warning">NOTE 3: Devices inherit the commands of their commands of interest.

```
saref:hasCommandOfInterest o saref:hasCommandKind ⊑ saref:hasCommand
```
</div>

### <a id="5.10"></a>Services and Operations

[Figure 14](#Figure_14) illustrates the main classes and properties for describing services and operations. 

<figure>
  <img src="diagrams/Service.png" alt="Services and operations"/>
  <figcaption id="Figure_14">Figure 14: Services and operations</figcaption>
</figure>

A [saref:Service](#saref:Service) is a digital representation of a function in a network, making it discoverable, registerable and remotely controllable in the network.

OP [saref:represents](#saref:represents) links a service to some function or function of interest it exposes to the network.

A service represents at least one function of interest.

OP [saref:offers](#saref:offers) links a device to a service it exposes to a network. Its inverse if [saref:isOfferedBy](#saref:isOfferedBy).

A service is offered by exactly one device.

<div class="alert-warning">NOTE 1: Typically, a device connected to a given network offers one service for each of its functions of interest.
</div>

<div class="alert-info">EXAMPLE 1: A light switch can offer the service of remotely switching the lights in a home through mobile phone devices that are connected to the local network (ex:SwitchOnService class). This "remote switching" service represents the ex:OnOffFunction.
</div>

A [saref:Operation](#saref:Operation) is the means of a service to communicate in a procedure-type manner over the network (i.e. transmit data to/from other devices). It is the -machine interpretable- exposure of a -human understandable- command to a network.

An operation may be described in terms of its inputs and outputs using OP [saref:hasInput](#saref:hasInput) and [saref:hasOutput](#saref:hasOutput). Inputs and outputs of operations typically describe the expected schema or shape of network messages.

<div class="alert-info">EXAMPLE 2: To turn on a light, send a CoAP PUT request with CBOR content `0xf5` (true).
</div>

OP [saref:represents](#saref:represents) also links an operation to some command or command of interest it exposes to the network.

An operation represents at least one command of interest.

OP [saref:hasOperation](#saref:hasOperation) links a service to its operations. Its inverse is [saref:isOperationOf](#saref:isOperationOf).

An operation belongs to exactly one service.

<div class="alert-warning">NOTE 2: Typically, a device connected to a given network offers one service for each of its functions of interest, and each service has one operation per command of interest of the function of interest it represents.
</div>

<div class="alert-info">EXAMPLE 3: In the set of operations exposed by a smart light bulb on a given network, one may be dedicated to turn on and off the light and expect a boolean as input. Another one may be dedicated to set the luminosity status and expect a target luminosity level (a byte) and a transition time (encoded on two bytes).
</div>

<div class="alert-info">EXAMPLE 4: In the set of operations exposed by a smart washing machine on a given network, one may be dedicated to set the water temperature for the washing cycle, and expected as input an enumerated value. Another one may be dedicated to start, pause, or stop the washing cycle.
</div>

<div class="alert-warning">NOTE 3: The concept of service is further elaborated in the oneM2M Base Ontology <a href="#[1]">[1]</a>, to which the reader is referred in order to model the details of a service that are out of the scope of SAREF.
</div>

### <a id="5.11"></a>Procedure executions and sub-classes

#### <a id="5.11.1"></a>Procedure executions

A [saref:ProcedureExecution](#saref:ProcedureExecution) represents the act of carrying out a procedure.

[Figure 15](#Figure_15) illustrates the main properties for describing procedure executions.
 
<figure>
  <img src="diagrams/ProcedureExecution.png" alt="Procedure executions"/>
  <figcaption id="Figure_15">Figure 15: Procedure executions</figcaption>
</figure>

OP [saref:madeBy](#saref:madeBy) links a procedure execution to the device that made it.

<div class="alert-info">EXAMPLE 1: The observation of the temperature in a room made by a temperature sensor.</div>

OP [saref:madeBy](#saref:madeBy) can link a procedure execution to any entity, not necessarily a tangible device.

<div class="alert-info">EXAMPLE 2: The prediction of the temperature in a room made by a software application.</div>

<div class="alert-info">EXAMPLE 3: A manual measurement of the circumference of a branch of a tree made by a person.</div>

A procedure execution may be linked to its inputs using OP [saref:hasInput](#saref:hasInput).

A procedure execution may be linked to its result using OP [saref:hasResult](#saref:hasResult).

DP [saref:hasStartTime](#saref:hasStartTime) links a procedure execution to the instant of time when it was initiated or tasked, expressed as an xsd:dateTime literal.

DP [saref:hasResultTime](#saref:hasResultTime) links a procedure execution to the instant of time when the procedure is completed, expressed as an xsd:dateTime literal.

OP [saref:hasPhenomenonTime](#saref:hasPhenomenonTime) links a procedure execution to the time that the result applies. It may be an interval or an instant, or some other compound temporal entity expressed using OWL Time [[8]](#[8]).

When the execution time and the phenomenon time are the same time instants, then DP [saref:hasTimestamp](#saref:hasTimestamp) can be used to simply link a procedure execution to the time of these instants, expressed as an xsd:dateTime literal. 

Optionally, a procedure execution can act upon (OP [saref:actsUpon](#saref:actsUpon)) a feature, property, or state.

#### <a id="5.11.2"></a>Command executions and operation executions

[Figure 16](#Figure_16) illustrates the main classes and properties for describing command executions and operation executions.

<figure>
  <img src="diagrams/CommandExecution.png" alt="Command executions and operation executions"/>
  <figcaption id="Figure_16">Figure 16: Command executions and operation executions</figcaption>
</figure>

A [saref:CommandExecution](#saref:CommandExecution) describes the execution of a command. Typically, its inputs and outputs are human understandable and relate to some feature of interest, such as its state (e.g. s4abcd:On), or the value of its temperature (e.g. property value 21,0 °C).

A [saref:OperationExecution](#saref:OperationExecution) describes the execution of an operation in a network: the - machine interpretable - description of a communication between devices over the network. Typically, its input and result are network messages, that conform to the input and output of the executed operation.

<div class="alert-info">EXAMPLE 1: A CoAP PUT request with CBOR content `0xf5` (true), a CoAP response with code `2.04` (Changed).
</div>

OP [saref:isExecutionOf](#saref:isExecutionOf) links a command execution to the command or command of interest that was executed.
It also liks an operation execution to the operation that was executed.

<div class="alert-warning">NOTE 1: If a command execution is an execution of a command, it is also the execution of its broader commands.

```
saref:isExecutionOf o skos:broader ⊑ saref:isExecutionOf
```
</div>

<div class="alert-warning">NOTE 2: If a command execution is an execution of a command of interest, it is also the execution of the command kind of that command of interest.

```
saref:isExecutionOf o saref:hasCommandKind ⊑ saref:isExecutionOf
```
</div>

#### <a id="5.11.3"></a>Observations and Actuations

[Figure 17](#Figure_17) illustrates the main classes and properties for describing observations and actuations.

<figure>
  <img src="diagrams/Observation.png" alt="Observations and actuations"/>
  <figcaption id="Figure_17">Figure 17: Observations and actuations</figcaption>
</figure>

A [saref:Observation](#saref:Observation) is the act of carrying out a procedure to estimate or calculate a value of a property of a feature of interest, or a state of a feature of interest. It links to a sensor to describe what made the observation, and to the observed feature, property, property of interest, state, or state of interest. Typically, its result is a property value or a state value. An observation of a state (OP [saref:observes](#saref:observes)) should have a state value as a result (OP [saref:hasResult](#saref:hasResult)). Respectively, an observation of a property should have a property value as a result.

<div class="alert-info">EXAMPLE 1:

```
ex:DTSObservation106 a saref:Observation ;
	saref:madeBy <meter> ;
	saref:hasTimestamp "2023-12-06T21:01:10"^^xsd:dateTime ;
	saref:observes s4watr:Cadmium ;
	saref:hasResult ex:Meter4837QW123Value184 .

ex:Meter4837QW123Value184 a saref:PropertyValue ;
	saref:isValueOfProperty s4watr:Cadmium ;
  saref:hasValue 0.005 .
```
</div>

<div class="alert-info">EXAMPLE 2:

```
[] a saref:Observation ;
	saref:madeBy <sensor> ;
 	saref:hasTimestamp "2023-12-06T21:47:10"^^xsd:dateTime .
	saref:observes <door_zef53ze7> ;
	saref:observes <door_zef53ze7#openclose> ;
	saref:observes saref:OpenClose ;
	saref:hasResult saref:Open .
```
</div>

<div class="alert-warning">NOTE 1: <a href="#saref:Observation">saref:Observation</a> is more general than <a href="#saref:Measurement">saref:Measurement</a>, as it applies 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="#[7]">[7]</a>. Therefore, <a href="#saref:Measurement">saref:Measurement</a> has been deprecated in version V3.2.1 <a href="#[i.8]">[i.8]</a>, and has been deleted in the present document <a href="#[0]">[0]</a>.
</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 or state value. An actuation of a state (OP [saref:controls](#saref:controls)) should have a state value as input (OP [saref:hasInput](#saref:hasInput)). Respectively, an actuation of a property should have a property value as input.

<div class="alert-warning">NOTE 2: An observation or an actuation may also be a command execution, if it corresponds to the execution of a directives a device supports and exposes to some network. However, an observation or an actuation should not be an operation execution, as these are intended to be machine interpretable descriptions of network communications.</div>

<div class="alert-warning">NOTE 3: It is acceptable that the inputs or results of a command execution are observations or actuations. For example:

- A command execution to aggregate observations will have these observations as input.
- A command execution to retrieve the past five observations will have these observations as output.
- A command execution to plan a series of actuations will have these actuations as input, and potentially also as result if successful. 
</div>

### <a id="5.12"></a>Profiles

A device in SAREF can be further characterized by profiles. [Figure 18](#Figure_18) illustrates the main classes and properties for describing profiles.

<figure>
  <img src="diagrams/Profiles.png" alt="Profiles"/>
  <figcaption id="Figure_18">Figure 18: Profiles</figcaption>
</figure>

A [saref:Profile](#saref:Profile) describes the money earned (negative values) or paied (positive values) for the use (production or consumption) of a commodity by a device in a certain context.

OP [saref:hasProfile](#saref:hasProfile) links a device to its profile. Its inverse is [saref:isProfileOf](#saref:isProfileOf). The device should be linked to a certain commodity using OP [saref:isUsedFor](#saref:isUsedFor) or its sub-properties, and optionally to some property or state using OP [saref:actsUpon](#saref:actsUpon) or its sub-properties.

<div class="alert-info">EXAMPLE 1:

```
ex:Device_1 a saref:Device ;
	saref:isUsedFor s4abcd:Electricity ;
	saref:hasProfile ex:FlexibilityProfile ;
	saref:controls <house#temperature> .
ex:FlexibilityProfile a saref:Profile ;
	saref:hasPrice <pricePropertyValue> .
```
</div>

The applicable context of a profile can be bound temporally using DP [saref:hasTimestamp](#saref:hasTimestamp) or its subproperties defined by SAREF extensions, or OP [saref:hasApplicableTime](#saref:hasApplicableTime) which links to instant or interval or other compound temporal entity expressed using OWL Time [[8]](#[8]).

<div class="alert-warning">NOTE: <a href="#saref:hasApplicableTime">saref:hasApplicableTime</a> may be applied to other entities, such as functions, commands, or procedure executions.
</div>

<div class="alert-info">EXAMPLE 2:

```
ex:FlexibilityProfile saref:hasTimestamp "2023-12-15T11:00:00"^^xsd:dateTime .
```
</div>

<div class="alert-info">EXAMPLE 3:

```
ex:FlexibilityProfile
	rdfs:comment "applies only on Saturdays"@en ;
  saref:hasApplicableTime [ 
		a time:DateTimeDescription ;
		time:dayOfWeek time:Saturday ] .
```
</div>

The applicable context can be restricted to when the property of a feature of interest has some value (OPs [saref:whenPropertyValue](#saref:whenPropertyValue)).

<div class="alert-info">EXAMPLE 4:

```
ex:FlexibilityProfile saref:whenPropertyValue [
  a saref:PropertyValue ;
  saref:hasValue 22.0 ;
  saref:isMeasuredIn <http://qudt.org/vocab/unit/DEG_C> ;
 	saref:isValueForProperty <house#comfort_temperature_setpoint> ] .
```
</div>

The applicable context can be restricted to when a feature of interest has a certain state value (OPs [saref:whenState](#saref:whenState)).

<div class="alert-info">EXAMPLE 5:

```
ex:FlexibilityProfile
saref:whenState [
  a saref:StateValue ;
  skos:broader s4abcd:ComfortSetpoint ;
 	saref:isStateOf <house#temperature_setpoint> ] .
```
</div>
   
OP [saref:profileHasPrice](#saref:profileHasPrice) links a profile to the money earned (negative values) or paid (positive values) for the use (production or consumption) of the commodity by the device.

<div class="alert-info">EXAMPLE 6:

```
ex:FlexibilityProfile saref:profileHasPrice [
  a saref:PropertyValue ;
  saref:hasValue 0.2 ;
  saref:isMeasuredIn <http://qudt.org/vocab/currency/EUR> ] .	
```
</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 [[i.9]](#[i.9]). 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 class="alert-info">EXAMPLE 7:

```
ex:FlexibilityProfile a saref:Profile ;
	s4abcd:{someConditionDefinedBySAREF4ABCD} <conditionSpecification> .
```
</div>

### <a id="5.13"></a>Features of Interest, devices, and spatial objects

An instance may be classified as both [saref:FeatureOfInterest](#saref:FeatureOfInterest) and [geo:SpatialObject](http://www.opengis.net/ont/geosparql#SpatialObject).

The class [saref:Device](#saref:Device) is a sub-class of [geo:Feature](http://www.opengis.net/ont/geosparql#Feature) from the GeoSPARQL standard [[9]](#[9]), section 6.2.

SAREF application may attach a geometry to a [saref:FeatureOfInterest](#saref:FeatureOfInterest) or a [saref:Device](#saref:Device) using [geo:hasGeometry](http://www.opengis.net/ont/geosparql#hasGeometry) or its sub-properties [geo:hasBoundingBox](http://www.opengis.net/ont/geosparql#hasBoundingBox), [geo:hasCentroid](http://www.opengis.net/ont/geosparql#hasCentroid), [geo:hasDefaultGeometry](http://www.opengis.net/ont/geosparql#hasDefaultGeometry) [[9]](#[9]), section 6.4.

<div class="alert-info">EXAMPLE 1:

```
<etsi_premises> a saref:FeatureOfInterest , geo:Feature ; 
	geo:hasCentroid "POINT( 7.052986 43.6169446 )"^^geo:wktLiteral .
```
</div>

SAREF application may describe how things are spatially related using different families of topological relations from GeoSPARQL, such as the Simple Features relation family (e.g. [geo:sfWithin](http://www.opengis.net/ont/geosparql#sfWithin), [geo:sfOverlaps](http://www.opengis.net/ont/geosparql#sfOverlaps)), the Egenhoer Relation Family (e.g. [geo:ehInside](http://www.opengis.net/ont/geosparql#ehInside), [geo:ehOverlap](http://www.opengis.net/ont/geosparql#ehOverlap)), the RCC8 Relation Family (e.g. [geo:rcc8tpp](http://www.opengis.net/ont/geosparql#rcc8tpp), [geo:rcc8po](http://www.opengis.net/ont/geosparql#rcc8po)) [[9]](#[9]), section 7.

<div class="alert-info">EXAMPLE 2:

```
<etsi_premises/athena> a saref:FeatureOfInterest , geo:Feature ; 
	geo:sfWithin <etsi_premises> .
```
</div>

### <a id="5.14"></a>Composite Properties and Property Values

The OP [saref:consistsOf](#saref:consistsOf) can link a composite property, property of interest, or property value to its individual components. 


<div class="alert-warning">NOTE 1: A feature kind or feature of interest has the individual components of its composite properties.

```
saref:hasProperty o saref:consistsOf ⊑ saref:hasProperty
```
</div>

Composite Properties can consist of feature kinds, properties, and states. [Figure 19](#Figure_19) illustrates the local restrictions of [saref:consistsOf](#saref:consistsOf) on the class [saref:Property](#saref:Property).

<figure>
  <img src="diagrams/composedOf_2.png" alt="Local restrictions of saref:consistsOf on the class of Properties"/>
  <figcaption id="Figure_19">Figure 19: Local restrictions of <a href="#saref:consistsOf">saref:consistsOf</a> on the class of Properties</figcaption>
</figure>

<div class="alert-info">EXAMPLE 1: A 2D position property observed by a position sensor consists of x and y coordinates.
  
```
s4abcd:2DPosition_xCoordinate a saref:Property .
s4abcd:2DPosition_yCoordinate a saref:Property .
s4abcd:2DPosition a saref:Property ;
  saref:consistsOf s4abcd:2DPosition_xCoordinate ;
  saref:consistsOf s4abcd:2DPosition_yCoordinate .
```
</div>
  

<div class="alert-info">EXAMPLE 2: A composite presence property observed by a smart presence sensor consists of persons, an occupied/not occupied state, and a temperature property.
  
```
ex:Person a saref:FeatureKind .
s4abcd:OccupiedOrNotOccupied a saref:State .
s4abcd:Temperature a saref:Property .
s4abcd:CompositePresence a saref:Property ;
 	saref:consistsOf ex:Person ;
 	saref:consistsOf s4abcd:OccupiedOrNotOccupied ;
 	saref:consistsOf s4abcd:Temperature .
```
</div>

In addition, properties of interest can be composed of features of interest, properties of interest and states of interest. [Figure 20](#Figure_20) illustrates the local restrictions of [saref:consistsOf](#saref:consistsOf) on the class [saref:PropertyOfInterest](#saref:PropertyOfInterest).

<figure>
  <img src="diagrams/composedOf_3.png" alt="Local restrictions of saref:consistsOf on the class of Properties of Interest"/>
  <figcaption id="Figure_20">Figure 20: Local restrictions of <a href="#saref:consistsOf">saref:consistsOf</a> on the class of Properties of Interest</figcaption>
</figure>

<div class="alert-warning">NOTE 2: When composed of a property of interest, a property of interest is also composed of the kinds of this property of interest.

```
saref:consistsOf o saref:hasPropertyKind ⊑ saref:consistsOf
```
</div>


<div class="alert-warning">NOTE 3: When composed of a state of interest, a property of interest is also composed of the kinds of this state of interest.

```
saref:consistsOf o saref:hasStateKind ⊑ saref:consistsOf
```
</div>

In addition, property values can be composed of property values, and state values. [Figure 21](#Figure_21) illustrates the local restrictions of [saref:consistsOf](#saref:consistsOf) on the class [saref:PropertyValue](#saref:PropertyValue).

<figure>
  <img src="diagrams/composedOf_4.png" alt="Local restrictions of saref:consistsOf on the class of Property Values"/>
  <figcaption id="Figure_21">Figure 21: Local restrictions of <a href="#saref:consistsOf">saref:consistsOf</a> on the class of Property Values</figcaption>
</figure>


<div class="alert-info">EXAMPLE 4: A 2D position value as the result of the observation made by a position sensor.
  
```
<position_sensor> a s4abcd:PositionSensor ;
  saref:madeExecution <observation> .
<observation> a saref:Observation ;
  saref:observes s4abcd:2DPosition, <room> ;
  saref:hasResult <value> .
<value> a saref:PropertyValue ;
  saref:consistsOf <value_x> , <value_y> .
<value_x> a saref:PropertyValue ;
  saref:isValueOfProperty s4abcd:2DPosition_xCoordinate ;
  saref:hasValue 2 .
<value_y> a saref:PropertyValue ;
  saref:isValueOfProperty s4abcd:2DPosition_yCoordinate ;
  saref:hasValue 3 .
```
</div>


<div class="alert-info">EXAMPLE 5: A composite presence value as the result of the observation made by a smart presence sensor.
  
```
<smart_camera> a s4abcd:SmartPresenceSensor ;
	saref:madeExecution <observation> .
<observation> a saref:Observation ;
  saref:observes s4abcd:CompositePresence, <room> ;
  saref:hasResult <composite_presence_value> .
<composite_presence_value> a saref:PropertyValue ;
	saref:consistsOf <person1>, <person2> ;
	saref:consistsOf s4abcd:Occupied ;
	saref:consistsOf <temperature_value> .
s4abcd:Occupied a saref:StateValue ;
 	saref:isValueOfState s4abcd:OccupiedOrNotOccupied .
<temperature_value> a saref:PropertyValue ;
	saref:hasValue 22.7 ;
	saref:isMeasuredIn <https://qudt.org/2.1/vocab/unit/DEG_C> .
```
</div>

<div class="alert-warning">NOTE 4: When composed of a property value, a property value is also composed of that value's property.

```
saref:consistsOf o saref:isValueOfProperty ⊑ saref:consistsOf
```
</div>

<div class="alert-warning">NOTE 5: When composed of a state value, a property value is also composed of that value's state.

```
saref:consistsOf o saref:isValueOfState ⊑ saref:consistsOf
```
</div>

<div class="alert-warning">NOTE 6: When composed of a feature of interest, a property value is also composed of the kind of that feature of interest.

```
saref:consistsOf o saref:hasFeatureKind ⊑ saref:consistsOf
```
</div>

