Several IoT ontologies have been developed lately to improve the semantic interoperability of IoT solutions. The most popular of these ontologies, the W3C Semantic Sensor Network (SSN), is considered an ontological foundation for diverse IoT initiatives, particularly OpenIoT. With characteristics similar to SSN, the ETSI Smart Appliances REFerence (SAREF) ontology evolved from the needs of smart home solutions to common requirements of IoT. Some IoT solutions rely on platform-speci c ontologies and their integration requires mechanisms to align these ontologies. In this paper we discuss the ontology alignment between SSN and SAREF, identifying mapping alternatives and proposing basic mappings that can be re-used to de ne more complex ones. We introduce here an initial speci cation of the semantic translations from the main elements of SSN to SAREF, which includes classes, object properties and data properties. The alignment will be used in a semantic matching process leveraging the semantic mediator component of the INTER-IoT project. An initial evaluation of the translation was executed by translating the wind sensor (Vaisala WM30), an example provided by the W3C, from SSN to SAREF. This initial evaluation demonstrates the coherence and feasibility of the proposed mappings.
© 2017 Copyright held by the author/owners. SEMANTiCS 2017 workshops proceedings: SIS-IoT September 11-14, 2017, Amsterdam, Netherlands •Information systems ! Semantic web description languages;
Over the past few years, numerous IoT ontologies were
proposed to improve the semantic interoperability of IoT
artifacts, i.e. the common understanding capabilities of
platforms, devices, gateways, applications and networks involved
in IoT solutions [
IoT platforms enable software engineers to bridge the gap between device sensors and connected applications through suites of components, which can include semantic technologies, e.g. FIWARE with the Sense2Web linked-data generic enabler (GE) and OpenIoT with its own ontology extended from SSN. The Inter-IoT project1 aims at designing, implementing and experimenting with voluntary interoperability among heterogeneous IoT platforms. The project is driven by use cases from (e/m)Health and transportation/logistics at the port of Valencia, which require semantic integration 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. nding and mapping the correspondences between entities (atomic) or groups of entities and sub-structures (complex). An approach to implement ontology alignment is semantics trans
lation, which is a process that transforms some information
described semantically, in terms of a source ontology, to
information described in terms of a target ontology [
In this paper we introduce mappings among the main elements for the semantic translations from SSN 1.0 to SAREF 2.0. We adopted a model-driven engineering methodology to develop these semantic translations which considers speci cation and implementation. The speci cation will be used for con guration and deployment in the Inter-Platform Semantic Mediator (IPSM) of INTER-IoT. We evaluated these mappings by demonstrating how the SSN representation of the WM30 wind sensor, an example provided by the W3C, is translated to SAREF. After the translations' execution, a veri cation of the generated ontology is made, measuring the level of semantics maintained from the original ontology.
Section 2 describes the background research with an overview of the IPSM, the SSN and SAREF ontologies. Section 3 describes the methodology used to develop the semantic translations. Section 4 introduces the mappings from SSN to SAREF, describes the evaluation of the mappings and discusses the challenges. Section 5 concludes this work by presenting the lessons learned and future work.
The main goal of the H2020 project Interoperability of
Heterogeneous IoT Platforms (INTER-IoT) [
INTER-IoT provides its own alignment format, based on an alignment API with a declarative ontology alignment language (XML-based), inspired on EDOAL2, to represent in
terconnections between semantic data of multiple ontologies.
IPSM utilizes alignment les and provides a multi-channel
environment for any artifact. Pairs of uni-directional
alignments between the central ontology and artifact ontology
are used to translate messages to and from the central
ontology. This enables connection of new artifacts without
jeopardizing the existing channels, and requires each
participant to provide only a pair of alignments. While
complete ontologies are used to build semantic understanding,
only conversation-speci c alignments are stored and used
for actual translations. Ontology alignments and
translation channels can be managed through the REST Manager.
Because of space limitations in this paper we omit other
related work, which can be found in our prior publications
that cover the state-of-the-art in this area [
The W3C Semantic Sensor Network (SSN)3 [
Skeleton module: represents the most basic concepts regarding sensors, as Sensor, Sensing, Property and Observation. A Sensor may be a physical device implementing Sensing, i.e. it has a sensing method observing some Property. "Sensing is a process that results in the estimation, or calculation, of the value of a phenomenon".
Measuring module: covers the elements Sensing Device and Sensor DataSheet. The prior is the main element of SSN. The former represents the data sheet speci cations of a sensor. Usually, the properties of a sensor are recorded directly with hasMeasurementCapability property of a Sensor. System module: represents the System concept as a Physical Object (DUL) composed by sub-systems (hasSubSys
4http://ontologydesignpatterns.org/wiki/Ontology: DOLCE+DnS Ultralite 5https://www.w3.org/2005/Incubator/ssn/wiki/DUL ssn tem), which has deployment(s) (hasDeployment ), operating range(s) (hasOperatingRange) and location(s) relative to other entities (onPlatform).
of SSN, i.e. properties and capabilities of measurements, such as Accuracy, MeasurementProperty and MeasurementCapability. Relevant object properties are the hasMeasurementCapability and hasMeasurementProperty. MeasurementCapability represents a characteristic of a sensor's observations or ability to make observations (e.g. accuracy and range). MeasurementProperty represents the collection of measurement properties and environmental conditions in which those properties hold.
Device module: covers Device, which is a physical piece of technology (a "system in a box") and can be composed of other (smaller) devices and software components.
The W3C SSN Incubator Group created an example of the
use of SSN by describing the Vaisala WM30 wind sensor 6.
It describes the measurement capabilities, power supply and
operating and survival properties based on the technical
speci cation of the measurement of wind direction and speed.
This example was initially reported in [
WM30:Vaisala WM30 v ssn:SensingDevice WM30:Vaisala WM30 v
9 ssn:hasSubSystem : WM30:WM30 WindDirection WM30:Vaisala WM30 v WM30:Vaisala WM30 v WM30:Vaisala WM30 v 9 ssn:hasSubSystem : WM30:WM30 WindSpeed 9 ssn:observes : WM30: WindDirection 9 ssn:observes : WM30: WindSpeed
Currently the W3C is updating the entire SSN ontology towards a new version (2.0), which is available as a public draft document prepared by the W3C and the Open Geospatial Consortium (OGC)7. In this new version, a new ontology is introduced, namely the Sensor Observation Sampling Actuator (SOSA), absorbing a number of classes and properties from SSN 1.0, such as Sensor, Observation and observes. SOSA is aligned with DUL and SSN 2.0 is aligned with SOSA. SOSA is also aligned with the foundational ontologies BFO and PROV-O8. Most important, the compatibility of our work with SSN 2.0 is not compromised because the speci cation provides alignments of SSN 2.0 with SSN 1.0, including complex ones. 2.3
Recently, the European Telecommunications Standards
Institute (ETSI) along with the European Comission (EC),
the Netherlands Organisation for Applied Scienti c Research
(TNO), the Universidad Politecnica de Madrid (UPM) and
other partners, developed the Smart Appliances REFerence
(SAREF) ontology [
SAREF facilitates the matching of existing assets, since
it was developed based on standards, ontologies, data
models and protocols of the IoT domain, providing a high-level
mapping of them (available in SAREF's rst interim study
report). One of these assets is SSN, which inspired the
de nition of the main elements of SAREF, namely Device,
Sensor, Unit of Measure and Time/Duration, according to
the high-level mappings provided in the SAREF initial
documentation [
The composition of a Device can be represented through the saref:consistsOf self-relationship, e.g. the WM30 wind sensor (a device) can be de ned as a composition of wind direction and wind speed sensors. A Device measures a speci c property, represented by the object property saref:measuresProperty to a Property. For example, a SmokeSensor (Sensor ) measures Smoke (Property), analogously a WindSensor measures Wind. Regarding a measurement observed by a sensor in time, SAREF represents it through the saref:makesMeasurement object property of a Device to Measurement(s), representing the relation between a device and the measurements it makes. A Measurement element links of the value of the Measurement, its Unit of Measure and the Property to which it relates.
A Device o ers a Service, which is a representation of a
10https://ec.europa.eu/digital-single-market/blog/ new-standard-smart-appliances-smart-home 11https://ec.europa.eu/digital-single-market/en/news/newversion-machine-2-machine-standard-smart-appliancesintroduced-etsi Function to a network that makes the function discoverable, registerable and remotely controllable by other devices in the network. A Service can represent one or more functions. A Service must specify the Device that o ers the Service, the function(s) to be represented, and the (input and output) parameters necessary to operate the service, supported by the ontology alignments with OneM2M ontology.
We surveyed tools for ontology alignment [
We use a speci cation strategy to avoid conceptual
errors during the implementation, which is a common issue in
software engineering. Moreover, directly implementing the
mappings forces a preliminary choice of the technology of the
transformation runtime, which couples the mappings with a
12https://jena.apache.org/
technology, thus, limiting the reuse of the mappings. Our
ontology-driven conceptual modeling strategy [
A MDE transformation can be developed as an unidirectional or a bi-directional transformation. The best practices show that, when creating a bi-directional transformation with a high number of meta-model elements, a cyclical process should be used. The rst step is to specify an unidirectional transformation with a selected sub-set of metamodel elements to be covered and validate with simulations. If errors are found then they should be xed and the transformations should be validated again until the mappings correctly generate the intended model. The second step is to specify the opposite direction with the same elements of the rst step, and validate/correct with simulations. The third step is to evaluate whether meaning is lost when executing the transformations in sequence, i.e. check how x is di erent 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 mappings before implementing. Once an acceptable level of the quality of the bi-directional transformation speci cation 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. In this paper we present the rst step applied from SSN to SAREF with three terms from SSN.
The rationale for speci cation are based on an ontological
analysis of the SSN and SAREF TBox, i.e. an analysis of the
statements that describe their conceptualization. Since SSN
is extended from DUL, and DUL is the lightweight
foundational ontology of DOLCE, we used DOLCE's categories as
a reference to map from SSN to SAREF. For example, the
object property ssn:hasSubSystem is a DUL:hasPart, which
means "a schematic relation between any entities". Based
on this de nition, we sought for in SAREF the possible
relations that have the same semantics for this mapping, nding
that saref:consistsOf has the same meaning: "a relationship
indicating a composite entity that consists of other
entities (e.g., a temperature/humidity sensor that consists of a
temperature sensor and a humidity sensor)". Although this
process is quite time consuming, error-prone and automatic
techniques based on natural language processing (NLP) are
commonly used for nding ontology similarity [
Here we present an initial evaluation of the speci cation created, simulating unidirectional semantic translation from WM30 ontology (SSN) to SAREF. In general, the result from the translations must represent the WM30 wind sensor with SAREF, keeping similar semantics of the original. Therefore, the goal of this evaluation is to check the semantic similarity between the original and the nal ontologies. Here we used an approach based on competency questions to measure this similarity. A list of competency questions is presented, and each question is answered by navigating the elements of both ontologies. The answers are compared to verify whether the semantics are maintained after the simulation. Intentionally, the competency questions were conceived according to the expressiveness of the SSN WM30 ontology, targeting its main elements, as the di erent measurement capabilities described in the technical speci cations14. For example, the accuracy of the WM30 wind speed sensor (within a range from 0.4 to 60 m/s) is +- 0.3 m/s for wind speed lower than 10 m/s and +-2% of variance for wind speed higher than 10 m/s. At rst, we answered each question based on the original ontology (in SSN) and, then, we answered the same question for the generated ontology (SAREF). Second, we compare whether the semantics of the response is similar to each other, i.e. if the semantics are lost or maintained. The competency questions are: CQ01. What are the characteristics of the WM30 sensor? CQ02. What is the composition of this sensor, i.e. what are the parts of WM30? CQ03. What measurement properties this sensor performs? CQ04. What are the accuracy, delay distance, starting threshold and damping ratio of wind direction sensors? CQ05. What measurement range constraints di erentiate these types of wind direction sensors?
According to the methodology used, the mappings between SSN and SAREF were speci ed through an ontological analysis of their TBox, i.e. concepts and roles de nitions (predicates) with logical operations. A study was made on how SSN and SAREF describe the characteristics of sensors, including their capabilities of observation. The mappings follow a logic sequence according to the main elements and similar structures of SSN and SAREF. Here we detail only the mappings from SSN to SAREF as a rst step towards the creation of the bi-directional translations. For each mapping a code snippet is presented as a pseudo-code to illustrate the algorithm for the creation of the SAREF-based ontology. This pseudo-code include an IN representing the input SSN element(s). When creating a new SAREF class or property, var is used and createTriple function creates a triple (class, object property, class).
While the main element of SSN is the Sensing Device, a subclass of Device and Sensor, in SAREF the main element is Device, which can be specialized as a Sensor related to a Sensing Function. The characteristics of ssn:SensingDevice, inherited from ssn:Sensor and ssn:System, are mapped to saref:Sensor, inheriting saref:Device properties, including the relationship with the saref:SensingFunction (saref:hasFunction). Figure 2 illustrates the elements involved in this mapping. Notice that, indirectly, this mapping also transforms from ssn:Sensor to saref:Sensor if the ssn:Sensor is a ssn:SensingDevice. All RDFS properties are copied from ssn:SensingDevice to saref:Sensor. 1 IN: ssn_sensingDevice 2 var saref_sensor = saref:Sensor 3 saref_sensor.rdfs = ssn_sensingDevice.rdfs 4 var saref_function = saref:SensingFunction 5 var saref_hasFunction = saref:hasFunction 6 createTriple ( saref_sensor saref_hasFunction saref_function )
M02. ssn:hasSubSystem -> saref:consistsOf 1 IN: ssn_sensingDevice , saref_sensor 2 for each ssn_system in
ssn_sensingDevice.ssn:hasSubSystem var saref_device_component = saref:Device After executing M01, M02 checks the composition relationship of a device, i.e. the components that are part of a device. In SSN, the object property ssn:hasSubSystem relating two ssn:System represents this relationship. In SAREF, the object property saref:consistsOf plays this role, relating two saref:Device in a similar way, both illustrated in Figure 2 as a self-relationship. Therefore, when ssn:hasSubSystem is used between the ssn sensingDevice (from M01) and a ssn:System, which must be a ssn:Device or a ssn:SensingDevice, then it is mapped to saref:consistsOf object property of the saref sensor (created in M01). If the device component is a ssn:SensingDevice, then a recursive algorithm is used by applying M01 to it. If the device component is a ssn:Device, then it is created a saref:Device.
After executing M01 and M02, M03 maps the measurement property which the sensor is able to observe. For example, a wind sensor is able to observe both wind direction and wind speed. Therefore, the ssn:observes of a ssn:SensingDevice is mapped to saref:measuresProperty of a saref:Device. These object properties relate to ssn:Property and saref:Property, respectively. Therefore, this mapping also includes the creation, if it does not exist, of the ssn:Property. At last, this mapping needs to create the relationship back from the saref:Property to the saref:Device through the object property saref:isMeasuredByDevice. The code snippet below illustrates this mapping. 1 IN: ssn_sensingDevice , saref_sensor 2 for each p in ssn_sensingDevice.observes 3 var ssn_property = p 4 var saref_property = saref:Property 5 saref_property = GetPropertyInSAREF ( ssn_property ) if not isnull ( saref_property ) then
saref_property.rdfs = ssn_property.rdfs var saref_measuresProperty =
saref:measuresProperty 11 var saref_sensor saref_measuresProperty saref_property 12 var saref_isMeasuredByDevice =
saref:isMeasuredByDevice 13 createTriple ( saref_property
saref_isMeasuredByDevice saref_sensor ) 14 end for
Listing 3: Pseudocode snippet for M03
As described in the methodology section, an execution of the mappings presented above was simulated having the WM30 wind sensor example (according to SSN) as input. The output of this translation, i.e. the WM30 ontology according to SAREF, was produced and made available 15. The answers of the competency questions (see section 3) were produced by navigating the generated ontology with support of an ontology editor (Protege and TopBraid Composer). The competency questions were responded as: CQ01. In the original ontology (SSN), the main characteristics of the WM30 sensor can be extracted by starting the navigation in the WM30:Vaisala WM30 element, which is a ssn:SensingDevice, inheriting the properties from ssn:Device and ssn:Sensor. Besides, the rdfs:comment with a general description of this wind sensor, it represents that the sensor is composed by two sensors (WM30:WM30 WindDirection 15https://github.com/jonimoreira/SSN-SAREF) and WM30:WM30 WindSpeed), one for wind direction and another for wind speed (both ssn:Sensor ). Moreover, WM30 sensor can measure (observe) the types (properties) WM30:WindDirection and WM30:WindSpeed (both ssn:Property). Figure 3 (top) illustrates these properties.
In the generated ontology (SAREF), according to M01, WM30:Vaisala WM30 element is created as a saref:Sensor. A saref:SensingFunction is created and the WM30:VaisalaWM30 element linked to it through saref:hasFunction property. According to M02, the composition of the sensor WM30:Vaisala WM30 is derived from the ssn:hasSubSystem properties, i.e. WM30:WM30 WindDirection and WM30:WM30WindSpeed. M03 produced the measurement properties of the sensor from the ssn:observes element, i.e. saref:measuresProperty to WM30:WindDirection and WM30:WindSpeed. Figure 3 illustrates the result WM30:Vaisala WM30) as a saref:Sensor. Therefore, by navigating to WM30:Vaisala WM30, a saref:Sensor, it is possible to respond this competency question in a similar way from the original, i.e. the semantics is completely maintained. CQ02. In the original ontology (SSN), the composition of WM30 sensor can be extracted by navigating from the WM30:Vaisala WM30 element to the ssn:hasSubSystem properties, i.e. WM30:WM30 WindDirection and WM30:WM30 WindSpeed (ssn:Sensor ). The WM30 wind direction sensor (WM30:WM30 WindDirection) can have one wiper (WMS301 ) or two (WMS302 ). The same structure is generated in SAREF, resulted from M02, having WM30:WM30 WindDirection and WM30:WM30 WindSpeed created as saref:Device, linked through the object property saref:consistsOf. It is possible to achieve the same structure of WM30:WM30WindDirection and WM30:WM30 WindSpeed, including the specialization to one or two wipers, by navigating from WM30:Vaisala WM30 (saref:Sensor ) through saref:consistsOf. This competency question is responded in a similar way from the original (semantics maintained).
CQ03. In the original ontology (SSN), the measurement properties of Vaisala WM30 sensor can be extracted by navigating from the WM30:Vaisala WM30 element through the ssn:observes properties, i.e. WM30:WindDirection and WM30:WindSpeed, both ssn:Property. WM30 original example also uses an ontology of Quantity Kinds (http://purl.oclc.org/ NET/ssnx/qu) through the element qu:QuantityKind as ssn:Property. This element provides a taxonomy of quality dimensions, making use of dim:Angle for WM30:WindDirection and dim:VelocityOrSpeed for WM30:WindSpeed. The same structure is generated in SAREF, resulted from M03, as saref:Property. Therefore, similar to CQ01 and CQ02, the semantics is completely maintained.
CQ04. The speci cation of the WMS30 wind direction sensor describes the accuracy, delay distance, starting threshold and damping ratio of this sensor. For example, accuracy can vary from -3 to 3 degrees, while the delay distance is 0.6 meters and the starting threshold is lower than 1.0 m/s. In the original ontology (SSN), the measurement capabilities of each wind direction and speed components of Vaisala WM30 sensor can be extracted by navigating from the WM30:Vaisala WM30 element through the ssn:hasSubSystem properties, i.e. WM30:WM30 WindDirection and WM30:WM30 WindSpeed, both ssn:Sensor, as described in CQ02. The WM30 wind direction sensor with one wiper (WMS301 ) has measurement capability a WM30:WM30WindDirection MeasurementCapability WMS301 (as WMS302 ). A WM30 WindDirection MeasurementCapability WMS301 is a WM30 WindDirection MeasurementCapability, which describes the ranges supported (restrictions) for accuracy, delay distance, starting threshold and damping ratio, illustrated in the axioms of Figure 4. ssn:MeasurementCapability is a ssn:Property. Regarding the accuracy, SSN provides naively the ssn:Accuracy element which represents the accuracy of all involved sensors, extracted with a simple SPARQL query (SELECT * WHERE f ?a ?b ssn:Accuracy. g) . In the generated ontology (SAREF), these measurement capabilities were lost because there is not a similar structure of ssn:MeasurementCapability in SAREF, thus, no mappings were added to consider the ssn:hasMeasurementCapability object property of ssn:Sensor. This question could not be responded with the generated ontology (semantics was lost). CQ05. In the original ontology (SSN), the measurement range constraints di erentiating 301 and 302 wind direction sensors can be extracted by analyzing the restrictions of WM30:WM30 WindDirection MeasurementCapability WMS301 and WM30:WM30 WindDirection MeasurementCapabilityWMS302 regarding the object property ssn:hasMeasurementProperty. The rst restricts the measurement range from 0 to 355 degrees, while the second restricts from 0 to 360 degrees. This question could not be responded with the generated ontology because of the same reason described in CQ04, i.e. the absence of ssn:MeasurementCapability in SAREF and no mappings on the ssn:hasMeasurementCapability object property. 4.3
The evaluation above demonstrated that from 5 competency questions only 3 (60%) could be answered with the mappings described in this paper. The main issue identied is the lack of a naive element in SAREF to describe the measurement capabilities of a sensor, which SSN enables through the ssn:hasMeasurementCapability object property of ssn:Sensor. To cope with this issue we suggest that a new mapping is created to align the structure from SSN, i.e. create the object property ssn:hasMeasurementCapability on saref:Sensor with the restriction of only ssn:MeasurementCapability. In addition, the mapping must consider to align both ssn:MeasurementCapability and ssn:MeasurementProperty as (is-a) saref:Property. This would enable the link of a saref:Sensor to the ssn:MeasurementCapability, which incorporates the links to the ssn:MeasurementProperty.
A conceptual issue in SSN was identi ed regarding the element ssn:Sensor. The description of this element states that it \allows sensors, methods, instruments, systems, algorithms and process chains as the process used of an observation (. . . ) 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 specialization of ssn:System. In this way, ssn:Sensor could also inherit the composition relationship (ssn:hasSubSystem) and, thus, can represent a set of sensors. Issues identi ed in WM30 ontology include: (i) the WM30:Vaisala WM30 composition of wind direction (WM30:WM30 WindDirection) and speed (WM30:WM30 WindSpeed ) sensors. Both are ssn:Sensor, but the composition relationship (ssn:hasSubSystem) is applied from a ssn:System to a ssn:System. Therefore, the M02 mapping must not consider the types of the subject or the object of the ssn:hasSubsystem property. (ii) the universal quanti er on ssn:forProperty (Figure 4) is wrong.
A practical issue when mapping to SAREF is to consider 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 classi ed as saref:SmokeSensor and saref:TemperatureSensor, respectively, having function (saref:hasFunction) and measure property (saref:measuresProperty ), linking the type of the sensor with functions it has and the type of property it measures (saref:Smoke and saref:Temperature. Thus, in our example, the correct implementation for the wind sensor is to create the subclass saref:WindSensor, with function sensing and measuring the properties of wind direction and wind speed, which is guaranteed by M01.
A limitation of this work is that this evaluation is a very preliminary application of the methodology, which is evaluated on a manual application of the algorithms on a single example. Furthermore, the use of pseudo-code to specify the translations seems not be the most adequate approach, which can be leveraged with a graphical modelling language for ontology alignments. Moreover, the number of competency questions( ve) is too small and lacks on characteristics represented in the original WM30 ontology. In future work it is intended to improve the evaluation process, so competency questions can be responded in di erent levels (e.g. fully, half, not answered). An issue that must be addressed is revisiting these mappings when SSN 2.0 is published, and decide whether the mappings will be updated or simply use the ontology alignments provided by SSN 2.0 speci cation. It includes the description of complex alignments which are presented with the property-chain axioms, as the alignment of oldssn:observes (property used in our third mapping) to the equivalent sosa:observes with chain axioms oldssn:hasMeasurementCapability oldssn:forProperty and oldssn:madeObservation oldssn:observedProperty. In either ways this work will still be applicable and will not become obsolete. Although this work only covers three vocabulary terms from the SSN 1.0, here we address the main elements used to characterize sensors, thus, providing a signi cant contribution for the state of the art.
In this paper we described the initial mappings between SSN and SAREF towards their ontological alignments to enable the semantic integration of IoT platforms relying on them. In particular, the mappings presented here focused in translating the main parts of a sensor ontology, i.e. the elements about sensor, device, its composition and functions. Here we detailed three mappings to cover these properties, showing how to produce a SAREF ontology from a SSN ontology through a semantic translation mechanism. An evaluation was performed to validate the initial speci cation produced, which used an ontology of wind sensor with SSN (WM30, provided by W3C) as input and generates a SAREF-based ontology as output. The results demonstrated a coverage of 60% of semantics maintained from the original ontology (SSN) to the generated (SAREF).
The main issue identi ed is the lack of measurement capabilities in SAREF to represent the collection of measurement properties of a component of a sensor. For example, the wind direction component of the WM30 wind sensor measures the wind direction property, which has a speci c con guration of accuracy, delay distance, starting threshold and damping ratio. Therefore, we identi ed that the representation of these characteristics in SAREF needs to be addressed, probably by extending it with the ssn:hasMeasurementCapability object property (used by saref:Sensor ) and importing ssn:MeasurementCapability and ssn:MeasurementProperty (as saref:Property ).
From this initial iteration on the development of the bidirectional semantic translations we can conclude that, although the mappings presented here are quite intuitive, they re ect the foundations of the ontology alignments between SSN and SAREF and is a required rst step towards complete semantic translations between them. Therefore, it represents a relevant contribution to the state-of-art by enabling a basic level of semantic interoperability between IoT platforms relying on SSN and SAREF.
Future work includes the acquisition and/or generation of
test datasets (in both SSN and SAREF), giving emphasis to
the requirements for an early warning system [
Thanks for the CAPES funding agency (BEX 1046/14-4), TNO and EU-H2020-ICT grant INTER-IoT 687283.