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

TECHNICAL REPORT
SmartM2M;
Smart Appliances;
SAREF extension investigation
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.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

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
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
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
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
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
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
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
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
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
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 the Web and has its foundations in
Description Logics. Multiple serialization formats are available for the ontology (Turtle, RDF/XML). The
axiomatization in SAREF is therefore accessible to all tools and frameworks that support these serializations.
It is recommendable that SAREF extensions to follow the same formalization and serializations.
• Minimum ontological commitment. An ontology should make assertions that require only the minimum
commitment sufficient to support the knowledge sharing activities, providing the parties that use the ontology
with the flexibility to extend and specialize the ontology as needed.
4.5 Publication
The first SAREF technical specification ETSI TS 103 264 (V1.1.1) [i.3] was published as a collection of two
documents, which could be downloaded together as a zip-file:
• Technical specification document in PDF format.
• Ontology file in Turtle format.
While this may be the normal method for publishing standards in ETSI, this is not the most suitable method for
publishing ontologies. The main reason is that ontologies such as SAREF and its extensions should become part of the
Semantic Web to ensure that the community will start adopting them. Publishing ontologies as Technical Specifications
in zip-files hinders the possibility for the Semantic Web community to find and access the ontology, and therefore
should be discouraged in ETSI.
In contrast, SAREF and its extensions should be made available according to the following best practices for publishing
ontologies in the Semantic Web as defined by the W3C (https://www.w3.org/TR/swbp-vocab-pub/):
• Make the ontology available at a persistent URI, such as PURL, DOI or w3id, which redirects the HTTP
requests against this persistent URI to another URL of choice (for example on an ETSI server) in which the
ontology is actually located. This guarantees that the ontology will always be accessible at the same URI, even
if its actual location changes.
• Enable content negotiation to make it possible to access SAREF on one URI, and depending on the request of
the user give back machine-processable content (.rdf, .owl, .ttl) or human-readable content (HTML). The
HTML documentation will be given as multiple hyperlinked HTML documents plus an overview document.
• Specify an appropriate license for the ontology, such as the creativecommons.org or opensources.org licenses.
• Make the ontology findable by registering it into community registries, such as the Linked Open Vocabularies
(LOV, see http://lov.okfn.org/).
4.6 Extension domains
A number of domains have been identified as possible domains for extending SAREF. For three of them extensions
have been defined (Energy, Environment and Building); for the other ones, extensions could be created in the near
future.
Energy demand response
In the energy domain the associations Energy@Home and EEBus are working on interconnecting smart appliances to
be able to perform demand and response use cases on the electricity grid. For this domain an extension has been
defined, and the use cases presented are defined in clause 5.1.1.
ETSI
12 ETSI TR 103 411 V1.1.1 (2017-02)
Environment
Due to the positive connotations about security, wealth and modernity, people tend to illuminate the environment
intensively. However, such exceed of artificial illumination, in addition to the waste of energy it represents, also
interferes with astronomical observatories, disrupts ecosystems and has adverse health effects. In this context, light
pollution is defined as excessive, misdirected or obtrusive artificial light. Based on input from the STARS4ALL project,
an extension has been defined based on the use cases defined in clause 5.1.2.
Buildings
A more efficient interaction and integration of actors, methods and tools during the different phases of the building life
cycle is being demanded in the Architecture, Engineering and Construction (AEC) and Facilities Management (FM)
fields. Along its life cycle, multiple tools interact with building models to extract information for different purposes
(e.g. energy demand, appliance characteristics, etc.). Therefore, mechanisms to facilitate the exchange of data between
actors along the different stages of the building life cycle and to provide the required interoperability between tools are
needed. As the ISO standard data model Industry Foundation Classes (IFC) [i.11] supports interoperability between data
and tools, it was decided to extend the SAREF ontology with the subset of the ISO IFC standard related to devices and
appliances. An extension has been defined based on the IFC standard [i.11] and the use cases defined in clause 5.1.3.
Health/Ageing well
Another possible extension of SAREF is an extension for the health domain. A number of parties are looking into
connecting smart appliances in the home to allow citizens to live longer in their own home, or to be able to better
support them remotely. The AIOTI Working Group 5 and the European Commission are interested in creating an
ontology for Healthy Ageing, it is worthwhile to discuss this ontology and to see whether there is a link with SAREF.
Furthermore, it is important to take into account the activities of the Continua Alliance
(http://www.continuaalliance.org/) to ensure alignment with their activities when working on an extension of SAREF.
Continua is publishing design guidelines that indicate how existing standards from different standardization bodies
should be combined to ensure interoperability between personal health devices. The standards used also facilitate the
exchange of data. For an extension of SAREF, it would be interesting to ensure that all data exchanged based on the
Continua design guidelines is defined in the SAREF extension so that full mappings are possible.
Agriculture
An additional potential extension of SAREF is an extension for the agriculture domain, which is seen as one of the
domains where the implementation of IoT could have a big impact. The Agricultural Industry Electronics Foundation
(AEF) establishes and continues the international development and expansion of electronic and electrical technology as
well as the implementation of electronic standards and coordinates the international cooperation in agricultural
electronics technology. As the AEF is highly involved with the electronic and electrical technology for the agricultural
domain, it is very interesting to ensure that an extension of SAREF includes all the data elements that are defined by the
AEF to ensure that the SAREF extension could be fully mapped to the AEF standards.
5 Use cases and requirements
5.1 Use cases
5.1.1 Use cases from Energy@Home and EEBus
The Energy@Home and EEBus use cases require an extension of SAREF for Energy@Home
(http://www.energy-home.it) - abbreviated in the rest of the document as E@H - and EEBus (http://www.eebus.org/en)
to enable the interconnection of their different data models. Its purpose is to facilitate the interoperability between
EEBus and E@H devices in demand response scenarios. By using this extension, smart appliances from manufacturers
that support the EEBus or E@H data models will be able to communicate with one another using any energy
management system at home or in the cloud, abstracting from the specifics of the underlying communication protocols.
ETSI
13 ETSI TR 103 411 V1.1.1 (2017-02)
In the E@H and EEBus demand response scenarios, customers can offer flexibility to the Smart Grid to manage their
smart home devices by means of a Customer Energy Manager (CEM). The CEM is a logical function for optimizing
energy consumption and/or production that can reside either in the home gateway or in the cloud. These scenarios
involve the following use cases:
Use case 1: configuration of devices that want to connect to each other in the home network, for example, to register a
new dishwasher to the list of devices managed by the CEM;

Figure 3
Use case 2: (re-)scheduling of appliances in certain modes and preferred times using power profiles to optimize energy
efficiency and accommodate the customer's preferences;

Figure 4
ETSI
14 ETSI TR 103 411 V1.1.1 (2017-02)
Use case 3: monitoring and control of the start and status of the appliances;

Figure 5
Use case 4: reaction to special requests from the Smart Grid, e.g. incentives to consume more or less depending on
current energy availability, or emergency situations that require temporary reduction of power consumption.

Figure 6
These use cases are associated with the user stories described in IEC TR 62746-2 [i.6], which include, among others,
the following examples:
• User wants to do basic settings of his/her devices.
• User wants to know when the washing machine has finished working.
• User wants their washing done by 5:00 p.m. with the lowest electrical power cost.
ETSI
15 ETSI TR 103 411 V1.1.1 (2017-02)
• User likes to limit his own energy consumption up to a defined limit.
• User allows the CEM to reduce the energy consumption of the freezer in a defined range for a specific time, if
the grid recognizes (severe) stability issues.
• Grid related emergency situations (e.g. blackout prevention).
5.1.2 Use cases from STARS4ALL
Due to the positive connotations about security, wealth and modernity, people tend to illuminate the environment
intensively. However, such exceed of artificial illumination, in addition to the waste of energy it represents, also
interferes with astronomical observatories, disrupts ecosystems and has adverse health effects. In this context, light
pollution is defined as excessive, misdirected or obtrusive artificial light.
Due to its importance, a number of light pollution initiatives have arisen such as the STARS4ALL European H2020
project (http://www.stars4all.eu/index.php/lpi/), the international Dark-Sky association (http://darksky.org/), or the
Spanish network about light pollution (https://guaix.fis.ucm.es/splpr/SQM-REECL). Indeed, based on this latter
initiative, researchers in the field are working towards a broader initiative entitled the European Photometer Network.
In order to extract requirements for extending the SAREF ontology for the environment domain, more precisely, for the
case of light pollution, the process presented in clause 4.2 has been followed. The rest of the clause details the roles
involved in the process, the documents provided by the domain experts and software developers, the purpose and scope
of the ontology, and the use cases extracted.
Roles involved. The requirements gathering process involved three ontological engineers, one end user, and one
software developer. The end user and the software developer are members of the STARS4ALL project.
Documents exchanged. Different documentation was provided after the data exchange identification activity that
helped in extracting an initial set of requirements: project deliverables [i.8], [i.9], a Ph.D. thesis [i.10], the technical
specification of a web API, and sample data.
Ontology purpose. The purpose of extending the SAREF ontology for photometers is to solve the lack of
interoperability between sensors that can measure and share information about light pollution.
Ontology scope. The ontology has to focus on the photometers used to measure light pollution. The level of granularity
is directly related to the competency questions and terms identified.
The following use cases have been extracted by means of interviewing domain experts.
Use case 1: Monitor light pollution in a city
Photometers are used to collect data about the magnitude of the light emitted in a given area and to analyse such data.
These data are used to rank areas according to their light pollution and to visualize such pollution information in maps.
The information shown in the maps is used by local authorities in order to identify the lampposts that are emitting
excessive or incorrect light and to adapt them accordingly. The ontology representing photometer and lamppost
characteristics would allow the integration of data from different types of sensors (for example TESS, SQM and human
sensors) since currently there are different photometer networks whose data should be harmonised. The ontology would
also allow the description of lampposts in order to identify which ones do not comply with the recommendations for
lower pollution.
Use case 2: Adjust lampposts light intensity due to high pollution
Local authorities gather data from sensor networks about light pollution in order to identify the most contaminating
lampposts and therefore the areas where more energy is being thrown away. Once the polluting lampposts are
identified, operators adjust their intensity using the devices as actuators. The ontology would be used in this case to
integrate the information about the lamppost descriptions and their actuator interfaces in order to tune their
configuration. In this case, the lamppost characteristics such as whether they have shade or the type of lamp used can
also be retrieved to facilitate the decision making.
ETSI
16 ETSI TR 103 411 V1.1.1 (2017-02)
Use case 3: Register a photometer
A new collection of photometers is incorporated into an existing sensor network. This new type of sensors should be
described according to the ontology in order to integrate the data that is going to be collected with the data already
gathered by the sensor network. By describing and identifying the new sensors, the discoverability of data sources is
increased. In this case, the ontology is also used to describe the sensors characteristics and communication interfaces.
5.1.3 Use cases from IFC
A more efficient interaction and integration of actors, methods and tools during the different phases of the building life
cycle is being demanded in the Architecture, Engineering and Construction (AEC) and Facilities Management (FM)
fields. Along its life cycle, multiple tools interact with building models to extract information for different purposes
(e.g. energy demand, appliance characteristics, etc.). Therefore, mechanisms to facilitate the exchange of data between
actors along the different stages of the building life cycle and to provide the required interoperability between tools are
needed. As the ISO standard data model Industry Foundation Classes (IFC) [i.11] supports interoperability between data
and tools, it was decided to extend the SAREF ontology with the subset of the ISO IFC standard related to devices and
appliances. It is worth noting that the IFC specification is developed and maintained by building SMART International
a
...