Resource Annotation, Dissemination and Discovery in the Semantic Web of Things: a Coap-Based Framework

2013 IEEE International Conference on Green Computing and Communications and IEEE Internet of Things and IEEE Cyber, Physical and Social Computing

Resource annotation, dissemination and discovery in the Semantic Web of Things: a CoAP-based framework

M. Ruta, F. Scioscia, A. Pinto, E. Di Sciascio, F. Gramegna, S. Ieva, G. Loseto DEI - Politecnico di Bari via E. Orabona 4, I-70125, Bari, Italy (m.ruta, f.scioscia, agnese.pinto, disciascio)@poliba.it, (gramegna, ieva, loseto)@deemail.poliba.it

Abstract—The Semantic Web of Things (SWoT) vision aims on context; severe computational constraints. In such dynamic to provide more advanced resource management and discov- environments, resource discovery is more challenging than ery w.r.t. standard Internet of Things architectures, by means static Web scenarios. of the integration of knowledge representation and reasoning techniques originally devised for the Semantic Web. This paper Among several alternatives proposed to define protocols proposes a novel SWoT framework, based on a backward- for object networks, 6LoWPAN [2] at network layer and the compatible extension of the Constrained Application Protocol Constrained Application Protocol (CoAP) [3] at application (CoAP), supporting non-standard inference services for semantic layer are emerging as widespread standards. Nevertheless, matchmaking. It allows retrieval and logic-based ranking of current solutions only allow a simplistic data-oriented rep- annotated resources. A computationally efficient data mining is also integrated in the framework to process raw data gathered resentation of resources and elementary retrieval procedures from the environment in order to detect high-level events and based on “string matching” between requests and resource characterize them with machine-understandable metadata. In attributes, which provide just binary yes/no outcomes. Exact order to test the effectiveness of the proposed approach, a case request/resource matches are very uncommon in real-world study about environmental risk prevention for Vehicular Ad-hoc scenarios with heterogeneous devices, sensors and actuators NETworks (VANETs) is presented. from several independent providers. Much like the case of Web Keywords—Semantic Web of Things, CoAP, Resource discovery, mashups [4], a large human effort is required on a case-by-case Matchmaking, Data mining basis for the design, deployment and integration of current IoT and Web of Things (WoT) applications. I. INTRODUCTION A more effective resource discovery should support also The Semantic Web of Things (SWoT) [1] is an emerging partial correspondences, possibly providing a measure of the vision, joining together the Semantic Web and the Internet of similarity degree between a request and available resources. Things paradigms. Every information resource in the Semantic Ideas and technologies adapted from the Semantic Web may be Web is annotated with metadata in RDF1 expressed w.r.t. useful to reach this goal. This paper proposes an overall frame- an RDF Schema2 or OWL3 ontology. Language specification work for the SWoT, managing semantic-based annotations of includes a standard XML serialization syntax. The adopted data streams, devices, high-level events and services with a knowledge representation models are grounded on formal, well-defined meaning w.r.t. a shared domain conceptualization 4 (i.e., ontology). The proposal introduces: (i) a slight backward- logic-based semantics. Query languages, e.g., SPARQL , are 5 6 defined to extract and combine asserted information, while compatible extensions to CoAP and CoRE Link Format reasoning engines can automatically infer knowledge entailed resource discovery protocol; (ii) computationally efficient data by a given Knowledge Base (KB). The goal of the SWoT is to mining procedures to detect and annotate high-level events associate semantically rich and machine-understandable infor- from raw data collected by a Semantic Sensor Network mation to real-world objects, locations and events, by means of (SSN) and the SSN-XG W3C ontology [5] is adopted as inexpensive, unobtrusive and often disposable micro-devices, reference vocabulary for resource annotations; (iii) a semantic- so enabling new classes of smart applications and services. based matchmaking via non-standard inference services [6] In order to allow this vision, frameworks and technologies to retrieve and rank resources best matching a given request, must deal with pervasive computing issues, that is resource, supporting not only full matches but also approximate ones. user and device volatility; platform heterogeneity; dependence In order to test and validate the proposed approach, a case study is also presented about environmental risk monitoring 1Resource Description Framework, W3C Recommendation, 10 February and management in Vehicular Ad-hoc NETworks (VANETs). 2004. http://www.w3.org/TR/rdf-primer/ 2RDF Vocabulary Description Language 1.0 (RDF Schema), W3C Recom- The remainder of the paper is organized as follows. Details mendation, 10 February 2004 http://www.w3.org/TR/rdf-schema/ 3OWL 2 Web Ontology Language Document Overview (Second Edition), 5We will refer to Constrained Application Protocol, IETF CoRE W3C Recommendation, 11 December 2012, http://www.w3.org/TR/owl2- Working Group Internet-Draft, version 13, 6 December 2012, overview/ http://tools.ietf.org/id/draft-ietf-core-coap-13.txt 4SPARQL Query Language for RDF, W3C Recommendation 15 January 6CoRE Link Format, IETF CoRE Working Group Internet-Draft, version 2008, http://www.w3.org/TR/rdf-sparql-query/ 14, 1 June 2012, http://www.ietf.org/id/draft-ietf-core-link-format-14.txt

978-0-7695-5046-6/13 $26.00 © 2013 IEEE 527 DOI 10.1109/GreenCom-iThings-CPSCom.2013.103 about functions and components of the framework architecture 6 V`J:C QG1CV are provided in Section II, followed by a case study in Section ]]C1H: 1QJ QC1VJ C%$1J III. Finally, Section IV discusses most relevant related research 1"1`Q QHQC and Section V closes the paper. ^$ 8GL]_ Q Q

II. PROPOSED APPROACH Q : V1:7 Q In what follows the proposed CoAP enhancements, the semantic matchmaking framework (adopted for resource dis- Q1J@ QRV Q1J@ QRV covery) and the event mining approach will be thoroughly Q described.

A. Semantic-enhanced CoAP and CoRE Link Format QRG:VRVJQ` V 1Q`@ Following the REST architectural style, CoAP adopts a loosely coupled client/server model, based on stateless op- Fig. 1. Framework Architecture erations on resources representation [3]. Each resource is a server-controlled abstraction, unambiguously identified by a In order to support a semantic-based resource discovery, URI (Uniform Resource Identifier). Clients access resources the CoAP protocol has been improved with a novel usage via synchronous request/response interactions, using HTTP- of standard URI-query options and with the addition of derived methods basically mapping the Read, Create, Update new ones. The CoAP-based SSN framework proposed here and Delete operations of data management. Basically, a CoAP extends the enhancements described in [7] enabling further message is composed of: (i) a 32-bit header, containing the non-standard inferences to support automated sensor discovery request method code (or response status); (ii) an optional token and composition, representing one of the main novelties of value, used to associate replies to requests, (iii) a sequence the approach. However the resulting framework is still fully of option fields (carrying information as resources URI and backward compatible: servers which do not support semantics payload media type), (iv) the payload data. The CoRE Link will simply reply to requests returning no resource records. Format specification is adopted for resource discovery. A Semantic-based requests are led back to standard CoAP ones client will access the reserved URI /.well-known/core by introducing three novel attributes: (i) reference ontology on the server via GET to retrieve available resources entry (ro), containing the URI of the domain conceptualization; (ii) points. Further GET requests will include URI-query fields semantic description (sd), i.e., the annotated request, com- to recall only resources with given attributes. Standardized pressed to cope with the verbosity of XML-based languages; query attributes include resource type (rt), interface usage (iii) annotation-type (at), specifying the compression format. (if), content-type (ct), and MIME (Multipurpose Internet The reference geographical location is achieved by specify- Mail Extension) type for a resource. Further non-reserved ing lg (longitude) and lt (latitude) attributes. Furthermore, attributes can be freely used. CoAP also provides push noti- md (maximum distance) is used to indicate the maximum fications without polling7, a useful feature when data have to acceptable distance (in meters) from the reference location be monitored over a time span. for retrieving resources. The adoption of a (center, distance) constraint allows the server to pre-filter resources, so avoiding In CoAP-based scenarios, each sensor is seen as a possibly expensive inference procedures for resources outside server, exposing both readings and internal information as the requested area. Finally, each provided reasoning task de- resources toward clients, which act on behalf of end-user voted to resource discovery is identified by a code, specified by applications. Different data series will be identified by dis- st (semantic task) attribute. In addition to existing tasks, a new tinct URIs. Further URIs will identify sensor device sta- code for sensor discovery based on Concept Covering [8] has tus and operating parameters; clients will be able to read been added. Furthermore, a semantic threshold (sr) attribute or modify them as appropriate. For example, a tempera- is used to set a minimum score threshold. Resources having ture sensor S can expose the latest temperature reading at an overall score w.r.t. the request lower than sr will not be the URI coap://[S-address]/temperature;inor- returned to the client. This allows to modulate the granularity der to access it, a client should issue a GET request with of discovery and to limit data transfers when many resources Uri-Host=S-address and Uri-Path=/temperature are available. In replies to discovery, this field contains the options. In case of success, it will receive status code 2.05 overall score of a resource w.r.t. the request. and the response message payload will contain the value, e.g., 22.5◦C if it is returned as plain text. Furthermore, since CoAP supports proxies, cluster-head or sink nodes can reply on behalf B. Sensory data annotation of a set of (possibly more constrained) sensor nodes deployed in an area, exploiting caching and decreasing the load at the An explicative architecture of the proposed framework edge of the network. This feature allows also the adoption of is depicted in Figure 1. A CoAP-based SSN is composed data fusion and mining techniques over data extracted from by several sensors deployed in a given area communicating sensors useful to nodes managing high-level applications. through a local sink node, acting as cluster head, with a gateway interfacing the network toward the rest of the world. 7Observing Resources in CoAP, IETF CoRE Working Group Internet- Each sensor is featured by data-oriented attributes, as usual, Draft, latest version: 8, 25 February 2013, http://tools.ietf.org/id/draft-ietf- but also by a semantic annotation describing its characteristics core-observe-08.txt and functions. Sink nodes will: (i) allow sensors to register

528 their semantic description as a CoAP resource and (ii) embed C. Resource discovery via Concept Covering a lightweight matchmaker [9] enabling ontology-based infer- The basic CoAP resource discovery protocol only allows ences on annotated metadata. Devices within the SSN can be a syntactic string-matching of attributes, lacking every explicit accessed through: and formal characterization of the resources semantics. Due to - CoAP clients, able to exploit a semantic-based discovery to this reason, advanced discovery services should be adopted search for sensors or actuators according to their annotations, to improve protocol capabilities. They should allow to: (i) and get raw data and/or event descriptions via standard CoAP rank resources w.r.t. a request and (ii) identify also partial primitives; correspondences between a request and device descriptions, - Remote applications, based on different wireless protocols, very frequent in practical scenarios involving heterogeneous e.g., IEEE 802.11b/p and usually getting high-level event resources. In [6], framework and algorithms were proposed descriptions from the SSN for further processing tasks. for a logic-based matchmaking between a request and one or more resource descriptions, both expressed using languages In a Semantic Web of Things vision, each system device or grounded on a well known logic. Description Logics (DL) client application produces large amounts of data which have [10] was the reference formalism and particularly the ALN to be collected and interpreted to extract useful application- (Attributive Language with Unqualified Number Restrictions) oriented information. This is the case of event detection where DL subset was adopted, having a well-known polynomial (semi) automatic procedures are strongly required. In a CoAP- computational complexity for standard and non-standard in- based SSN, each sink device collects data and process them ferences. Particularly, the Concept Abduction Problem (CAP) for detecting events; when done, a dedicated resource record [11] resolution was exploited in [7] to enhance the CoAP is updated by adding a semantic description. The record will discovery capabilities. It allowed to determine, given a request also contain extra-logical contextual parameters such as a D and a resource S, what should be hypothesized in S in order timestamp and geographic information about the monitored to completely satisfy D also enabling a logic-based relevance area. In the proposed framework a simple and effective data ranking of S w.r.t. D. mining process has been devised in order to annotate the sensor audit. After detection, the sink and/or the CoAP gateway In addition to CAP, here we propose a further enhancement will wait for resource discovery requests coming from client of the discovery protocol to support a slightly refined version applications searching for dedicated sensors in the area. of the Concept Covering [8] inference. Such a reasoning task is devoted to select a minimum set of resources best covering a request. That is, given a request D and a set of resources S The procedure for identification of sensory events via = {S1, S2, ..., Sk}, where D and S1, S2, ..., Sk are satisfiable surveys comprises several stages: w.r.t. the ontology T , the Concept Covering Problem (CCoP) 1) Data are read from sensors in the field through standard resolution aims to find a pair Sc,H where Sc includes CoAP GET requests, possibly using Observe option to be concepts in S (partially) covering D w.r.t. T and H is the notified of updates. Then a list of elements is built, consisting (possible) part of D not covered by concepts in Sc. The of three fields: ID, storing the identifier of the sensor and algorithm 1 reported hereafter is applied to request and sensor therefore the type of data; value, containing the detected data; annotations. A compatibility check is performed to verify if the timestamp. This list will group measurements in time slots sensor si (from the set S) is a cover for the request (line 7). of application-defined period T , used to compute statistical Then the CAP is solved (line 8) to determine what is missing indexes. in the sensor description, in order to completely satisfy the 2) For each data set, average, variance and standard deviation request. Afterwards a rank value is computed via the following values are computed for the current time slot, to assess the utility function: variability of collected information within the monitored area. 3) Statistical indexes of elapsed periods are then exploited to distance (P, si) rank (D, Hi) = 100 ∗ 1 − s match (D, Hi) ∗ 1+ compute an incremental ratio to evidence trends and significant md event changes inside the monitored area. 4) For every data collection, the application defines a binary or where s match measures the CAP-induced semantic distance multiple classifier, to reveal a situation when given conditions [11] between D and a description Hi; the geographical dis- occur (see the Section III for an implementation): the identi- tance of the sensor si from the reference point P (defined fication is performed by taking into account threshold values by the attributes lt and lg), normalized by user-specified for statistical indexes. maximum distance (attribute md), is combined as weighting 5) The output of each classifier is a logic-based expression factor. Finally, the sensor with the highest rank (Smax)is mapped according to knowledge modeled in the reference on- selected and moved from S to Sc (lines 17-18) and the tology. The final semantic description is the logical conjunction part of D covered by Smax is removed from the starting of all derived expressions. request (line 19). The algorithm will return the set of sensors best covering the request, along with the uncovered part, if present. Such non-standard inference service is particularly It is important to note that semantic-enhanced CoAP dis- useful in semantic-based Internet of Things scenarios, e.g., covery per se does not impose restrictions on where data sensor network, where it is needed to gather data from different mining happens, whether in clients running the application kind of sensors to infer proper events. logic, in sink nodes or in sensors having processing capabilities enough. In the approach proposed here mining and event A toy example should clarify both structure and content detection are executed at sink level after sensors send data of request and reply messages in the semantic-enhanced via standard CoAP frames. variant of CoAP protocol. Semantic annotations will be

529 Algorithm 1 Request covering algorithm Algorithm: requestCovering (L, T ,D,S) Require: – L Description Logics; – acyclic TBox T ; – concept expression of the request D; – S = {s1,s2,...sn} concept expression of sensors; – D and si are expressed in L and satisfiable in T . Ensure: – Sc = {s1,s2,...sk} set of sensors covering the request D; – uncovered part of the request H. 1: Sc := ∅ 2: H := D 3: repeat 4: Rmax := 0 5: Smax := 6: for all si ∈ S do 7: if (si D) is satisfiable in T and si isacoverforD then 8: Hi := solveCAP (L, T D, si ) 9: R := rank(D, Hi) 10: if R>Rmax then 11: Rmax := R 12: Smax := si Fig. 2. JOSM plugin for CoAP-based SSNs 13: end if 14: end if 15: end for D. Framework architecture 16: if Smax = then 17: Sc := Sc ∪ Smax Two novel prototypical CoAP clients have been developed 18: S := S − Smax to enable an advanced sensor discovery through a visual user 19: H := H \{Smax} 20: end if interface. Communication with sensors has been implemented 21: until Smax = using a modified version of Californium CoAP library [12], 22: return Sc,H extended with the semantic-based enhancement described in Section II-A. The first one is a plugin for the open source JOSM8 application: a screenshot of the prototype GUI is shown in Figure 2. Thanks to an easily understandable interface, the proposed tool can be used to perform the following voluntarily omitted here for the sake of clarity. Let us suppose tasks in a graphical way: an application addresses a discovery request toward a SSN - SSN browsing. A geographic area of interest can be down- sink at the 193.204.59.75 IP address to find a set of sensors loaded from the OpenStreetMap server. Available sensors, most suitable for a task expressed in OWL/RDF language registered on CoAP sinks, can be shown on the map on the w.r.t. SSN-XG ontology (gzip compressed). The application left panel (A); is interested only in sensors located within 800m from the - Semantic-based sensor discovery. A semantic-based CoAP (41.079769, 16.763571) coordinates. The application will request can be sent to discover sensors in the environment. The therefore send a GET CoAP request to: right panel (C) allows to customize the request by means of coap://193.204.59.75:5683/.well-known/core? the features described in Section II-A. Particularly, a reference &ro=SSN-XG-IRI&sd=yyyyyy=&at=30004&lg=16.763571 location point can be selected by clicking on the map. Then it <=41.079769&md=800&st=2&sr=70 is possible to choose the task to perform (e.g., discovery via Upon received the request, the CoAP server will start a Concept Covering), the outcome threshold and the maximum matchmaking process comparing it w.r.t. all stored annotations discovery range. Finally, the semantic description can be referred to the same ontology. The semantic matchmaking composed by simply selecting (with drag-and-drop operations) is carried out by solving CCoP, in order to find the set of from the UI panel (B) properties and classes defined in the resources best covering the request and what elements of the reference ontology. request are lacking in the retrieved sensor list. Let us suppose that the returned set is composed of two sensors matching A mobile client for smartphones was also devised to enable the above request. The discovery reply payload sent by the the communication between SSNs and Android-based devices. CoAP server will be: The client was developed using Android SDK Tools, Revision 21.1, corresponding to Android Platform version 4.2.2 (API ;ct=0;ct=41;at=30004;lg=16.768277; level 17), and tested on an off-the-shelf smartphone9. Also in lt=41.077286;md=480;ro=SSN-XG-IRI;sd=aaaaaaa; this case, the client can be used either to browse the SSN or title="Humidity-Sensor-2030", to perform an advanced sensor discovery. The user can select ;ct=0;ct=41;at=30004;lg=16.758347; a sink node and view all connected sensors or only devices lt=41.081983;md=500;ro=SSN-XG-IRI;sd=bbbbbbb; retrieved after a semantic-based discovery, as shown in Figure title="Anemometer-Sensor-111", 3(a). By selecting a sensor, it is also possible to see its details ;sd=ccccccc;sr=9.12 In case of a partial cover, the response can also include (in as in Figure 3(b) and its location on the map (see Figure 3(c)). addition to the sensor list) both the semantic description of Then, each device can be queried to retrieve data it measures, the uncovered part (H) of the request and a ranking value as reported in Figure 3(d). corresponding to the percentage of request not covered. This 8Java OpenStreetMap (OSM) editor, http://josm.openstreetmap.de/ value is obtained comparing H w.r.t. the starting request by 9Samsung GT-i9250 Galaxy Nexus with ARM Cortex A9 Dual Core CPU means of semantic-based ranking algorithms [11]. at 1.2 GHz, 1 GB RAM, 16 GB internal memory, and Android version 4.2.2

530 (a) Discovery results (b) Sensor details (a) CoAP query attributes (b) Content types list

Fig. 3. Mobile client - Sensor discovery Fig. 4. Mobile client - Attributes settings

In addition to classic CoAP messages, a semantic-based along a road to monitor and gather information about the CoAP request can be composed by filling the query attributes weather conditions of a given area. In the proposed scenario, as in Figure 4(a). For each attribute, the user must specify each RSU acts as a CoAP gateway and periodically queries the a value. As an example, Figure 4(b) shows the selectable CoAP sinks in its range. Afterward sinks select suitable sensors values for the Content-Type attribute. In addition, the semantic by means of a logic-based resource discovery and return to description is completed by selecting (drawing in the lists in the RSU the most appropriate device set. The RSU can now Figure 4(c) and 4(d)) properties and classes extracted from the query the sensors to obtain raw data and exploits data mining, reference ontology. as described in Section II-B, to detect a meteorological event. Event annotations are then exposed for external applications, in III. CASE STUDY: ENVIRONMENTAL RISK MONITORING IN this case vehicles warned about detected events by the RSUs. VANETS Each sensor is able to measure one or more parame- In order to show the benefits of the proposed approach, in ters (e.g., temperature, humidity, atmospheric pressure, wind what follows a simple case study in the field of environmental speed), with specific measurement capabilities (e.g., accu- monitoring is reported. The scenario is configured as a Vehic- racy, precision, resolution, frequency) defined in the same ular Ad-Hoc Network (VANET), an application-oriented net- reference ontology. The SSN-XG ontology cited above was work solution for safety and emergency information delivery. extended to enable sensor descriptions as conjunctive concept By exploiting Vehicle-to-Infrastructure (V2I) wireless com- expressions. Figure 5 shows an example of temperature sensor munication technologies, each vehicle approaching dangerous modeling. The Stimulus-Sensor-Observation design pattern [5] road sections receives safety warnings and traffic information was exploited to describe the measuring features of a sensor, from deployed Road-Side Units (RSUs). Particularly, we focus with some differences. A sensor can “observe” properties on Hybrid Sensor and Vehicular Networks (HSVNs), which modeled as subclasses of ssn:FeatureOfInterest and merge VANETs and WSNs. In HSVNs, sensors are distributed has proper measurement capabilities expressed as subclasses

531 Device Measurement Capabilities Operative Description Device Type Visibility Temperature Pressure Wind Speed Humidity Range LowAcc. LowRes., LowAcc. LowMedium MediumRes. MediumAcc., MediumRes. Request (D) Sensor LowAcc., MediumRes. LowFreq. HighLatency Altitude MediumAcc., LowPrec. HighFreq. Temperature HighAcc., HighFreq. MediumHigh SE95Sensor - - - - Sensor HighRange, HighRes. Altitude Temperature LowAcc., MediumFreq. LowMedium LM70Sensor - - - - Sensor HighRange Altitude Humidity MediumAcc., HighFreq. Hts2030Sensor - - - - - Sensor MediumRes., HighRange Anemometer MediumAcc., LowRes. BitLineBLVSensor - - - - - Sensor MediumRes., LowPrec. Barometer LowAcc., MediumRes. BMP085Sensor - - - - - Sensor LowRange, LowPrec. LowAcc. Visibility FS11Sensor LowRange - - - - - Sensor LowFreq. LowRes., Uncovered (US2) ------HighLatency

TABLE I. REQUEST AND SENSORS DESCRIPTIONS

near to RSU1 receiving the request –i.e., S1 and S2– solves the - - - CCoP, as described in Algorithm 1, exploiting the embedded reasoning engine [9]. S1 and S2 return the set of compatible - - resources Sc whose intersection best cover the request D. ! * ! Concept expressions for some of the sensors inside the mea-

* #$ * *$ surement area (Figure 6) and connected to the sink node S2, are " # ( 2) % reported in Table I. Sc S –the covering set retrieved by S2– " +, #%+ - & " $# is composed by LM70Sensor, Hts2030Sensor, BMP085Sensor, - BitLineBLVSensor and FS11Sensor. Nevertheless, as reported * )* '( )*'( $ - - " in the pie chart in Figure 6, this set does not fully cover - - the request: an uncovered part US2 is returned (see Table I), " '( '( $ corresponding to the 5.20% of the original D. In particular, - - - LM70Sensor does not completely satisfy the required features " in terms of temperature measurement capabilities. Instead, S1 returns a second set of sensor Sc(S1) with an uncovered part Fig. 5. Temperature sensor modelling equals to the 9.10% of D. In this case, Sc(S2) is better than Sc(S1) so the first set is selected. of the ssn:MeasurementCapability class. In turn, each Now RSU1 can query/observe sensors that compose specific subclass of ssn:MeasurementCapability has Sc(S2) to acquire data for the meteorological events detection. a set of measurement properties and (optional) operating For example, let us suppose that, after a period of observation, range, represented as subclasses of the ssn:Property the mining process produces the following average values class. Furthermore, a sensor is related to a subclass of for the gathered parameters: sea level temperature 7.09°C; ssn:EnergyDevice through the ssn:hasSubSystem temperature between 0÷599 m 1.98°C; relative humidity property to model its energy source. 80.52%; wind speed 19.69 km/h; atmospheric pressure 971.51 Let us suppose a car is driving in the morning on the mbar; visibility 254.38 m. Based on studies and laws on SS96, a highway near to Bari in Italy. The road presents a meteorological event detection, a classifier able to detect one of low-flowing with a poor traffic density (90 vehicles per hour). the weather conditions reported in Table II has been designed. Possible dangers are due to several crossroads.Toshowina graphical way the results of processing tasks described above, Meteorological event the JOSM plugin presented in Section II-D is used. As shown Parameter Fog Wind Rain Snow in Figure 6, the car is riding near to the RSU1. The gateway temp 0 m (°C) - - ≥6 - temp 0÷599 m (°C) t − td ≤4 - - ≤5 composes a discovery request D, using concepts defined in the temp 600÷1499 m (°C) - - - 5÷10 domain ontology, as described in Table I10. The CoAP GET temp ≥1500 m (°C) - - - ≤0 request also includes three query parameters: (i) RSU reference visibility(m) ≤1000 - - - wind speed (km/h) - ≥100 - - location P , defined through the attributes lt and lg; (ii) the humidity (%) - - 80÷100 - maximum distance d from P , defining the area where sensors pressure (mbar) - - 970÷1000 - must be located; (iii) the minimum threshold t, to retrieve only td: dew point temperature device sets with a covering percentage score higher than t.In TABLE II. CRITERIA FOR METEOROLOGICAL EVENT DETECTION particular, RSU1 looks for devices located near to SS96 with a maximum distance of 800m from P and a coverage threshold value of 90%. After a distance-based filtering, each sink node In the example, the classifier identifies Fog and Rain events Each detected event is annotated w.r.t. the reference ontology 10For the sake of readability, concept expressions for both request and as subclass of the Weather concept. This high level semantic- sensors are summarized in textual form. based characterization of the weather conditions becomes a

532 IV. RELATED WORK CoAP [3] is a protocol similar to HTTP devoted to interconnect objects, exploiting a binary data representation and a subset of HTTP methods. It follows the REST (REp- resentational State Transfer) paradigm for making data and resources accessible. Analogously, 6LoWPAN [2] is a protocol for WSNs defined to enable IPv6 packets to be carried on top of low power wireless networks, specifically exploiting IEEE 802.15.4 protocol. Both 6LoWPAN and CoAP use UDP for data transport, as TCP is considered too resource-consuming. 6LoWPAN can be interfaced to IPv6 and CoAP/UDP to HTTP/TCP, so that sensor data can be accessed from the Web. Particularly CoAP is assuming relevance for its lightweight impact on storage and computation, resulting useful for a variety of application domains [13], [14]. In latest years, some interesting SSN approaches were Fig. 6. Covering result developed to integrate WSNs and smart objects with the Semantic Web. Existing architectures largely vary in scope but query for further matchmaking processes based on the envi- usually aim to: (i) exploit reference ontologies –e.g., OntoSen- ronmental conditions. In the proposed case study, RSU1 waits sor [15] and SSN-XG– to annotate data, devices and services; for vehicles equipped with a wireless interface that come into (ii) share sensor data along the Linked Open Data (LOD) [16] its radio range. Each vehicle will send a semantic description guidelines and by means of RESTful [17], [18] and OGC’s containing main characteristics of its safety devices. Let us Sensor Web Enablement (SWE) [19] web service interfaces. suppose that the following vehicles, described in DL formalism Particularly, Sense2Web [20] proposed a LOD-based platform hereafter, drive nearby RSU1: to publish sensor data and link them to existing resource on the BMWX5 ≡ Vehicle SUV ∃hasSpeed Semantic Web. Different sensor data ontologies were used to ∀ hasSpeed.(ModerateSpeed) ∃hasLamp ∀ hasLamp.(XenonLamp F ogLamp) ∃hasSecureDevice describe physical resources, query data and relations to obtain ∀ hasSecureDevice.(ABS ESP) ∃hasP neumatic ∀ hasP neumatic.(SnowTire). implicit information and integrate sensor data coming from various sources. Similarly, SPITFIRE [21] combines semantic AudiA3 ≡ Vehicle Sedan ∃hasSpeed ∀ hasSpeed.(HighSpeed) ∃hasLamp ∀hasLamp.(F ogLamp) and networking technologies to build a service infrastructure ∃ hasSecureDevice ∀hasSecureDevice.(ABS) ∃ hasP neumatic ∀hasP neumatic.(T raditionalT ire). aiming to develop semantic applications exploiting Internet- connected sensors and lightweight protocols, as CoAP. In such Fiat600 ≡ Vehicle EconomyCar ∃hasSpeed ∀ hasSpeed.(HighSpeed) ∃hasLamp framework, sensors are described via RDF triples and service ∀ hasLamp.(Headlight) ∃hasP neumatic ∀ hasP neumatic.(T raditionalT ire). discovery is based on meta-data retrieval (device features or location). In [22] the Linked Stream Middleware (LSM) RSU1 will perform a matchmaking task between a vehicle platform was proposed to integrate sensor data with other description and previously detected events, each annotated in LOD sources, by enriching both sensor sources and sensor data terms of safety requirements a car must adopt to limit risks streams with semantic descriptions. A processing engine was for that weather conditions: used to perform SPARQL queries across both dataset types, Fog ≡ Weather ∃hasSpeed ∀hasSpeed.(ModerateSpeed) ∃ hasLamp ∀hasLamp.(F ogLamp) ∃hasSecureDevice mashup the data and process results. Tran et al. [23] propose an ∀ hasSecureDevice.(ABS). application to automatically compose sensor features and mea- Rain ≡ Weather ∃hasSpeed ∀hasSpeed.(ModerateSpeed) sures. In particular user goals, functional and non-functional ∃ hasP neumatic ∀hasP neumatic.(RibbedT ire) properties of sensors are described w.r.t. an OWL ontology ∃ hasSecureDevice ∀hasSecureDevice.(ABS ESP). so that the composition system is able to combine sensors Finally, for each pair vehicle/event, RSU1 exploits the and processes to satisfy a user request. In [24] ontology-based rankPotential [11] algorithm and returns a Rank Value (RV) sensor descriptions allow the users to express requests in terms 0 ≤ ≤ 1 representing the risk level: very low ( RV ), low of device characteristics. Quantitative reasoning and semantic =2 =3 4 ≤ ≤ 5 (RV ), medium (RV ), high ( RV ), very high querying techniques were employed to improve the resource =6 ≥ 7 (RV ), ultra high (RV ). As reported in Table III, the discovery and select appropriate sensors. BMW is the the safest vehicle, because it is equipped with snow tyres (also useful in case of rain), fog lamps, ABS and Unfortunately, the above solutions only allow elementary ESP. The Audi has higher risk levels due to its medium-high queries in SPARQL fragments on RDF annotations and then speed that contributes in a significant way to increase the risk only basic resource discovery features are allowed. Ontology- level, despite of ABS and fog lamps activated. A high speed based complex event processing [25] and semantic matchmak- and inadequate safety features make the Fiat 600 absolutely ing [6] can be used to improve data management and sensor unsuitable. discovery in mobile and pervasive contexts (see [26], [27], [28]) exploiting logic-based reasoning to support approximated BMW X5 Audi A3 Fiat 600 matches, resource ranking and explanation of outcomes. In [7] RVFog very low (1) low (2) very high (6) RVRain very low (1) high (4) ultra high (7) a novel SSN framework was defined complying such theoret- ical approach, based on a backward-compatible extension of TABLE III. RISK LEVELS FOR DETECTED EVENTS CoAP resource discovery, employing non-standard inference

533 services [11] for retrieving and ranking resources. [11] M. Ruta, E. Di Sciascio, and F. Scioscia, “Concept Abduction and Contraction in Semantic-based P2P Environments,” Web Intelligence and Agent Systems, vol. 9, no. 3, pp. 179–207, 2011. ONCLUSION V. C [12] M. Kovatsch, S. Mayer, and B. Ostermaier, “Moving Application Logic The paper proposed a novel framework for the Semantic from the Firmware to the Cloud: Towards the Thin Server Architecture for the Internet of Things,” in Proceedings of the 6th International Web of Things, based on a backward-compatible CoAP exten- Conference on Innovative Mobile and Internet Services in Ubiquitous sion supporting flexible resource description, management and Computing (IMIS 2012), Jul. 2012. discovery via logic languages and inference services. A case [13] W. Colitti, K. Steenhaut, N. De Caro, B. Buta, and V. Dobrota, “REST study in a VANET scenario allows to test both feasibility and Enabled Wireless Sensor Networks for Seamless Integration with Web effectiveness. An implementation of the presented approach in Applications,” in 8th IEEE International Conference on Mobile Adhoc a large testbed with off-the-shelf devices is ongoing. Future and Sensor Systems (MASS 2011), 2011, pp. 867–872. work includes the extension of the underlying logic toward [14] A. Dimitrios, G. Vasileios, G. Dimitrios, and C. Ioannis, “Employing EL EL++ Internet of Things technologies for building automation,” in 17th IEEE / (in order to increase allowed expressiveness of Conference on Emerging Technologies & Factory Automation (ETFA resource and request descriptions) as well as the integration 2012), 2012, pp. 1–8. of specialized compression algorithms for Semantic Web lan- [15] D. J. Russomanno, C. R. Kothari, and O. A. Thomas, “Building a Sensor guages [1] to reduce storage and network load. Ontology: A Practical Approach Leveraging ISO and OGC Models,” in The 2005 International Conference on Artificial Intelligence, 2005, pp. 637–643. ACKNOWLEDGMENT [16] C. Bizer, T. Heath, and T. Berners-Lee, “Linked data-the story so The authors acknowledge partial support of Italian PON far,” International Journal on Semantic Web and Information Systems project RES NOVAE and POR project UbiCare. (IJSWIS), vol. 5, no. 3, pp. 1–22, 2009. [17] H. Patni, C. Henson, and A. Sheth, “Linked Sensor Data,” in Collabo- rative Technologies and Systems (CTS), 2010 International Symposium REFERENCES on. IEEE, 2010, pp. 362–370. [1] F. Scioscia and M. Ruta, “Building a Semantic Web of Things: [18] S. Mayer and D. Guinard, “An extensible discovery service for smart issues and perspectives in information compression,” in Semantic Web things,” in 2nd International Workshop on Web of Things, ser. WoT ’11. Information Management (SWIM’09). In Proceedings of the 3rd IEEE New York, NY, USA: ACM, 2011, pp. 7:1–7:6. International Conference on Semantic Computing (ICSC 2009). IEEE [19] A. Broring,¨ P. Maue,´ K. Janowicz, D. Nust,¨ and C. Malewski, Computer Society, 2009, pp. 589–594. “Semantically-enabled sensor plug & play for the sensor web,” Sensors, [2] N. Kushalnagar, G. Montenegro, and C. P. Schumacher, “IPv6 over vol. 11, no. 8, pp. 7568–7605, 2011. Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, [20] P. Barnaghi, M. Presser, and K. Moessner, “Publishing Linked Sensor Assumptions, Problem Statement, and Goals,” RFC Editor, Fremont, Data,” in Proceedings of the 3rd International Workshop on Semantic CA, USA, RFC 4919, Aug. 2007. Sensor Networks, 2010. [3] C. Bormann, A. Castellani, and Z. Shelby, “Coap: An application [21] D. Pfisterer, K. Romer, D. Bimschas, O. Kleine, R. Mietz, C. Truong, protocol for billions of tiny internet nodes,” Internet Computing, IEEE, H. Hasemann, M. Pagel, M. Hauswirth, M. Karnstedt et al., “SPITFIRE: vol. 16, no. 2, pp. 62–67, 2012. Toward a Semantic Web of Things,” Communications Magazine, IEEE, [4] D. Guinard and V. Trifa, “Towards the Web of Things: Web Mashups vol. 49, no. 11, pp. 40–48, 2011. for Embedded Devices,” in Workshop on Mashups, Enterprise Mashups [22] D. Le-Phuoc, H. Q. Nguyen-Mau, J. X. Parreira, and M. Hauswirth, and Lightweight Composition on the Web (MEM 2009), in proceedings “A middleware framework for scalable management of linked streams,” of WWW (International World Wide Web Conferences), Madrid, Spain, Web Semantics: Science, Services and Agents on the World Wide Web, 2009. vol. 16, pp. 42–51, Nov. 2012. [5] M. Compton, P. Barnaghi, L. Bermudez, R. Garcia-Castro, O. Corcho, [23] K.-N. Tran, M. Compton, and R. G. Jemma Wu, “Semantic Sensor S. Cox, J. Graybeal, M. Hauswirth, C. Henson, A. Herzog et al., “The Composition,” in 3rd International Workshop on Semantic Sensor Net- SSN ontology of the W3C semantic sensor network incubator group,” works. Proceedings of the 9th International Semantic Web Conference Web Semantics: Science, Services and Agents on the World Wide Web, (ISWC 2010), ser. CEUR Workshop Proceedings, D. R. D. Taylor K., vol. 17, pp. 25–32, Dec. 2012. Ayyagari A., Ed., vol. 668. CEUR-WS, nov 2010, pp. 33–48. [6] S. Colucci, T. Di Noia, A. Pinto, A. Ragone, M. Ruta, and E. Tinelli, [24] C. Perera, A. Zaslavsky, P. Christen, M. Compton, and D. Georgakopou- “A Non-Monotonic Approach to Semantic Matchmaking and Request los, “Context-aware Sensor Search, Selection and Ranking Model for Refinement in E-Marketplaces,” International Journal of Electronic Internet of Things Middleware,” in IEEE 14th International Conference Commerce, vol. 12, no. 2, pp. 127–154, 2007. on Mobile Data Management (MDM 2013), jun 2013, to appear. [7] M. Ruta, F. Scioscia, G. Loseto, F. Gramegna, A. Pinto, S. Ieva, and [25] K. Taylor and L. Leidinger, “Ontology-driven complex event processing E. Di Sciascio, “A logic-based CoAP extension for resource discovery in heterogeneous sensor networks,” The Semanic Web: Research and in semantic sensor networks,” in 5th International Workshop on Seman- Applications, pp. 285–299, 2011. tic Sensor Networks (SSN 2012), ser. CEUR Workshop Proceedings, [26] M. Ruta, T. Di Noia, E. Di Sciascio, and F. Donini, “Semantic-Enhanced C. O. Henson C., Taylor K., Ed., vol. 904. CEUR-WS, nov 2012, pp. Bluetooth Discovery Protocol for M-Commerce Applications,” Interna- 17–32. tional Journal of Web and Grid Services, vol. 2, no. 4, pp. 424–452, [8] A. Ragone, T. Di Noia, E. Di Sciascio, F. M. Donini, S. Colucci, and 2006. F. Colasuonno, “Fully Automated Web Services Discovery and Compo- [27] M. Ruta, F. Scioscia, T. Di Noia, and E. Di Sciascio, “A hybrid Zig- sition through Concept Covering and Concept Abduction,” International Bee/Bluetooth approach to mobile semantic grids,” Computer Systems Journal of Web Services Research (JWSR), vol. 4, no. 3, pp. 85–112, Science and Engineering, vol. 25, no. 3, pp. 235–249, May 2010. 2007. [28] R. De Virgilio, E. Di Sciascio, M. Ruta, F. Scioscia, and R. Torlone, [9] M. Ruta, F. Scioscia, E. Di Sciascio, F. Gramegna, and G. Los- “Semantic-based RFID Data Management,” in Unique Radio Innovation eto, “Mini-ME: the Mini Matchmaking Engine,” in OWL Reasoner for the 21st Century: Building Scalable and Global RFID Networks. Evaluation Workshop (ORE 2012), ser. CEUR Workshop Proceedings, Springer, 2011, pp. 111–142. I. Horrocks, M. Yatskevich, and E. Jimenez-Ruiz, Eds., vol. 858. CEUR-WS, 2012, pp. 52–63. [10] F. Baader, D. Calvanese, D. Mc Guinness, D. Nardi, and P. Patel- Schneider, The Description Logic Handbook. Cambridge University Press, 2002.

534