SIST EN 303 760 V1.1.1:2024

EUROPEAN STANDARD
SmartM2M;
SAREF Guidelines for IoT Semantic Interoperability;
Develop, apply and evolve Smart Applications ontologies

2 ETSI EN 303 760 V1.1.1 (2024-10)

Reference
DEN/SmartM2M-303760
Keywords
application, application layer, artificial intelligence,
interoperability, IoT, IoT platforms, methodology,
ontology, SAREF, semantic
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
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 on ETSI deliver.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
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 2024.
All rights reserved.
ETSI
3 ETSI EN 303 760 V1.1.1 (2024-10)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Introduction . 5
1 Scope . 7
2 References . 8
2.1 Normative references . 8
2.2 Informative references . 9
3 Definition of terms, symbols and abbreviations . 10
3.1 Terms . 10
3.2 Symbols . 11
3.3 Abbreviations . 11
4 Motivation . 12
5 Getting started . 14
5.1 Define use cases . 14
5.2 Identify core elements . 15
5.3 Get acquainted with SAREF . 16
5.3.1 Introduction. 16
5.3.2 Get Familiar with SAREF Core . 16
5.3.3 Define the Domain of the Information that Require Structuring . 16
5.3.4 Get Familiar with the Selected SAREF Extensions . 16
5.3.5 Enhance SAREF Core with its Extensions . 17
5.4 Ensure use of correct SAREF version . 17
6 Use and instantiation of SAREF (data) . 18
6.1 Map data to SAREF-compliant data . 18
6.2 Test SAREF-compliant data . 19
7 Extension of SAREF . 20
7.1 Create a new SAREF extension . 20
7.2 Ensure compliance of an extension to SAREF . 21
8 Contribution to ETSI SAREF suite of ontologies . 21
8.1 Introduction . 21
8.2 Actors and workflow for starting the development of a new SAREF extension . 21
8.3 SAREF development framework and SAREF pipeline . 23
8.3.1 Introduction. 23
8.3.2 SAREF Project Version Specification and Documentation . 24
8.3.3 Quality Control and Requirements Verification with the SAREF Pipeline . 25
Annex A (informative): Example of a use case . 28
Annex B (informative): Example of relevant core elements from a use case . 31
Annex C (informative): Example of data translated into SAREF-compliant data. 37
Annex D (informative): Example of testing SAREF data . 39
Annex E (informative): SAREF methodology . 41
Annex F (informative): Implementation conformance statement pro forma . 42
Annex G (informative): Example of how to enhance SAREF Core with its Extensions . 45
History . 47
ETSI
4 ETSI EN 303 760 V1.1.1 (2024-10)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are 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 Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
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.
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.
Foreword
This European Standard (EN) has been produced by ETSI Technical Committee Smart Machine-to-Machine
communications (SmartM2M).
National transposition dates
Date of adoption of this EN: 25 September 2024
Date of latest announcement of this EN (doa): 31 December 2024
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 30 June 2025
Date of withdrawal of any conflicting National Standard (dow): 30 June 2025

Modal verbs terminology
In the present document "shall", "shall not", "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 EN 303 760 V1.1.1 (2024-10)
Introduction
Fragmentation of the IoT ecosystem in terms of standardization, architectures and available technologies and IoT
service platforms targeting specific applications or application domains impede the sharing of information between the
resulting silos. An increasing number of IoT devices located in different IoT networks generate greater quantities of
data to be shared across the IoT. Therefore, more and more devices and applications need to interoperate.
Manufacturers of IoT devices are faced with many standards and protocols to choose from. Consumers invest in smart
IoT products. In order to combine products from different vendors according to their needs, consumers want to make
sure that these products are interoperable with each other.
All of this underscores the need for open and standardized interfaces for products of different brands to interoperate and
to avoid vendor-lock in. Interoperability offers the business benefit, to unlock new added value services for consumers
from data integration, while manufacturers and other commercial parties can still maintain their competitive advantage
in offering their solutions (not everything needs to become open and interoperable).
In the past, interoperability used to be addressed at the technical communication level.
EXAMPLES:
- by using one agreed single data model, but nowadays there is too big fragmentation in existing data
models/protocols to choose from;
- by implementing ad-hoc translations between different data models/protocols, which turns to be very
expensive when there are so many standards/protocols that can be translated into each other.
In recent years, the interoperability challenge has been raised to the information level, where the common concepts for
all existing data models/protocols can be incorporated in an ontology (i.e. a common vocabulary). This captures the
meaning of a concept (i.e. semantics) rather than the specific data format in which the concept is encoded for data
exchange at the underlying communication layer.
The Smart Applications REFerence ontology (SAREF) developed and maintained by ETSI since 2015 provides a
mature, sustainable and standardized framework of ontologies for IoT that enables different parties to interoperate with
each other at the semantic level.
The present document brings together widely considered good practices in semantic interoperability for IoT smart
applications in a set of high-level outcome-focused provisions. The objective of the present document is to support all
parties involved in the development and manufacturing of IoT smart applications and products with guidance on
making them interoperable in compliance to the SAREF framework. The provisions give organizations and companies
the flexibility to innovate and implement SAREF-compliant semantic interoperability solutions appropriate for their
products and applications.
The present document is not intended to specify the technical details of SAREF, which are evolving further dynamically
in the respective ETSI Standards, and which it refers to. Rather, it describes a methodology to apply SAREF in
products/solutions and how to show SAREF compliance according to the present SAREF EN and optionally how to
contribute to a new SAREF extension (if what Users need is not yet in the SAREF framework).
The provisions in the present document have been developed following a review of published standards,
recommendations and guidance on semantic interoperability and SAREF, including:
• "SAREF: the Smart Applications REFerence ontology" [i.7]
• ETSI TS 103 673 [1]
• ETSI TS 103 264 [2]
• ETSI TS 103 548 [3]
• ETSI TS 103 410-1 [4]
• ETSI TS 103 410-2 [5]
• ETSI TS 103 410-3 [6]
• ETSI TS 103 410-4 [7]
ETSI
6 ETSI EN 303 760 V1.1.1 (2024-10)
• ETSI TS 103 410-5 [8]
• ETSI TS 103 410-6 [9]
• ETSI TS 103 410-7 [10]
• ETSI TS 103 410-8 [11]
• ETSI TS 103 410-9 [12]
• ETSI TS 103 410-10 [13]
• ETSI TS 103 410-11 [14]
• ETSI TS 103 410-12 [16]
As IoT applications and products become increasingly interoperable, it is envisioned that future revisions of the present
document will mandate provisions that are currently recommendations in the present document.

ETSI
7 ETSI EN 303 760 V1.1.1 (2024-10)
1 Scope
The present document gives guidance and provisions for making IoT smart applications and products interoperable at
the semantic level in compliance to the SAREF framework. It contains provisions about how to use SAREF, points to
the relevant existing Technical Reports and Technical Specifications and specifies a methodology to follow for showing
SAREF compliance according to the present SAREF EN. Further on, it describes how to contribute optionally to a new
SAREF extension (if what Users need is not yet in the SAREF framework).
The present document addresses parties involved in the development and manufacturing of IoT smart applications and
products, who might take different roles in their organization like:
• executives and product owners, who decide on to invest in a SAREF-compliant product;
• developers, who will implement a SAREF-compliant product as non-ontology experts or even ontology
experts.
Different roles imply different intentions and expectations when reading the present document according to their tasks
in the organization. The present document considers this by its implemented structure. Clause 4 provides guidance
about how to go throughout the present document in order to judge, which clauses might be essential for the special role
of the reader and which ones might be skipped.
The present document is structured as follows:
• Clauses 1 to 3 set the scene and provide references as well as definitions of terms, symbols and abbreviations,
which are used in the present document.
• Clause 4 defines the motivation and principles shared by those who are reading the present document also
serving as a checkpoint whether the reader is in the right place or not. It includes a brief reading guide as not
everyone needs to read every part of the present document, depending on the reader's role and expertise.
• Clause 5.1 provides guidance about the best practice of specifying use cases as the important basis for
deriving requirements from them.
• Clause 5.2 provides guidance/provisions about identifying core elements from the use cases defined in
clause 5.1.
• Clause 5.3 describes, how to get acquainted with SAREF.
• Clause 5.4 provides guidance /provisions about ensuring that the correct (latest) versions of the relevant
SAREF modules/patterns/extensions are selected. It illustrates, how to document the version of those SAREF
modules, which the product, application, or possible ontology extension is compliant to.
• Clause 6.1 provides guidance/provisions about the translation of data into SAREF.
• Clause 6.2 gives guidance about testing "SAREF-compliant data" in one example application of
interoperability exchange with another organization/manufacturer/brand.
• Clause 7.1 provides guidance/provisions about creating a new SAREF extension (or pattern).
• Clause 7.2 provides guidance/provisions about checking SAREF compliance of a new created SAREF
extension without going (yet) to an official standardization contribution to ETSI.
• Clause 8 describes the process of incorporating a new created SAREF extension according to clause 7 in the
official standardization process in ETSI, which will then result in a new official extension/pattern
(SAREF4abcd) under the ETSI SAREF namespace.
• Annex A contains an example of a possible use case to provide context to clause 5.1.
• Annex B contains examples of relevant core elements from use cases to provide context to clause 5.2.
• Annex C contains examples of translating data into SAREF-compliant data to provide context to clause 6.1.
• Annex D contains examples of testing SAREF data to provide context to clause 6.2.
ETSI
8 ETSI EN 303 760 V1.1.1 (2024-10)
• Annex E provides a short summary of SAREF ontology development methodology with figures and different
phases.
• Annex F provides a mechanism for the User of the present document (who is expected to be an entity involved
in the development and manufacturing of IoT smart applications and products) to give information about the
implementation of the provisions within the present document.
• Annex G provides an example of how to enhance the SAREF core with its extensions to give context to
clause 7.
2 References
2.1 Normative 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.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
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 necessary for the application of the present document.
[1] ETSI TS 103 673: "SmartM2M; SAREF Development Framework and Workflow, Streamlining
the Development of SAREF and its Extensions".
[2] ETSI TS 103 264: "SmartM2M; Smart Applications; Reference Ontology and oneM2M
Mapping".
[3] ETSI TS 103 548: "SmartM2M; SAREF reference ontology patterns".
[4] ETSI TS 103 410-1: "SmartM2M; Extension to SAREF; Part 1: Energy Domain".
[5] ETSI TS 103 410-2: "SmartM2M; Extension to SAREF; Part 2: Environment Domain".
[6] ETSI TS 103 410-3: "SmartM2M; Extension to SAREF; Part 3: Building Domain".
[7] ETSI TS 103 410-4: "SmartM2M; Extension to SAREF; Part 4: Smart Cities Domain".
[8] ETSI TS 103 410-5: "SmartM2M; Extension to SAREF; Part 5: Industry and Manufacturing
domains".
[9] ETSI TS 103 410-6: "SmartM2M; Extension to SAREF; Part 6: Smart Agriculture and Food Chain
Domain".
[10] ETSI TS 103 410-7: "SmartM2M; Extension to SAREF; Part 7: Automotive Domain".
[11] ETSI TS 103 410-8: "SmartM2M; Extension to SAREF; Part 8: eHealth/Ageing-well Domain".
[12] ETSI TS 103 410-9: "SmartM2M; Extension to SAREF; Part 9: Wearables Domain".
[13] ETSI TS 103 410-10: "SmartM2M; Extension to SAREF; Part 10: Water Domain".
[14] ETSI TS 103 410-11: "SmartM2M; Extension to SAREF; Part 11: Lift Domain".
[15] ETSI Labs: SAREF extensions online.
[16] ETSI TS 103 410-12: "SmartM2M; Extension to SAREF; Part 12: Smart Grid Domain".
ETSI
9 ETSI EN 303 760 V1.1.1 (2024-10)
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 Labs: SAREF pipeline SW.
[i.2] Poveda-Villalón, M., Fernández-Izquierdo, A., Fernández-López, M., & García-Castro, R. (2022).
LOT: An industrial oriented ontology engineering framework. Engineering Applications of
Artificial Intelligence, 111, 104755.
[i.3] Linked Open Terms (LOT) methodology website.
[i.4] ETSI TR 103 411: "SmartM2M; Smart Appliances; SAREF extension investigation".
[i.5] IEC 62559: "Use case methodology".
[i.6] EN 50631-1: "Household appliances network and grid connectivity - Part 1: General
Requirements, Generic Data Modelling and Neutral Messages" (produced by CENELEC).
[i.7] ETSI SAREF portal.
[i.8] EN 50491-12-2: "General requirements for Home and Building Electronic Systems (HBES) and
Building Automation and Control Systems (BACS) - Part 12-2: Smart grid - Application
specification - Interface and framework for customer - Interface between the Home / Building
CEM and Resource manager(s) - Data model and messaging" (produced by CENELEC).
[i.9] ETSI Labs: Sources of the SAREF Extensions.
[i.10] ETSI Labs: SAREF-portal repository.
[i.11] Chávez-Feria, Serge, Raúl García-Castro, and María Poveda-Villalón. "Chowlk: from UML-Based
th
Ontology Conceptualizations to OWL." The Semantic Web: 19 International Conference, ESWC
2022, Hersonissos, Crete, Greece, May 29-June 2, 2022, Proceedings. Cham: Springer
International Publishing, 2022. ®
[i.12] W3C Recommendation 27 September 2012: "A Direct Mapping of Relational Data to RDF". ®
[i.13] W3C Recommendation 27 September 2012: "R2RML: RDB to RDF Mapping Language".
[i.14] Declarative RDF graph generation from heterogeneous (semi-)structured data: A systematic
literature review, Journal of Web Semantics, Volume 75, January 2023, 100753.
[i.15] Common JUnit XML Format & Examples, JUnit project. ®
[i.16] W3C Recommendation 21 March 2013: "SPARQL 1.1 Query Language".
[i.17] ETSI TS 103 735: "SmartM2M; Smart Lifts IoT System".
[i.18] EN 627: "Specification for data logging and monitoring of lifts, escalators and passenger
conveyors", 1995 (produced by CEN).
ETSI
10 ETSI EN 303 760 V1.1.1 (2024-10)
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI TS 103 673 [1] apply:
cleansing plan: data cleansing is the process of fixing or removing incorrect, corrupted, incorrectly formatted,
duplicate, or incomplete data within a dataset which improves data quality and helps provide more accurate, consistent
and reliable information
ETSI Labs: platform where ETSI members and others on invitation can collaborate and experiment with code around
ETSI standardized technologies, developing demos, prototypes and proofs of concept
NOTE: As specified in ETSI Labs: SAREF pipeline SW [i.1].
ontology: formal specification of a conceptualization, used to explicitly capture the semantics of a certain reality
SAREF actor: role that a person can play when using or contributing to SAREF
SAREF core: versioned reference ontology for the IoT developed by ETSI SmartM2M
NOTE: As specified in ETSI TS 103 264 [2].
SAREF development framework: actors, software, and infrastructure that support the SAREF development
workflows
NOTE: As specified in ETSI TS 103 673 [1].
SAREF development workflows: specification of a lifecycle of SAREF project versions, where SAREF actors interact
in a codified manner
NOTE: For example their creation, development, and release ETSI TS 103 673 [1].
SAREF extension: versioned ontology extending SAREF core for a certain domain
NOTE: SAREF extensions are documented in ETSI Technical Specifications ETSI TS 103 410-1 [4], ETSI
TS 103 410-2 [5], ETSI TS 103 410-3 [6], ETSI TS 103 410-4 [7], ETSI TS 103 410-5 [8], ETSI
TS 103 410-6 [9], ETSI TS 103 410-7 [10], ETSI TS 103 410-8 [11], ETSI TS 103 410-9 [12], ETSI
TS 103 410-10 [13], ETSI TS 103 410-11 [14] and ETSI TS 103 410-12 [16].
SAREF extension acronym: SAREF extension is named SAREF4ABCD, where ABCD is the SAREF extension
acronym, and is any sequence of four letters
NOTE: This acronym is unique for each extension.
SAREF pipeline: software on ETSI Labs that can check the conformance of one or more SAREF project versions with
respect to ETSI TS 103 673 [1], and generate part of the SAREF public portal [i.7]
NOTE: The SAREF pipeline may be run manually by a SAREF actor, or automatically by a continuous
integration and continuous deployment service. See ETSI Labs: SAREF pipeline SW [i.1] for
instructions.
SAREF project: SAREF core, or any SAREF extension
SAREF project version: SAREF project has several versions, each being numbered by a version number vx.y.z
NOTE 1: The first number x is the major version. The second number y is the minor version. The third number z
is the patch version.
NOTE 2: The version numbering system for SAREF projects is different from the ETSI version numbering system.
SAREF project release: SAREF project version whose documentation is exposed on the SAREF public portal
ETSI
11 ETSI EN 303 760 V1.1.1 (2024-10)
SAREF project repository: git repository that consists of git branches, which consist of sequences of git commits
NOTE: Git commits have a unique identifier. There are four types of branches in a SAREF project repository:
issue branches, develop branches, pre-release branches, and release branches:
 issue branches are named issue-w, where w is an issue number of the SAREF project;
 develop branches are named develop-vx.y.z, where vx.y.z is a SAREF project version
number;
 pre-release branches are named prerelease-vx.y.z, where vx.y.z is a SAREF project version
number;
 release branches are named release-vx.y.z, where vx.y.z is a SAREF project version number.
SAREF project sources: git repository called the SAREF project repository, an associated public issue tracker, and
a continuous integration and continuous deployment service
SAREF ETSI Labs: software development and git-based source code web platform managed by the ETSI Secretariat
NOTE: The SAREF ETSI Labs contains the SAREF projects sources. The entry point to the SAREF public
ETSI Labs is https://labs.etsi.org/rep/saref/ [i.9].
SAREF public portal: web server hosted on an ETSI server and managed by the ETSI Secretariat [i.7]
NOTE: It exposes the documentation of SAREF and the SAREF projects to the public. The entry point to the
SAREF public portal is https://saref.etsi.org/. The SAREF public portal contains the documentation of all
the SAREF projects for different SAREF project releases.
user: stakeholder, who wants to apply SAREF in his products/solutions
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AI Artificial Intelligence
BER Bit Error Rate
CD Continuous Deployment
CI Continuous Integration
CLI Command Line Interface
CSV Comma Separated Values
DL Description Logics
EN European Standard
FoaF Friend-of-a-Friend
GUI Graphical User Interface
HTML Hyper Text Markup Language
IoT Internet of Things
IPR Intellectual Property Right
IRI Internationalized Resource Identifier
LOT Linked Open Terms (methodology)
NAN Not A Number
ORSD Ontology Requirements Specification Document
OWL Web Ontology Language
QUDT Quantities, Units, Dimensions, and Types Ontology
R2RML RDB to RDF Mapping Language
RDB Relational Data Base
RDF Resource Description Framework
RSSI Radio Signal Strength Indicator
ETSI
12 ETSI EN 303 760 V1.1.1 (2024-10)
SAREF Smart Applications REFerence ontology
SCD SAREF-Compliant Data
SHA Secure Hash Algorithm
SHACL Shapes Constraint Language
SPARQL SPARQL Protocol and RDF Query Language
SPINE-IoT Smart Premises Interoperable Neutral-message Exchange protocol
STF Specialist Task Force
TR Technical Report
TS Technical Specification
URI Uniform Resource Identifier
URL Universal Resource Locator
UTF-8 Unicode Transformation Format (the 8-bit form) ®
W3C World Wide Web Consortium
WSDB Web Service Data Broker
YAML YAML Ain't Markup Language
4 Motivation
The present document addresses parties involved in the development and manufacturing of IoT smart applications,
services and products, which want to make their applications, services and products interoperable with each other and
with those of other different parties. The Smart Applications REFerence ontology (SAREF) developed and maintained
by ETSI since 2015 provides a mature, sustainable and standardized framework of ontologies for IoT that enables
different parties to interoperate with each other at the semantic level.
The present document provides a decision support for the implementation of SAREF, a commonly agreed and
standardized ontology with many extensions in different IoT domains, a shared model of consensus that facilitates the
matching of existing assets in the smart applications. Once decided to apply SAREF, the present document describes all
steps to be taken in order to be SAREF-compliant by fulfilling the documented provisions.
As the reader of the present document might take different roles in his organization like:
• executives and product owners, who decide on to invest in a SAREF-compliant application, service or product;
• developers, who will implement a SAREF-compliant product as non-ontology experts or even ontology
experts.
Different roles imply different intentions and expectations when reading the present document according to the specific
tasks in the reader's organization, the present clause gives some guidance about how to go throughout the present
document in order to judge, which clauses might be essential for the special role of the reader and which ones might be
skipped.
Figure 4-1 illustrates the steps, which are necessary to get a SAREF-compliant data set for usage in an interoperable IoT
product, application or service and which are mandatory (some are optional) to perform for being compliant with the
present document.
ETSI
13 ETSI EN 303 760 V1.1.1 (2024-10)

Figure 4-1: Steps to SAREF Compliance
• Starting point:
A company wants to apply SAREF in their products/solutions and show SAREF compliance according to the
present document and optionally contribute to a new SAREF extension if what they need is not yet in the SAREF
framework.
• Step 1 (clause 4):
The present clause 4 shall be read first before the following clauses, since it describes the principles of being
compliant with the present document.
It also recommends to perform an initial self-assessment of the reader's expertise on ontologies, as this could lead to
different paths in using the present document as well as different roles of the reader (e.g. decision maker, traditional
developer not experienced in semantic technology, ontology expert, etc.) may also take advantage of it.
• Step 2 (clause 5.1):
Defining use cases is a sound basis for selecting, implementing and applying an ontology. Therefore clause 5.1
provides a description of best practice to define use cases as a way to clarify requirements and identifying core
elements from them.
Based on this information, the User shall formulate and describe his use case, e.g. short natural language description
like as described in IEC 62559 [i.5] or following a certain different standard.
• Step 3 (clauses 5.2 and 5.3):
Clauses 5.2 to 5.3 provide guidance and provisions for this step 3, which requests the identification of core elements
from the use cases, which have been described by performing step 2.
Before exploring, which SAREF modules/extensions can be relevant, Users shall get acquainted with the SAREF
framework in general, so that in the next step 4 they can keep focus on getting more acquainted with the relevant
parts of SAREF only.
ETSI
14 ETSI EN 303 760 V1.1.1 (2024-10)
• Step 4 (clauses 5.3 and 5.4):
After in step 3 the Users have got acquainted with the SAREF framework in general, step 4 requests to identify
which existing SAREF modules/extensions can be relevant for the core elements being derived from the use cases.
These are the ones to keep focus on getting acquainted with in more in detail. It is important to ensure using the
latest version of the SAREF ontology/extensions.
If there is no existing SAREF modules/extensions being relevant for the core elements, step 5 will be the next one.
• Step 5 (optional, clause 7):
If there is no existing SAREF modules/extensions being relevant for the core elements derived from the use cases
(from step 4), clause 7 provides guidance/provisions about extending the existing SAREF ontology or creating a
new SAREF extension. The pipeline on the SAREF portal [i.1] is supporting this step as well.
• Step 6 (clause 6.1):
Having identified existing SAREF modules/extensions being relevant for the core elements or having created a new
SAREF extension (step 5), step 6 requests to translate the User's data into SAREF-compliant data. Clause 6.1
provides respective guidance/provisions to use SAREF in practice for this purpose.
Testing of the produced SAREF-compliant data according to interoperability is strongly recommended. Therefore,
the optional step 7 is the next one. Otherwise step 8 continues the process.
• Step 7 (optional, clause 6.2):
This optional step includes a test of the generated "SAREF-compliant data" in one example application of
interoperability exchange with another organization/manufacturer/brand that speaks a different language/protocol
(therefore interacting with it via SAREF).
• Step 8 (clause 8.3):
This step requests to show that and to demonstrate how the generated SAREF data have been created by following
the guidance/provisions of the present document and that they are SAREF-compliant. Using table F-1 in Annex F
supports to prove compliance with the present document.
• Step 9 (optional, clause 8):
Once having extended the existing SAREF ontology or created a new SAREF extension for implementing it in a
product or application, it makes a lot of sense to share it publicly with other Users by evolving the SAREF standard.
For this purpose, the optional step 9 includes the contribution of a new extension to be submitted to ETSI as part of
the official SAREF framework. This step supported by guidance/provisions given in clause 8 includes the
contribution and incorporation of new SAREF extensions or pattern (ontology schema) in the official
standardization process in ETSI.
Provision 4-1 In order to prove compliance with the present document, the User shall perform at least all steps listed in
clause 4, which are not optional.
NOTE 1: The product/application is SAREF-compliant when implementing the SAREF-compliant data generated
by following the entire process (steps 1 to 9) specified in the present document.
Table F-1 can provide a mechanism for the User of the present document (who is expected to be an entity
involved in the development or manufacturing of IoT systems and/or devices and/or applications) to give
information about the implementation of the provisions within the present document.
NOTE 2: As one example, suppose one department or company team has produced a working system that one or
more other departments could readily use. Defining a shared ontology facilitates and unifies the sharing
of this system, all the more so if direct database or system access is problematic. Data silos are often
deeply separated because of substantial technical and language differences. A similar situation is the
employment of sub-contractors, particularly in terms of industrial quality.
5 Getting started
5.1 Define use cases
The definition of use cases allows Users to write down their requirements and at the same time, to have a clear idea of
how SAREF can be useful for their purposes. As "use case", a natural language description of the main aspects of the
scenarios covering Users' activities is intended.
ETSI
15 ETSI EN 303 760 V1.1.1 (2024-10)
To describe use cases, the Users are not asked to provide such descriptions through the adoption of specific standards
(e.g. IEC 62559 [i.5] or EN 50631-1 [i.6]), but they are invited to adopt the following schema enabling the provision of
a simple but complete overview of each use case.
Such overview may guide the creation of the contents samples within Annexes A, B, C and D. Below, it is provided the
list of the provisions a User shall consider defining each use case.
Provision 5.1.1 The User shall provide a general description of the use case, including domain specification and the
problems to be solved. Here, it is expected to find the main purposes of the use case including the mention to each element
of interest that may be linked to conceptual entities already defined within SAREF Core or existing SAREF extensions.
Alternatively, such elements of interest may represent the main concepts of a further SAREF extension proposed by the
User. In this case, a detailed description of each element of interest is required to better understand its context and try to
define a candidate model.
Provision 5.1.2 The User shall provide the list of the actors that are part of the use case. Through a precise definition of
the actors it is possible to gather specific information that may be included in the possible future conceptual model.
Provision 5.1.3 The User shall describe the existing context in which the use case is defined. Such a description allows
to have a broad landscape of how the knowledge necessary to manage the use case may be linked with existing SAREF
concepts (both Core and its extensions), if any. Indeed, through the analysis of the use case the need to define new concepts
and/or properties linking existing SAREF concepts with a candidate new extension.
Provision 5.1.4 The User shall provide a use case workflow by describing how each task is performed and how the entities
described evolve through time.
Provision 5.1.5 The User should provide any further information about the use case that is not included in the previous
provisions.
NOTE: IEC 62559 [i.5] may be used as an optional standard for describing use cases.
5.2 Identify core elements
This clause provides guidance via a set of provisions to identify the core elements of the use case in questions. These
core elements will in the following sections inform the user to which extent SAREF and its extensions can cover their
use cases.
Provision 5.2-1 The User shall identify the core elements of the use cases.
Provision 5.2-2 The User should categorize the list of core elements according to their type, e.g. objects, attributes,
datatypes, code list elements, and more.
EXAMPLE 1: In an example use case covering a flexible start for white goods, the main concepts could be the
appliance, its energy usage configuration options, the User preferences, as well as instructions
from an energy management system. The appliances would be the main objects. The User
preferences and the energy usage would be the attributes. The relevant datatypes could be gathered
from the attributes.
Provision 5.2-3 The User should identify the questions that the semantic model should be able to answer, potentially in
collaboration with a use case tool.
EXAMPLE 2: In the flexible start for white goods use case, the main questions that would have to be answered
could be:
 What is the allowed possible start time?
 What is my power consumption profile?
 What is the forecasted energy production and consumption throughout the relevant period?
 At which moment should the white goods start its program execution?
ETSI
16 ETSI EN 303 760 V1.1.1 (2024-10)
NOTE: Some questions can be directly answered by the data employing the semantic model, whereas in other
cases semantic model only facilitates the answering. The question of which types of energy flexibility a
device exposes can be directly answered, whereas the question of which energy flexibility configuration
is optimal would be facilitated by the ontology but would still require an external component.
Provision 5.2-4 The User shall identify which, if any, existing standards could be relevant to the use case.
EXAMPLE 3: For an energy flexibility use case, energy usage
...

SLOVENSKI STANDARD
01-december-2024
SmartM2M - Smernice SAREF za semantično interoperabilnost IoT - Razvoj,
uporaba in prenos ontologij za pametne aplikacije
SmartM2M - SAREF Guidelines for IoT Semantic Interoperability - Develop, apply and
evolve Smart Applications ontologies
Ta slovenski standard je istoveten z: ETSI EN 303 760 V1.1.1 (2024-10)
ICS:
35.020 Informacijska tehnika in Information technology (IT) in
tehnologija na splošno general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
SmartM2M;
SAREF Guidelines for IoT Semantic Interoperability;
Develop, apply and evolve Smart Applications ontologies

2 ETSI EN 303 760 V1.1.1 (2024-10)

Reference
DEN/SmartM2M-303760
Keywords
application, application layer, artificial intelligence,
interoperability, IoT, IoT platforms, methodology,
ontology, SAREF, semantic
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
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 on ETSI deliver.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
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 2024.
All rights reserved.
ETSI
3 ETSI EN 303 760 V1.1.1 (2024-10)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Introduction . 5
1 Scope . 7
2 References . 8
2.1 Normative references . 8
2.2 Informative references . 9
3 Definition of terms, symbols and abbreviations . 10
3.1 Terms . 10
3.2 Symbols . 11
3.3 Abbreviations . 11
4 Motivation . 12
5 Getting started . 14
5.1 Define use cases . 14
5.2 Identify core elements . 15
5.3 Get acquainted with SAREF . 16
5.3.1 Introduction. 16
5.3.2 Get Familiar with SAREF Core . 16
5.3.3 Define the Domain of the Information that Require Structuring . 16
5.3.4 Get Familiar with the Selected SAREF Extensions . 16
5.3.5 Enhance SAREF Core with its Extensions . 17
5.4 Ensure use of correct SAREF version . 17
6 Use and instantiation of SAREF (data) . 18
6.1 Map data to SAREF-compliant data . 18
6.2 Test SAREF-compliant data . 19
7 Extension of SAREF . 20
7.1 Create a new SAREF extension . 20
7.2 Ensure compliance of an extension to SAREF . 21
8 Contribution to ETSI SAREF suite of ontologies . 21
8.1 Introduction . 21
8.2 Actors and workflow for starting the development of a new SAREF extension . 21
8.3 SAREF development framework and SAREF pipeline . 23
8.3.1 Introduction. 23
8.3.2 SAREF Project Version Specification and Documentation . 24
8.3.3 Quality Control and Requirements Verification with the SAREF Pipeline . 25
Annex A (informative): Example of a use case . 28
Annex B (informative): Example of relevant core elements from a use case . 31
Annex C (informative): Example of data translated into SAREF-compliant data. 37
Annex D (informative): Example of testing SAREF data . 39
Annex E (informative): SAREF methodology . 41
Annex F (informative): Implementation conformance statement pro forma . 42
Annex G (informative): Example of how to enhance SAREF Core with its Extensions . 45
History . 47
ETSI
4 ETSI EN 303 760 V1.1.1 (2024-10)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are 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 Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
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.
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.
Foreword
This European Standard (EN) has been produced by ETSI Technical Committee Smart Machine-to-Machine
communications (SmartM2M).
National transposition dates
Date of adoption of this EN: 25 September 2024
Date of latest announcement of this EN (doa): 31 December 2024
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 30 June 2025
Date of withdrawal of any conflicting National Standard (dow): 30 June 2025

Modal verbs terminology
In the present document "shall", "shall not", "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 EN 303 760 V1.1.1 (2024-10)
Introduction
Fragmentation of the IoT ecosystem in terms of standardization, architectures and available technologies and IoT
service platforms targeting specific applications or application domains impede the sharing of information between the
resulting silos. An increasing number of IoT devices located in different IoT networks generate greater quantities of
data to be shared across the IoT. Therefore, more and more devices and applications need to interoperate.
Manufacturers of IoT devices are faced with many standards and protocols to choose from. Consumers invest in smart
IoT products. In order to combine products from different vendors according to their needs, consumers want to make
sure that these products are interoperable with each other.
All of this underscores the need for open and standardized interfaces for products of different brands to interoperate and
to avoid vendor-lock in. Interoperability offers the business benefit, to unlock new added value services for consumers
from data integration, while manufacturers and other commercial parties can still maintain their competitive advantage
in offering their solutions (not everything needs to become open and interoperable).
In the past, interoperability used to be addressed at the technical communication level.
EXAMPLES:
- by using one agreed single data model, but nowadays there is too big fragmentation in existing data
models/protocols to choose from;
- by implementing ad-hoc translations between different data models/protocols, which turns to be very
expensive when there are so many standards/protocols that can be translated into each other.
In recent years, the interoperability challenge has been raised to the information level, where the common concepts for
all existing data models/protocols can be incorporated in an ontology (i.e. a common vocabulary). This captures the
meaning of a concept (i.e. semantics) rather than the specific data format in which the concept is encoded for data
exchange at the underlying communication layer.
The Smart Applications REFerence ontology (SAREF) developed and maintained by ETSI since 2015 provides a
mature, sustainable and standardized framework of ontologies for IoT that enables different parties to interoperate with
each other at the semantic level.
The present document brings together widely considered good practices in semantic interoperability for IoT smart
applications in a set of high-level outcome-focused provisions. The objective of the present document is to support all
parties involved in the development and manufacturing of IoT smart applications and products with guidance on
making them interoperable in compliance to the SAREF framework. The provisions give organizations and companies
the flexibility to innovate and implement SAREF-compliant semantic interoperability solutions appropriate for their
products and applications.
The present document is not intended to specify the technical details of SAREF, which are evolving further dynamically
in the respective ETSI Standards, and which it refers to. Rather, it describes a methodology to apply SAREF in
products/solutions and how to show SAREF compliance according to the present SAREF EN and optionally how to
contribute to a new SAREF extension (if what Users need is not yet in the SAREF framework).
The provisions in the present document have been developed following a review of published standards,
recommendations and guidance on semantic interoperability and SAREF, including:
• "SAREF: the Smart Applications REFerence ontology" [i.7]
• ETSI TS 103 673 [1]
• ETSI TS 103 264 [2]
• ETSI TS 103 548 [3]
• ETSI TS 103 410-1 [4]
• ETSI TS 103 410-2 [5]
• ETSI TS 103 410-3 [6]
• ETSI TS 103 410-4 [7]
ETSI
6 ETSI EN 303 760 V1.1.1 (2024-10)
• ETSI TS 103 410-5 [8]
• ETSI TS 103 410-6 [9]
• ETSI TS 103 410-7 [10]
• ETSI TS 103 410-8 [11]
• ETSI TS 103 410-9 [12]
• ETSI TS 103 410-10 [13]
• ETSI TS 103 410-11 [14]
• ETSI TS 103 410-12 [16]
As IoT applications and products become increasingly interoperable, it is envisioned that future revisions of the present
document will mandate provisions that are currently recommendations in the present document.

ETSI
7 ETSI EN 303 760 V1.1.1 (2024-10)
1 Scope
The present document gives guidance and provisions for making IoT smart applications and products interoperable at
the semantic level in compliance to the SAREF framework. It contains provisions about how to use SAREF, points to
the relevant existing Technical Reports and Technical Specifications and specifies a methodology to follow for showing
SAREF compliance according to the present SAREF EN. Further on, it describes how to contribute optionally to a new
SAREF extension (if what Users need is not yet in the SAREF framework).
The present document addresses parties involved in the development and manufacturing of IoT smart applications and
products, who might take different roles in their organization like:
• executives and product owners, who decide on to invest in a SAREF-compliant product;
• developers, who will implement a SAREF-compliant product as non-ontology experts or even ontology
experts.
Different roles imply different intentions and expectations when reading the present document according to their tasks
in the organization. The present document considers this by its implemented structure. Clause 4 provides guidance
about how to go throughout the present document in order to judge, which clauses might be essential for the special role
of the reader and which ones might be skipped.
The present document is structured as follows:
• Clauses 1 to 3 set the scene and provide references as well as definitions of terms, symbols and abbreviations,
which are used in the present document.
• Clause 4 defines the motivation and principles shared by those who are reading the present document also
serving as a checkpoint whether the reader is in the right place or not. It includes a brief reading guide as not
everyone needs to read every part of the present document, depending on the reader's role and expertise.
• Clause 5.1 provides guidance about the best practice of specifying use cases as the important basis for
deriving requirements from them.
• Clause 5.2 provides guidance/provisions about identifying core elements from the use cases defined in
clause 5.1.
• Clause 5.3 describes, how to get acquainted with SAREF.
• Clause 5.4 provides guidance /provisions about ensuring that the correct (latest) versions of the relevant
SAREF modules/patterns/extensions are selected. It illustrates, how to document the version of those SAREF
modules, which the product, application, or possible ontology extension is compliant to.
• Clause 6.1 provides guidance/provisions about the translation of data into SAREF.
• Clause 6.2 gives guidance about testing "SAREF-compliant data" in one example application of
interoperability exchange with another organization/manufacturer/brand.
• Clause 7.1 provides guidance/provisions about creating a new SAREF extension (or pattern).
• Clause 7.2 provides guidance/provisions about checking SAREF compliance of a new created SAREF
extension without going (yet) to an official standardization contribution to ETSI.
• Clause 8 describes the process of incorporating a new created SAREF extension according to clause 7 in the
official standardization process in ETSI, which will then result in a new official extension/pattern
(SAREF4abcd) under the ETSI SAREF namespace.
• Annex A contains an example of a possible use case to provide context to clause 5.1.
• Annex B contains examples of relevant core elements from use cases to provide context to clause 5.2.
• Annex C contains examples of translating data into SAREF-compliant data to provide context to clause 6.1.
• Annex D contains examples of testing SAREF data to provide context to clause 6.2.
ETSI
8 ETSI EN 303 760 V1.1.1 (2024-10)
• Annex E provides a short summary of SAREF ontology development methodology with figures and different
phases.
• Annex F provides a mechanism for the User of the present document (who is expected to be an entity involved
in the development and manufacturing of IoT smart applications and products) to give information about the
implementation of the provisions within the present document.
• Annex G provides an example of how to enhance the SAREF core with its extensions to give context to
clause 7.
2 References
2.1 Normative 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.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
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 necessary for the application of the present document.
[1] ETSI TS 103 673: "SmartM2M; SAREF Development Framework and Workflow, Streamlining
the Development of SAREF and its Extensions".
[2] ETSI TS 103 264: "SmartM2M; Smart Applications; Reference Ontology and oneM2M
Mapping".
[3] ETSI TS 103 548: "SmartM2M; SAREF reference ontology patterns".
[4] ETSI TS 103 410-1: "SmartM2M; Extension to SAREF; Part 1: Energy Domain".
[5] ETSI TS 103 410-2: "SmartM2M; Extension to SAREF; Part 2: Environment Domain".
[6] ETSI TS 103 410-3: "SmartM2M; Extension to SAREF; Part 3: Building Domain".
[7] ETSI TS 103 410-4: "SmartM2M; Extension to SAREF; Part 4: Smart Cities Domain".
[8] ETSI TS 103 410-5: "SmartM2M; Extension to SAREF; Part 5: Industry and Manufacturing
domains".
[9] ETSI TS 103 410-6: "SmartM2M; Extension to SAREF; Part 6: Smart Agriculture and Food Chain
Domain".
[10] ETSI TS 103 410-7: "SmartM2M; Extension to SAREF; Part 7: Automotive Domain".
[11] ETSI TS 103 410-8: "SmartM2M; Extension to SAREF; Part 8: eHealth/Ageing-well Domain".
[12] ETSI TS 103 410-9: "SmartM2M; Extension to SAREF; Part 9: Wearables Domain".
[13] ETSI TS 103 410-10: "SmartM2M; Extension to SAREF; Part 10: Water Domain".
[14] ETSI TS 103 410-11: "SmartM2M; Extension to SAREF; Part 11: Lift Domain".
[15] ETSI Labs: SAREF extensions online.
[16] ETSI TS 103 410-12: "SmartM2M; Extension to SAREF; Part 12: Smart Grid Domain".
ETSI
9 ETSI EN 303 760 V1.1.1 (2024-10)
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 Labs: SAREF pipeline SW.
[i.2] Poveda-Villalón, M., Fernández-Izquierdo, A., Fernández-López, M., & García-Castro, R. (2022).
LOT: An industrial oriented ontology engineering framework. Engineering Applications of
Artificial Intelligence, 111, 104755.
[i.3] Linked Open Terms (LOT) methodology website.
[i.4] ETSI TR 103 411: "SmartM2M; Smart Appliances; SAREF extension investigation".
[i.5] IEC 62559: "Use case methodology".
[i.6] EN 50631-1: "Household appliances network and grid connectivity - Part 1: General
Requirements, Generic Data Modelling and Neutral Messages" (produced by CENELEC).
[i.7] ETSI SAREF portal.
[i.8] EN 50491-12-2: "General requirements for Home and Building Electronic Systems (HBES) and
Building Automation and Control Systems (BACS) - Part 12-2: Smart grid - Application
specification - Interface and framework for customer - Interface between the Home / Building
CEM and Resource manager(s) - Data model and messaging" (produced by CENELEC).
[i.9] ETSI Labs: Sources of the SAREF Extensions.
[i.10] ETSI Labs: SAREF-portal repository.
[i.11] Chávez-Feria, Serge, Raúl García-Castro, and María Poveda-Villalón. "Chowlk: from UML-Based
th
Ontology Conceptualizations to OWL." The Semantic Web: 19 International Conference, ESWC
2022, Hersonissos, Crete, Greece, May 29-June 2, 2022, Proceedings. Cham: Springer
International Publishing, 2022. ®
[i.12] W3C Recommendation 27 September 2012: "A Direct Mapping of Relational Data to RDF". ®
[i.13] W3C Recommendation 27 September 2012: "R2RML: RDB to RDF Mapping Language".
[i.14] Declarative RDF graph generation from heterogeneous (semi-)structured data: A systematic
literature review, Journal of Web Semantics, Volume 75, January 2023, 100753.
[i.15] Common JUnit XML Format & Examples, JUnit project. ®
[i.16] W3C Recommendation 21 March 2013: "SPARQL 1.1 Query Language".
[i.17] ETSI TS 103 735: "SmartM2M; Smart Lifts IoT System".
[i.18] EN 627: "Specification for data logging and monitoring of lifts, escalators and passenger
conveyors", 1995 (produced by CEN).
ETSI
10 ETSI EN 303 760 V1.1.1 (2024-10)
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI TS 103 673 [1] apply:
cleansing plan: data cleansing is the process of fixing or removing incorrect, corrupted, incorrectly formatted,
duplicate, or incomplete data within a dataset which improves data quality and helps provide more accurate, consistent
and reliable information
ETSI Labs: platform where ETSI members and others on invitation can collaborate and experiment with code around
ETSI standardized technologies, developing demos, prototypes and proofs of concept
NOTE: As specified in ETSI Labs: SAREF pipeline SW [i.1].
ontology: formal specification of a conceptualization, used to explicitly capture the semantics of a certain reality
SAREF actor: role that a person can play when using or contributing to SAREF
SAREF core: versioned reference ontology for the IoT developed by ETSI SmartM2M
NOTE: As specified in ETSI TS 103 264 [2].
SAREF development framework: actors, software, and infrastructure that support the SAREF development
workflows
NOTE: As specified in ETSI TS 103 673 [1].
SAREF development workflows: specification of a lifecycle of SAREF project versions, where SAREF actors interact
in a codified manner
NOTE: For example their creation, development, and release ETSI TS 103 673 [1].
SAREF extension: versioned ontology extending SAREF core for a certain domain
NOTE: SAREF extensions are documented in ETSI Technical Specifications ETSI TS 103 410-1 [4], ETSI
TS 103 410-2 [5], ETSI TS 103 410-3 [6], ETSI TS 103 410-4 [7], ETSI TS 103 410-5 [8], ETSI
TS 103 410-6 [9], ETSI TS 103 410-7 [10], ETSI TS 103 410-8 [11], ETSI TS 103 410-9 [12], ETSI
TS 103 410-10 [13], ETSI TS 103 410-11 [14] and ETSI TS 103 410-12 [16].
SAREF extension acronym: SAREF extension is named SAREF4ABCD, where ABCD is the SAREF extension
acronym, and is any sequence of four letters
NOTE: This acronym is unique for each extension.
SAREF pipeline: software on ETSI Labs that can check the conformance of one or more SAREF project versions with
respect to ETSI TS 103 673 [1], and generate part of the SAREF public portal [i.7]
NOTE: The SAREF pipeline may be run manually by a SAREF actor, or automatically by a continuous
integration and continuous deployment service. See ETSI Labs: SAREF pipeline SW [i.1] for
instructions.
SAREF project: SAREF core, or any SAREF extension
SAREF project version: SAREF project has several versions, each being numbered by a version number vx.y.z
NOTE 1: The first number x is the major version. The second number y is the minor version. The third number z
is the patch version.
NOTE 2: The version numbering system for SAREF projects is different from the ETSI version numbering system.
SAREF project release: SAREF project version whose documentation is exposed on the SAREF public portal
ETSI
11 ETSI EN 303 760 V1.1.1 (2024-10)
SAREF project repository: git repository that consists of git branches, which consist of sequences of git commits
NOTE: Git commits have a unique identifier. There are four types of branches in a SAREF project repository:
issue branches, develop branches, pre-release branches, and release branches:
 issue branches are named issue-w, where w is an issue number of the SAREF project;
 develop branches are named develop-vx.y.z, where vx.y.z is a SAREF project version
number;
 pre-release branches are named prerelease-vx.y.z, where vx.y.z is a SAREF project version
number;
 release branches are named release-vx.y.z, where vx.y.z is a SAREF project version number.
SAREF project sources: git repository called the SAREF project repository, an associated public issue tracker, and
a continuous integration and continuous deployment service
SAREF ETSI Labs: software development and git-based source code web platform managed by the ETSI Secretariat
NOTE: The SAREF ETSI Labs contains the SAREF projects sources. The entry point to the SAREF public
ETSI Labs is https://labs.etsi.org/rep/saref/ [i.9].
SAREF public portal: web server hosted on an ETSI server and managed by the ETSI Secretariat [i.7]
NOTE: It exposes the documentation of SAREF and the SAREF projects to the public. The entry point to the
SAREF public portal is https://saref.etsi.org/. The SAREF public portal contains the documentation of all
the SAREF projects for different SAREF project releases.
user: stakeholder, who wants to apply SAREF in his products/solutions
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AI Artificial Intelligence
BER Bit Error Rate
CD Continuous Deployment
CI Continuous Integration
CLI Command Line Interface
CSV Comma Separated Values
DL Description Logics
EN European Standard
FoaF Friend-of-a-Friend
GUI Graphical User Interface
HTML Hyper Text Markup Language
IoT Internet of Things
IPR Intellectual Property Right
IRI Internationalized Resource Identifier
LOT Linked Open Terms (methodology)
NAN Not A Number
ORSD Ontology Requirements Specification Document
OWL Web Ontology Language
QUDT Quantities, Units, Dimensions, and Types Ontology
R2RML RDB to RDF Mapping Language
RDB Relational Data Base
RDF Resource Description Framework
RSSI Radio Signal Strength Indicator
ETSI
12 ETSI EN 303 760 V1.1.1 (2024-10)
SAREF Smart Applications REFerence ontology
SCD SAREF-Compliant Data
SHA Secure Hash Algorithm
SHACL Shapes Constraint Language
SPARQL SPARQL Protocol and RDF Query Language
SPINE-IoT Smart Premises Interoperable Neutral-message Exchange protocol
STF Specialist Task Force
TR Technical Report
TS Technical Specification
URI Uniform Resource Identifier
URL Universal Resource Locator
UTF-8 Unicode Transformation Format (the 8-bit form) ®
W3C World Wide Web Consortium
WSDB Web Service Data Broker
YAML YAML Ain't Markup Language
4 Motivation
The present document addresses parties involved in the development and manufacturing of IoT smart applications,
services and products, which want to make their applications, services and products interoperable with each other and
with those of other different parties. The Smart Applications REFerence ontology (SAREF) developed and maintained
by ETSI since 2015 provides a mature, sustainable and standardized framework of ontologies for IoT that enables
different parties to interoperate with each other at the semantic level.
The present document provides a decision support for the implementation of SAREF, a commonly agreed and
standardized ontology with many extensions in different IoT domains, a shared model of consensus that facilitates the
matching of existing assets in the smart applications. Once decided to apply SAREF, the present document describes all
steps to be taken in order to be SAREF-compliant by fulfilling the documented provisions.
As the reader of the present document might take different roles in his organization like:
• executives and product owners, who decide on to invest in a SAREF-compliant application, service or product;
• developers, who will implement a SAREF-compliant product as non-ontology experts or even ontology
experts.
Different roles imply different intentions and expectations when reading the present document according to the specific
tasks in the reader's organization, the present clause gives some guidance about how to go throughout the present
document in order to judge, which clauses might be essential for the special role of the reader and which ones might be
skipped.
Figure 4-1 illustrates the steps, which are necessary to get a SAREF-compliant data set for usage in an interoperable IoT
product, application or service and which are mandatory (some are optional) to perform for being compliant with the
present document.
ETSI
13 ETSI EN 303 760 V1.1.1 (2024-10)

Figure 4-1: Steps to SAREF Compliance
• Starting point:
A company wants to apply SAREF in their products/solutions and show SAREF compliance according to the
present document and optionally contribute to a new SAREF extension if what they need is not yet in the SAREF
framework.
• Step 1 (clause 4):
The present clause 4 shall be read first before the following clauses, since it describes the principles of being
compliant with the present document.
It also recommends to perform an initial self-assessment of the reader's expertise on ontologies, as this could lead to
different paths in using the present document as well as different roles of the reader (e.g. decision maker, traditional
developer not experienced in semantic technology, ontology expert, etc.) may also take advantage of it.
• Step 2 (clause 5.1):
Defining use cases is a sound basis for selecting, implementing and applying an ontology. Therefore clause 5.1
provides a description of best practice to define use cases as a way to clarify requirements and identifying core
elements from them.
Based on this information, the User shall formulate and describe his use case, e.g. short natural language description
like as described in IEC 62559 [i.5] or following a certain different standard.
• Step 3 (clauses 5.2 and 5.3):
Clauses 5.2 to 5.3 provide guidance and provisions for this step 3, which requests the identification of core elements
from the use cases, which have been described by performing step 2.
Before exploring, which SAREF modules/extensions can be relevant, Users shall get acquainted with the SAREF
framework in general, so that in the next step 4 they can keep focus on getting more acquainted with the relevant
parts of SAREF only.
ETSI
14 ETSI EN 303 760 V1.1.1 (2024-10)
• Step 4 (clauses 5.3 and 5.4):
After in step 3 the Users have got acquainted with the SAREF framework in general, step 4 requests to identify
which existing SAREF modules/extensions can be relevant for the core elements being derived from the use cases.
These are the ones to keep focus on getting acquainted with in more in detail. It is important to ensure using the
latest version of the SAREF ontology/extensions.
If there is no existing SAREF modules/extensions being relevant for the core elements, step 5 will be the next one.
• Step 5 (optional, clause 7):
If there is no existing SAREF modules/extensions being relevant for the core elements derived from the use cases
(from step 4), clause 7 provides guidance/provisions about extending the existing SAREF ontology or creating a
new SAREF extension. The pipeline on the SAREF portal [i.1] is supporting this step as well.
• Step 6 (clause 6.1):
Having identified existing SAREF modules/extensions being relevant for the core elements or having created a new
SAREF extension (step 5), step 6 requests to translate the User's data into SAREF-compliant data. Clause 6.1
provides respective guidance/provisions to use SAREF in practice for this purpose.
Testing of the produced SAREF-compliant data according to interoperability is strongly recommended. Therefore,
the optional step 7 is the next one. Otherwise step 8 continues the process.
• Step 7 (optional, clause 6.2):
This optional step includes a test of the generated "SAREF-compliant data" in one example application of
interoperability exchange with another organization/manufacturer/brand that speaks a different language/protocol
(therefore interacting with it via SAREF).
• Step 8 (clause 8.3):
This step requests to show that and to demonstrate how the generated SAREF data have been created by following
the guidance/provisions of the present document and that they are SAREF-compliant. Using table F-1 in Annex F
supports to prove compliance with the present document.
• Step 9 (optional, clause 8):
Once having extended the existing SAREF ontology or created a new SAREF extension for implementing it in a
product or application, it makes a lot of sense to share it publicly with other Users by evolving the SAREF standard.
For this purpose, the optional step 9 includes the contribution of a new extension to be submitted to ETSI as part of
the official SAREF framework. This step supported by guidance/provisions given in clause 8 includes the
contribution and incorporation of new SAREF extensions or pattern (ontology schema) in the official
standardization process in ETSI.
Provision 4-1 In order to prove compliance with the present document, the User shall perform at least all steps listed in
clause 4, which are not optional.
NOTE 1: The product/application is SAREF-compliant when implementing the SAREF-compliant data generated
by following the entire process (steps 1 to 9) specified in the present document.
Table F-1 can provide a mechanism for the User of the present document (who is expected to be an entity
involved in the development or manufacturing of IoT systems and/or devices and/or applications) to give
information about the implementation of the provisions within the present document.
NOTE 2: As one example, suppose one department or company team has produced a working system that one or
more other departments could readily use. Defining a shared ontology facilitates and unifies the sharing
of this system, all the more so if direct database or system access is problematic. Data silos are often
deeply separated because of substantial technical and language differences. A similar situation is the
employment of sub-contractors, particularly in terms of industrial quality.
5 Getting started
5.1 Define use cases
The definition of use cases allows Users to write down their requirements and at the same time, to have a clear idea of
how SAREF can be useful for their purposes. As "use case", a natural language description of the main aspects of the
scenarios covering Users' activities is intended.
ETSI
15 ETSI EN 303 760 V1.1.1 (2024-10)
To describe use cases, the Users are not asked to provide such descriptions through the adoption of specific standards
(e.g. IEC 62559 [i.5] or EN 50631-1 [i.6]), but they are invited to adopt the following schema enabling the provision of
a simple but complete overview of each use case.
Such overview may guide the creation of the contents samples within Annexes A, B, C and D. Below, it is provided the
list of the provisions a User shall consider defining each use case.
Provision 5.1.1 The User shall provide a general description of the use case, including domain specification and the
problems to be solved. Here, it is expected to find the main purposes of the use case including the mention to each element
of interest that may be linked to conceptual entities already defined within SAREF Core or existing SAREF extensions.
Alternatively, such elements of interest may represent the main concepts of a further SAREF extension proposed by the
User. In this case, a detailed description of each element of interest is required to better understand its context and try to
define a candidate model.
Provision 5.1.2 The User shall provide the list of the actors that are part of the use case. Through a precise definition of
the actors it is possible to gather specific information that may be included in the possible future conceptual model.
Provision 5.1.3 The User shall describe the existing context in which the use case is defined. Such a description allows
to have a broad landscape of how the knowledge necessary to manage the use case may be linked with existing SAREF
concepts (both Core and its extensions), if any. Indeed, through the analysis of the use case the need to define new concepts
and/or properties linking existing SAREF concepts with a candidate new extension.
Provision 5.1.4 The User shall provide a use case workflow by describing how each task is performed and how the entities
described evolve through time.
Provision 5.1.5 The User should provide any further information about the use case that is not included in the previous
provisions.
NOTE: IEC 62559 [i.5] may be used as an optional standard for describing use cases.
5.2 Identify core elements
This clause provides guidance via a set of provisions to identify the core elements of the use case in questions. These
core elements will in the following sections inform the user to which extent SAREF and its extensions can cover their
use cases.
Provision 5.2-1 The User shall identify the core elements of the use cases.
Provision 5.2-2 The User should categorize the list of core elements according to their type, e.g. objects, attributes,
datatypes, code list elements, and more.
EXAMPLE 1: In an example use case covering a flexible start for white goods, the main concepts could be the
appliance, its energy usage configuration options, the User preferences, as well as instructions
from an energy management system. The appliances would be the main objects. The User
preferences and the energy usage would be the attributes. The relevant datatypes could be gathered
from the attributes.
Pro
...