ETSI TR 103 549 V1.1.1 (2019-07)

SmartM2M; Guidelines for consolidating SAREF with new reference ontology patterns, based on the experience from the ITEA SEAS project

DTR/SmartM2M-103549

General Information

• Status: Published
• Publication Date: 16-Jul-2019
• Technical Committee: SmartM2M - Smart M2M
• Current Stage: 12 - Completion
• Due Date: 08-Aug-2019
• Completion Date: 17-Jul-2019

Standards Content (Sample)

TECHNICAL REPORT
SmartM2M;
Guidelines for consolidating SAREF with
new reference ontology patterns,
based on the experience from the ITEA SEAS project


2 ETSI TR 103 549 V1.1.1 (2019-07)

Reference
DTR/SmartM2M-103549
Keywords
energy efficiency, energy management, EV,
industry, intelligent homes & buildings,
interoperability, IoT, oneM2M, ontology,
renewable, SAREF, semantic, smart grid, testing
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2019.
All rights reserved.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI TR 103 549 V1.1.1 (2019-07)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definition of terms, symbols and abbreviations . 6
3.1 Terms . 6
3.2 Symbols . 6
3.3 Abbreviations . 6
4 Consolidation of SAREF using ontology patterns . 7
5 Related initiatives . 7
6 Use cases . 8
6.1 Introduction . 8
6.2 Use case 1: Smart Energy . 8
6.2.0 Introduction. 8
6.2.1 Types, topology and properties of the Features Of Interest . 8
6.2.2 Kinds of measures . 8
6.3 Use case 2: Smart Building . 9
6.3.0 Introduction. 9
6.3.1 Types, topology, and properties, of the Features Of Interest . 9
6.3.2 Kinds of measures . 9
7 Analysis of the modularization and factorization potential of SAREF . 9
7.1 Introduction . 9
7.2 Modularization . 10
7.3 Factorization . 10
8 Ontology patterns . 12
8.1 Introduction . 12
8.2 Functions, commands, states, services . 12
8.3 Features Of Interest, states and properties . 13
8.4 Characterizing states and properties . 14
8.5 Features Of Interest, properties and devices . 16
8.6 Platform, system and deployment . 17
8.7 Systems, connections and connection points . 18
8.7.0 Introduction. 18
8.7.1 Systems . 18
8.7.2 Connections . 19
8.7.3 Connection points . 19
8.7.4 Instances of the ontology pattern . 20
8.8 Concept hierarchy extension . 20
8.9 Concept specialization . 21
8.10 Concept instantiation . 22
9 Issues and recommended resolution in SAREF . 23
10 Conclusions . 33
History . 35

ETSI
4 ETSI TR 103 549 V1.1.1 (2019-07)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Smart Machine-to-Machine
communications (SmartM2M).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
5 ETSI TR 103 549 V1.1.1 (2019-07)
1 Scope
The present document specifies the functional requirements for a set of reference ontology patterns for the SAREF
semantic model, along with guidelines for developing extensions to this semantic model for multiple engineering-
related verticals. The present document has been developed leveraging the experience of the EUREKA ITEA 12004
SEAS (Smart Energy Aware Systems) project, and the development of the OGC&W3C SSN (Semantic Sensor
Network) ontology. It illustrates the applications of the guidelines with use cases for Smart Energy, Smart Building, and
Industry of the Future/Industry 4.0 verticals. The associated ETSI TS 103 548 [i.1] will define the update to SAREF and
its extensions based on the requirements and guidelines specified in the present document.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TS 103 548: "SmartM2M; SAREF consolidation with new reference ontology patterns,
based on the experience from the SEAS project".
[i.2] ETSI TS 103 264 (V2.1.1): "SmartM2M; Smart Appliances; Reference Ontology and oneM2M
Mapping".
[i.3] ETSI TS 103 410-1 (V1.1.1): "SmartM2M; Smart Appliances Extension to SAREF; Part 1:
Energy Domain".
[i.4] ETSI TS 103 410-2 (V1.1.1): "SmartM2M; Smart Appliances Extension to SAREF; Part 2:
Environment Domain".
[i.5] ETSI TS 103 410-3 (V1.1.1): "SmartM2M; Smart Appliances Extension to SAREF; Part 3:
Building Domain".
[i.6] ETSI TS 103 410-4 (V1.1.1): "SmartM2M; Extension to SAREF; Part 4: Smart Cities Domain".
[i.7] ETSI TS 103 410-5 (V1.1.1): "SmartM2M; Extension to SAREF; Part 5: Industry and
Manufacturing Domains".
[i.8] ETSI TS 103 410-6 (V1.1.1): "SmartM2M; Extension to SAREF; Part 6: Smart Agriculture and
Food Chain Domain".
[i.9] ETSI TR 103 411 (V1.1.1): "SmartM2M; Smart Appliances; SAREF extension investigation".
[i.10] A. Haller, K. Janowicz, S. Cox, D. Le Phuoc, K. Taylor, M. Lefrançois, R. Atkinson, R. García-
Castro, J. Lieberman, C. Stadler: "Semantic Sensor Network Ontology". W3C Recommendation,
19 October 2017.
NOTE: Available at https://www.w3.org/TR/vocab-ssn/.
ETSI
6 ETSI TR 103 549 V1.1.1 (2019-07)
[i.11] M. Lefrançois, J. Kalaoja, T. Ghariani, A. Zimmerman: "The SEAS Knowledge Model", ITEA2
12004 Smart Energy Aware Systems Deliverable 2.2, January 2017.
NOTE: Available at http://w3id.org/seas/.
[i.12] M. Lefrançois, A. Zimmermann, N. Bakerally: "A SPARQL extension for generating RDF from
heterogeneous formats", in Proc. Extended Semantic Web Conference, 2017.
NOTE: Available at http://w3id.org/sparql-generate.
[i.13] H. Rijgersberg, M.F.J. van Assem, J.L. Top: "Ontology of Units of Measure and Related
Concepts." Semantic Web, 4, 1, 2013, pp. 3-13.
NOTE: Available at http://www.ontology-of-units-of-measure.org/page/om-2.
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
ontology: formal specification of a conceptualization, used to explicitly capture the semantics of a certain reality
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
CHE Concept Hierarchy Extension
CS Concept Specialization
EMSE École des Mines de Saint-Étienne, France
FOI Feature Of Interest
FOIPD Feature Of Interest, Properties and Devices
GECAD/ISEP Knowledge Engineering and Decision-Support Research Center, School of Engineering,
Polytechnic of Porto, Portugal
IoT Internet of Things
IRI Internationalized Resource Identifier
ITEA Information Technology for European Advancement
OGC Open Geospatial Consortium
OM Ontology of Measurements
OWL Web Ontology Language
PEP Procedure Execution Ontology
PSD Platform, System and Deployment
QUDT Quantities, Units, and DataTypes
RDF Resource Description Framework
RG Research Group
RMS Root Mean Square amplitude
RN Phase R to Neutral
SAREF Smart Appliances REFerence ontology
SEAS Smart Energy Aware Systems
SN Phase S to Neutral
SOSA Sensor, Observation, Sample, and Actuator
SPARQL SPARQL Protocol And RDF Query Language
SSN Semantic Sensor Networks
STF ETSI Specialist Task Force
ETSI
7 ETSI TR 103 549 V1.1.1 (2019-07)
TB Technical Body
THD Total Harmonic Distortion
TN Phase T to Neutral
TR Technical Report
TS Technical Specification
URI Universal Resource Identifier
URL Universal Resource Locator
W3C World Wide Web Consortium
4 Consolidation of SAREF using ontology patterns
SAREF (V2.1.1) (ETSI TS 103 548 [i.2]) is a reference ontology for the IoT developed by ETSI SmartM2M in close
interaction with the industry. SAREF contains core concepts that are common to several IoT domains and, to be able to
handle specific data elements for a certain domain, dedicated extensions of SAREF have been created, for example
SAREF4ENER (ETSI TS 103 410-1 [i.3]), SAREF4ENVI (ETSI TS 103 410-2 [i.4]), SAREF4BLDG (ETSI
TS 103 410-3 [i.5]), and SAREF4CITY (ETSI TS 103 410-4 [i.6]), SAREF4INMA (ETSI TS 103 410-5 [i.7]),
SAREF4AGRI (ETSI TS 103 410-6 ) [i.8]. Each domain can have one or more extensions, depending on the
complexity of the domain. As a reference ontology, SAREF serves as the means to connect the extensions in different
domains. The earlier document ETSI TR 103 411 [i.9] specifies the rationale and methodology used to create, publish
and maintain the SAREF extensions.
Ontology patterns are like design patterns in object oriented programming. They describe structural, logical, naming, or
documentation best practices that one can consider when building an ontology.
The present document provides an analysis of the potential of modularization and factorization of the SAREF core
ontology (V2.1.1) (ETSI TS 103 548 [i.2]) as patterns.
Then, the present document specifies a set of ontology patterns for the modelling and the description of any kind of
engineering-related data/information/systems; that may be used to consolidate SAREF.
Finally, the present document lists a set of issues that are identified in the current version of SAREF, and proposes
changes to consolidate SAREF.
The present document has been developed in the context of the STF 556
(https://portal.etsi.org/STF/STFs/STFHomePages/STF556.aspx), which was established with the goal to consolidate
SAREF and its community of industrial users based on the experience of the EUREKA ITEA 12004 SEAS (Smart
Energy Aware Systems) project. The present document specifies requirements for an initial set of SAREF extensions
instantiating the defined ontology patterns, for some use cases taken from SEAS project, therefore filling some of the
representational gaps that were identified during this project.
5 Related initiatives
In this clause, some of the main related initiatives in terms of modelling reference ontology patterns for the IoT, and
using these ontology patterns to develop ontologies, are reviewed.
• Joint OGC and W3C Spatial Data on the Web working group: the SSN (Semantic Sensor Network)
ontology [i.10] is a modular ontology using some design patterns that were instantiated manually. One of these
design patterns involves different kinds of systems and the procedures they execute: Sensors, Actuators and
Samplers, execute Observation, Actuation and Sampling activities.
• OntologyDesignPatterns.org: This website references ontology design patterns, which are classified in
different categories such as Content, Logical, or Lexico-Syntactic patterns.
• EUREKA ITEA 12004 SEAS: The SEAS ontology [i.11] is a modular and versioned ontology with all the
terms it defines having the same namespace (https://w3id.org/seas/). It contains a core of SEAS reference
ontology patterns that can be instantiated to create the SEAS ontology itself with a homogeneous and
predictable structure for the modelling and the description of any kind of engineering-related
data/information/systems. These design patterns and some of their instances fill some of the representational
gaps that were identified in SAREF.
ETSI
8 ETSI TR 103 549 V1.1.1 (2019-07)
6 Use cases
6.1 Introduction
The SEAS (Smart Energy Aware Systems) project was a 35 partners and 13 500 000 € project that ran from February
2014 to December 2016 (https://itea3.org/project/seas.html), and received the ITEA Award of Excellence 2017. Its goal
was to design and develop an eco-system of smart things and services, collectively capable of optimizing the energy
efficiency within the future Smart Grid. 100 use cases were defined by 35 partners, from which some identified gaps not
yet covered by SAREF to be filled in the SEAS knowledge model. SAREF focuses on the notion of Device, while
industry use cases often require some description of the physical systems and their connections, value association for
their properties, and the activities by which such value association is done. The SEAS ontology development was
initiated during a workshop that gathered 45 participants during 3 days and continued with close collaborations between
ontology engineering experts, domain experts, and industry software architects.
6.2 Use case 1: Smart Energy
6.2.0 Introduction
New SAREF ontology patterns can be used to homogeneously represent knowledge that is relevant for use cases in the
Smart Energy domain.
6.2.1 Types, topology and properties of the Features Of Interest
• An Actuator Switch acts on the state of a specific device. Given a device, one should be able to know what are
the switches that can act on it.
• A Smart-Meter measures the energy consumption of the energy grid at a certain point of the energy grid.
• Electric power systems can exchange electricity with other electric power systems. The electric energy can
flow both ways in some cases (from the Public Grid to a Prosumer), or in only one way (from the Public Grid
to a Load). Electric power systems can be made up of different sub-systems. Generic sub-types of electric
power systems include producers, consumers, storage systems, transmission systems. The properties that are
relevant for these systems include power production, consumption, energy stored. These properties may be
measured or acted on by IoT devices.
• Electric power systems may be connected one to another through electrical connection points. An Electric
power system may have multiple connection points (Multiple Winding Transformer generally have one single
primary winding with two or more secondary windings). Generic sub-types of electrical connection points
include plugs, sockets, direct-current, single-phase, three-phase, connection points. The properties that are
relevant for these connection points include Voltage, Resistance, Conductance, Reactance, Susceptance, and
can be measured between two wires of the connection points.
• An Electrical connection may exist between two Electric power systems at two of their respective connection
points. Generic sub-types of electrical connections include Single-phase Buses, Three-phase Buses. A
single-phase electric power system can be connected using different configurations at a three-phase bus (RN,
SN, TN types). The properties that are relevant for a three-phase electric bus include voltage between the
different wires R, S, T, N (R-to-N, S-to-N, R-to-S, etc.). IoT devices can be used to measure and control this
voltage at different points of the grid.
6.2.2 Kinds of measures
• Every electric power device potentially consumes and produces electric power, and stores electric energy.
Over a given period of time, different Smart Meters may measure different aggregated values for these
quantities. E.g. cumulative (sum), maximum, minimum, average.
• Quantities that evolve periodically are usually described in terms of their frequency, the peak, RMS amplitude,
THD of the quantity value. Smart Meters may measure different aspects of a direct current, single-phase
alternating current, or three-phase alternating electric current.
ETSI
9 ETSI TR 103 549 V1.1.1 (2019-07)
• Some properties are controllable, such as the consumption or production of electric power systems. The
reduction, augmentation, cut, move flexibility, of a specific controllable property can be evaluated (and
valuated).
6.3 Use case 2: Smart Building
6.3.0 Introduction
New SAREF ontology patterns can be used to homogeneously represent knowledge that is relevant for use cases in the
Smart Building domain.
6.3.1 Types, topology, and properties, of the Features Of Interest
• A light switch acts on the luminosity of a specific room. Given a room, one should be able to know what light
switch may be used to change the luminosity in this room.
• Temperature Sensors, Heaters, Coolers, observe or act on a specific zone of a building. Given a zone, one
should be able to know what are the devices that observe or act on the temperature in this zone.
• Buildings, Storeys, Spaces, are different sub-types of Zones. Zones can contain sub-zones. Zones can be
adjacent or intersect with other zones. The properties that are relevant for these systems include temperature,
luminosity, humidity, pressure, population. These properties may be measured or acted on by IoT devices.
• Two zones may share one or more connections. For example some fresh air may be a created inside a storey if
it has two controllable openings to the exterior at different cardinal points. Different properties may be
relevant depending on the connection between zones. Observing and controlling the flow of humans or
animals, total heat transfer, pressure difference, wind speed, may be relevant for controllable openings.
6.3.2 Kinds of measures
• Temperature, pressure, humidity, can be observed or acted upon by dedicated IoT devices. An observation
may be instantaneous, or aggregated over a period of time: maximum, minimum, average. Derived properties
may be evaluated, like the number of occurrences for a certain temperature rising above a threshold.
• Depending on the quantity, derived quantities may be observed such as the sum (interesting for properties like
flows of humans/animals, or rain precipitation), or the growth rate (important for controlling the pressure in
specific zones like planes or cleanrooms).
7 Analysis of the modularization and factorization
potential of SAREF
7.1 Introduction
This clause provides an analysis of the potential of modularization and factorization of the SAREF core ontology
(V2.1.1) (ETSI TS 103 548 [i.2]). It highlights inter-dependent parts of the ontology, parts that are more or less central,
and parts that are repeated homogeneously for different concepts (patterns). The result of this analysis is illustrated on
Figure 1, and detailed in the next clauses.
ETSI
10 ETSI TR 103 549 V1.1.1 (2019-07)
7.2 Modularization
In Figure 1, a box illustrates a module constituted by a subset of concept declarations and axioms of SAREF core
(V2.1.1) (ETSI TS 103 548 [i.2]). Each module has a label in bold font, and the lower part of the box lists the concept
declarations that belong to this module. Axioms are not shown in Figure 1. For example, the box labelled Service-core
contains the concept declarations and axioms related to the terms saref:Service, saref:isOfferedBy,
saref:offers, saref:represents. The terms saref:Function and saref:hasFunction will also be
grouped in one single module because they share a similar name.
A directed link between two boxes illustrate a dependency between the two modules. The label of a link explicits the
rationale, and potentially the condition, for this dependency. For example, the module Service-core depends on the
module Functions and Commands because there exists an axiom in SAREF stating that every saref:Service
represents some saref:Function. Therefore, saref:Service cannot be defined without the
saref:Function. In general, restrictions such as existential cardinality restrictions and minimal cardinality
restrictions are used to decide on the direction of a dependency.
The grouping of concept declaration and axioms of SAREF in modules and the orientation of the dependencies between
modules is partly made by choosing to view SAREF according to a certain perspective, and partly for intuitive reasons.
For example, it makes sense to consider that saref:Property can be defined independently of
saref:Measurement, but not the other way around. Therefore, the dependency link will be oriented from
Measurement-core to Property-core.
It is necessary to group the concepts and axioms related to functions and commands into one single module Functions
and Commands, because there exists axioms in SAREF stating that every saref:Function is associated to at least
one saref:Command, and vice versa.
This analysis can be used to discuss conceptual issues in the axiomatization of SAREF. For example, SAREF (V2.1.1)
(ETSI TS 103 548 [i.2]) contains an axiom that specifies that every saref:Task is accomplished by at least one
saref:Device. This results in the module Task-core depending on the module Device-core, which is odd. In fact,
tasks should be defined independently of devices.
Second, this analysis can be used to modularize SAREF core (V2.1.1) (ETSI TS 103 548 [i.2]): modules or group of
modules with no incoming dependencies are not required for other modules. They could be safely filtered out in the
documentation on the portal or in some embedded implementation of SAREF, without impacting the rest of the
documentation or application. For example, the two modules Service-core and specific Service have no incoming
dependency, therefore they are not essential to the specification of the rest of the ontology.
7.3 Factorization
In Figure 1, a box with an underlined label represents a pattern which can be applied to different concepts. For example,
the pattern specific Sensor can be instantiated for saref:SmokeSensor and saref:TemperatureSensor. The
pattern specific Function can be instantiated for saref:ActuatingFunction, saref:OpenCloseFunction,
etc.
These instantiated patterns have dependency links with other modules, and potentially other patterns. The latter are to
be understood as dependencies between two specific pattern instances. For example, the instance of pattern specific
Function for saref:OpenCloseFunction has a dependency to instance of pattern specific Command for
saref:OpenCommand and saref:CloseCommand, because they are the types of commands this function can
have.
This factorization analysis is used to extract the existing ontology patterns in SAREF core (V2.1.1) (ETSI
TS 103 548 [i.2]). Future evolutions of SAREF may progressively migrate to using languages and tools to generate the
ontology from patterns and some description of the instances of these patterns. A proof of concept of such a pattern
instantiation mechanism for SAREF is implemented using the SPARQL-Generate RDF transformation language [i.12].
ETSI
11 ETSI TR 103 549 V1.1.1 (2019-07)

Figure 1: Analysis of the modularization and factorization potential of SAREF-Core (V2.1.1)
ETSI
12 ETSI TR 103 549 V1.1.1 (2019-07)
8 Ontology patterns
8.1 Introduction
This clause presents the ontology patterns for SAREF resulting from:
• the incorporation of SEAS and SSN core ontology patterns, resolving any incompatibility that could arise with
SAREF in the process;
• the specification of the common patterns that form the backbone of the SAREF family of ontologies.
8.2 Functions, commands, states, services
In SAREF, sensing, actuating, metering, are kinds of functions. Usually, a function (e.g.
saref:StartStopFunction) has one or more commands to trigger it (e.g. for saref:StartStopFuncton,
this should be either a saref:StartCommand or a saref:StopCommand). Some commands act upon some state
(saref:StartStopCommand acts upon some saref:StartStopState).
There is an implicit ontology pattern that is used for functions, commands, states, in SAREF. This clause will
explicit this pattern.
NOTE 1: Some saref:Commands have a "generic" instance.
NOTE 2: saref:StepUpCommand and saref:StepDownCommands could be defined as specific kinds of
saref:SetRelativeLevelCommand.
NOTE 3: SAREF also has a command named saref:PauseCommand, which is associated with no Function.
The meaning of Commands in SAREF is different from the meaning of Commands in SEAS. Instead, it is very close to
the meaning of the SEAS Sensing, Actuating, Forecasting, Planning, Metering, are Procedures. SEAS specifies that an
input and output of the procedures can be described. Devices can "implement" and "execute" these procedures. The
Executions of these procedures have commands and results (see Figure 2).
The ontology pattern for functions, commands, states, in SAREF, should be augmented with the input, output, and the
description of the executions of these commands.
NOTE 4: In SAREF, a device may implement all the commands of a function it has, as "a package". It may be
interesting to link a device directly to a specific command.

Figure 2: The PEP pattern: IoT Devices implement procedures and
make executions of these procedures (activities)
In SAREF, Service is defined as a "representation of a function to a network that makes the function discoverable,
registerable, remotely controllable by other devices in the network. A service can represent one or more functions.
[…]". Although multiple commands are defined (on, off, start, stop, …) only one type of service is defined:
saref:SwitchOnService. Other such services should be defined for each of the other kind of commands.
Table 1 list generic requirements for ontology patterns related to functions, commands, states, services.
ETSI
13 ETSI TR 103 549 V1.1.1 (2019-07)
Table 1: Guidelines to write requirements for instantiations
of the "Functions, commands, states, services" ontology patterns
Id Requirement
A {#Device} that implements a function {#Function} has commands for {#list of
F-1
possible Commands}.
A window opener that implements an open/close function does implement commands for
opening and closing the window.
Example
A heater that implements an on/off function does implement commands for turning on or off
the heater.
A {#ActuationFunction} of a {#actuator} acts on a {#State or Property} of a {#Feature
F-2
of Interest}.
An open/close function of a window opener acts on the open/close state of a window.
Example
A level control function of a heater acts on the temperature of a space.
A {#SensingFunction} of a {#sensor} observes the {#State or Property} of a {#Feature
F-3
of Interest}.
Example A sensing function of a temperature sensor measures the temperature of a room.
A {#EventFunction} of a {#sensor} watches the {#State or Property} of a {#Feature of
F-3
Interest}.
A {#MeteringFunction} of a {#meter} provides measures about the {#State or
F-3
Property} of a {#Feature of Interest}.
A metering function of a smart meter measures the RMS amplitude, THD, peak value for the
Example voltage and current between every pairs of R, S, T, N wires of an electrical connection point,
and the cumulative consumption of the associated electric power system.

8.3 Features Of Interest, states and properties
Features Of Interest are of high relevance for the IoT domain. Measurements and actuations are made for properties of
specific Features Of Interest. Features Of Interest may also have states. For example, not only devices can be in Open
and Close state, but also a Door or a Window.
The meaning of seas:Property generalizes the concepts of saref:State and saref:Property. A
seas:Property is specific to a feature of interest and can be observed, acted on, forecasted, planned, estimated.

Figure 3: Illustration of the FOI pattern from SEAS
ETSI
14 ETSI TR 103 549 V1.1.1 (2019-07)
The SAREF saref:Property as defined in SAREF may be aligned with the SEAS seas:Property concept. In
addition, SEAS proposes a mechanism to avoid artificially duplicate properties such as
saref:InactiveDurationMin, saref:InactiveDurationMax, saref:ActiveDurationMax,
saref:ActiveDurationMin, saref:ActiveDurationSumMax, saref:ActiveDurationSumMin, etc.
These artificially duplicated properties raise issues such as: which of them is the one a sensor observes, or an actuator
acts upon. The SEAS approach consists in linking a Feature of interest to only one instance of the Property class
through a relationship named seas:activeDuration. Then this instance of a property can be of a generic type
seas:DurationProperty, and be observed by a sensor or be acted on by an actuator. SEAS also assumes that
sub-classes of seas:Property hold the information about the quantity kind of the property such as
seas:PowerProperty, seas:PercentProperty, seas:OpenCloseStatus, whereas the relationships that
link the feature of interest to the instances of properties would be named seas:electricConsumption,
seas:humidity, or seas:windowOpenCloseStatus. There is no distinction among the properties regarding
the way they are qualified or quantified. A property may be quantified using literals having any datatype, or also using
named individuals that may be further qualified elsewhere. It is therefore possible to define a property such as
seas:operator of a machine, provided that there is only one such seas:operator at any point in time. A face
recognition sensor may observe this property, and detect who the current operator is (a person identified by his/her own
IRI). The way one may associate actual values with a property or state is defined in clause 8.4.
Therefore, the proposal for SAREF is:
• to introduce the concept saref:FeatureOfInterest, which has e.g. saref:Device as a sub-class;
• to make saref:State a sub-class of saref:Property;
• to define three intricated patterns for extending the saref:FeatureOfInterest, and
saref:Property classes, and the saref:hasProperty relationship;
• keep the state instances.
Table 2 lists generic requirements for ontology patterns related to Features Of Interest, States, Properties.
Table 2: Guidelines to write requirements for instantiations
of the "Feature Of Interest, states and Properties" ontology patterns
Id Requirement
FOI-1 A {#Feature Of Interest} is either in {#possible values for State} states.
A door is either in Open or Closed state.
Example
A heater is either in On or Off state.
FOI-2 A {#Feature Of Interest} has a {#Property}, of kind {#Super-Property}.
A hydraulic cylinder has a unique, of kind length.
Example
A room has a temperature, of kind temperature.
FOI-3 A {#Sensor} observes the {#State of PropertyKind} of a {#Feature Of Interest}
Example A temperature sensor observes the Temperature property of a room.
FOI-4 A {#Actuator} acts on the {#State of PropertyKind} of a {#Feature Of Interest}
An heater acts on the temperature property of a room.
Example
A window opener acts on the open or close state of a window.
FOI-5 All those Features Of Interest that have a {?property} are of type {?featureOfInterest}
All those Features Of Interest that have a speed are of type mobile object.
Example
All those Features Of Interest that have a position are of type geolocated object.
FOI-3 The {?property} of any feature of interest is a {?propertyKind}
The consumedElectricalPower of any feature of interest is a PowerProperty.

8.4 Characterizing states and properties
SEAS defines the class seas:Evaluation as a means to assign a value to a property or a state. This
seas:Evaluation class may be aligned to the saref:Measurement class in SAREF. Integrating the
seas:Evaluation in SAREF adds interesting representational capabilities on top of the saref:Measurement.
SEAS defines different patterns that can be instantiated in different verticals.
ETSI
15 ETSI TR 103 549 V1.1.1 (2019-07)
The evaluation is true when each of its validity contexts are true. A validity context may be a temporal context,
described with the OWL Time ontology, it may also be a spatial context described with geoSPARQL (the temperature
in a certain part of the city), or any other condition (e.g. other evaluations of other properties). Again, SEAS decouples
the sub-class of evaluations and the sub-classes of properties. Sub-classes of Evaluation describe the aspect of the
evaluation of the property over the given context that is given a value to. For example, considering the property
seas:speed of a car (an instance of the type seas:CelerityProperty which is specific to a certain car),
evaluations of the car may be a diverse as follows:
• the average speed of the car on a certain portion or road;
• the current speed of the car;
• the maximum operating speed of the car (in any context);
• the number of times the car speeded above 100 km/h during the past hour;
• the duration during which the car was speeding above 100 km/h during the past hour;
• the maximum derivative value of the speed of the car (an acceleration value) during the past hour;
• a multi-valued state (very-slow, slow, fairly-fast, fast, very-fast).
The actual value (a literal or a named individual) is linked through the relation seas:evaluatedSimpleValue
(for literals) and seas:evaluatedValue (for named individuals). Literals may be of any datatype, such as
cdt:ucum for quantities, xsd:int or xsd:boolean, or any other datatype. Named individuals may be instances
of states (On, Off), an instance of qudt:QuantityValue or om:Measure (with a unit of measure and a float or a
double), or anything else.
Comparatively, the concept saref:Measurement is:
• only for properties (not states);
• mandatorily for xsd:float values, with a unit of measures (no integer or boolean);
• valid at a certain time stamp (not in a more general context such as time interval and geolocation);
• not linked to the actual feature of interest whose property is quantified;
• not heavily specialized in SAREF extensions (only a flat list of quantities is defined).
Therefore, the proposal is to deprecate the saref:Measurement class and use instead the seas:Evaluation
pattern.
Figure 4 illustrates the SEAS pattern for characterizing states and properties, and the way it may enrich the concept of
SAREF saref:Measurement, illustrated on Figure 5.
ETSI
16 ETSI TR 103 549 V1.1.1 (2019-07)

Figure 4: Illustration of the Evaluation pattern from SEAS

Figure 5: Illustration of the Measurement class in SAREF (V2.1.1)
8.5 Features Of Interest, properties and devices
Features Of Interest (FOIs) are of high relevance for the IoT domain including also sub-domains as Smart Cities and
Smart Agriculture. For example, when generating KPIs as city indicators, such indicators might be related to a given
feature of interest in the city. In addition, FOIs might have one or more properties to be observed, for example, one can
measure the average speed or the CO level of a road or the moisture level or the type of soil of a crop.
ETSI
17 ETSI TR 103 549 V1.1.1 (2019-07)

Figure 6: The FoIPD Pattern: Feature of Interests their properties and devices controlling them
Table 3 lists generic requirements for ontology patterns related to Features of Interest, Properties and Devices.
Table 3: Guidelines to write requirements for instantiations
of the "Feature Of Interest, Properties and Devices" ontology pattern
Id Requirement
A {#FeatureOfInterest} has one or more {# Property}.
...