=Paper=
{{Paper
|id=Vol-2063/sisiot-paper3
|storemode=property
|title=Towards IoT Platforms’ Integration Semantic Translations between W3C SSN and ETSI SAREF
|pdfUrl=https://ceur-ws.org/Vol-2063/sisiot-paper3.pdf
|volume=Vol-2063
|authors=Joao Moreira,Laura Daniele,Luis Ferreira Pires,Marten van Sinderen,Katarzyna Wasielewska,Paweł Szmeja,Wiesław Pawłowski,Maria Ganzha,Marcin Paprzycki
|dblpUrl=https://dblp.org/rec/conf/i-semantics/MoreiraDPSWSPGP17
}}
==Towards IoT Platforms’ Integration Semantic Translations between W3C SSN and ETSI SAREF==
https://ceur-ws.org/Vol-2063/sisiot-paper3.pdf
Towards IoT platforms’ integration: Semantic Translations
between W3C SSN and ETSI SAREF
João Moreira∗ Laura Daniele† Luis Ferreira Pires∗
Marten van Sinderen∗ Katarzyna Wasielewska‡ Pawel Szmeja‡
Wiesław Pawłowski§ Maria Ganzha‡ Marcin Paprzycki‡
ABSTRACT CCS Concepts
Several IoT ontologies have been developed lately to im- •Information systems → Semantic web description
prove the semantic interoperability of IoT solutions. The languages;
most popular of these ontologies, the W3C Semantic Sensor
Network (SSN), is considered an ontological foundation for
diverse IoT initiatives, particularly OpenIoT. With charac-
Keywords
teristics similar to SSN, the ETSI Smart Appliances REF- Semantic interoperability, internet-of-things, ontology align-
erence (SAREF) ontology evolved from the needs of smart ment, ETSI SAREF, W3C SSN
home solutions to common requirements of IoT. Some IoT
solutions rely on platform-specific ontologies and their in- 1. INTRODUCTION
tegration requires mechanisms to align these ontologies. In
Over the past few years, numerous IoT ontologies were
this paper we discuss the ontology alignment between SSN
proposed to improve the semantic interoperability of IoT ar-
and SAREF, identifying mapping alternatives and propos-
tifacts, i.e. the common understanding capabilities of plat-
ing basic mappings that can be re-used to define more com-
forms, devices, gateways, applications and networks involved
plex ones. We introduce here an initial specification of the
in IoT solutions [8]. In this context, the W3C Semantic
semantic translations from the main elements of SSN to
Sensor Network (SSN) is considered an ontological founda-
SAREF, which includes classes, object properties and data
tion for the IoT, covering the application of diverse types
properties. The alignment will be used in a semantic match-
of sensors, widely used by initiatives as OpenIoT [12] and
ing process leveraging the semantic mediator component of
INTER-IoT [7]. Recently, the Smart Appliances REFerence
the INTER-IoT project. An initial evaluation of the trans-
(SAREF) ontology has evolved from the smart appliances
lation was executed by translating the wind sensor (Vaisala
domain (e.g. smart ovens and refrigerators) [4] to cover
WM30), an example provided by the W3C, from SSN to
other characteristics of the IoT domain [6], being created
SAREF. This initial evaluation demonstrates the coherence
in close interaction with the smart home market [5]. It is
and feasibility of the proposed mappings.
grounded on 47 “semantic assets”, i.e. standards, propriet-
∗ ary data models, protocols and other ontologies, as SSN.
University of Twente, Enschede, The Netherlands.
{j.luizrebelomoreira@utwente.nl, l.ferreirapires@utwente.nl, IoT platforms enable software engineers to bridge the gap
m.j.vansinderen}@utwente.nl between device sensors and connected applications through
†
Netherlands Organisation for Applied Scientific Research, suites of components, which can include semantic technolo-
TNO. gies, e.g. FIWARE with the Sense2Web linked-data generic
laura.daniele@tno.nl enabler (GE) and OpenIoT with its own ontology extended
‡
Systems Research Institute, Polish Academy of Sciences, from SSN. The Inter-IoT project1 aims at designing, imple-
Warsaw, Poland
{katarzyna.wasielewska, pawel.szmeja, maria.ganzha, mar- menting and experimenting with voluntary interoperability
cin.paprzycki}@ibspan.waw.pl among heterogeneous IoT platforms. The project is driven
§
Faculty of Mathematics, Physics, and Informatics, Univer- by use cases from (e/m)Health and transportation/logistics
sity of Gdańsk, Poland at the port of Valencia, which require semantic integration
w.pawlowski@inf.ug.edu.pl among IoT artifacts relying on SSN and SAREF.
A challenge to enable semantic integration between IoT
artifacts relying on SSN and SAREF, is how to translate
from one ontology to another, i.e. align these ontologies.
To deal with this problem, the development of an ontology
alignment between SSN and SAREF is required, i.e. finding
and mapping the correspondences between entities (atomic)
© 2017 Copyright held by the author/owners. or groups of entities and sub-structures (complex). An ap-
SEMANTiCS 2017 workshops proceedings: SIS-IoT proach to implement ontology alignment is semantics trans-
September 11-14, 2017, Amsterdam, Netherlands 1
www.inter-iot-project.eu
lation, which is a process that transforms some information terconnections between semantic data of multiple ontologies.
described semantically, in terms of a source ontology, to in- IPSM utilizes alignment files and provides a multi-channel
formation described in terms of a target ontology [9]. environment for any artifact. Pairs of uni-directional align-
In this paper we introduce mappings among the main ele- ments between the central ontology and artifact ontology
ments for the semantic translations from SSN 1.0 to SAREF are used to translate messages to and from the central on-
2.0. We adopted a model-driven engineering methodology to tology. This enables connection of new artifacts without
develop these semantic translations which considers specific- jeopardizing the existing channels, and requires each par-
ation and implementation. The specification will be used ticipant to provide only a pair of alignments. While com-
for configuration and deployment in the Inter-Platform Se- plete ontologies are used to build semantic understanding,
mantic Mediator (IPSM) of INTER-IoT. We evaluated these only conversation-specific alignments are stored and used
mappings by demonstrating how the SSN representation of for actual translations. Ontology alignments and transla-
the WM30 wind sensor, an example provided by the W3C, tion channels can be managed through the REST Manager.
is translated to SAREF. After the translations’ execution, Because of space limitations in this paper we omit other re-
a verification of the generated ontology is made, measuring lated work, which can be found in our prior publications
the level of semantics maintained from the original ontology. that cover the state-of-the-art in this area [7, 8, 9, 10].
Section 2 describes the background research with an over-
view of the IPSM, the SSN and SAREF ontologies. Section 2.2 W3C Semantic Sensor Network
3 describes the methodology used to develop the semantic The W3C Semantic Sensor Network (SSN)3 [2] is an on-
translations. Section 4 introduces the mappings from SSN tology developed by W3C, (current published version 1.0,
to SAREF, describes the evaluation of the mappings and 2011). It provides a comprehensive framework to describe
discusses the challenges. Section 5 concludes this work by sensors, devices, observations, measurements and other terms,
presenting the lessons learned and future work. enabling reasoning of individual sensors and the connection
of sensors, such as wireless networks. SSN 1.0 is groun-
2. BACKGROUND ded in a set of existing ontologies and standards, such as
CSIRO, SWAMO, SEEK Extensible Observation, SemSOS
and OGC SensorML [8]. The main concept of SSN is the
2.1 INTER-IoT semantic mediator Sensing Device, which is a sensor that reports measurements
The main goal of the H2020 project Interoperability of and observations of real world phenomena. A sensor is
Heterogeneous IoT Platforms (INTER-IoT) [7, 10] is to design, different in nature from other types of devices, e.g. actu-
implement and validate a framework that will allow inter- ators, because of its event-based behavior, which requires
operability between heterogeneous IoT platforms across the temporal relationships. SSN enables reasoning, which can
transportation (logistics) and (e/m)Health domains. The facilitate the development of advanced applications, for ex-
use case scenarios are based on real world situations that ample, by reasoning about sensor measurements, considering
need integration among IoT platforms, as the port author- constraints as power restriction and limited memory. It con-
ity IoT platform and the haulier IoT platform, with systems sists of 10 modules, representing 41 concepts and 39 object
as the container terminal system and the port management. properties. It inherits 11 concepts and 14 object properties
The (e/m)Health domain scenarios aims at improving inter- from the foundational ontology DOLCE-UltraLite (DUL)4 .
operability among IoT artifacts for patient monitoring, e.g. In this paper we cover the following modules:
body sensor networks, wearable and non-wearable devices. DUL module5 : represents the foundational categorization
Some of these IoT artifacts rely on SSN, such as the OpenIoT of Designed Artifact, Method, Physical Object, Quality, Re-
platform. In the scenario of detecting emergencies at the gion and Situation. For example, a Sensing Device (Meas-
port by monitoring drivers’ vital signs with medical wearable uring module) is a Designed Artifact and a Physical Object,
devices, semantic integration is required between IoT arti- which observes a Property (Skeleton module). A Property is
facts based on SSN and smart appliances based on SAREF, an observable Quality of an Event or Object, i.e. ”an aspect
e.g. building sensors for vehicle collision detection, security of an entity that is intrinsic to and cannot exist without the
and electrical systems. INTER-IoT is currently developing entity and is observable by a sensor”.
the Inter-Platform Semantic Mediator (IPSM) tool. IPSM Skeleton module: represents the most basic concepts re-
is a software tool that follows the semantic interoperability garding sensors, as Sensor, Sensing, Property and Obser-
design patterns identified in INTER-IoT [7], and is intended vation. A Sensor may be a physical device implementing
to be used as part of the translation process defined in the Sensing, i.e. it has a sensing method observing some Prop-
methodology (INTER-Meth). The process of achieving se- erty. ”Sensing is a process that results in the estimation, or
mantic interoperability involves the following steps: (i) lift calculation, of the value of a phenomenon”.
semantics to a common format and make it explicit; (ii) Measuring module: covers the elements Sensing Device
develop, or choose, a central modular ontology; (iii) pre- and Sensor DataSheet. The prior is the main element of
pare uni-directional alignments between ontologies of com- SSN. The former represents the data sheet specifications of
municating artifacts and the central ontology; (iv) establish a sensor. Usually, the properties of a sensor are recorded dir-
a multi-channel (1-1, 1-many, many-1) communication ar- ectly with hasMeasurementCapability property of a Sensor.
chitecture to facilitate translations in all needed contexts, System module: represents the System concept as a Phys-
with the central ontology as intermediary. ical Object (DUL) composed by sub-systems (hasSubSys-
INTER-IoT provides its own alignment format, based on
3
an alignment API with a declarative ontology alignment lan- https://www.w3.org/2005/Incubator/ssn/ssnx/ssn
4
guage (XML-based), inspired on EDOAL2 , to represent in- http://ontologydesignpatterns.org/wiki/Ontology:
DOLCE+DnS Ultralite
2 5
http://alignapi.gforge.inria.fr/edoal.html https://www.w3.org/2005/Incubator/ssn/wiki/DUL ssn
tem), which has deployment(s) (hasDeployment), operat- Recently, the European Telecommunications Standards
ing range(s) (hasOperatingRange) and location(s) relative Institute (ETSI) along with the European Comission (EC),
to other entities (onPlatform). the Netherlands Organisation for Applied Scientific Research
Measuring Capability module: represents core concepts (TNO), the Universidad Politécnica de Madrid (UPM) and
of SSN, i.e. properties and capabilities of measurements, other partners, developed the Smart Appliances REFerence
such as Accuracy, MeasurementProperty and Measurement- (SAREF) ontology [4, 5]9 . At first this ontology was built
Capability. Relevant object properties are the hasMeas- as a reference model targeting smart appliance solutions for
urementCapability and hasMeasurementProperty. Measure- the smart home domain10 . However, SAREF has evolved
mentCapability represents a characteristic of a sensor’s ob- to cover the IoT domain in general, being acknowledged by
servations or ability to make observations (e.g. accuracy the EC as the ”first ontology standard in the IoT ecosys-
and range). MeasurementProperty represents the collection tem, and sets a template and a base for the development
of measurement properties and environmental conditions in of similar standards for the other verticals to unlock the
which those properties hold. full potential of IoT” [6]. The SAREF ontology provides
Device module: covers Device, which is a physical piece building blocks that enable re-utilization of different parts
of technology (a ”system in a box”) and can be composed of of the ontology according to specific requirements. The new
other (smaller) devices and software components. version SAREF 2.011 brings a number of changes towards
The W3C SSN Incubator Group created an example of the this evolution, including new alignments with OneM2M for
use of SSN by describing the Vaisala WM30 wind sensor 6 . services’ provision of smart things.
It describes the measurement capabilities, power supply and SAREF facilitates the matching of existing assets, since
operating and survival properties based on the technical spe- it was developed based on standards, ontologies, data mod-
cification of the measurement of wind direction and speed. els and protocols of the IoT domain, providing a high-level
This example was initially reported in [3], which gives a mapping of them (available in SAREF’s first interim study
precise description of the WM30 sensor. In this paper we report). One of these assets is SSN, which inspired the
updated these axioms, since WM30 ontology main defin- definition of the main elements of SAREF, namely Device,
itions and restrictions are different, a consequence of the Sensor, Unit of Measure and Time/Duration, according to
changes in the TBox of SSN until the current published the high-level mappings provided in the SAREF initial doc-
version. These axioms represent the Vaisala WM30 as a umentation [4]. A Device (e.g. a Sensor ) represents tan-
Sensing Device (therefore a Device (System) and a Sensor ), gible objects designed to accomplish one or more functions
composed by (hasSubSystem) WM30 particular sensors for in diverse types of locations (e.g. households and buildings).
wind direction and wind speed, being able to measure (ob- For example, a Sensor has Function of type Sensing func-
serves) wind direction (WM30 WindDirection) and speed tion. The SAREF ontology offers a list of basic functions
(WM30 WindSpeed ): that can be combined towards more complex functions in a
single device. For example, a Switch can offer an Actuating
WM30:Vaisala WM30 v ssn:SensingDevice function of type “switching on/off” and a Sensing function
WM30:Vaisala WM30 v of type Light Sensor, so if there is illumination in the envir-
∃ ssn:hasSubSystem . WM30:WM30 WindDirection onment then the switch turns off the light. Each Function
has some associated Commands, which can also be picked
WM30:Vaisala WM30 v
up as building blocks from a list. For example, the “switch-
∃ ssn:hasSubSystem . WM30:WM30 WindSpeed ing on/off” is associated with the commands “switch on”,
WM30:Vaisala WM30 v “switch off” and “toggle”. Depending on the Function(s) it
∃ ssn:observes . WM30: WindDirection accomplishes, a device can be found in some corresponding
State(s) that are also listed as building blocks.
WM30:Vaisala WM30 v The composition of a Device can be represented through
∃ ssn:observes . WM30: WindSpeed the saref:consistsOf self-relationship, e.g. the WM30 wind
sensor (a device) can be defined as a composition of wind
Currently the W3C is updating the entire SSN ontology direction and wind speed sensors. A Device measures a
towards a new version (2.0), which is available as a public specific property, represented by the object property saref:-
draft document prepared by the W3C and the Open Geospa- measuresProperty to a Property. For example, a Smoke-
tial Consortium (OGC)7 . In this new version, a new onto- Sensor (Sensor ) measures Smoke (Property), analogously
logy is introduced, namely the Sensor Observation Sampling a WindSensor measures Wind. Regarding a measurement
Actuator (SOSA), absorbing a number of classes and prop- observed by a sensor in time, SAREF represents it through
erties from SSN 1.0, such as Sensor, Observation and ob- the saref:makesMeasurement object property of a Device to
serves. SOSA is aligned with DUL and SSN 2.0 is aligned Measurement(s), representing the relation between a device
with SOSA. SOSA is also aligned with the foundational on- and the measurements it makes. A Measurement element
tologies BFO and PROV-O8 . Most important, the compat- links of the value of the Measurement, its Unit of Measure
ibility of our work with SSN 2.0 is not compromised because and the Property to which it relates.
the specification provides alignments of SSN 2.0 with SSN A Device offers a Service, which is a representation of a
1.0, including complex ones.
9
http://ontology.tno.nl/saref/
2.3 ETSI Smart Appliances REFerence 10
https://ec.europa.eu/digital-single-market/blog/
6
new-standard-smart-appliances-smart-home
https://www.w3.org/2005/Incubator/ssn/ssnx/meteo 11
https://ec.europa.eu/digital-single-market/en/news/new-
7
https://www.w3.org/TR/vocab-ssn version-machine-2-machine-standard-smart-appliances-
8
https://www.w3.org/2015/spatial/wiki/SOSA Ontology introduced-etsi
Function to a network that makes the function discoverable, technology, thus, limiting the reuse of the mappings. Our
registerable and remotely controllable by other devices in the ontology-driven conceptual modeling strategy [11] can ad-
network. A Service can represent one or more functions. A dress this issue by leveraging the MDE approach with a spe-
Service must specify the Device that offers the Service, the cification artifact targeted to human readers, i.e. the trans-
function(s) to be represented, and the (input and output) formation developers. For specification, the transformation
parameters necessary to operate the service, supported by runtime is not considered. For the transformation defini-
the ontology alignments with OneM2M ontology. tion, an approach based on natural language enriched with
pseudo-code is used instead of a formal language, similar
to the OASIS EDXL-TEP and HL7 (syntactic interoperab-
3. METHODOLOGY ility standards) transformations13 . This approach enables
We surveyed tools for ontology alignment [9], describing to (re)use the specification for different strategies to imple-
the conceptual differences of alignment, matching, merging, ment ontology alignment. The implementation of our map-
mapping and semantic translations. Here we describe the pings, i.e. the transformation definition, is planned to be
semantic translations between SSN to SAREF and, thus, represented as configuration files (XML format), which is
a methodology is required for implementing and evaluating an instance of the IPSM configuration schema (transform-
these translations. Our methodology for semantic trans- ation language). However, this is an ongoing activity and
lations development follows a common software engineer- this paper covers the specification artifact (pseudo-code).
ing approach, considering specification and implementation A MDE transformation can be developed as an unidirec-
phases during the design time of the ontology alignment. tional or a bi-directional transformation. The best prac-
The specification describes in natural language the possible tices show that, when creating a bi-directional transforma-
mappings and the involved rules, linking the original onto- tion with a high number of meta-model elements, a cyclical
logy to the generated ontology. This methodology is based process should be used. The first step is to specify an uni-
on a typical pattern Model-Driven Engineering (MDE) [1] directional transformation with a selected sub-set of meta-
to specify transformations in terms of a source and a target model elements to be covered and validate with simulations.
meta-model, as illustrated in Figure 1. If errors are found then they should be fixed and the trans-
formations should be validated again until the mappings cor-
rectly generate the intended model. The second step is to
specify the opposite direction with the same elements of the
first step, and validate/correct with simulations. The third
step is to evaluate whether meaning is lost when execut-
ing the transformations in sequence, i.e. check how x is
different to T(T(x )A>B )B>A , where T(a)A>B produces the
model b (meta-model B) from model a (meta-model A), and
T(b)B>A the opposite direction. This step supports possible
conceptual errors, enabling the early correction of the map-
pings before implementing. Once an acceptable level of the
quality of the bi-directional transformation specification is
achieved, the transformations can be implemented. This is
an interactive process that must be executed while there are
elements to be addressed, as in agile development methods.
Figure 1: Model transformations in MDE In this paper we present the first step applied from SSN to
SAREF with three terms from SSN.
The set of mappings from SSN to SAREF is a transforma- The rationale for specification are based on an ontological
tion definition, which is an instance of a transformation lan- analysis of the SSN and SAREF TBox, i.e. an analysis of the
guage. These mappings are a definition of transformations statements that describe their conceptualization. Since SSN
of the instance level of these ontologies, e.g. the transform- is extended from DUL, and DUL is the lightweight founda-
ations are able to transform from the WM30 ontology (an tional ontology of DOLCE, we used DOLCE’s categories as
instance of SSN) to an equivalent instance of SAREF. For a reference to map from SSN to SAREF. For example, the
the implementation of these mappings, a transformation lan- object property ssn:hasSubSystem is a DUL:hasPart, which
guage could be the library Apache JENA12 (Java) and the means ”a schematic relation between any entities”. Based
mappings (transformation definition), which uses the SSN on this definition, we sought for in SAREF the possible rela-
(source) and SAREF (target) meta-models, an instance of tions that have the same semantics for this mapping, finding
JENA implementation. The mappings and a message ac- that saref:consistsOf has the same meaning: ”a relationship
cording to SSN (source) are used as input by the transform- indicating a composite entity that consists of other entit-
ation runtime environment, e.g. Java Runtime Environment ies (e.g., a temperature/humidity sensor that consists of a
(JRE), which produces a SAREF (target) ontology with sim- temperature sensor and a humidity sensor)”. Although this
ilar semantics as the original. process is quite time consuming, error-prone and automatic
We use a specification strategy to avoid conceptual er- techniques based on natural language processing (NLP) are
rors during the implementation, which is a common issue in commonly used for finding ontology similarity [9], such on-
software engineering. Moreover, directly implementing the tological analysis can produce a more semantically assertive
mappings forces a preliminary choice of the technology of the
13
transformation runtime, which couples the mappings with a http://docs.oasis-open.org/emergency/
TEP-HL7v2-transforms/v1.0/TEP-HL7v2-transforms-v1.
12
https://jena.apache.org/ 0.html
set of ontology alignments that does not rely only on the 4.1 Mappings: SSN to SAREF
terms, but also on their descriptions, thus, their meaning. According to the methodology used, the mappings between
Therefore, we produced an initial documentation regarding SSN and SAREF were specified through an ontological ana-
the classes and object properties of both ontologies and their lysis of their TBox, i.e. concepts and roles definitions (pre-
possible relations, analyzing each class/object property ac- dicates) with logical operations. A study was made on how
cording to their definitions. SSN and SAREF describe the characteristics of sensors, in-
Here we present an initial evaluation of the specification cluding their capabilities of observation. The mappings fol-
created, simulating unidirectional semantic translation from low a logic sequence according to the main elements and
WM30 ontology (SSN) to SAREF. In general, the result similar structures of SSN and SAREF. Here we detail only
from the translations must represent the WM30 wind sensor the mappings from SSN to SAREF as a first step towards
with SAREF, keeping similar semantics of the original. The- the creation of the bi-directional translations. For each map-
refore, the goal of this evaluation is to check the semantic ping a code snippet is presented as a pseudo-code to illus-
similarity between the original and the final ontologies. Here trate the algorithm for the creation of the SAREF-based
we used an approach based on competency questions to ontology. This pseudo-code include an IN representing the
measure this similarity. A list of competency questions is input SSN element(s). When creating a new SAREF class
presented, and each question is answered by navigating the or property, var is used and createTriple function creates a
elements of both ontologies. The answers are compared to triple (class, object property, class).
verify whether the semantics are maintained after the sim-
ulation. Intentionally, the competency questions were con- M01. ssn:SensingDevice -> saref:Sensor
ceived according to the expressiveness of the SSN WM30 on- While the main element of SSN is the Sensing Device, a sub-
tology, targeting its main elements, as the different measure- class of Device and Sensor, in SAREF the main element is
ment capabilities described in the technical specifications14 . Device, which can be specialized as a Sensor related to a
For example, the accuracy of the WM30 wind speed sensor Sensing Function. The characteristics of ssn:SensingDevice,
(within a range from 0.4 to 60 m/s) is +- 0.3 m/s for wind inherited from ssn:Sensor and ssn:System, are mapped to
speed lower than 10 m/s and +-2% of variance for wind saref:Sensor, inheriting saref:Device properties, including
speed higher than 10 m/s. At first, we answered each ques- the relationship with the saref:SensingFunction (saref:has-
tion based on the original ontology (in SSN) and, then, Function). Figure 2 illustrates the elements involved in this
we answered the same question for the generated ontology mapping. Notice that, indirectly, this mapping also trans-
(SAREF). Second, we compare whether the semantics of the forms from ssn:Sensor to saref:Sensor if the ssn:Sensor is
response is similar to each other, i.e. if the semantics are lost a ssn:SensingDevice. All RDFS properties are copied from
or maintained. The competency questions are: ssn:SensingDevice to saref:Sensor.
CQ01. What are the characteristics of the WM30 sensor?
CQ02. What is the composition of this sensor, i.e. what 1 IN: s s n _ s e n s i n g D e v i c e
2 var saref_sensor = saref:Sensor
are the parts of WM30?
3 saref_sensor.rdfs = ssn_sensingDevice.rdfs
CQ03. What measurement properties this sensor performs? 4 var saref_function = s a r e f : S e n s i n g F u n c t i o n
CQ04. What are the accuracy, delay distance, starting 5 var s a r e f _ h a s F u n c t i o n = s a r e f : h a s F u n c t i o n
threshold and damping ratio of wind direction sensors? 6 createTriple ( saref_sensor s a r e f _ h a s F u n c t i o n
CQ05. What measurement range constraints differentiate saref_function )
these types of wind direction sensors?
Listing 1: Pseudocode snippet for M01
4. SEMANTIC TRANSLATIONS
M02. ssn:hasSubSystem -> saref:consistsOf
1 IN: ssn_sensingDevice , saref_sensor
2 for each ssn_system in
ssn_sensingDevice.ssn:hasSubSystem
3 var s a r e f _ d e v i c e _ c o m p o n e n t = saref:Device
4
5 if ssn_system is s s n : S e n s i n g D e v i c e then
6 s a r e f _ d e v i c e _ c o m p o n e n t = Map ( M01 ,
ssn_system )
7 else if ssn_system is ssn:Device then
8 saref_device_component.rdfs =
ss n_sy stem .rdf s
9
10 var s ar e f_ c on s is t sO f = s ar e f: c on s is ts O f
11 createTriple ( saref_sensor sa r ef _ co n si s ts O f
saref_device_component )
12 end for
Figure 2: Main elements of SSN and SAREF Listing 2: Pseudocode snippet for M02
After executing M01, M02 checks the composition relation-
14
http://www.vaisala.fi/Vaisala%20Documents/ ship of a device, i.e. the components that are part of a
Brochures%20and%20Datasheets/ device. In SSN, the object property ssn:hasSubSystem relat-
WM30-Datasheet-B210384EN-B-LoRes.pdf ing two ssn:System represents this relationship. In SAREF,
the object property saref:consistsOf plays this role, relating and WM30:WM30 WindSpeed), one for wind direction and
two saref:Device in a similar way, both illustrated in Figure 2 another for wind speed (both ssn:Sensor ). Moreover, WM30
as a self-relationship. Therefore, when ssn:hasSubSystem is sensor can measure (observe) the types (properties) WM30:-
used between the ssn sensingDevice (from M01) and a ssn:- WindDirection and WM30:WindSpeed (both ssn:Property).
System, which must be a ssn:Device or a ssn:SensingDevice, Figure 3 (top) illustrates these properties.
then it is mapped to saref:consistsOf object property of the In the generated ontology (SAREF), according to M01,
saref sensor (created in M01). If the device component is WM30:Vaisala WM30 element is created as a saref:Sensor.
a ssn:SensingDevice, then a recursive algorithm is used by A saref:SensingFunction is created and the WM30:Vaisala-
applying M01 to it. If the device component is a ssn:Device, WM30 element linked to it through saref:hasFunction prop-
then it is created a saref:Device. erty. According to M02, the composition of the sensor WM30:-
Vaisala WM30 is derived from the ssn:hasSubSystem prop-
M03. ssn:observes -> saref:measuresProperty erties, i.e. WM30:WM30 WindDirection and WM30:WM30-
After executing M01 and M02, M03 maps the measurement WindSpeed. M03 produced the measurement properties
property which the sensor is able to observe. For example, a of the sensor from the ssn:observes element, i.e. saref:-
wind sensor is able to observe both wind direction and wind measuresProperty to WM30:WindDirection and WM30:Wi-
speed. Therefore, the ssn:observes of a ssn:SensingDevice is ndSpeed. Figure 3 illustrates the result WM30:Vaisala WM-
mapped to saref:measuresProperty of a saref:Device. These 30) as a saref:Sensor. Therefore, by navigating to WM30:-
object properties relate to ssn:Property and saref:Property, Vaisala WM30, a saref:Sensor, it is possible to respond this
respectively. Therefore, this mapping also includes the cre- competency question in a similar way from the original, i.e.
ation, if it does not exist, of the ssn:Property. At last, the semantics is completely maintained.
this mapping needs to create the relationship back from the
saref:Property to the saref:Device through the object prop-
erty saref:isMeasuredByDevice. The code snippet below il-
lustrates this mapping.
1 IN: ssn_sensingDevice , saref_sensor
2 for each p in s s n _ s e n s i n g D e v i c e . o b s e r v e s
3 var ssn_property = p
4 var saref_property = saref:Property
5 saref_property = G e t P r o p e r t y I n S A R E F (
ssn_property )
6
7 if not isnull ( saref_property ) then
8 saref_property.rdfs = ssn_property.rdfs
9
10 var s a r e f _ m e a s u r e s P r o p e r t y =
saref:measuresProperty
11 var saref_sensor s a r e f _ m e a s u r e s P r o p e r t y
saref_property
12 var s a r e f _ i s M e a s u r e d B y D e v i c e = Figure 3: ssn:SensingDevice and saref:Device
saref:isMeasuredByDevice
13 createTriple ( saref_property CQ02. In the original ontology (SSN), the composition
s a r e f _ i s M e a s u r e d B y D e v i c e saref_sensor ) of WM30 sensor can be extracted by navigating from the
14 end for
WM30:Vaisala WM30 element to the ssn:hasSubSystem pro-
perties, i.e. WM30:WM30 WindDirection and WM30:WM-
Listing 3: Pseudocode snippet for M03
30 WindSpeed (ssn:Sensor ). The WM30 wind direction sen-
sor (WM30:WM30 WindDirection) can have one wiper (W-
4.2 Evaluation MS301 ) or two (WMS302 ). The same structure is generated
As described in the methodology section, an execution in SAREF, resulted from M02, having WM30:WM30 Wind-
of the mappings presented above was simulated having the Direction and WM30:WM30 WindSpeed created as saref:-
WM30 wind sensor example (according to SSN) as input. Device, linked through the object property saref:consistsOf.
The output of this translation, i.e. the WM30 ontology ac- It is possible to achieve the same structure of WM30:WM30-
cording to SAREF, was produced and made available 15 . WindDirection and WM30:WM30 WindSpeed, including the
The answers of the competency questions (see section 3) specialization to one or two wipers, by navigating from WM30:-
were produced by navigating the generated ontology with Vaisala WM30 (saref:Sensor ) through saref:consistsOf. This
support of an ontology editor (Protegé and TopBraid Com- competency question is responded in a similar way from the
poser). The competency questions were responded as: original (semantics maintained).
CQ01. In the original ontology (SSN), the main character- CQ03. In the original ontology (SSN), the measurement
istics of the WM30 sensor can be extracted by starting the properties of Vaisala WM30 sensor can be extracted by nav-
navigation in the WM30:Vaisala WM30 element, which is a igating from the WM30:Vaisala WM30 element through the
ssn:SensingDevice, inheriting the properties from ssn:Device ssn:observes properties, i.e. WM30:WindDirection and WM30:-
and ssn:Sensor. Besides, the rdfs:comment with a general WindSpeed, both ssn:Property. WM30 original example also
description of this wind sensor, it represents that the sensor uses an ontology of Quantity Kinds (http://purl.oclc.org/
is composed by two sensors (WM30:WM30 WindDirection NET/ssnx/qu) through the element qu:QuantityKind as ssn:-
Property. This element provides a taxonomy of quality di-
15
https://github.com/jonimoreira/SSN-SAREF) mensions, making use of dim:Angle for WM30:WindDirection
and dim:VelocityOrSpeed for WM30:WindSpeed. The same Property. The first restricts the measurement range from 0
structure is generated in SAREF, resulted from M03, as to 355 degrees, while the second restricts from 0 to 360 de-
saref:Property. Therefore, similar to CQ01 and CQ02, the grees. This question could not be responded with the gener-
semantics is completely maintained. ated ontology because of the same reason described in CQ04,
CQ04. The specification of the WMS30 wind direction i.e. the absence of ssn:MeasurementCapability in SAREF
sensor describes the accuracy, delay distance, starting thres- and no mappings on the ssn:hasMeasurementCapability ob-
hold and damping ratio of this sensor. For example, ac- ject property.
curacy can vary from -3 to 3 degrees, while the delay dis-
tance is 0.6 meters and the starting threshold is lower than 4.3 Discussion
1.0 m/s. In the original ontology (SSN), the measurement
The evaluation above demonstrated that from 5 compet-
capabilities of each wind direction and speed components
ency questions only 3 (60%) could be answered with the
of Vaisala WM30 sensor can be extracted by navigating
mappings described in this paper. The main issue identi-
from the WM30:Vaisala WM30 element through the ssn:-
fied is the lack of a naive element in SAREF to describe the
hasSubSystem properties, i.e. WM30:WM30 WindDirection
measurement capabilities of a sensor, which SSN enables
and WM30:WM30 WindSpeed, both ssn:Sensor, as described
through the ssn:hasMeasurementCapability object property
in CQ02. The WM30 wind direction sensor with one wiper
of ssn:Sensor. To cope with this issue we suggest that a
(WMS301 ) has measurement capability a WM30:WM30-
new mapping is created to align the structure from SSN, i.e.
WindDirection MeasurementCapability WMS301 (as WM-
create the object property ssn:hasMeasurementCapability on
S302 ). A WM30 WindDirection MeasurementCapability -
saref:Sensor with the restriction of only ssn:MeasurementCa-
WMS301 is a WM30 WindDirection MeasurementCapability,
pability. In addition, the mapping must consider to align
which describes the ranges supported (restrictions) for ac-
both ssn:MeasurementCapability and ssn:MeasurementPro-
curacy, delay distance, starting threshold and damping ratio,
perty as (is-a) saref:Property. This would enable the link
illustrated in the axioms of Figure 4. ssn:MeasurementCapa-
of a saref:Sensor to the ssn:MeasurementCapability, which
bility is a ssn:Property. Regarding the accuracy, SSN provides
incorporates the links to the ssn:MeasurementProperty.
naively the ssn:Accuracy element which represents the ac-
A conceptual issue in SSN was identified regarding the
curacy of all involved sensors, extracted with a simple SPARQL
element ssn:Sensor. The description of this element states
query (SELECT * WHERE { ?a ?b ssn:Accuracy. }) .
that it “allows sensors, methods, instruments, systems, al-
gorithms and process chains as the process used of an ob-
servation (. . . ) they are all grouped under the term sensor”.
Thus, the description includes that a ssn:Sensor can be a
”system”, but ssn:Sensor was not implemented as a special-
ization of ssn:System. In this way, ssn:Sensor could also in-
herit the composition relationship (ssn:hasSubSystem) and,
thus, can represent a set of sensors. Issues identified in
WM30 ontology include: (i) the WM30:Vaisala WM30 com-
position of wind direction (WM30:WM30 WindDirection)
and speed (WM30:WM30 WindSpeed ) sensors. Both are
ssn:Sensor, but the composition relationship (ssn:hasSubSy-
stem) is applied from a ssn:System to a ssn:System. There-
fore, the M02 mapping must not consider the types of the
subject or the object of the ssn:hasSubsystem property. (ii)
the universal quantifier on ssn:forProperty (Figure 4) is wrong.
A practical issue when mapping to SAREF is to con-
sider extending the taxonomy of sensor ”types” by creating
a new element when the type does not exist in SAREF. For
example, smoke and temperature sensors are classified as
saref:SmokeSensor and saref:TemperatureSensor, respectively,
having function (saref:hasFunction) and measure property
(saref:measuresProperty), linking the type of the sensor with
Figure 4: Measurement capabilities of WM30 functions it has and the type of property it measures (saref:-
Smoke and saref:Temperature. Thus, in our example, the
In the generated ontology (SAREF), these measurement correct implementation for the wind sensor is to create the
capabilities were lost because there is not a similar structure subclass saref:WindSensor, with function sensing and meas-
of ssn:MeasurementCapability in SAREF, thus, no mappings uring the properties of wind direction and wind speed, which
were added to consider the ssn:hasMeasurementCapability is guaranteed by M01.
object property of ssn:Sensor. This question could not be A limitation of this work is that this evaluation is a very
responded with the generated ontology (semantics was lost). preliminary application of the methodology, which is evalu-
CQ05. In the original ontology (SSN), the measurement ated on a manual application of the algorithms on a single
range constraints differentiating 301 and 302 wind direc- example. Furthermore, the use of pseudo-code to specify
tion sensors can be extracted by analyzing the restrictions of the translations seems not be the most adequate approach,
WM30:WM30 WindDirection MeasurementCapability WMS- which can be leveraged with a graphical modelling language
301 and WM30:WM30 WindDirection MeasurementCapability- for ontology alignments. Moreover, the number of compet-
WMS302 regarding the object property ssn:hasMeasurement- ency questions(five) is too small and lacks on characterist-
ics represented in the original WM30 ontology. In future or not. Then, these mappings will be implemented through
work it is intended to improve the evaluation process, so configurations in IPSM, exposing semantic translation ser-
competency questions can be responded in different levels vices that will be consumed by the early warning system.
(e.g. fully, half, not answered). An issue that must be ad-
dressed is revisiting these mappings when SSN 2.0 is pub- 6. ACKNOWLEDGMENTS
lished, and decide whether the mappings will be updated Thanks for the CAPES funding agency (BEX 1046/14-4),
or simply use the ontology alignments provided by SSN 2.0 TNO and EU-H2020-ICT grant INTER-IoT 687283.
specification. It includes the description of complex align-
ments which are presented with the property-chain axioms,
as the alignment of oldssn:observes (property used in our
7. REFERENCES
[1] M. Brambilla, J. Cabot, and M. Wimmer.
third mapping) to the equivalent sosa:observes with chain Model-Driven Software Engineering in Practice.
axioms oldssn:hasMeasurementCapability oldssn:forProperty Morgan & Claypool Publishers, 1st edition, 2012.
and oldssn:madeObservation oldssn:observedProperty. In ei- [2] M. Compton, P. Barnaghi, L. Bermudez, and et al.
ther ways this work will still be applicable and will not be- The SSN ontology of the W3C semantic sensor
come obsolete. Although this work only covers three vocab- network incubator group. Journal of Web Semantics,
ulary terms from the SSN 1.0, here we address the main 17:25–32, 2012.
elements used to characterize sensors, thus, providing a sig-
[3] M. Compton, H. Neuhaus, K. Taylor, and K. N. Tran.
nificant contribution for the state of the art.
Reasoning about sensors and compositions. CEUR
Workshop Proceedings, 522:33–48, 2009.
5. CONCLUSIONS [4] L. Daniele, F. den Hartog, and J. Roes. Created in
In this paper we described the initial mappings between Close Interaction with the Industry: The Smart
SSN and SAREF towards their ontological alignments to Appliances REFerence (SAREF) Ontology. In 7th
enable the semantic integration of IoT platforms relying on international FOMI workshop, volume 225, pages
them. In particular, the mappings presented here focused in 100–112, 2015.
translating the main parts of a sensor ontology, i.e. the ele- [5] L. Daniele, F. den Hartog, and J. Roes. How to Keep
ments about sensor, device, its composition and functions. a Reference Ontology Relevant to the Industry: A
Here we detailed three mappings to cover these properties, Case Study from the Smart Home. Lecture Notes in
showing how to produce a SAREF ontology from a SSN Computer Science (Artificial Intelligence),
ontology through a semantic translation mechanism. An 9557:117–123, 2016.
evaluation was performed to validate the initial specifica- [6] L. Daniele, M. Solanki, F. den Hartog, and J. Roes.
tion produced, which used an ontology of wind sensor with Interoperability for Smart Appliances in the IoT
SSN (WM30, provided by W3C) as input and generates World, pages 21–29. Springer International
a SAREF-based ontology as output. The results demon- Publishing, Cham, 2016.
strated a coverage of 60% of semantics maintained from the [7] M. Ganzha, M. Paprzycki, W. Pawlowski, and
original ontology (SSN) to the generated (SAREF). P. Szmeja. From implicit semantics towards ontologies
The main issue identified is the lack of measurement cap- — practical considerations from the INTER-IoT
abilities in SAREF to represent the collection of measure- perspective. pages 59–64, 2017.
ment properties of a component of a sensor. For example,
[8] M. Ganzha, M. Paprzycki, W. Pawlowski, P. Szmeja,
the wind direction component of the WM30 wind sensor
and K. Wasielewska. Semantic technologies for the IoT
measures the wind direction property, which has a specific
- An Inter-IoT perspective. Proceedings - 2016 IEEE
configuration of accuracy, delay distance, starting threshold
1st International Conference on Internet-of-Things
and damping ratio. Therefore, we identified that the repres-
Design and Implementation, IoTDI 2016, pages
entation of these characteristics in SAREF needs to be ad-
271–276, 2016.
dressed, probably by extending it with the ssn:hasMeasure-
[9] M. Ganzha, M. Paprzycki, W. Pawlowski, P. Szmeja,
mentCapability object property (used by saref:Sensor ) and
K. Wasielewska, and G. Fortino. Tools for Ontology
importing ssn:MeasurementCapability and ssn:Measurement-
Matching—Practical Considerations from INTER-IoT
Property (as saref:Property).
Perspective. 9258:143–154, 2015.
From this initial iteration on the development of the bi-
directional semantic translations we can conclude that, al- [10] M. Ganzha, M. Paprzycki, W. Pawlowski, P. Szmeja,
though the mappings presented here are quite intuitive, they and K. Wasielewska. Semantic interoperability in the
reflect the foundations of the ontology alignments between Internet of Things: An overview from the INTER-IoT
SSN and SAREF and is a required first step towards com- perspective. Journal of Network and Computer
plete semantic translations between them. Therefore, it rep- Applications, 2016.
resents a relevant contribution to the state-of-art by enabling [11] J. Moreira, L. Ferreira Pires, M. V. Sinderen, and
a basic level of semantic interoperability between IoT plat- P. D. Costa. Ontology-driven Conceptual Modeling for
forms relying on SSN and SAREF. Early Warning Systems: Redesigning the Situation
Future work includes the acquisition and/or generation of Modeling Language. In MODELSWARD, 2017.
test datasets (in both SSN and SAREF), giving emphasis to [12] J. Soldatos, N. Kefalakis, M. Hauswirth, M. Serrano,
the requirements for an early warning system [11] to detect J.-P. Calbimonte, M. Riahi, K. Aberer, P. P.
accidents in the port of Valencia, an INTER-IoT application Jayaraman, A. Zaslavsky, I. P. Žarko,
scenario. New mappings will be created according to this L. Skorin-Kapov, and R. Herzog. OpenIoT: Open
scope with incremental evaluations, using the test datasets Source Internet-of-Things in the Cloud, pages 13–25.
to verify whether the semantic interoperability is improved Springer International Publishing, Cham, 2015.