Content uploaded by Maxime Lefrançois
Author content
All content in this area was uploaded by Maxime Lefrançois on Jul 05, 2023
Content may be subject to copyright.
Chapter 7
The ETSI SAREF ontology
for smart applications: a long
path of development and
evolution
Ra´ul Garc´ıa-Castro,1* Maxime Lefran¸cois,2Mar´ıa
Poveda-Villal´on,1and Laura Daniele3
1Ontology Engineering Group, Universidad Polit´ecnica de Madrid, Madrid, Spain
2Mines Saint- ´
Etienne, Univ. Clermont Auvergne, INP Clermont Auvergne, CNRS,
Saint- ´
Etienne, France
3TNO, Netherlands Organization for Applied Scientific Research, The Hague, The
Netherlands
*Corresponding Author: Author; r.garcia@upm.es
Abstract:
This book chapter provides the motivation for the SAREF ontology as
well as its relationship with existing IoT ontologies, focussing on the smart
home and smart application domains. Provides the context of its origin
and evolution since its first version published by ETSI in November 2015
and details how it is developed in practice. The chapter not only provides
an overview of the SAREF ontology but also shows how SAREF and its
extensions can be applied to the smart home environment and discusses
1
the lessons learnt during its design and development.
Keywords: SAREF, ontology, IoT, smart home, energy, water, building,
city
7.1. Introduction
Building smart applications in the Internet of Things (IoT) field requires in-
terchanging and using information from others - whether people or machines -,
but also being able to understand such information unambiguously. To address
this issue, the European Telecommunications Standards Institute (ETSI) Tech-
nical Committee (TC) on Machine-to-Machine, SmartM2M, leads the Smart
Applications REFerence ontology (SAREF) initiative with the goal of bringing
a common understanding among cross-domain heterogeneous systems.
IoT fragmentation is one of the main threats to the adoption of IoT tech-
nologies on a large scale. To overcome this, the current fragmented landscape
of IoT technologies requires standardised interfaces and data models to ensure
interoperability. In this scenario, one of the main challenges to ensure interop-
erability is having a set of standard data models that enable interchanging not
only information but also the meaning of such information to avoid misinter-
pretations between senders and receivers.
To cope with this, the European Commission has promoted the SAREF on-
tology in collaboration with ETSI SmartM2M TC since 2014 with the goal of
providing and maintaining a common data model over time to ensure interop-
erability. The SAREF ontology is a reference data model enriched with formal
semantics, intended to enable interoperability between solutions from different
providers and among various activity sectors in the IoT, thus contributing to
2
the development of the global digital market. Over time, SAREF has evolved
into a suite of ontologies that includes a general-purpose ontology (i.e., SAREF
core, which is currently in its third release), 11 extensions, and an ontology
pattern. It further defines a clear workflow for development and versioning and
provides a portal to its user community for documentation and collaborative
development. Several experts have made great efforts in the past years (2014-
2022) to document the extensive work of SAREF in technical reports and
specifications, scientific papers, project deliverables, websites, etc., but this in-
formation is often perceived by stakeholders as scattered and not easy to find.
This book chapter provides stakeholders with the opportunity to find this in-
formation in one single place, including a historical overview of the SAREF
activities since its first release, a description of the main SAREF concepts that
are relevant for the smart home environment (from SAREF, SAREF4ENER,
SAREF4BLDG, SAREF4WATR, SAREF4CITY and SAREF4SYST), a clar-
ification of the mechanism for version control and the automatic tool support
for the ontology developers. Everything according to the best practises for
ontology standardisation adopted in ETSI SmartM2M TC.
The rest of this chapter is organised as follows. Section 7.2 presents the
need for a standard ontology that can serve as an umbrella to represent con-
textual and multisectorial IoT-related data and will review the most relevant
existing IoT ontologies. Section 7.3 introduces the SAREF initiative with a
brief history of the SAREF ontology, promoted by the European Commission
and the European Telecommunications Standards Institute (ETSI), from its
initial conception to its current third version and 11 extensions. Section 7.4 de-
scribes the main ontology requirements followed when developing the SAREF
ontology, as well as the design patterns implemented in the ontology and the
3
main design decisions and lessons learnt during development. Section 7.5 pro-
vides an overview of the SAREF ontology and its main classes and properties.
Section 7.6 describes how the SAREF ontology and its extensions can be ap-
plied to smart appliances and the smart home environment. To do so, it will
describe the main extensions that are relevant for this environment: those
for the energy, water, building, and smart city domains and the extension to
represent systems. Section 7.7 presents examples of the use of the SAREF on-
tology focussing on the environment of Smart Homes. Section 7.8 discusses
some lessons learnt from the development and evangelization of SAREF to the
industry. Section 7.9 concludes the chapter and discusses future work.
7.2. IoT ontologies for semantic inter-
operability
One of the cornerstones to making the Internet of Things a reality is the
interoperability between heterogeneous services and actors. Such heterogeneity
appears at different levels, for example at the protocol level for connectivity,
temporal validity or update of data, data storage, language, etc. Focussing on
data interoperability, different levels of interoperability should be addressed:
transport (how data are accessed), syntactic (how data are expressed), and
semantic (how data are modelled). Ontologies play a key role in addressing
and allowing semantic interoperability in many heterogeneous data scenarios,
including IoT. For this reason, a number of ontologies have been developed.
Hundreds of ontologies for IoT and related domains are listed in ontol-
4
ogy repositories such as the LOV4IoT1catalogue [Gyrard et al., 2016], which
registers and classifies IoT ontologies considering a wide number of domains
such as transport, healthcare, energy agriculture, city, weather, etc. Another
ontology registry in which IoT ontologies can be found is Linked Open Vocab-
ularies2(LOV) [Vandenbussche et al., 2017], a general-purpose ontology index.
The ontology landscape maintained by the Alliance for the Internet of Things
Innovation (AIOTI)3provides a more focused overview of the main IoT ontolo-
gies structured by their domain of interest, taking into account aspects such as
sustainability (i.e., who is maintaining it) and technology readiness level (i.e.,
how mature it is).
One of the main ontologies developed in the context of IoT is the Semantic
Sensor Network (SSN) ontology developed by the first joint working group of
the Open Geospatial Consortium (OGC) and the World Wide Web Consortium
(W3C) on Spatial Data on the Web. SSN4was released in 2017 and is composed
of the SSN module5and a module called SOSA6(Sensor, Observation, Sampler
and Actuator), among others. The SOSA module replaces the SSO pattern
(Stimulus Sensor Observation Pattern) and could be used in isolation in a
lightweight fashion. The main components of the SOSA module are “sensors
and observations”, “samplings and samples” and “actuators and actuations”.
SSN augments SOSA with additional terms and a stronger axiomatisation.
Another relevant ontology in the IoT domain is the oneM2M base on-
tology [ETSI, 2016, oneM2M, 2018], created to provide the definition of the
1http://lov4iot.appspot.com
2https://lov.linkeddata.es
3https://aioti.eu/aioti-ontology-landscape- report
4https://www.w3.org/TR/vocab-ssn/
5http://www.w3.org/ns/ssn
6http://www.w3.org/ns/sosa
5
concepts, relations, and restrictions needed to allow the semantic discovery
of entities in oneM2M systems. The objective of oneM2M for this ontology
is to provide syntactic and semantic interoperability between oneM2M sys-
tems and external systems that could derive new ontologies based on the
oneM2M base model. The oneM2M ontology focusses on the description of
oneM2M:Thing which is specialised as oneM2M:Device. For devices, their func-
tions (oneM2M:Function) and services (oneM2M:Service) are modelled. Ser-
vices are linked to the operations (oneM2M:Operation) they provide, which
can expose commands (oneM2M:Command).
Finally, the Web of Things ontology could be mentioned in relation to
IoT ontologies based on the Web of Things (WoT) Thing Description7, devel-
oped under the W3C WoT working group activities. The core vocabulary of
the Thing Description includes the representation of interaction affordances in
addition to the metadata needed to represent the abstraction of physical or
virtual entities, called Things. The interaction affordances are classified into
Properties (used for sensing and controlling parameters by exposing internal
state of the thing), Actions (used to invoke physical processes and set the inter-
nal state of the thing not exposed as properties), and Events (used to describe
the event sources that asynchronously push messages).
7.3. The SAREF initiative
SAREF originated from a standardisation initiative launched by the European
Commission in collaboration with ETSI in 2013, when more than forty percent
7https://www.w3.org/TR/wot-thing-description/
6
of the total energy consumption in the European Union used to be produced
by the residential and tertiary sector, of which a large part were residential
houses. Appliances, which are inherent in the building ecosystem, were con-
sidered among the culprits of this high energy consumption. Therefore, the
European Commission (EC) identified an immediate need for the market to
optimise energy use by managing and controlling appliances at the system
level. In particular, industry and the EC raised the need for standardised in-
terfaces and a common data model to ensure interoperability and overcome
market fragmentation. The development of a reference ontology was targeted
as the main interoperability enabler for appliances relevant for energy efficiency,
and ETSI was accepted to cover the communication aspect and provide the
necessary standardisation process support. As a result, after a comprehensive
consultation with stakeholders to address clear market needs, the EC finan-
cially supported a study (SMART 2013/01077) to create a reference ontology
for smart appliances [Daniele et al., 2015b]. The study was carried out from
January 2014 to April 2015 in close collaboration with smart appliance man-
ufacturers, and the resulting ontology, SAREF, was standardised by ETSI in
November 2015 (TS 103 264 v1.1.1).
In 2016, ETSI TC SmartM2M requested a Specialist Task Force (STF) to
provide input on the evolution of SAREF and create possible extensions in
relevant domains of interest. STF 513 was established and developed the first
three extensions for SAREF in the energy, environment, and building domains,
resulting in SAREF4ENER (TS 103 410-1), SAREF4ENVI (TS 103 410-2)
and SAREF4BLDG (TS 103 410-3). STF 513 also developed a second version
of SAREF, taking into account feedback received from industry stakeholders
since its first release in April 2015. As a result, a new version of SAREF was
7
published in March 2017 (TS 103 264 V2.1.1).
In 2017, the first SAREF-based proof-of-concept solution was demonstrated
and implemented on existing commercial products in the energy domain, as
part of a second study launched by the EC to ensure interoperability to enable
Demand Side Flexibility (SMART 2016/0082) [Daniele and Strabbing, 2018].
A new series of initiatives promoted by ETSI and the EC followed in re-
cent years (e.g., STF 534, STF566, STF578) in which more extensions have
been created for additional domains such as smart cities, agriculture, industry
and manufacturing, automotive, eHealth, wearables, and smart lifts, making
SAREF a modular framework that comprises SAREF as generic core ontology
(TS 103 264 V3.1.1), 11 domain specific extensions (TS 103 410, parts 1-11)
and an ontology pattern for systems, connections, and connection points (TS
103 548). The SAREF framework is maintained and evolved under the umbrella
of ETSI by an ecosystem of experts from various research organisations, uni-
versities and industry in Europe who collaborate successfully with each other.
One of the latest supported initiatives is the development of an open portal
for the SAREF community and industry stakeholders, so that they can also
directly contribute to the evolution of SAREF8. SAREF is currently adopted
in a considerable number of European projects that provide applications of
semantic interoperability solutions in various domains and are encouraged to
contribute with their results and findings to the standardisation and evolution
process in the ETSI SmartM2M TC.
8https://saref.etsi.org/
8
7.4. Specification and design of the SAREF
ontology
The general development framework for the SAREF ontology and its extensions
(generally referred to as SAREF projects) is specified in the ETSI TS 103 673
technical specification [ETSI, 2020k], and is hosted on the public ETSI Forge
portal https://saref.etsi.org/sources/.
7.4.1. A modular and versioned suite of ontolo-
gies
As illustrated in Figure 7.1, the SAREF suite of ontologies is composed of
ontologies that define generic patterns such as SAREF4SYST [ETSI, 2020g]
(detailed in Section 7.6.5), a core ontology SAREF Core [ETSI, 2020j] illus-
trated in Figure 7.4 (detailed in Section 7.5), and different extensions devel-
oped for distinct vertical domains: SAREF4ENER for energy [ETSI, 2020e],
SAREF4ENVI for environment [ETSI, 2020f], SAREF4BLDG for smart build-
ings [ETSI, 2020f], SAREF4CITY for smart cities, SAREF4INMA for manufac-
turing, SAREF4AGRI for agriculture, SAREF4AUTO for automotive [ETSI,
2020a], SAREF4EHAW for health [ETSI, 2020d], SAREF4WEAR for wear-
ables [ETSI, 2020i], SAREF4WATR for water management [ETSI, 2020h], and
SAREF4LIFT for smart lifts [ETSI, 2021].
As SAREF is specified in the ETSI technical documents, it uses Semantic
Versioning. Each module of the ontology has a distinct version composed of
three numbers: a MAJOR, a Minor, and a patch. The increase in MAJOR
9
Pattern for
Measurements
Pattern for
Functions and
Commands
Pattern for
Features of
Interest and
Properties
SAREF4SYST
SAREF-core
SAREF4LIFT
Smart Lifts
SAREF4WATR
Water
SAREF4WEAR
Wearables
SAREF4EHAW
eHealth / Ageing Well
SAREF4AUTO
Automotive
SAREF4AGRI
Argrifood
SAREF4INMA
Indus. & Manuf.
SAREF4CITY
Smart City
SAREF4BLDG
Building
SAREF4ENVI
Environment
SAREF4ENER
Energy
Figure 7.1: The SAREF suite of ontologies with its different modules
indicates a break in backward compatibility. The increment in Minor indicates
the addition of features. The increment in the patch indicates the correction
of a bug.
7.4.2. Methodology
In general, the development of SAREF ontologies follows the Linked Open
Terms (LOT) methodology [Poveda-Villal´on et al., 2022], which adopts a V-
model approach with conditional feedback in some development stages. More
specifically, the SAREF development framework defines the different work-
flows to be followed for new SAREF project versions, SAREF project version
development, and SAREF project release. The following roles are defined:
Steering Board member A Steering Board member belongs to the group
of persons in charge of steering the development of SAREF, including
the SAREF core and SAREF extensions, community participation, and
10
the underlying infrastructure.
Technical Board member A Technical Board member belongs to the group
of persons in charge of maintaining the SAREF public forge and the
SAREF public portal.
Project leader A project leader is the person in charge of the SAREF project
who performs project management tasks.
Ontology developer An ontology developer is a member of the ontology de-
velopment team who has a great understanding of ontology development
and the rights to modify the ontology and interact in the development
cycle. Ontology developers create and modify the different development
artefacts, provide new requirements to the ontology, validate whether
they are satisfied or not when implemented, and have decision rights
about what contributions can be included in the ontology.
Contributor A contributor is a person who is knowledgeable about the on-
tology domain and who proposes contributions.
Ontology user An ontology user is someone interested in any of the SAREF
projects or in proposing a new SAREF project.
Different workflows are established for the creation of an ontology version,
the development of an ontology version, and the publication of a project [ETSI,
2020k, Clauses 6.1, 7.1, 8.1]. For example, Figure 7.2 illustrates the workflow for
the development of project versions that supports the development of SAREF
project versions from the SAREF community of users. SAREF project ver-
sions may be new versions of SAREF core, new versions of existing SAREF
extensions, or initial versions (V1.1.1) of new SAREF extensions. The SAREF
11
project version development workflow is formulated around the use of issues
in the corresponding SAREF project issue tracker on the ETSI public forge.
This enables us not only to have a single point of interaction for development,
but also to keep track of the development activity and discussions. Any update
in a SAREF project version should be made through a change request, which
is posted as an issue in the corresponding repository of the ETSI public forge
and is assigned an issue number. This includes change requests related to new
ontology requirements, defects, or improvements in the ontology specification,
in the ontology tests, ontology examples, or ontology documentation. Any con-
tributor can create a new change request or review and discuss existing change
requests. Ontology developers should review change requests, propose, and re-
view implementations of accepted change requests. The Steering Board should
review change requests. The Project leader is responsible for ensuring that the
change requests are approved by SmartM2M and that the implementations of
the change requests satisfy the requested change.
7.4.3. Version Control and Editing Workflow
The sources of the SAREF ontologies are hosted on the public ETSI Forge
portal (https://saref.etsi.org/sources/), with four different types of branches:
issue-x branches to work on an issue, develop-vx.y.z branches to work on
a version, prerelease-vx.y.z branches to work on the final validation of the
ontology, and release-vx.y.z branches for published versions. Protection rules
are defined to prevent ontology developers from directly pushing their changes
to development-vx.y.z branches or from directly accepting merge requests in
prerelease-vx.y.z branches.
12
Approved
change request
is clear
implementation
is clear
Needs
Implementation
implementation
is clear
after discussion
implementation
starts
implementation
is not clear
Submitted
Needs
Clarication
change request
is not clear
Needs
Discussion
Work
In Progress
implementation
is not approved
Implementation
Available
implementation
ends
change request
is submitted
change request
is updated
Propose Closing
change request
is dismissed
implementation
is dismissed
Closed
change request
is closed
implementation
is approved
Figure 7.2: The SAREF project version development workflow (adapted from
[ETSI, 2020k])
There are two main practises to identify software versions with git: version
tags and release branches. The development of SAREF ontologies uses this
second approach, which allows documentation or examples to continue evolving
even when an ontology version is published.
7.4.4. Automatization of requirements and qual-
ity checks
The requirements for every SAREF ontology project are listed in a specific
CSV document with three columns: an identifier, a category, and a require-
13
ment expressed as an assertion or a competency question [ETSI, 2020k, Clause
9]. These requirements are then assessed with the Themis tool [Fern´andez-
Izquierdo and Garc´ıa-Castro, 2019].
A set of rules that a SAREF ontology repository must comply with is also
defined in the ETSI TS 103 673 technical specification [ETSI, 2020k, Clause 9].
The SAREF Pipeline application allows each of these rules to be evaluated with
severity level: (a) structure of the repository directory, (b) presence of a defined
license file, (c) specification of the ontology requirements, (d) presence of a
well-formed file /saref4[a-z]{4}.ttl/, (e) declaration of predefined prefixes,
(f) presence of an ontology declaration, with a series Internationalized Resource
Identifier (IRI) and a version IRI conforming to the naming of the git branch
(ex: develop-v2.1.1), (g) possible imports of other SAREF ontologies by their
version IRI, (h) presence of creators and contributors, (i) naming convention
for classes, properties, instances, (j) presence of metadata for each term, (k) the
ontology must be in the OWL 2 DL profile, (l) the ontology must be consistent,
(m) each class must be satisfiable, (n) no pitfall must be detected by the OOPS!
scanner [Poveda-Villal´on et al., 2014], (o) presence of tests, (p) presence and
quality of examples, and (q) existence of external terms used.
Some of these tests use SHACL shapes [Knublauch and Kontokostas, 2017],
others use OWLAPI functionalities after cloning the necessary repositories.
The message folder of the application gives a global view of all the errors that
can be identified9. The SAREF Pipeline can be used with a graphical interface
(Figure 7.3a) or a command line (Figure 7.3b). The error report is formatted
as markdown, allowing one to quickly open an issue to collaboratively deal
9https://labs.etsi.org/rep/saref/saref-pipeline/-/tree/master/src/main/resources/
messages
14
with problems (Figure 7.3c). Finally, the application generates different seri-
alizations for ontologies and examples, and an HTML documentation inspired
by LODE and rewritten with SPARQL-Generate [Lefran¸cois et al., 2017]. See,
for example, https://saref.etsi.org/core or https://saref.etsi.org/core/Command.
7.4.5. Continuous Integration and Deployment
We configured Gitlab CI/CD in each SAREF ontology repository to run the
SAREF pipeline differently depending on the type of branch where a commit is
pushed (issue, develop, pre-release, release), and finally automatically pushes
the output files to the SAREF documentation portal https://saref.etsi.org/. Fig-
ure 7.3d illustrates the automatic execution of the SAREF pipelines.
7.5. Overview of the SAREF ontology
Figure 7.4 shows an overview of the main classes of SAREF and their relation-
ships. Then a detailed explanation of each class is presented.
7.5.1. Device
SAREF focuses on the concept of device, which is defined as “a tangible ob-
ject designed to perform a particular task in households, public buildings, or
offices. To accomplish this task, the device performs one or more functions”.
Examples of devices are a light switch, a temperature sensor, an energy meter
and a washing machine. A washing machine is designed to wash (task) and to
accomplish this task it performs a start and stop function. The saref:Device
15
(a) Running the SAREF pipeline with
the graphical interface https://saref.etsi.
org/sources/saref-pipeline/
(b) Running the SAREF pipeline from
the command line https://saref.etsi.org/
sources/saref-pipeline/
(c) The output of the SAREF pipeline is
formatted in markdown and can be used
to create an issue
(d) Overview of the integration and
continuous deployment pipeline:
Snapshot,Staging,Manual release.
Source: https://saref.etsi.org/sources/
saref4ehaw/-/pipelines
Figure 7.3: The SAREF pipeline checks the compliance of a SAREF project
with respect to the ETSI TS 103 673 technical specification [ETSI, 2020k,
Clause 9], and generates the public portal.
16
saref:Function saref:Command
saref:isCommandOf
saref:hasCommand
saref:Device
saref:hasFunction
saref:Service
saref:isOfferedBy
saref:offers
saref:represents
saref:Task
saref:isAccomplishedBy
saref:actsUpon
saref:State
saref:hasState
saref:Property
saref:Measurement
saref:UnitOfMeasure
saref:FeatureOfInterest
saref:isMeasuredByDevice
saref:isControlledByDevice
saref:measuresProperty
saref:controlsProperty
saref:relatesToProperty
saref:relatesToMeasurement
saref:makesMeasurement
saref:measurementMadeBy
saref:isPropertyOfsaref:hasProperty
saref:isMeasurementOf
saref:hasMeasurement
saref:isMeasuredIn
Figure 7.4: Overview of the SAREF ontology (adapted from [ETSI, 2020j])
class and its properties are shown in Figure 7.4.
A saref:Device can have some properties that uniquely characterise it,
namely its model and manufacturer (saref:hasModel and saref:hasManufacturer
properties, respectively).
SAREF is conceived in a modular way in order to allow the definition of
any device from predefined building blocks, based on the function(s) that it
performs. Therefore, a saref:Device has at least one function (saref:hasFunction
min 1 saref:Function) and can be used for (saref:isUsedFor property) the pur-
pose of offering a commodity, such as saref:Water or saref:Gas. It can also
measure properties such as saref:Temperature, saref:Energy, and saref:Smoke.
Moreover, a device may consist of other devices (saref:consistsOf property).
The device types that can be represented are actuators (e.g., a saref:Switch
that can be further specialised in saref:LightSwitch and saref:DoorSwitch),
17
sensors (e.g., a saref:SmokeSensor and saref:TemperatureSensor), meters, and
appliances. Note that there are more types of devices, sensors, and actuators
that can be defined to extend SAREF (the device types in Figure 4 represent
only some examples that explain the rationale behind SAREF). A description
of these types of device is presented in the next clause, in combination with the
function they perform. Examples of devices for specific domains are defined in
the SAREF extensions.
7.5.2. Feature of interest and property
Features of Interest (FOIs) are of high relevance for the IoT domain, including
also subdomains such as smart cities and smart agriculture. For example, when
generating KPIs as city indicators, such indicators might be related to a given
FOI in the city. Additionally, FOIs may have one or more properties to be
observed; for example, one can measure the average speed or the CO2 level of
a road, the moisture level, or the type of soil of a crop.
SAREF borrows the modelling pattern from the SOSA/SSN ontology, with
classes saref:FeatureOfInterest: “any real-world entity from which a property
is measured” and saref:Property: “a quality of a feature of interest that can be
measured; an aspect of a feature of interest that is intrinsic to and cannot exist
without the feature”. A FOI can be linked to its properties using the property
saref:hasProperty.
7.5.3. Measurement
The classes saref:Measurement, saref:Property, and saref:UnitOfMeasure al-
low relating different measurements from a given device for different proper-
18
ties measured in different units, i.e., the saref:Measurement class describes a
measurement of a physical quantity (using the saref:hasValue property) for
a given saref:Property and according to a given saref:UnitOfMeasure. In this
way, it is possible to differentiate between properties and measurements made
for such properties and to store measurements for a concrete property in dif-
ferent units of measurement. Furthermore, a timestamp can be added (us-
ing the saref:hasTimestamp property) to identify when the measurement ap-
plies to the property, which can be used for single measurements or for se-
ries of measurements (e.g. measurement streams). Figure 7.4 shows that a
saref:Device can measure or control a saref:Property (which may be from a
saref:FeatureOfInterest), which in turn relates to a saref:Measurement, which
in turn is measured in a given saref:UnitOfMeasure. Note that it is also pos-
sible to follow the inverse direction in which a saref:Device makes a measure-
ment in a certain unit of measure (using the saref:makesMeasurement prop-
erty), and this measurement can be related to a saref:Property (using the
saref:relatesToProperty property). A saref:FeatureOfInterest represents any
entity of the real world from which a saref:Property is measured.
As an example, the saref:Power and saref:Energy classes can be related to a
certain measurement value (using the saref:hasValue property), which is mea-
sured in a certain unit of measure, e.g., kilowatt for power (saref:PowerUnit)
and kilowatt Hour for energy (saref:EnergyUnit). Analogously, the saref:Price
class can be related to a certain measurement value that is measured using a
certain saref:Currency, which is a subclass of the saref:UnitOfMeasure class.
Further examples of how to define units of measure can be found in the different
SAREF extensions.
The saref:Time class allows one to specify the concept of time in terms
19
of temporal entities (i.e., instants or intervals) according to the existing W3C
Time ontology to avoid defining this concept from scratch.
7.5.4. Service, function, command and state
Figure 7.4 shows that a device offers a service (the saref:Service class), which
is a representation of a function in a network that makes this function dis-
coverable, registerable, and remotely controllable by other devices in the net-
work. A service shall represent at least one function (saref:represents min 1
saref:Function) and is offered by at least one device that wants (a certain
set of) its function(s) to be discoverable, registerable, and remotely control-
lable by other devices in the network (saref:isOfferedBy min 1 saref:Device).
Multiple devices can offer the same service. A service shall specify the de-
vice that is offering the service and the function(s) to be represented. For
example, a light switch can offer the service of remotely switching lights in a
home through mobile phone devices that are connected to the local network
(saref:SwitchOnService class). This “remote switching” service represents the
saref:OnOffFunction previously described. Note that the concept of service is
further elaborated in the oneM2M Base Ontology, to which the reader is re-
ferred in order to model the details of a service that are out of the scope of
SAREF.
A function is represented in SAREF with the saref:Function class and is de-
fined as ”the functionality necessary to accomplish the task for which a device
is designed”. Examples of functions are saref:ActuatingFunction, which allows
transmitting data to actuators; saref:SensingFunction, which allows transmit-
ting data from sensors; saref:MeteringFunction, which allows obtaining data
20
from meters; and saref:EventFunction, which allows contacting other devices.
A saref:Function shall have at least one command associated to it (saref:has-
Command min 1 saref:Command). Furthermore, a command can act on a state
(saref:actsUpon relation) to represent that the consequence of a command can
be a change in the state of a device. Note that a command may act upon
a state, but it does not necessarily need to act upon a state. For example,
saref:OnCommand acts on saref:OnOffState, but saref:GetCommand does not
act on any state, since it only gives a directive to retrieve a certain value.
Depending on the function(s) it performs, a device can be found in a corre-
sponding saref:State. For example, a switch can be in saref:OnOffState, which is
also specialised in saref:OnState and saref:OffState. A light switch can be found
in saref:OnOffState on which saref:OnCommand and saref:OffCommand will
act. Note that SAREF is not restricted to binary states such as saref:OnOffState,
but allows us to also define n-ary states (see the saref:MultiLevelState class).
7.6. The SAREF ontology in the smart
home environment
This section describes how the SAREF ontology and its extensions can be
applied to smart appliances and the smart home environment. To do so, it
will describe the main extensions that are relevant for this environment: those
for the energy, water, building, and smart city domains and the extension to
represent systems.
As Figure 7.5 presents, the SAREF ontology includes a set of generic classes
that can be used in smart homes to represent features of interest, measure-
21
ments, devices, and their profiles. From these and depending on the aspects of
interest, terms from one or multiple extensions can be reused.
The SAREF4ENER extension allows one to represent information on the
power profile of any device. It specialises the Device and Profile classes of
SAREF to allow us to include further energy-related information.
The SAREF4WATR extension enables representing information related to
the water domain; not only at the device level through water devices (such as
water meters), but also at the infrastructure level by describing water assets
and infrastructures. The systems underlying these assets and infrastructures
can be described in detail using the SAREF4SYST extension.
With the SAREF4BLDG extension, devices (and other building objects)
can be included in the context of a particular building. The extension also
allows us to represent the topology of a building through its building spaces.
Finally, the SAREF4CITY extension extends the context of features of
interest, devices, and their measurements to the smart city. To do so, new
spatial features are defined, such as facilities and administrative areas, and
city objects can also be represented in them.
This last extension also adds the possibility of representing key performance
indicators. In this way, performance measurements and their assessments can
be defined for features of interest at any level.
22
s
a
ref
:
D
evice
s
a
ref
:
M
e
a
surement s
a
ref
:
F
e
a
ture
O
f
I
nterest
s
4
city
:
K
ey
P
erform
a
nce
I
ndic
a
tor
s
4
syst
:
S
ystem
s
4
w
a
tr
:
Wa
ter
I
nfr
a
structures
4
w
a
tr
:
Wa
ter
A
sset
s
4
w
a
tr
:
Wa
ter
D
evice
geosp
:
F
e
a
ture
s
4
city
:
Fa
cility s
4
city
:
A
dministr
a
tive
A
re
a
s
4
city
:
C
ity
O
bjects
4
bldg
:
B
uilding s
4
bldg
:
B
uilding
S
p
a
ce s
4
bldg
:
P
hysic
a
l
O
bject
s
4
bldg
:
B
uilding
O
bject
s
4
bldg
:
B
uilding
D
evice s
4
ener
:
D
evice
s
a
ref
:
P
ro
fi
le
s
4
ener
:
P
ower
P
ro
fi
le
Figure 7.5: Main SAREF classes that are relevant for the smart home environ-
ment 23
7.6.1. Energy
SAREF4ENER is the first extension of SAREF that was created in 2016
in collaboration with industry associations EEBus10 and Energy@Home11 to
allow interconnection of their different data models [Daniele et al., 2016].
SAREF4ENER is based on EN50631 by CLC TC59 WG7 (EEbus SPINE).
SAREF4ENER focusses on demand response scenarios, in which customers
can offer flexibility to the Smart Grid to manage their smart home devices by
means of a Home Energy Manager System (HEMS). The HEMS is a logical
function for optimising energy consumption and/or production that can reside
either in the cloud or in a home gateway. Moreover, the Smart Grid can in-
fluence the quantity or patterns of use of the energy consumed by customers
when energy-supply systems are constrained, e.g. during peak hours. These
scenarios involve use cases such as smart energy management of appliances in
certain modes and preferred times using power profiles to optimise energy effi-
ciency and accommodate the customer’s preferences; monitoring and control of
the start and status of appliances; reaction to special requests from the Smart
Grid, for example, incentives to consume more or less depending on current
energy availability, or emergency situations that require temporary reduction
of power consumption.
Figure 7.6 shows the main classes of SAREF4ENER that represent the
concepts of ’power profile’, ’power sequence’, ’alternative’, and ’slot’ that a
device uses to communicate its energy flexibility to the HEMS according to
the preferences and needs of the consumer.
A s4ener:Device is a subclass of a saref:Device, that is, it inherits the prop-
10http://www.eebus.org/en
11http://www.energy-home.it
24
saref:Profile
saref:consistsOf saref:Profile
saref:hasPrice saref:Price
saref:hasTime saref:Time
saref:isAbout (saref:Commodi ty or saref: Property)
s4ener:AlternativesGroup
s4ener:belongsTo s4ener:PowerProfile (exa ctly 1 s4ener:PowerProfile)
saref:consistsOf s4ener:PowerSequence ( min 1 s4ener:PowerSequence)
s4ener:alternativesGroupID u nsignedInt (1..1)
s4ener:Slot
s4ener:belongsTo s4ener:PowerSequence (exa ctly 1
s4ener:PowerSequence)
s4ener:hasEnergyValueType s4ener:E nergy
s4ener:hasPowerValueType s4enerPow er
s4ener:hasValueType (min 1 s4 ener:Energy or
s4ener:Power)
saref:hasTime max 1 s4ener:Star tTime
saref:hasTime max 1 s4ener:EndTi me
saref:hasTime max 1 s4ener:Earli estStartTime
saref:hasTime max 1 s4ener:Lat estEndTime
saref:hasTime max 1 s4ener:MaxD uration
saref:hasTime max 1 s4ener:MinD uration
saref:hasTime max 1 s4ener:Defa ultDuration
saref:hasTime max 1 s4ener:Dura tionUncertainty
saref:hasTime max 1
s4ener:RemainingPauseTimes4ener:opt ionalSlot
boolean (0..1)
s4ener:slotActivated boolea n (0..1)
s4ener:slotNumber unsignedInt (1. .1)
saref:hasDescription string (0..1)
saref:consistsOf
s4ener:PowerSequence
saref:hasDescription string (0..1)
saref:consistsOf s4ener:Slot (min 1 s4ener:Slot)
saref:hasPrice s4ener:ResumeCostEsti mated (max 1 s4ener:ResumeCostEstimated)
saref:hasState s4ener:PowerSequ enceState (min 1 s4ener:PowerSequenceState)
saref:hasTime min 1 s4ener:Star tTime
saref:hasTime max 1 s4ener:EndTi me
saref:hasTime max 1 s4ener:Earli estStartTime
saref:hasTime max 1 s4ener:Lat estEndTime
saref:hasTime max 1 s4ener:Act iveDurationMin
saref:hasTime max 1 s4ener:Act iveDurationMax
saref:hasTime max 1 s4ener:Act iveDurationSumMax
saref:hasTime max 1 s4ener:Act iveDurationSumMin
saref:hasTime max 1 s4ener:Pau seDurationMax
saref:hasTime max 1 s4ener:Pau seDurationMin
saref:hasTime max 1 s4ener:Remai ningSlotTime
saref:hasTime max 1 s4ener:Elap sedSlotTime
s4ener:belongsTo s4ener:AlternativesG roup (exactly 1 s4ener:AlternativesGrou p)
s4ener:hasEnergy s4ener:ResumeEnergyEst imated (max 1
s4sener:ResumeEnergyEstimated)
s4ener:activeRepetitionNumb er unsignedInt (0..1)
s4ener:activeSlotNumber unsigned Int (0..1)
s4ener:cheapest boolean (0.. 1)
s4ener:greenest boolean (0..1)
s4ener:isPausable boolean (0. .1)
s4ener:isStoppable boolean ( 0..1)
s4ener:maxCyclesPerDay unsignedInt (0..1)
s4ener:repetitionsTotal unsignedI nt (0..1)
s4ener:sequenceID unsignedInt (1 ..1)
s4ener:sequenceRemoteControllable boolea n (1..1)
s4ener:taskIdentifier unsignedI nt (0..)
s4ener:valueSource {“measuredValue” , “calculated Value”, “empirical V alue”} min 1
s4ener:belongsTo
s4ener:PowerProfile
s4ener:belongsTo s4ener:Device (exac tly 1 s4ener:Device)
saref:consistsOf s4ener:Alternativ esGroup (min 0
s4ener:AlternativesGroup)
s4ener:alternativesCount integer (1..1)
s4ener:nodeRemoteControllable boolea n (1..1)
s4ener:supportsReselection boolean ( 1..1)
s4ener:supportsSingleSlotScheduli ngOnly boolean (1..1)
s4ener:totalSequencesCountMax unsig nedInt (1..1)
saref:Device
s4ener:Device
saref:hasProfile
s4ener:exposes
s4ener:hasEnergyValueType
s4ener:hasPowerValueType
saref:consistsOf
saref:consistsOf
s4ener:belongsTo
s4ener:belongsTo
saref:Property
saref:Power
saref:Energy
s4ener:Energy
s4ener:Power
Figure 7.6: Main classes of SAREF4ENER [ETSI, 2020e]
25
erties of the more general saref:Device and extends it with additional properties
that are specific to SAREF4ENER. A s4ener:PowerProfile inherits the prop-
erties of the more general saref:Profile, extending it with additional properties
that are specific to SAREF4ENER. A power profile is a way to model curves of
power and energy over time, which also provides definitions for the modelling
of power scheduling, including alternative plans. With a power profile, a device
exposes the power sequences that are potentially relevant for the HEMS, for
example, a washing machine that wants to communicate its expected energy
consumption for a certain day. An alternative group is a collection of power se-
quences for a certain power profile. For example, the above-mentioned washing
machine can offer two alternative plans, a ’cheapest’ alternative in which the
HEMS should try to minimise the user’s energy bill and a ’greenest’ alternative
in which the HEMS should try to optimise the configuration to maximise the
availability of renewable energy. An alternative consists of one or more power
sequences (s4ener:PowerSequence class). A power sequence is the specification
of a task, such as washing or drying, according to user preferences and/or the
manufacturer’s settings for a certain device. For example, in the ’cheapest’ al-
ternative mentioned above, the washing machine can ask to allocate two power
sequences during the night, while for the ’greenest’ alternative, it can ask to
allocate one power sequence in the morning and one in the afternoon. Of these
power sequences, one is allocated for the washing task and cannot be stopped
once it started, while the other power sequence is allocated for the tumble
drying task and has the flexibility to be paused by the HEMS as long as it
finishes within a specified latest end time. A power sequence consists of one or
more slots (s4ener:Slot class) that represent different phases of consumption
(or production) and their values. In the power sequence allocated for washing,
26
for example, various slots can represent the consumption during the different
phases of washing, such as heating the water, washing, and rinsing.
7.6.2. Water
SAREF4WATR [ETSI, 2020h] is the extension of SAREF that provides a com-
mon core of general terms for water data orientated to the Internet of Things.
These core terms can be extended to particular water subdomains, for exam-
ple, to water supply. Figure 7.7 presents the main terms related to water of
the SAREF4WATR extension.
The extension specialises devices for the water domain and includes a par-
ticular type of water device, a water meter, based on the European M-Bus
standard [CEN, 2017a]. It also allows for the representation of the tariff that is
applied to a water meter, according to the CEN TR 17167:2018 [CEN, 2017b].
The extension also covers a non-exhaustive set of measurable properties
that are of interest for this domain: properties of water meters, properties of
water flows (based on the European M-Bus standard [CEN, 2017a]), water
properties (based on the classification proposed by the World Health Organi-
sation [World Health Organization, 2017] and on different EC directives on the
quality of drinking water [EC, 1998], bathing water [EC, 2006a], and ground-
water [EC, 2006b]) and environmental properties that affect water and the
infrastructures that use it.
Water assets and water infrastructures related to different types of water
can also be defined. To represent the topology of a water infrastructure or its as-
sets, the GeoSPARQL ontology [Open Geospatial Consortium, 2012] has been
reused and, by reusing the SAREF4SYST ontology, the different subsystems of
27
a water infrastructure can be defined. In SAREF4WATR, key performance in-
dicators (KPIs) are intended to be defined for water infrastructures. However,
KPIs can also be defined for other features of interest.
s
a
ref
:
A
ctu
a
tor s
a
ref
:
S
ensor
s
a
ref
:
M
eter
s
a
ref
:
h
a
s
P
roperty s
4
w
a
tr
:
Wa
ter
M
eter
P
roperty
s
4
w
a
tr
:
Wa
ter
P
roperty
s
a
ref
:
P
roperty
s
a
ref
:
me
a
sures
P
roperty
s
4
w
a
tr
:
Wa
ter
F
low
P
roperty
s
4
syst
:
S
ystem
s
4
w
a
tr
:
Wa
ter
I
nfr
a
structures
4
w
a
tr
:
Wa
ter
A
sset s
4
syst
:
h
a
s
S
ub
S
ystem
geosp
:
F
e
a
ture
s
4
w
a
tr
:
Wa
ter
s
4
w
a
tr
:
is
D
esigned
F
or
s
4
w
a
tr
:
Wa
ter
M
eter
s
a
ref
:
D
evice
s
4
w
a
tr
:
Ta
ri
ff
s
4
w
a
tr
:
a
pplies
T
o
s
a
ref
:
F
e
a
ture
O
f
I
nterest
s
a
ref
:
h
a
s
P
roperty
s
4
w
a
tr
:
Wa
ter
D
evice
s
4
w
a
tr
:
Wa
ter
U
se
s
4
w
a
tr
:
is
I
ntended
F
or
s
4
w
a
tr
:
E
nvironment
a
l
P
roperty
Figure 7.7: Water-related terms of SAREF4WATR (adapated from [ETSI,
2020h])
7.6.3. Building
This section provides an overview of the SAREF4BLDG ontology [ETSI, 2020b],
which represents the SAREF extension dedicated to model building devices
based on the International Organization for Standardization (ISO) standard
data model Industry Foundation Classes (IFC) [ISO, 2013]. The main goal of
the SAREF4BLDG ontology is to allow the representation of some IFC fea-
tures by means of web technologies in combination with SAREF, focussing on
the devices, including appliances, described in IFC; and on the location of such
28
devices in buildings.
An overview of the main classes and properties defined in SAREF4BLDG
is shown in Figure 7.8.
BuildingSpace
hasSpace
saref:Device
BuildingDevice
BuildingObject
Building
geo:SpatialThinggeo:location
PhysicalObjectisSpaceOf
contains
isContainedIn
<<owl:inverseOf>> <<owl:inverseOf>>
geo:location
isSpaceOf
hasSpace
Figure 7.8: Overview of SAREF4BLDG (adapted from [ETSI, 2020b])
To reuse the geo ontology modelling for locations, the classes s4bldg:Building,
s4bldg:BuildingSpace, and s4bldg:PhysicalObject are represented as subclasses
of the class geo:SpatialThing. The s4bldg:Building and s4bldg:BuildingSpace
classes are linked to each other through the properties s4bldg:hasSpace and
s4bldg:isSpaceOf; which are inverse properties between them. These proper-
ties could also be used to define subspaces of a s4bldg:BuildingSpace.
Building spaces can contain physical objects that could represent any type
of object or sensors as depicted in Figure 7.8. The property that links the
building with the objects is s4bldg:contains.
Finally, the class representing building devices, namely s4bldg:Building-
Device, is defined as a subclass of both saref:Device and s4bldg:BuildingObject.
The device hierarchy extracted from IFC is represented as different subclasses
29
of s4bldg:BuildingDevice and is represented in Figures 7.9a and 7.9b. This hi-
erarchy represents the devices defined in IFC reproducing the classification de-
fined in the standard, for example, grouping the devices in s4bldg:Distribution-
Device, s4bldg:ShadindDevice, s4bldg:TransportElement and s4bldg:Vibration-
Isolator and their inner classifications. More details on the selection of IFC
concepts and the ontology development process to build SAREF4BLDG are
described in [Poveda-Villal´on and Garc´ıa-Castro, 2018].
7.6.4. City
The SAREF4CITY ontology [ETSI, 2020c] aims to extend SAREF in order to
create a general framework for representing Smart City data in the IoT do-
main by identifying the main components. For doing so, different resources have
been investigated during the definition of the ontology, for example, ontologies
defined by the Open Geospatial Consortium, IoT platforms as FIWARE, Euro-
pean projects and initiatives as the ISA2 programme, or the Spanish Federation
of Municipalities and Provinces catalogue of vocabularies.
An overview of the SAREF4CITY ontology is shown in Figure 7.10. As can
be observed, the main areas represented are as follows: Topology, Administra-
tive Area, City Object, Event, Measurement, Key Performance Indicator, and
Public Service.
The topology domain has been represented by reusing the main geograph-
ical ontologies, GeoSPARQL and the W3C vocabulary WGS84. The adminis-
trative area domain is linked to the topology domain by extending the concept
of geosp:Feature with s4city:AdministrativeArea and its subclasses represent-
ing cities, countries, districts, and neighbourhoods.
30
saref:Device
BuildingDevice
TransportElement
VibrationIsolator
DistributionDevice
ShadingDevice
DistributionControlDevice
DistributionFlowDevice
Actuator
Alarm
Controller
Flowinstrument
Sensor saref:Sensor
UnitaryControlElement
EnergyConversionDevice
FlowController
FlowMovingDevice
FlowStorageDevice
FlowTerminal
FlowTreatmentDevice
BuildingObject
saref:Actuator
ProtectiveDeviceTrippingUnit
(a) Hierarchy of s4bldg:BuildingObject
DistributionFlowDevice
EnergyConversionDevice FlowController
FlowMovingDevice
FlowStorageDevice
FlowTerminal
FlowTreatmentDevice
AirToAirHeatR
ecovery
Boiler
Burner
Chiller
Coil
Condenser
CooledBeam
CoolingTower
ElectricGenerator
ElectricMotor
Engine
HeatExchanger
Transformer
SolarDevice
Humidifier
Evaporator
EvaporativeCooler
TubeBundle
Damper
ElectricTime
Control
FlowMeter
ProtectiveDevice
SwitchingDevice
Valve
Communication
Appliance
SanitaryTerminal
Outlet
MedicalDevice
Lamp
SpaceHeater
Compressor
Fan
Pump
ElectricFlow
StorageDevice
Tank
AudioVisual
Appliance
Electric
Appliance
FireSuppression
Terminal
DuctSilencer
Filter
Interceptor
(b) Hierarchy of s4bldg:DistributionFlowDevice
Figure 7.9: Device hierarchy in SAREF4BLDG (adapted from [ETSI, 2020b])
31
The model to represent city objects also relies on the GeoSPARQL topology
pattern that allows the connection of city objects with the city or with the
parts in which they are located by using the properties geosp:sfContains and
geosp:sfWithin inherited from the geosp:SpatialObject class.
Events are modelled by the class s4city:Event that is linked to the agent
who organises them through the property s4city:organizedBy. The facilities in
which the events can take place are indicated by the property s4city:takes-
PlaceAtFacility. The time in which it takes place is represented by the class
time:TemporalEntity reused from the W3C Time ontology, and it is indicated
by the property s4city:takesPlaceAtTime.
Conceptualisation of KPIs involves two main concepts, namely s4city:Key-
PerformanceIndicator and s4city:KeyPerformanceIndicatorAssessment.
This distinction is motivated by the need to decouple the definition of a KPI in
general terms, for example, the mean air pollution per week, and a particular
value of such a KPI, for example, the mean value of air pollution last week in
Paris. The relationship between a specific assessment of a KPI (s4city:KeyPer-
formanceIndicatorAssessment) and the general KPI definition (s4city:KeyPer-
formanceIndicator) can be established by means of the property s4city:quan-
tifiesKPI.
The property s4city:isKPIOf allows linking from a s4city:KeyPerformance-
Indicator to the measured saref:FeatureOfInterest. The calculation period of
s4city:KeyPerformanceIndicator is provided by the s4city:hasCalculationPeriod
property. Some attributes are attached to KPIs, such as its name (using the
property s4city:hasName) and a natural language description (s4city:hasDes-
cription).
Finally, the SAREF4CITY ontology allows representing public services
32
(s4city:PublicService) by extending the reused concept cpsv:PublicService de-
fined in the Public Service vocabulary provided by the ISA vocabularies Euro-
pean initiative. Services can also be linked to the facilities involved by the prop-
erty s4city:involvesFacility and it is possible to indicate in which administra-
tive area it is provided using the reused property cpsv:physicallyAvailableAt.
It is possible to indicate that an agent (s4city:Agent) provides (cpsv:provides)
or uses (cpsv:uses) public services and the language in which they are avail-
able (s4city:isAvailableInLanguage). The name and description in natural lan-
guage of public services are represented by the attributes s4city:hasName and
s4city:hasDescription, respectively.
7.6.5. Systems
The SAREF4SYST ontology [ETSI, 2020g], shown in Figure 7.11 and inspired
by SEAS [Lefran¸cois, 2017], is the first ontology pattern incorporated into
SAREF. It defines an ontology model that can be instantiated for different
domains. SAREF4SYST defines systems, connections between systems, and
connection points to which systems can be connected. These basic concepts
can be used generically to define the topology of entities of interest and can
be specialised for multiple domains. For example, to describe areas within a
building (systems) that share a boundary (connections). The properties of sys-
tems are usually state variables (e.g., agent population, temperature), while
properties of connections are usually flows (e.g., heat flow). SAREF4SYST has
two main goals: on the one hand, to extend SAREF with the ability to repre-
sent the general topology of systems and how they are connected or interact,
and, on the other hand, to illustrate how ontology patterns can help ensure a
33
geosp:Feature
geo:location
s4city:PublicAdministration
foaf:Agent
saref:FeatureOfInterest
geo:Point
time:TemporalEntity
geosp:Geometry
s4city:AdministrativeArea
s4city:District
s4city:Country
s4city:CityObject
s4city:City
s4city:Neighbourhood
saref:hasDescription:: rdfs:Literal
saref:hasManufacturer:: rdfs:Literal
saref:hasModel:: rdfs:Literal
saref:Device
saref:Sensor
saref:Actuator
saref:hasTimestamp:: xsd:dateTime
saref:hasValue::
saref:Measurement
saref:isMeasuredIn
saref:Property
saref:UnitOfMeasure
saref:isControlledByDevice
saref:controlsProperty
saref:measuresProperty
saref:isMeasuredBy
Device
saref:makes
Measurement
saref:relatesTo
Property
saref:relatesTo
Measurement s4city:Facility
dcterms:LinguisticS
ystem
time:Interval
s4city:assesses
s4city:isAssessedBy
org:Organization
geosp:sfContains
geosp:sfWithin
owl:Thing
s4city:hasAccesibility
s4city:hasCalculation
Period
saref:has
Feature
OfInterest
geosp:hasGeometry
saref:isMeasuredIn
sarefy:has
Property
s4city:involves
Facility
cpsv:physicallyA
vailableAt
s4city:isAvailableIn
Language
s4city:organizedBy
saref:isPropertyOf
s4city:isSub
EventOf
cpsv:provides
cpsv:uses
<<owl:inverseOf>>
saref:measurement
MadeBy
<<owl:inverseOf>>
saref:hasName:: rdfs:Literal
s4city:Event
saref:hasName:: rdfs:Literal
saref:hasDescripton:: rdfs:Literal
saref:hasValue::
s4city:hasLastUpdateDate :: xsd:datetime
s4city:hasCreationDate :: xsd:datetime
s4city:hasExpirationDate :: xsd:datetime
saref:hasName:: rdfs:Literal
saref:hasDescripton:: rdfs:Literal
s4city:KeyPerformanceIndicator
Assessment
saref:hasName:: rdfs:Literal
saref:hasDescripton:: rdfs:Literal
s4city:KeyPerformanceIndicator s4city:quantifiesKPI
s4city:takesPlaceAtTime
s4city:isDerivedFrom
time:Instant
foaf:Person
s4city:refersToTime
s4city:refersTo
Feature
s4city:takesPlaceAtFacility
geosp:SpatialObject
s4city:PublicService
cpsv:PublicService
s4city:isKPIOf
s4city:hasKPI
<<owl:inverseOf>>
saref:isFeature
OfInterestOf
<<owl:inverseOf>>
s4city:Agent
time:TemporalDuration
Figure 7.10: Overview of SAREF4CITY (adapted from [ETSI, 2020c])
34
homogeneous structure of the overall SAREF ontology and speed up extension
development.
System
hasSubSystem
<<transitive>>
ConnectionPoint
connectsAt
connectionPointOf
<<inverseOf>>
=1
connectedTo
<<symmetric>>
Connection
connectsSystem
connectedThrough
<<inverseOf>>
connectsSystemAt
connectsSystemThrough
<<inverseOf>>
∃
subSystemOf
<<transitive>>
<<inverseOf>>
∃
Figure 7.11: Overview of the SAREF4SYST ontology pattern (adapted from
[ETSI, 2020g])
7.7. The SAREF ontology in use
As a result of significant standardisation efforts such as SAREF, the IoT in-
dustry perceives the impact that ontologies can have to enable the missing
interoperability. However, most industrial practitioners are not familiar with
semantic technology or have an incentive to adopt it, as they believe the learn-
ing curve is too steep. Information on ontologies appears to them abstract and
scattered over the Web, and thus not easily applicable. The goal of this sec-
tion is to provide examples of existing SAREF-based implementations in the
smart home environment as a support for practitioners to understand in which
35
practical settings the ontologies presented in this chapter can be applied.
The first example is based on a scenario of the Dutch pilot of the H2020
InterConnect project12 within a household in which smart appliances from dif-
ferent vendors (i.e., Bosch, Siemens, Miele, and Whirlpool) interact with an
energy manager in the cloud that takes care of optimising the energy con-
sumption and production of all home appliances depending on the time of the
day, the user preferences and possible incentives from the grid. In particu-
lar, we focus on the specific interaction between smart appliances from Bosch,
Siemens or Miele, which are equipped with EEBUS SPINE-IoT communica-
tion defined in the EN50631 standard, with an energy manager that makes
use of the so-called “S2 interface” according to the EN50491-12-2 standard.
The energy manager is an implementation of the TNO Reflex platform, which
organises the demand and supply of energy, as a tool for aggregation and
scheduling of energy flexibility. Smart appliances and energy managers expose
their data to a semantic interoperability layer in the format of the SAREF and
SAREF4ENER ontologies. Therefore, SAREF and SAREF4ENER are used
as the common language to allow seamless communication in the smart home
and enable optimisation of energy consumption and production of the home.
As an example of a storyline that uses this infrastructure, household owners
load their laundry into a washing machine (i.e., an iQ700 Siemens device in
the example under consideration) and specify their preference by selecting the
latest end time when the laundry needs to be ready. Setting this preference
can be done by the user directly using the washing machine display or through
the Siemens app available for the mobile phone. The washing machine, which
12https://interconnectproject.eu/wp-content/uploads/2021/03/Interconnect Netherlands
Residencial EnglishVersion.pdf
36
communicates with the energy manager using SAREF and SAREF4ENER,
sends the new user demand (in the form of a s4ener:AlternativesGroup that
belongs to the washing machine s4ener:PowerProfile), which is received by the
Reflex Energy Manager that adapts the plan based on the updated conditions.
The Energy Manager is the one who finally decides when the washing ma-
chine should start and updates the new start time by sending it to the washing
machine.
The second example is based on a SAREF-based implementation in the
context of the Greek pilot of the H2020 InterConnect project13 in which res-
idential buildings are transformed into smart homes with energy meters and
sensors installed in the houses. Several companies are involved: GRIDNET, an
SME ICT company responsible for transforming 50 homes to smart-homes with
smart-meters and sensors connected to an IoT gateway and company’s cloud
services; COSMOTE, a Telco Provider responsible for transforming additional
50 homes to smart-homes with smart-meters and sensors connected with an
IoT Gateway and company’s cloud services; and HERON, a retailer responsi-
ble for equipping 200 houses with smart-meters and collection of consumption
data within the company’s cloud services. In addition, AUEB is an academic
partner responsible for developing a mobile app that building residents can
use to monitor their house consumption and interact with the various services
offered by the Greek pilot. This example of SAREF in action focusses on how
the four different service providers (i.e., GRIDNET, COSMOTE, HERON,
and AUEB) leverage SAREF and its extensions as a common data model to
exchange information. GRIDNET has installed Qubino energy meters that
13https://interconnectproject.eu/wp-content/uploads/2021/03/Interconnect
Greece-Geral EN-1.pdf
37
communicate wirelessly with Z-Wave technology with an IoT gateway that
runs the open source framework openHAB. COSMOTE uses AEOTEC energy
meters with Z-Wave technology that communicate with an IoT gateway that
runs the open source framework Home Assistant. HERON takes advantage
of the Wi-fi network of the user to connect directly to Shelly energy metres.
An AUEB-developed IoT app presents residents with their energy consump-
tion information regardless of the specific IoT solution the house has been
equipped with (i.e., GRIDNET, COSMOTE, or HERON). The bridging tech-
nology for the communication is SAREF, SAREF4BLDG and SAREF4ENER.
As an example of storyline, the user logs into the app and after authentica-
tion the app requests historical consumption data, for example, about the last
week. A response is generated and forwarded to the mobile app, which is then
presented in the user dashboard. The user experience remains the same while
using different service providers behind the scenes.
7.8. Lessons learnt
This section provides some lessons learnt from a long path of development and
evolution of the ETSI SAREF ontology for smart applications.
Specification of ontology requirements. The ETSI approach for the de-
velopment of SAREF has been applied in a constrained setting due to the fact
that the ETSI STF SAREF projects are usually focused efforts that aim at
reaching concrete results in rather short time, compared to European research
projects with a typical duration of 3-4 years. As an example, the STF projects
carried out in the past years to extend SAREF (e.g., STF 513, STF 534, STF
38
566, STF 602), in the ontological requirement specification step, have consid-
ered an average of three use cases per SAREF extension, as this was sufficient
to generate a variety of significant requirements (e.g., an average of 60 compe-
tency questions per extension) and, at the same time, keep focus in the scope
of the ontology and pace in the ontology development process. On the other
hand, it was also necessary to apply the process in larger settings, for example,
112 use cases, 66 services, 166 APIs, and 864 parameters were analysed in the
InterConnect project to enrich the current SAREF suite of ontologies with ad-
ditional concepts to accommodate new use cases in the smart home and energy
domains. In these types of large-scale settings, an initial information overload
is unavoidable. For example, this resulted in 350+ requirements in InterCon-
nect, after an initial analysis based on the most relevant use cases and services.
However, we could observe that eventually the situation stabilised, i.e., the ad-
dition of more use cases did not result anymore in new requirements. Therefore,
we learnt that use cases are a useful input to drive the ontology development
taking into account concrete needs of the industry and that a limited number
of use cases (i.e., 3+ use cases) helps to keep focus and pace, yet, guaranteeing
a suitable semantic coverage. However, new concepts may be needed to accom-
modate new use cases, and the addition of use cases eventually will reach an
optimum in which no new concepts will be anymore added to the ontologies,
but will provide useful support to validate the already existing concepts.
Stakeholder’s Workshops. Since the beginning of SAREF development in
2014, ETSI ontology experts have used to conduct stakeholder workshops in
person for the development of SAREF and its extensions with a large number of
stakeholders (i.e., 60+ stakeholders). Face-to-face interaction with stakeholders
proved to be an extremely successful aspect, especially in increasing the un-
39
derstanding and acceptance of the resulting ontologies [Daniele et al., 2015a].
In order to make these workshops manageable and productive, we adopted the
best practise to divide the participants into different (small) groups and work
in parallel, drawing ontology concepts and relations on a whiteboard. Due to
the COVID19 pandemic in 2019-2021, it has no longer been possible to gather
stakeholders in person and ontology workshops had to be conducted entirely
online. From this experience we learnt that i) an online workshop helps to in-
volve a larger number of stakeholders compared to the more limited number
reachable in a meeting in person, and ii) it is still possible collect ontology re-
quirements (smaller sessions, break-out rooms, etc.), although in a less effective
manner compared with face-to-face interaction (results of one day face-to-face
are comparable to three days online workshops). In conclusion, we observe that
the desired goals for the SAREF development can also be reached online, but
this affects the pace (slower) and the resources (higher) invested to achieve the
result compared to the face-to-face setting used in the past.
Tool support. The development of ontologies with close and active partic-
ipation of stakeholders is essential and, at the same time, challenging. The
learning curve of semantic technology and ontologies for industrial practition-
ers is steep, as it requires a paradigm shift for traditional software developers,
who are not used to thinking in terms of semantics and triples. Moreover,
stakeholders often do not have the time nor the incentive to browse through
lengthy ontology specifications, and as a consequence they rather rely on di-
rect consultancy of the (ETSI SAREF) semantic experts, which are a minority
compared to the vast majority of traditional software developers, and this is
not sustainable. We therefore learnt that it is essential to improve training and
communication material that can be reused by the semantic experts across and
40
beyond specific projects, as basis to speed up the adoption of the technology.
Moreover, tool support is needed in the near future, starting from visualisa-
tion tools for nonexperts to quickly browse ontologies and become familiar with
them, to intuitive user interfaces that help the same nonexpert users select and
focus on only a few parts of interest of the ontologies, especially when they are
faced with the challenge of combining different subparts of an extensive frame-
work of ontologies such as SAREF and its extensions (e.g., parts of SAREF,
SAREF4ENER, SAREF4BLDG, SAREF4WATR, and SAREF4CITY that are
relevant for the smart home environment, as shown in Figure 7.5). Finally, we
also learnt that despite the efforts in ETSI for the creation of the user-friendly
SAREF portal with the collection of all related technical reports and specifica-
tions, it is unclear for the majority of stakeholders how to actively participate
to the development and standardise new contributions to SAREF. This chap-
ter serves as an initial tool for stakeholders to find, all in one place, not only
the information to become familiar with SAREF and its extensions but also
the ETSI workflow for the SAREF projects in order to clarify to stakeholders
how they contribute to the further development and standardisation of these
ontologies.
Ontology Modularization. Two design choices are recurrent in ontology
networks: (1) the definition of namespaces for each module, and (2) the choice
of the module in which a term is defined. Choosing a distinct namespace for
each module makes it easy to identify from which module a term originates.
It also simplifies the publication of ontologies in accordance with the good
practise of making a description of each term accessible to its IRI (hash IRIs
can be used). However, this approach presents three problems.
First, it is sometimes difficult for a user of these ontologies to remember
41
what the namespace is for each concept. We have, for example, a variety of
subclasses of saref:Property spread over the namespaces of the different exten-
sions, depending on where we needed to define them first: saref:Temperature,
saref:Humidity, saref:Power, s4ener:PowerMax, s4ener:PowerStandardDeviation,
s4inma:Size, saref:Light, s4envi:LightProperty and the following instances of
saref:Property: s4envi:Frequency, s4wear:SoundLevel, s4wear:Temperature,
s4wear:BatteryRemainingTime, s4watr:Conductivity. An alternative approach
would have been to use a single namespace and slash ’/’ IRIs, and implement
redirects from the IRI of each term to the document that describes the ontology
where it is defined.
Second, experience shows that it can be relevant to move a term from
one module to another. For example, SAREF4CITY V1.1.1 introduced the
concept of s4city:FeatureOfInterest, and it was decided during the develop-
ment of SAREF Core V3.1.1 that this concept should be moved into the core
ontology. Therefore, it is now identified by saref:FeatureOfInterest, and the
SAREF4CITY implementations had to be modified. This problem would not
have arisen if an approach based on a unique namespace and slash IRIs had
been adopted.
Finally, what the list of classes and instances of saref:Property shows is
that even within the SAREF developer community, the modelling and nam-
ing choices are sometimes varied. Therefore, it would seem important to us
to rebase the development of SAREF on ontology patterns to harmonize its
development.
Ontology Patterns. One of the deliverables of the ETSI STF 556 project
is the technical report TR 103 549 entitled “Consolidation of SAREF and its
industrial user community, based on the experience of the EUREKA ITEA
42
12004 SEAS project”. This report identifies the implicitly existing patterns in
SAREF and that formalisation could be appropriate to achieve a consolidated
version of the SAREF ontology [ETSI, 2019].
For example, in SAREF Core V2.1.1, measurement, actuation, and meter-
ing functions are function types. Usually, a function (e.g., saref:StartStopFun-
ction) has one or more commands to trigger it (e.g., for saref:StartStopFun-
ction, it should be either a saref:StartCommand or a saref:StopCommand).
Some commands act on certain states (saref:StartStopCommand acts on a cer-
tain saref:StartStopState). It would be advisable, for example, to make sure
that all subclasses of the saref:Command class are described in the same way.
For example, some subclasses of saref:Command had generic instances, associ-
ated with no real action. SAREF also had a command saref:PauseCommand,
which was not associated with any function.
Patterns can be instantiated with elements taken in orthogonal dimen-
sions. For example, SAREF4ENER defines s4ener:EnergyStandardDeviation,
s4ener:EnergyMax, s4ener:EnergyMin, s4ener:EnergyExpected, s4ener:Power-
Max, s4ener:PowerMin, s4ener:PowerExpected, s4ener:PowerStandardDeviation.
Manually managing the addition of, for example, a new aggregate type Average
involves creating many additional properties, such as s4ener:EnergyAverage,
s4ener:PowerAverage. A partial solution to this problem is to decouple the
dimensions. In the example above, we will specify the property type and the
aggregate type.
43
7.9. Conclusions and future work
This chapter provided an overview of how the ETSI SAREF ontology is de-
signed and can be used for smart applications in smart home environments.
The design rationale and development framework of SAREF, together with
the level of support from the European Commission and ETSI, make it a good
candidate for designing interoperable cross-vertical common data spaces with
a focus on IoT applications.
SAREF illustrates how the development of an ontology can transition from
focused short-term projects mainly involving researchers to large-scale research
and development projects with large industrial stakeholders. The SAREF de-
velopment framework and workflow as specified in ETSI TS 103 673 [ETSI,
2020k], the SAREF pipeline and the public SAREF portal enable SAREF de-
velopers to accelerate the development of SAREF and its extensions, as well as
the SAREF user community to actively contribute to development. Other keys
to SAREF success include participation of stakeholders in regular workshops,
good tool support for its development, and the adoption of design best prac-
tises including modularization, versioning, and ontology patterns for improved
homogeneity.
Acknowledgements
Part of the development of the SAREF suite of ontologies has been funded by
European Commission SMART 2013/01077 and 2016/0082 studies; the Euro-
pean Telecommunications Standards Institute Specialist Task Forces 513, 534,
556, 566, 578, and 602; the Horizon 2020 European project InterConnect grant
agreement 857237; and the French project ANR-19-CE23-0012-04 CoSWoT.
44
The authors would also like to thank Josef Baumeister (BSH), Jorrit Nutma
(TNO) and Donatos Stavropoulos (GRIDNET) for the examples of SAREF in
use from the Dutch and Greek pilots of InterConnect.
Bibliography
CEN. EN 13757-2:2017: Communication systems for meters - Part 2: Wired
M-Bus communication. Technical report, 2017a.
CEN. TR 17167:2018: Communication system for meters - Accompanying
TR to EN 13757-2,-3 and -7, Examples and supplementary information.
Technical report, 2017b.
Laura Daniele and Willem Strabbing. Study on ensuring interoperability for
Demand Side Flexibility. European Commission, 2018.
Laura Daniele, Frank den Hartog, and Jasper Roes. Created in Close Interac-
tion with the Industry: The Smart Appliances REFerence (SAREF) Ontol-
ogy. In Proceedings of the Formal Ontologies Meet Industry workshop (FOMI
2015), Vol. Lecture Notes in Business Information Processing, volume 225,
pages 100–112. Springer, Cham, 2015a.
Laura Daniele, Frank den Hartog, and Jasper Roes. Study on semantic assets
for smart appliances interoperability, D-S4 final report. European Commis-
sion, 2015b.
Laura Daniele, Monika Solanki, Frank den Hartog, and Jasper Roes. Inter-
operability for Smart Appliances in the IoT World. In Proceedings of the
45
International Semantic Web Conference (ISWC 2016), Vol. Lecture Notes
in Computer Science, volume 9982, pages 21–29. Springer Cham, 2016.
EC. Council Directive 98/83/EC of 3 November 1998 on the quality of water
intended for human consumption. Technical report, 1998.
EC. Directive 2006/7/EC of the European Parliament and of the Council of
15 February 2006 concerning the management of bathing water quality and
repealing Directive 76/160/EEC. Technical report, 2006a.
EC. Directive 2006/118/EC of the European Parliament and of the Council of
12 December 2006 on the protection of groundwater against pollution and
deterioration. Technical report, 2006b.
ETSI. oneM2M; Base Ontology (oneM2M TS-0012 version 2.0.0 Release 2).
ETSI Technical Specification 118 112 v2.0.0., 2016.
ETSI. SmartM2M; Guidelines for consolidating SAREF with new reference
ontology patterns, based on the experience from the ITEA SEAS project.
ETSI Technical Report 103 549 V1.1.1., 07 2019.
ETSI. SmartM2M; Extension to SAREF; Part 7: Automotive Domain. ETSI
Technical Specification 103 410-7 V1.1.1., 07 2020a.
ETSI. SmartM2M; Extension to SAREF; Part 3: Building Domain. ETSI
Technical Specification 103 410-3 V1.1.2., 05 2020b.
ETSI. SmartM2M; Extension to SAREF; Part 4: Smart Cities Domain. ETSI
Technical Specification 103 410-4 V1.1.2., 05 2020c.
ETSI. SmartM2M; Extension to SAREF; Part 8: eHealth/Ageing-well Domain.
ETSI Technical Specification 103 410-8 V1.1.1., 07 2020d.
46
ETSI. SmartM2M; Extension to SAREF; Part 1: Energy Domain. ETSI Tech-
nical Specification 103 410-1 V1.1.2., 05 2020e.
ETSI. SmartM2M; Extension to SAREF; Part 2: Environment Domain. ETSI
Technical Specification 103 410-2 V1.1.2., 05 2020f.
ETSI. SmartM2M; SAREF consolidation with new reference ontology pat-
terns, based on the experience from the SEAS project. ETSI Technical
Specification 103 548 V1.1.2., 06 2020g.
ETSI. SmartM2M; Extension to SAREF; Part 10: Water Domain. ETSI
Technical Specification 103 410-10 V1.1.1., 07 2020h.
ETSI. SmartM2M; Extension to SAREF; Part 9: Wearables Domain. ETSI
Technical Specification 103 410-9 V1.1.1., 07 2020i.
ETSI. SmartM2M; Smart Applications; Reference Ontology and oneM2M
Mapping. ETSI Technical Specification 103 264 V3.1.1., 02 2020j.
ETSI. SmartM2M; SAREF Development Framework and Workflow, Stream-
lining the Development of SAREF and its Extensions. ETSI Technical Spec-
ification 103 673 V1.1.1., 2020k.
ETSI. SmartM2M; Extension to SAREF; Part 11: Lift Domain. ETSI Tech-
nical Specification 103 410-11 V1.1.1., 07 2021.
Alba Fern´andez-Izquierdo and Ra´ul Garc´ıa-Castro. Themis: a tool for validat-
ing ontologies through requirements. In Software Engineering and Knowledge
Engineering, pages 573–753, 2019.
Amelie Gyrard, Ghislain Atemezing, Christian Bonnet, Karima Boudaoud, and
Martin Serrano. Reusing and unifying background knowledge for internet
47
of things with LOV4IoT. In 2016 IEEE 4th International Conference on
Future Internet of Things and Cloud (FiCloud), pages 262–269, 2016. doi:
10.1109/FiCloud.2016.45.
ISO. ISO 16739:2013 - Industry Foundation Classes (IFC) for data sharing
in the construction and facility management industries. International Stan-
dardization Organization, 2013.
Holger Knublauch and Dimitris Kontokostas. Shapes Constraint Language
(SHACL). W3C Recommendation, W3C, July 20 2017.
Maxime Lefran¸cois. Planned ETSI SAREF extensions based on the
W3C&OGC SOSA/SSN-compatible SEAS ontology patterns. In Workshop
on semantic interoperability and standardization in the IoT, SIS-IoT, page
11p, 2017.
Maxime Lefran¸cois, Antoine Zimmermann, and Noorani Bakerally. A SPARQL
extension for generating RDF from heterogeneous formats. In European
Semantic Web Conference, pages 35–50. Springer, 2017.
oneM2M. oneM2M; Base Ontology (oneM2M TS-0012 version 3.7.1). oneM2M
Technical Specification 0012 v3.7.1., 2018.
Open Geospatial Consortium. OGC 11-052r4: OGC GeoSPARQL - A Geo-
graphic Query Language for RDF Data. Version 1.0. Technical report, 2012.
Mar´ıa Poveda-Villal´on and Ra´ul Garc´ıa-Castro. Extending the SAREF ontol-
ogy for building devices and topology. In Proceedings of the 6th Linked Data
in Architecture and Construction Workshop (LDAC 2018), Vol. CEUR-WS,
volume 2159, pages 16–23, 2018.
48
Mar´ıa Poveda-Villal´on, Asunci´on G´omez-P´erez, and Mari Carmen Su´arez-
Figueroa. OOPS! (ontology pitfall scanner!): An on-line tool for ontology
evaluation. International Journal on Semantic Web and Information Sys-
tems (IJSWIS), 10(2):7–34, 2014.
Mar´ıa Poveda-Villal´on, Alba Fern´andez-Izquierdo, Mariano Fern´andez-L´opez,
and Ra´ul Garc´ıa-Castro. LOT: An industrial oriented ontology engineering
framework. Engineering Applications of Artificial Intelligence, 111, 2022.
Pierre-Yves Vandenbussche, Ghislain A Atemezing, Mar´ıa Poveda-Villal´on,
and Bernard Vatant. Linked Open Vocabularies (LOV): a gateway to
reusable semantic vocabularies on the Web. Semantic Web, 8(3):437–452,
2017.
World Health Organization. Guidelines for drinking water quality. fourth edi-
tion incorporating the first addendum. Technical report, 2017.
49