ETSI TR 103 411 V1.1.1 (2017-02)

SmartM2M; Smart Appliances; SAREF extension investigation

DTR/SmartM2M-103411SAREF-EXT-I

General Information

• Status: Published
• Publication Date: 01-Feb-2017
• Technical Committee: SmartM2M - Smart M2M
• Current Stage: 12 - Completion
• Due Date: 01-Feb-2017
• Completion Date: 02-Feb-2017

Standards Content (Sample)

ETSI TR 103 411 V1.1.1 (2017-02)






TECHNICAL REPORT
SmartM2M;
Smart Appliances;
SAREF extension investigation

---------------------- Page: 1 ----------------------
2 ETSI TR 103 411 V1.1.1 (2017-02)



Reference
DTR/SmartM2M-103411SAREF-EXT-I
Keywords
data sharing, IoT, M2M, ontology, SAREF,
smart appliance

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

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

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

© European Telecommunications Standards Institute 2017.
All rights reserved.

TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI

---------------------- Page: 2 ----------------------
3 ETSI TR 103 411 V1.1.1 (2017-02)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Introduction . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 6
4 SAREF extension and maintenance . 7
4.1 Extensions . 7
4.2 Maintenance . 8
4.3 Specification . 9
4.4 Implementation . 10
4.5 Publication . 11
4.6 Extension domains . 11
5 Use cases and requirements . 12
5.1 Use cases . 12
5.1.1 Use cases from Energy@Home and EEBus . 12
5.1.2 Use cases from STARS4ALL . 15
5.1.3 Use cases from IFC . 16
5.2 General feedback on SAREF. 17
5.3 Requirements for the energy domain. 18
5.5 Requirements for the environment domain . 20
5.5 Requirements for the building domain . 22
5.6 Requirements from the oneM2M base ontology . 27
6 Instantiating SAREF and its extensions . 29
6.1 SAREF example . 29
6.2 SAREF4ENER example . 30
6.3 SAREF4ENVI example . 31
6.4 SAREF4BLDG example . 33
7 Conclusion . 36
Annex A: RDF code for SAREF example . 37
Annex B: RDF code for SAREF4ENER example . 38
Annex C: RDF code for SAREF4ENVI example . 41
Annex D: RDF code for SAREF4BLDG example . 43
Annex E: Bibliography . 45
History . 46


ETSI

---------------------- Page: 3 ----------------------
4 ETSI TR 103 411 V1.1.1 (2017-02)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Smart Machine-to-Machine
communications (SmartM2M).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
The present document was drafted by ETSI Technical Committee SmartM2M to provide insight into the management
of SAREF and its extensions. SAREF was created in 2014/2015 by TNO in a study requested by the European
Commission. After finishing the study, SAREF was transformed into a Technical Specification by ETSI SmartM2M
and published in November 2015. Since this period, a number of request for updates of SAREF were made, and a first
extension of SAREF for the Energy Demand and Response domain was also created. To elaborate a strategy on the
management of SAREF and identify possible extensions of SAREF in new domains, ETSI SmartM2M requested a
Specialist Task Force (STF) to provide input on these topics.
A number of possible areas for extensions have been identified: energy demand and response, environment, buildings,
agriculture and e-health/ageing well. The present document provides insight into the requirements from these domains,
and provides the guidelines for the maintenance, extension and publication of SAREF and its extensions.

ETSI

---------------------- Page: 4 ----------------------
5 ETSI TR 103 411 V1.1.1 (2017-02)
1 Scope
The present document presents the requirements gathered from the main smart appliances industrial actors to be
exploited and implemented in the companion ETSI TS 103 410-1 [i.13], ETSI TS 103 410-2 [i.14] and ETSI
TS 103 410-3 [i.15]. Next to that, the present document also provides input on the extension and maintenance of the
SAREF ontology. The aforementioned technical specifications define extensions to the Smart Appliances reference
ontology (SAREF) and the mapping to oneM2M as defined in ETSI TS 103 264 [i.3]. The objective is to include input
from the industrial actors from the appliances domain including non-energy related aspects.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] European Commission and TNO: "Smart Appliances REFerence ontology (SAREF)", April 2015.
NOTE: Available at http://ontology.tno.nl/saref.
[i.2] European Commission and TNO: "D-S4 - SMART 2013-0077 - Smart Appliances - Mapping
SAREF to short list assets.xlsx ", February 2015.
NOTE: Available at https://sites.google.com/site/smartappliancesproject/documents.
[i.3] ETSI TS 103 264 (V1.1.1) (11-2015): "SmartM2M; Smart Appliances; Reference Ontology and
oneM2M Mapping".
[i.4] ETSI TS 118 112: "oneM2M; Base Ontology (oneM2M TS-0012)".
[i.5] Gruber, T.: "Toward principles for the design of ontologies used for knowledge sharing",
International Journal of Human-Computer Studies, Volume 43, Issues 5-6, November 1995,
Pages 907-928.
NOTE: Available at http://www.sciencedirect.com/science/article/pii/S1071581985710816.
[i.6] IEC TR 62746-2: "Systems interface between customer energy management system and the power
management system - Part 2: Use cases and requirements", 2015.
[i.7] EEBus, SPINE.
NOTE: Available at https://www.eebus.org/en/specifications/.
[i.8] Corcho, O., González, E. Deliverable D1.1. Kick-off meeting report. STARS4ALL project.
March 2nd, 2016.
[i.9] Zamorano, J., García, C., González, R, Gallego, J., Pascual, S., Tapia, C., Nievas, M., Sánchez, A.,
Cardiel, N. Deliverable D4.1. Photometer sensor (prototype). STARS4ALL project. March 30th,
2016.
ETSI

---------------------- Page: 5 ----------------------
6 ETSI TR 103 411 V1.1.1 (2017-02)
[i.10] "Variación espacial, temporal y espectral de la contaminación lumínica y sus fuentes: Metodología
y resultados". Ph.D. thesis. Universidad Complutense de Madrid. February, 2015.
NOTE: Available at http://eprints.ucm.es/31436/.
[i.11] ISO 16739:2013: "Industry Foundation Classes (IFC) for data sharing in the construction and
facility management industries".
NOTE: Available at http://www.iso.org/iso/catalogue_detail.htm?csnumber=51622.
[i.12] Industry Foundation Classes (IFC) - Version 4 - Addendum 1. buildingSMART.
NOTE: Available at http://www.buildingsmart-tech.org/ifc/IFC4/Add1/html/.
[i.13] ETSI TS 103 410-1: "SmartM2M; Smart Appliances Extension to SAREF; Part 1: Energy
Domain".
[i.14] ETSI TS 103 410-2: "SmartM2M; Smart Appliances Extension to SAREF; Part 2: Environment
Domain".
[i.15] ETSI TS 103 410-3: "SmartM2M; Smart Appliances Extension to SAREF; Part 3: Building
Domain".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
ontology: formal specification of a conceptualization, used to explicit capture the semantics of a certain reality
smart appliances: devices, which are used in the household, e.g. for performing domestic work, and which have the
ability to communicate with each other and which can be controlled via Internet
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AEC Architecture Engineering and Construction
AEF Agricultural Industry Electronics Foundation
AIOTI Alliance for the Internet of Things Innovation
API Application programming interface
CEM Customer Energy Manager
CRUD Create Read Update and Delete
DOI Digital Object Identifier
E@H Energy@Home association
EEBus EEBus initiative
FM Facilities Management
HFC Hydrofluorocarbon
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
HVAC Heating, Ventilation, and Air Conditioning
IFC Industry Foundation Classes
IoT Internet of Things
ISO International Organization for Standardization
LOV Linked Open Vocabularies
MQTT MQ Telemetry Transport
OM Ontology of units of Measure
ORSD Ontology Requirements Specification Document
OWL Web Ontology Language
ETSI

---------------------- Page: 6 ----------------------
7 ETSI TR 103 411 V1.1.1 (2017-02)
PURL Persistent Uniform Resource Locator
RPC Remote Procedure Call
SAREF Smart Appliances REFerence ontology
SAREF4BLDG SAREF extension for the Building domain
SAREF4ENER SAREF extension for the Energy domain
SAREF4ENVI SAREF extension for the Environment domain
SQM Sky Quality Meter
TESS Telescope Encoder and Sky Sensor
TNO Netherlands Organization for Applied Scientific Research
TR Technical Report
TS Technical Specification
UML Unified Modeling Language
URI Uniform Resource Identifier
URL Uniform Resource Locator
W3C World Wide Web Consortium
WGS84 World Geodetic System 1984
XML Extensible Markup Language
4 SAREF extension and maintenance
4.1 Extensions
SAREF is the core semantic model for smart appliances (see ETSI TS 103 264 [i.3]), which contains the data elements
that are used in more than one domain. SAREF has a close relation with the oneM2M base ontology, for which
mappings are defined. Since smart appliances can be used in and come from several domains, it is possible that specific
data elements for a certain domain are not defined in SAREF. To be able to handle these additional data elements and
provide a specific domain with a semantic model that fits all the needs of that domain, there is the possibility to create
extensions to SAREF. This is depicted in Figure 1, in which SAREF is represented as the upper model and the
extensions for different domains as triangles that generate from the upper model, specializing core concepts from
SAREF. Each domain can have one or more extensions, depending on the complexity of the domain. Existing
extensions of SAREF are highlighted in the left part of Figure 1 (i.e. for the Energy, Environment and Building
domains), while other possible domains of interest are depicted in the right part. Figure 1 further depicts the equivalence
of some concepts between SAREF and the oneM2M base ontology [i.4].

Figure 1: SAREF and extensions
ETSI

---------------------- Page: 7 ----------------------
8 ETSI TR 103 411 V1.1.1 (2017-02)
As SAREF is the core semantic model for smart appliances, it functions as the connecting factor between the extensions
in the different domains, and the domain specific extensions should reuse the parts of SAREF that are relevant for their
domain. A domain specific extension should add new concepts that are not defined in SAREF. Furthermore, domain
specific extension can also reuse concepts from other extensions.
Each domain specific extension should be specified as a separate TS in order to ensure that domain specific extensions
can be maintained independently of each other and also independently of SAREF. Numbering of SAREF extensions
will be based on the following schema: ETSI TS 103 410-X (where X is a positive integer. Naming of SAREF
extensions will be based on the following schema: SAREF4XXXX (where XXXX are letters). For example, the
extension of SAREF for the energy domain is specified in ETSI TS 103 410-1 [i.13] and is named SAREF4ENER. The
extension of SAREF for the environment domain is specified in ETSI TS 103 410-2 [i.14] and is named SAREF4ENVI.
The extension of SAREF for the building domain is specified in ETSI TS 103 410-3 [i.15] and is named
SAREF4BLDG. Future extensions will follow the same numbering and naming schema.
Extensions can be created within an ETSI committee or outside of ETSI, but for standardization, they have always to
pass through the ETSI SmartM2M committee.
Once a year, a check should be performed by ETSI SmartM2M on all extensions to identify concepts and properties that
are used in more than one extension, as it could be desirable to move them to SAREF (to keep its role as a reference
ontology with core concepts common to several domains).
4.2 Maintenance
SAREF and all the extensions created within the ETSI community are maintained using an approach as open as
possible. This means that it is possible for every stakeholder (for SAREF and the domain specific extensions) to provide
input on the maintenance of the models and participate in discussions on the improvement of the models.
Furthermore, it is also expected that extensions of SAREF will not only be created within the ETSI community, but also
outside. ETSI should play an important role in the standardization of extensions of SAREF by allowing the models
created outside of ETSI to be fed as input into the SmartM2M group and stimulating external stakeholders to provide
their continuous input over time.
The formal standardization activities of SAREF and turning the drafts into Technical Specifications should be handled
by the SmartM2M technical body within ETSI. Furthermore, the SmartM2M group should also be in charge of the
vision on the development of SAREF and ensuring that the extensions created are in line with this vision.
As soon as any group or association has created an extension to SAREF and provided it as a contribution to ETSI
SmartM2M as candidate to become a Technical Specification, the ETSI SmartM2M technical body will perform a set of
predetermined checks to decide whether the proposed extension is accepted. Checks to be performed are:
• Is the extension a proper ontology according to the criteria specified in clauses 4.4 and 4.5?
• Were all relevant stakeholders in the domain involved in the creation process of the extension?
• Is the group that created the extension willing to work on the maintenance of the extension?
• Is SAREF properly used, and is the extension not adding concepts that are already present in SAREF?
• Is the extension properly documented?
• Is the extension in line with the vision of ETSI SmartM2M?
While working on the maintenance, it is important that SAREF and the domain specific extension are kept aligned: as
soon as there is a number of domain specific extensions and concepts that occur in several domains are identified, these
concepts should be moved as upper concepts in SAREF as a reference for all domains. Furthermore, every domain
specific extension should have a maintenance strategy/schedule to ensure consistency and allow input from relevant
stakeholders.
ETSI

---------------------- Page: 8 ----------------------
9 ETSI TR 103 411 V1.1.1 (2017-02)
4.3 Specification
This clause describes a possible specification process for creating extensions of SAREF. The goal of the ontological
requirements specification process is to extract the set of requirements that will guide the implementation and validation
of the ontology. This process will allow identifying the purpose and scope of the ontology in the different use cases and
to generate a list of requirements (in form of Competency Questions) that will guide the posterior development (and that
will be updated along such development).
Figure 2 provides an overview of the ontology requirements specification process followed and its relation with the rest
of the ontology development process. In this figure, the following information is included:
• Actors. The different roles involved in each activity. These roles can be:
- Users. The potential end users of the ontology. This group includes software developers that will make
use of the ontology within their applications.
- Experts. Experts in the domains covered by the ontology. This role does not need to be knowledgeable
about ontology development.
- Ontology development team. This role represents ontological engineers and ontology developers with
high knowledge on ontology implementation languages, techniques, tools, etc.
• Activities. The activities to be carried out in the process.
• Outputs. The products derived from each activity and that will serve as input to the posterior activities.
Figure 2 also provides the workflow of activities indicating the order in which they are carried out. In this sense it can
be observed that after an implementation cycle the workflow goes back to the ontological requirements specification
phase in which new requirements to be implemented will be chosen.
Requirementspecification
Ont. Devel.Ont. Devel.Ont. Devel.Ont. Devel.
UsersUsersOnt. Devel.UsersOnt. Devel.Users
ExpertsExpertsExpertsExperts
Purpose and Ontological Ontological
Use case Ontology Ontology
scope requirements requirements
specification implementation maintenance
identification proposal completion
Ontology Competency
Competency Change
Use cases Ontology
purpose and questions questions requests
scope (early stage) (verified)



Users
Experts
ORSD ORSD
formalization document
Data
exchange
Legen d
identification
Ont. Devel.
Actor
Domain
documentation
Activity
activity flow
Output

Figure 2: Ontology development process
ETSI

---------------------- Page: 9 ----------------------
10 ETSI TR 103 411 V1.1.1 (2017-02)
The activities to be carried out during the ontology requirements specification process are the following:
• Data exchange identification. The goal of this activity is to provide the ontology development team with the
necessary documentation about the domain to be modelled. In this case such documentation might origin from
domain experts and/or users. The documentation to be shared might correspond to: manuals, datasets,
standards, API specifications, data formats, etc.
• Use case specification. The goal of this activity is to collect a general description of the applications or
processes in which the ontology to be developed may be used. These descriptions are written in natural
language by domain experts and software developers who could be assisted by the ontology development team
if required.
• Purpose and scope identification. The goal of this activity is to define the purpose and scope of the ontology
for each of the use cases identified. During this activity, the ontology development team works in collaboration
with users and domain experts to define the purpose and scope of each ontology or ontology module to be
developed.
• Ontological requirements proposal. Taking as input the documentation and data provided by domain experts
and users, the ontology development team generates a first proposal of the ontological requirements written in
the form of Competency Questions [i.5]. The means used for gathering requirements follows a tabular
approach in which the following fields are included: Requirement identifier, Competency question (question
and answer or a statement in natural language), Provenance information (origin of the requirement),
Comments, Relation with other requirements, Priority, and Status (proposed, accepted, rejected).
• Ontological requirements completion. During this activity, domain experts and users in collaboration with
the ontology development team validate whether the ontology requirements defined in the previous step are
correct and complete.
• Ontological Requirement Specification Document (ORSD) formalization. During this activity, the ORSD
document is compiled by ontology developers. Such compilation of requirements would be taken as a first
backlog that will trigger the ontology implementation phase.
4.4 Implementation
SAREF and its extensions should be high-quality ontology standards that provide additional value (e.g. break new
ground, fill in an important gap, provide additional value compared to similar efforts, etc.), with high potential of being
adopted by others, persistently accessible and available for reuse, and characterized by an exemplary design and
technical quality. Concerning the design and technical quality, the most widely adapted, objective criteria for the design
of ontologies for knowledge sharing are the principles proposed by Gruber [i.5]. SAREF and its extensions should
therefore be implemented according to these criteria. Gruber's criteria can be summarized as follows:
• Clarity. For achieving clarity in ontological definitions, Gruber emphasizes the importance of:
1) independence from social and computational contexts by using formalism;
2) the use of logical axioms that provide a complete definition, i.e. a predicate defined by necessary and
sufficient conditions;
3) documentation supported by natural language.
• Coherence. Gruber states that definitions in an ontology should be logically consistent with the inferences that
can be derived from these definitions. Further there should also be consistency between the logical axioms and
their natural language documentation to maintain coherence. Extensions should be therefore checked using
popular reasoners for logical consistency.
• Extendibility. The design of the ontology should enable monotonic extensions of the ontology, i.e. one should
be able to define new terms for special use based on the existing vocabulary in a way that a revision of the
existing definitions is not necessary.
ETSI

---------------------- Page: 10 ----------------------
11 ETSI TR 103 411 V1.1.1 (2017-02)
• Minimal encoding bias. To encourage wider adoption of the ontology, Gruber proposes the use of a
conceptualization mechanism that minimizes the dependencies on encoding formats (i.e. design choices should
not be made purely for the convenience of notation or implementation). SAREF has been formalized in
OWL-DL, which is a W3C standard for representing ontologies on
...