Resource annotation, dissemination and discovery inthe Semantic Web of Things: a CoAP-based

framework

M. Ruta, F. Scioscia, A. Pinto, E. Di Sciascio, F. Gramegna, S. Ieva, G. LosetoDEI - 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 aimsto provide more advanced resource management and discov-ery w.r.t. standard Internet of Things architectures, by meansof the integration of knowledge representation and reasoningtechniques originally devised for the Semantic Web. This paperproposes a novel SWoT framework, based on a backward-compatible extension of the Constrained Application Protocol(CoAP), supporting non-standard inference services for semanticmatchmaking. It allows retrieval and logic-based ranking ofannotated resources. A computationally efficient data mining isalso integrated in the framework to process raw data gatheredfrom the environment in order to detect high-level events andcharacterize them with machine-understandable metadata. Inorder to test the effectiveness of the proposed approach, a casestudy about environmental risk prevention for Vehicular Ad-hocNETworks (VANETs) is presented.

Keywords—Semantic Web of Things, CoAP, Resource discovery,Matchmaking, Data mining

I. INTRODUCTION

The Semantic Web of Things (SWoT) [1] is an emergingvision, joining together the Semantic Web and the Internet ofThings paradigms. Every information resource in the SemanticWeb is annotated with metadata in RDF1 expressed w.r.t.an RDF Schema2 or OWL3 ontology. Language specificationincludes a standard XML serialization syntax. The adoptedknowledge representation models are grounded on formal,logic-based semantics. Query languages, e.g., SPARQL4, aredefined to extract and combine asserted information, whilereasoning engines can automatically infer knowledge entailedby a given Knowledge Base (KB). The goal of the SWoT is toassociate semantically rich and machine-understandable infor-mation to real-world objects, locations and events, by means ofinexpensive, unobtrusive and often disposable micro-devices,so enabling new classes of smart applications and services.In order to allow this vision, frameworks and technologiesmust deal with pervasive computing issues, that is resource,user and device volatility; platform heterogeneity; dependence

1Resource Description Framework, W3C Recommendation, 10 February2004. http://www.w3.org/TR/rdf-primer/

2RDF Vocabulary Description Language 1.0 (RDF Schema), W3C Recom-mendation, 10 February 2004 http://www.w3.org/TR/rdf-schema/

3OWL 2 Web Ontology Language Document Overview (Second Edition),W3C Recommendation, 11 December 2012, http://www.w3.org/TR/owl2-overview/

4SPARQL Query Language for RDF, W3C Recommendation 15 January2008, http://www.w3.org/TR/rdf-sparql-query/

on context; severe computational constraints. In such dynamicenvironments, resource discovery is more challenging thanstatic Web scenarios.

Among several alternatives proposed to define protocolsfor object networks, 6LoWPAN [2] at network layer and theConstrained Application Protocol (CoAP) [3] at applicationlayer are emerging as widespread standards. Nevertheless,current solutions only allow a simplistic data-oriented rep-resentation of resources and elementary retrieval proceduresbased on “string matching” between requests and resourceattributes, which provide just binary yes/no outcomes. Exactrequest/resource matches are very uncommon in real-worldscenarios with heterogeneous devices, sensors and actuatorsfrom several independent providers. Much like the case of Webmashups [4], a large human effort is required on a case-by-casebasis for the design, deployment and integration of current IoTand Web of Things (WoT) applications.

A more effective resource discovery should support alsopartial correspondences, possibly providing a measure of thesimilarity degree between a request and available resources.Ideas and technologies adapted from the Semantic Web may beuseful to reach this goal. This paper proposes an overall frame-work for the SWoT, managing semantic-based annotations ofdata streams, devices, high-level events and services with awell-defined meaning w.r.t. a shared domain conceptualization(i.e., ontology). The proposal introduces: (i) a slight backward-compatible extensions to CoAP5 and CoRE Link Format6

resource discovery protocol; (ii) computationally efficient datamining procedures to detect and annotate high-level eventsfrom raw data collected by a Semantic Sensor Network(SSN) and the SSN-XG W3C ontology [5] is adopted asreference vocabulary for resource annotations; (iii) a semantic-based matchmaking via non-standard inference services [6]to retrieve and rank resources best matching a given request,supporting not only full matches but also approximate ones.In order to test and validate the proposed approach, a casestudy is also presented about environmental risk monitoringand management in Vehicular Ad-hoc NETworks (VANETs).

The remainder of the paper is organized as follows. Details

5We will refer to Constrained Application Protocol, IETF CoREWorking Group Internet-Draft, version 13, 6 December 2012,http://tools.ietf.org/id/draft-ietf-core-coap-13.txt

6CoRE Link Format, IETF CoRE Working Group Internet-Draft, version14, 1 June 2012, http://www.ietf.org/id/draft-ietf-core-link-format-14.txt

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

Physical and Social Computing

978-0-7695-5046-6/13 $26.00 © 2013 IEEE

DOI 10.1109/GreenCom-iThings-CPSCom.2013.103

527

about functions and components of the framework architectureare provided in Section II, followed by a case study in SectionIII. Finally, Section IV discusses most relevant related researchand Section V closes the paper.

II. PROPOSED APPROACH

In what follows the proposed CoAP enhancements, thesemantic matchmaking framework (adopted for resource dis-covery) and the event mining approach will be thoroughlydescribed.

A. Semantic-enhanced CoAP and CoRE Link Format

Following the REST architectural style, CoAP adopts aloosely coupled client/server model, based on stateless op-erations on resources representation [3]. Each resource is aserver-controlled abstraction, unambiguously identified by aURI (Uniform Resource Identifier). Clients access resourcesvia synchronous request/response interactions, using HTTP-derived methods basically mapping the Read, Create, Updateand Delete operations of data management. Basically, a CoAPmessage is composed of: (i) a 32-bit header, containing therequest method code (or response status); (ii) an optional tokenvalue, used to associate replies to requests, (iii) a sequenceof option fields (carrying information as resources URI andpayload media type), (iv) the payload data. The CoRE LinkFormat specification is adopted for resource discovery. Aclient will access the reserved URI /.well-known/coreon the server via GET to retrieve available resources entrypoints. Further GET requests will include URI-query fieldsto recall only resources with given attributes. Standardizedquery attributes include resource type (rt), interface usage(if), content-type (ct), and MIME (Multipurpose InternetMail Extension) type for a resource. Further non-reservedattributes can be freely used. CoAP also provides push noti-fications without polling7, a useful feature when data have tobe monitored over a time span.

In CoAP-based scenarios, each sensor is seen as aserver, exposing both readings and internal information asresources toward clients, which act on behalf of end-userapplications. Different data series will be identified by dis-tinct URIs. Further URIs will identify sensor device sta-tus and operating parameters; clients will be able to reador modify them as appropriate. For example, a tempera-ture sensor S can expose the latest temperature reading atthe URI coap://[S-address]/temperature; in or-der to access it, a client should issue a GET request withUri-Host=S-address and Uri-Path=/temperatureoptions. In case of success, it will receive status code 2.05and the response message payload will contain the value, e.g.,22.5◦C if it is returned as plain text. Furthermore, since CoAPsupports proxies, cluster-head or sink nodes can reply on behalfof a set of (possibly more constrained) sensor nodes deployedin an area, exploiting caching and decreasing the load at theedge of the network. This feature allows also the adoption ofdata fusion and mining techniques over data extracted fromsensors useful to nodes managing high-level applications.

7Observing Resources in CoAP, IETF CoRE Working Group Internet-Draft, latest version: 8, 25 February 2013, http://tools.ietf.org/id/draft-ietf-core-observe-08.txt

��

����������� � ����������� �

�������� ��� ����� �����

����� ���������� ��

�� �� � �� �� ��

��� ����������������

�����������

�������� �� �

�����

�����

!�"������������#$����%&'())��*�+�

����������

Fig. 1. Framework Architecture

In order to support a semantic-based resource discovery,the CoAP protocol has been improved with a novel usageof standard URI-query options and with the addition ofnew ones. The CoAP-based SSN framework proposed hereextends the enhancements described in [7] enabling furthernon-standard inferences to support automated sensor discoveryand composition, representing one of the main novelties ofthe approach. However the resulting framework is still fullybackward compatible: servers which do not support semanticswill simply reply to requests returning no resource records.Semantic-based requests are led back to standard CoAP onesby introducing three novel attributes: (i) reference ontology(ro), containing the URI of the domain conceptualization; (ii)semantic description (sd), i.e., the annotated request, com-pressed to cope with the verbosity of XML-based languages;(iii) annotation-type (at), specifying the compression format.The reference geographical location is achieved by specify-ing lg (longitude) and lt (latitude) attributes. Furthermore,md (maximum distance) is used to indicate the maximumacceptable distance (in meters) from the reference locationfor retrieving resources. The adoption of a (center, distance)constraint allows the server to pre-filter resources, so avoidingpossibly expensive inference procedures for resources outsidethe requested area. Finally, each provided reasoning task de-voted to resource discovery is identified by a code, specified byst (semantic task) attribute. In addition to existing tasks, a newcode for sensor discovery based on Concept Covering [8] hasbeen added. Furthermore, a semantic threshold (sr) attributeis used to set a minimum score threshold. Resources havingan overall score w.r.t. the request lower than sr will not bereturned to the client. This allows to modulate the granularityof discovery and to limit data transfers when many resourcesare available. In replies to discovery, this field contains theoverall score of a resource w.r.t. the request.

B. Sensory data annotation

An explicative architecture of the proposed frameworkis depicted in Figure 1. A CoAP-based SSN is composedby several sensors deployed in a given area communicatingthrough a local sink node, acting as cluster head, with agateway interfacing the network toward the rest of the world.Each sensor is featured by data-oriented attributes, as usual,but also by a semantic annotation describing its characteristicsand functions. Sink nodes will: (i) allow sensors to register

528

their semantic description as a CoAP resource and (ii) embeda lightweight matchmaker [9] enabling ontology-based infer-ences on annotated metadata. Devices within the SSN can beaccessed through:- CoAP clients, able to exploit a semantic-based discovery tosearch for sensors or actuators according to their annotations,and get raw data and/or event descriptions via standard CoAPprimitives;- Remote applications, based on different wireless protocols,e.g., IEEE 802.11b/p and usually getting high-level eventdescriptions from the SSN for further processing tasks.

In a Semantic Web of Things vision, each system device orclient application produces large amounts of data which haveto be collected and interpreted to extract useful application-oriented information. This is the case of event detection where(semi) automatic procedures are strongly required. In a CoAP-based SSN, each sink device collects data and process themfor detecting events; when done, a dedicated resource recordis updated by adding a semantic description. The record willalso contain extra-logical contextual parameters such as atimestamp and geographic information about the monitoredarea. In the proposed framework a simple and effective datamining process has been devised in order to annotate thesensor audit. After detection, the sink and/or the CoAP gatewaywill wait for resource discovery requests coming from clientapplications searching for dedicated sensors in the area.

The procedure for identification of sensory events viasurveys comprises several stages:1) Data are read from sensors in the field through standardCoAP GET requests, possibly using Observe option to benotified of updates. Then a list of elements is built, consistingof three fields: ID, storing the identifier of the sensor andtherefore the type of data; value, containing the detected data;timestamp. This list will group measurements in time slotsof application-defined period T , used to compute statisticalindexes.2) For each data set, average, variance and standard deviationvalues are computed for the current time slot, to assess thevariability of collected information within the monitored area.3) Statistical indexes of elapsed periods are then exploited tocompute an incremental ratio to evidence trends and significantevent changes inside the monitored area.4) For every data collection, the application defines a binary ormultiple classifier, to reveal a situation when given conditionsoccur (see the Section III for an implementation): the identi-fication is performed by taking into account threshold valuesfor statistical indexes.5) The output of each classifier is a logic-based expressionmapped according to knowledge modeled in the reference on-tology. The final semantic description is the logical conjunctionof all derived expressions.

It is important to note that semantic-enhanced CoAP dis-covery per se does not impose restrictions on where datamining happens, whether in clients running the applicationlogic, in sink nodes or in sensors having processing capabilitiesenough. In the approach proposed here mining and eventdetection are executed at sink level after sensors send datavia standard CoAP frames.

C. Resource discovery via Concept Covering

The basic CoAP resource discovery protocol only allowsa syntactic string-matching of attributes, lacking every explicitand formal characterization of the resources semantics. Due tothis reason, advanced discovery services should be adoptedto improve protocol capabilities. They should allow to: (i)rank resources w.r.t. a request and (ii) identify also partialcorrespondences between a request and device descriptions,very frequent in practical scenarios involving heterogeneousresources. In [6], framework and algorithms were proposedfor a logic-based matchmaking between a request and one ormore resource descriptions, both expressed using languagesgrounded on a well known logic. Description Logics (DL)[10] was the reference formalism and particularly the ALN(Attributive Language with Unqualified Number Restrictions)DL subset was adopted, having a well-known polynomialcomputational complexity for standard and non-standard in-ferences. Particularly, the Concept Abduction Problem (CAP)[11] resolution was exploited in [7] to enhance the CoAPdiscovery capabilities. It allowed to determine, given a requestD and a resource S, what should be hypothesized in S in orderto completely satisfy D also enabling a logic-based relevanceranking of S w.r.t. D.

In addition to CAP, here we propose a further enhancementof the discovery protocol to support a slightly refined versionof the Concept Covering [8] inference. Such a reasoning taskis devoted to select a minimum set of resources best coveringa request. That is, given a request D and a set of resources S= {S1, S2, ..., Sk}, where D and S1, S2, ..., Sk are satisfiablew.r.t. the ontology T , the Concept Covering Problem (CCoP)resolution aims to find a pair 〈Sc, H〉 where Sc includesconcepts in S (partially) covering D w.r.t. T and H is the(possible) part of D not covered by concepts in Sc. Thealgorithm 1 reported hereafter is applied to request and sensorannotations. A compatibility check is performed to verify if thesensor si (from the set S) is a cover for the request (line 7).Then the CAP is solved (line 8) to determine what is missingin the sensor description, in order to completely satisfy therequest. Afterwards a rank value is computed via the followingutility function:

rank (D,Hi) = 100 ∗[1− s match (D,Hi) ∗

(1 +

distance (P, si)

md

)]

where s match measures the CAP-induced semantic distance[11] between D and a description Hi; the geographical dis-tance of the sensor si from the reference point P (definedby the attributes lt and lg), normalized by user-specifiedmaximum distance (attribute md), is combined as weightingfactor. Finally, the sensor with the highest rank (Smax) isselected and moved from S to Sc (lines 17-18) and thepart of D covered by Smax is removed from the startingrequest (line 19). The algorithm will return the set of sensorsbest covering the request, along with the uncovered part, ifpresent. Such non-standard inference service is particularlyuseful in semantic-based Internet of Things scenarios, e.g.,sensor network, where it is needed to gather data from differentkind of sensors to infer proper events.

A toy example should clarify both structure and contentof request and reply messages in the semantic-enhancedvariant 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 := D3: repeat4: Rmax := 05: Smax := �6: for all si ∈ S do7: if (si �D) is satisfiable in T and si is a cover for D then8: Hi := solveCAP (〈L, T D, si〉)9: R := rank(D,Hi)

10: if R > Rmax then11: Rmax := R12: Smax := si13: end if14: end if15: end for16: if Smax = � then17: Sc := Sc ∪ Smax

18: S := S − Smax

19: H := H \ {Smax}20: end if21: until Smax = �22: return Sc, H

voluntarily omitted here for the sake of clarity. Let us supposean application addresses a discovery request toward a SSNsink at the 193.204.59.75 IP address to find a set of sensorsmost suitable for a task expressed in OWL/RDF languagew.r.t. SSN-XG ontology (gzip compressed). The applicationis interested only in sensors located within 800m from the(41.079769, 16.763571) coordinates. The application willtherefore send a GET CoAP request to:coap://193.204.59.75:5683/.well-known/core?

&ro=SSN-XG-IRI&sd=yyyyyy=&at=30004&lg=16.763571

&lt=41.079769&md=800&st=2&sr=70

Upon received the request, the CoAP server will start amatchmaking process comparing it w.r.t. all stored annotationsreferred to the same ontology. The semantic matchmakingis carried out by solving CCoP, in order to find the set ofresources best covering the request and what elements of therequest are lacking in the retrieved sensor list. Let us supposethat the returned set is composed of two sensors matchingthe above request. The discovery reply payload sent by theCoAP server will be:</Hts2030HumidSens>;ct=0;ct=41;at=30004;lg=16.768277;

lt=41.077286;md=480;ro=SSN-XG-IRI;sd=aaaaaaa;

title="Humidity-Sensor-2030",

</BitLineAnemomSens>;ct=0;ct=41;at=30004;lg=16.758347;

lt=41.081983;md=500;ro=SSN-XG-IRI;sd=bbbbbbb;

title="Anemometer-Sensor-111",

</H>;sd=ccccccc;sr=9.12

In case of a partial cover, the response can also include (inaddition to the sensor list) both the semantic description ofthe uncovered part (H) of the request and a ranking valuecorresponding to the percentage of request not covered. Thisvalue is obtained comparing H w.r.t. the starting request bymeans of semantic-based ranking algorithms [11].

Fig. 2. JOSM plugin for CoAP-based SSNs

D. Framework architecture

Two novel prototypical CoAP clients have been developedto enable an advanced sensor discovery through a visual userinterface. Communication with sensors has been implementedusing a modified version of Californium CoAP library [12],extended with the semantic-based enhancement described inSection II-A. The first one is a plugin for the open sourceJOSM8 application: a screenshot of the prototype GUI isshown in Figure 2. Thanks to an easily understandable inter-face, the proposed tool can be used to perform the followingtasks in a graphical way:- SSN browsing. A geographic area of interest can be down-loaded from the OpenStreetMap server. Available sensors,registered on CoAP sinks, can be shown on the map on theleft panel (A);- Semantic-based sensor discovery. A semantic-based CoAPrequest can be sent to discover sensors in the environment. Theright panel (C) allows to customize the request by means ofthe features described in Section II-A. Particularly, a referencelocation point can be selected by clicking on the map. Then itis possible to choose the task to perform (e.g., discovery viaConcept Covering), the outcome threshold and the maximumdiscovery range. Finally, the semantic description can becomposed by simply selecting (with drag-and-drop operations)from the UI panel (B) properties and classes defined in thereference ontology.

A mobile client for smartphones was also devised to enablethe communication between SSNs and Android-based devices.The client was developed using Android SDK Tools, Revision21.1, corresponding to Android Platform version 4.2.2 (APIlevel 17), and tested on an off-the-shelf smartphone9. Also inthis case, the client can be used either to browse the SSN orto perform an advanced sensor discovery. The user can selecta sink node and view all connected sensors or only devicesretrieved after a semantic-based discovery, as shown in Figure3(a). By selecting a sensor, it is also possible to see its detailsas in Figure 3(b) and its location on the map (see Figure 3(c)).Then, each device can be queried to retrieve data it measures,as reported in Figure 3(d).

8Java OpenStreetMap (OSM) editor, http://josm.openstreetmap.de/9Samsung GT-i9250 Galaxy Nexus with ARM Cortex A9 Dual Core CPU

at 1.2 GHz, 1 GB RAM, 16 GB internal memory, and Android version 4.2.2

530

(a) Discovery results (b) Sensor details

(c) Sensor location (d) Method selection

Fig. 3. Mobile client - Sensor discovery

In addition to classic CoAP messages, a semantic-basedCoAP request can be composed by filling the query attributesas in Figure 4(a). For each attribute, the user must specifya value. As an example, Figure 4(b) shows the selectablevalues for the Content-Type attribute. In addition, the semanticdescription is completed by selecting (drawing in the lists inFigure 4(c) and 4(d)) properties and classes extracted from thereference ontology.

III. CASE STUDY: ENVIRONMENTAL RISK MONITORING IN

VANETS

In order to show the benefits of the proposed approach, inwhat follows a simple case study in the field of environmentalmonitoring is reported. The scenario is configured as a Vehic-ular Ad-Hoc Network (VANET), an application-oriented net-work solution for safety and emergency information delivery.By exploiting Vehicle-to-Infrastructure (V2I) wireless com-munication technologies, each vehicle approaching dangerousroad sections receives safety warnings and traffic informationfrom deployed Road-Side Units (RSUs). Particularly, we focuson Hybrid Sensor and Vehicular Networks (HSVNs), whichmerge VANETs and WSNs. In HSVNs, sensors are distributed

(a) CoAP query attributes (b) Content types list

(c) Concepts list (d) Properties list

Fig. 4. Mobile client - Attributes settings

along a road to monitor and gather information about theweather conditions of a given area. In the proposed scenario,each RSU acts as a CoAP gateway and periodically queries theCoAP sinks in its range. Afterward sinks select suitable sensorsby means of a logic-based resource discovery and return tothe RSU the most appropriate device set. The RSU can nowquery the sensors to obtain raw data and exploits data mining,as described in Section II-B, to detect a meteorological event.Event annotations are then exposed for external applications, inthis case vehicles warned about detected events by the RSUs.

Each sensor is able to measure one or more parame-ters (e.g., temperature, humidity, atmospheric pressure, windspeed), with specific measurement capabilities (e.g., accu-racy, precision, resolution, frequency) defined in the samereference ontology. The SSN-XG ontology cited above wasextended to enable sensor descriptions as conjunctive conceptexpressions. Figure 5 shows an example of temperature sensormodeling. The Stimulus-Sensor-Observation design pattern [5]was exploited to describe the measuring features of a sensor,with some differences. A sensor can “observe” propertiesmodeled as subclasses of ssn:FeatureOfInterest andhas proper measurement capabilities expressed as subclasses

531

Device Measurement Capabilities

Description Device Type Visibility TemperatureOperativeRange

Pressure Wind Speed Humidity

Request (D) SensorLowAcc.LowFreq.

LowRes., LowAcc.HighLatency

LowMediumAltitude

LowAcc., MediumRes.MediumRes.

MediumAcc., LowPrec.MediumAcc., MediumRes.

HighFreq.

SE95Sensor TemperatureSensor

-HighAcc., HighFreq.HighRange, HighRes.

MediumHighAltitude

- - -

LM70Sensor TemperatureSensor

-LowAcc., MediumFreq.

HighRangeLowMedium

Altitude- - -

Hts2030Sensor HumiditySensor

- - - - -MediumAcc., HighFreq.MediumRes., HighRange

BitLineBLVSensor AnemometerSensor

- - - -MediumAcc., LowRes.MediumRes., LowPrec.

-

BMP085Sensor BarometerSensor

- - -LowAcc., MediumRes.LowRange, LowPrec.

- -

FS11Sensor VisibilitySensor

LowAcc.LowRangeLowFreq.

- - - - -

Uncovered (US2) - -LowRes.,

HighLatency- - - -

TABLE I. REQUEST AND SENSORS DESCRIPTIONS

���������������� ���� �������������������������������������������

���������������

������������������

� !������������������

����������� ���������������������

��� !����������� ���������������������

��������������

����"��������

����������"��������

����� ����������"��������

����#�����$���

����%��������

�������&������

����'�(�������$���

��)��*'�(�������$���

'�(����

)��*��������'�(����

"��������+,�#%+���

�-�������������� �-��������������

�-��������������

�-��������������

�-��������������

�-��������������

�-�������������� �-��������������

�-�������������� �-��������������

�-��������������

�-��������������

����*������������

����*�� ���������������������

����*���������"��������

����*�� �����������"��������

������������

�-��������������

����������$��#�����

����*�������$���#�����

�-��������������

Fig. 5. Temperature sensor modelling

of the ssn:MeasurementCapability class. In turn, eachspecific subclass of ssn:MeasurementCapability hasa set of measurement properties and (optional) operatingrange, represented as subclasses of the ssn:Propertyclass. Furthermore, a sensor is related to a subclass ofssn:EnergyDevice through the ssn:hasSubSystemproperty to model its energy source.

Let us suppose a car is driving in the morning on theSS96, a highway near to Bari in Italy. The road presents alow-flowing with a poor traffic density (90 vehicles per hour).Possible dangers are due to several crossroads. To show in agraphical way the results of processing tasks described above,the JOSM plugin presented in Section II-D is used. As shownin Figure 6, the car is riding near to the RSU1. The gatewaycomposes a discovery request D, using concepts defined in thedomain ontology, as described in Table I10. The CoAP GETrequest also includes three query parameters: (i) RSU referencelocation P , defined through the attributes lt and lg; (ii) themaximum distance d from P , defining the area where sensorsmust be located; (iii) the minimum threshold t, to retrieve onlydevice sets with a covering percentage score higher than t. Inparticular, RSU1 looks for devices located near to SS96 with amaximum distance of 800m from P and a coverage thresholdvalue of 90%. After a distance-based filtering, each sink node

10For the sake of readability, concept expressions for both request andsensors are summarized in textual form.

near to RSU1 receiving the request –i.e., S1 and S2– solves theCCoP, as described in Algorithm 1, exploiting the embeddedreasoning engine [9]. S1 and S2 return the set of compatibleresources 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, arereported in Table I. Sc(S2) –the covering set retrieved by S2–is composed by LM70Sensor, Hts2030Sensor, BMP085Sensor,BitLineBLVSensor and FS11Sensor. Nevertheless, as reportedin the pie chart in Figure 6, this set does not fully coverthe 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 featuresin terms of temperature measurement capabilities. Instead, S1returns a second set of sensor Sc(S1) with an uncovered partequals to the 9.10% of D. In this case, Sc(S2) is better thanSc(S1) so the first set is selected.

Now RSU1 can query/observe sensors that composeSc(S2) to acquire data for the meteorological events detection.For example, let us suppose that, after a period of observation,the mining process produces the following average valuesfor the gathered parameters: sea level temperature 7.09°C;temperature between 0÷599 m 1.98°C; relative humidity80.52%; wind speed 19.69 km/h; atmospheric pressure 971.51mbar; visibility 254.38 m. Based on studies and laws onmeteorological event detection, a classifier able to detect one ofthe weather conditions reported in Table II has been designed.

Meteorological eventParameter Fog Wind Rain Snow

temp 0 m (°C) - - ≥6 -

temp 0÷599 m (°C) t− td ≤4 - - ≤5

temp 600÷1499 m (°C) - - - 5÷10

temp ≥1500 m (°C) - - - ≤0

visibility(m) ≤1000 - - -

wind speed (km/h) - ≥100 - -

humidity (%) - - 80÷100 -

pressure (mbar) - - 970÷1000 -

td: dew point temperatureTABLE II. CRITERIA FOR METEOROLOGICAL EVENT DETECTION

In the example, the classifier identifies Fog and Rain eventsEach detected event is annotated w.r.t. the reference ontologyas subclass of the Weather concept. This high level semantic-based characterization of the weather conditions becomes a

532

Fig. 6. Covering result

query for further matchmaking processes based on the envi-ronmental conditions. In the proposed case study, RSU1 waitsfor vehicles equipped with a wireless interface that come intoits radio range. Each vehicle will send a semantic descriptioncontaining main characteristics of its safety devices. Let ussuppose that the following vehicles, described in DL formalismhereafter, drive nearby RSU1:

BMWX5 ≡ V ehicle � SUV � ∃ hasSpeed �∀ hasSpeed.(ModerateSpeed) � ∃ hasLamp �∀ hasLamp.(XenonLamp � FogLamp) � ∃ hasSecureDevice �∀ hasSecureDevice.(ABS � ESP ) � ∃ hasPneumatic �∀ hasPneumatic.(SnowTire).

AudiA3 ≡ V ehicle � Sedan � ∃ hasSpeed �∀ hasSpeed.(HighSpeed) � ∃ hasLamp � ∀ hasLamp.(FogLamp) �∃ hasSecureDevice � ∀ hasSecureDevice.(ABS) �∃ hasPneumatic � ∀ hasPneumatic.(TraditionalT ire).

Fiat600 ≡ V ehicle � EconomyCar � ∃ hasSpeed �∀ hasSpeed.(HighSpeed) � ∃ hasLamp �∀ hasLamp.(Headlight) � ∃ hasPneumatic �∀ hasPneumatic.(TraditionalT ire).

RSU1 will perform a matchmaking task between a vehicledescription and previously detected events, each annotated interms of safety requirements a car must adopt to limit risksfor that weather conditions:Fog ≡ Weather � ∃ hasSpeed � ∀ hasSpeed.(ModerateSpeed) �∃ hasLamp � ∀ hasLamp.(FogLamp) � ∃ hasSecureDevice �∀ hasSecureDevice.(ABS).

Rain ≡ Weather � ∃ hasSpeed � ∀ hasSpeed.(ModerateSpeed) �∃ hasPneumatic � ∀ hasPneumatic.(RibbedT ire) �∃ hasSecureDevice � ∀ hasSecureDevice.(ABS � ESP ).

Finally, for each pair vehicle/event, RSU1 exploits therankPotential [11] algorithm and returns a Rank Value (RV)representing the risk level: very low (0 ≤ RV ≤ 1), low(RV = 2), medium (RV = 3), high (4 ≤ RV ≤ 5), very high(RV = 6), ultra high (RV ≥ 7). As reported in Table III, theBMW is the the safest vehicle, because it is equipped withsnow tyres (also useful in case of rain), fog lamps, ABS andESP. The Audi has higher risk levels due to its medium-highspeed that contributes in a significant way to increase the risklevel, despite of ABS and fog lamps activated. A high speedand inadequate safety features make the Fiat 600 absolutelyunsuitable.

BMW X5 Audi A3 Fiat 600RVFog very low (1) low (2) very high (6)RVRain very low (1) high (4) ultra high (7)

TABLE III. RISK LEVELS FOR DETECTED EVENTS

IV. RELATED WORK

CoAP [3] is a protocol similar to HTTP devoted tointerconnect objects, exploiting a binary data representationand a subset of HTTP methods. It follows the REST (REp-resentational State Transfer) paradigm for making data andresources accessible. Analogously, 6LoWPAN [2] is a protocolfor WSNs defined to enable IPv6 packets to be carried on topof low power wireless networks, specifically exploiting IEEE802.15.4 protocol. Both 6LoWPAN and CoAP use UDP fordata transport, as TCP is considered too resource-consuming.6LoWPAN can be interfaced to IPv6 and CoAP/UDP toHTTP/TCP, so that sensor data can be accessed from the Web.Particularly CoAP is assuming relevance for its lightweightimpact on storage and computation, resulting useful for avariety of application domains [13], [14].

In latest years, some interesting SSN approaches weredeveloped to integrate WSNs and smart objects with theSemantic Web. Existing architectures largely vary in scope butusually aim to: (i) exploit reference ontologies –e.g., OntoSen-sor [15] and SSN-XG– to annotate data, devices and services;(ii) share sensor data along the Linked Open Data (LOD) [16]guidelines and by means of RESTful [17], [18] and OGC’sSensor Web Enablement (SWE) [19] web service interfaces.Particularly, Sense2Web [20] proposed a LOD-based platformto publish sensor data and link them to existing resource on theSemantic Web. Different sensor data ontologies were used todescribe physical resources, query data and relations to obtainimplicit information and integrate sensor data coming fromvarious sources. Similarly, SPITFIRE [21] combines semanticand networking technologies to build a service infrastructureaiming to develop semantic applications exploiting Internet-connected sensors and lightweight protocols, as CoAP. In suchframework, sensors are described via RDF triples and servicediscovery is based on meta-data retrieval (device featuresor location). In [22] the Linked Stream Middleware (LSM)platform was proposed to integrate sensor data with otherLOD sources, by enriching both sensor sources and sensor datastreams with semantic descriptions. A processing engine wasused to perform SPARQL queries across both dataset types,mashup the data and process results. Tran et al. [23] propose anapplication to automatically compose sensor features and mea-sures. In particular user goals, functional and non-functionalproperties of sensors are described w.r.t. an OWL ontologyso that the composition system is able to combine sensorsand processes to satisfy a user request. In [24] ontology-basedsensor descriptions allow the users to express requests in termsof device characteristics. Quantitative reasoning and semanticquerying techniques were employed to improve the resourcediscovery and select appropriate sensors.

Unfortunately, the above solutions only allow elementaryqueries in SPARQL fragments on RDF annotations and thenonly basic resource discovery features are allowed. Ontology-based complex event processing [25] and semantic matchmak-ing [6] can be used to improve data management and sensordiscovery in mobile and pervasive contexts (see [26], [27],[28]) exploiting logic-based reasoning to support approximatedmatches, resource ranking and explanation of outcomes. In [7]a novel SSN framework was defined complying such theoret-ical approach, based on a backward-compatible extension ofCoAP resource discovery, employing non-standard inference

533

services [11] for retrieving and ranking resources.

V. CONCLUSION

The paper proposed a novel framework for the SemanticWeb of Things, based on a backward-compatible CoAP exten-sion supporting flexible resource description, management anddiscovery via logic languages and inference services. A casestudy in a VANET scenario allows to test both feasibility andeffectiveness. An implementation of the presented approach ina large testbed with off-the-shelf devices is ongoing. Futurework includes the extension of the underlying logic towardEL/EL++ (in order to increase allowed expressiveness ofresource and request descriptions) as well as the integrationof specialized compression algorithms for Semantic Web lan-guages [1] to reduce storage and network load.

ACKNOWLEDGMENT

The authors acknowledge partial support of Italian PONproject RES NOVAE and POR project UbiCare.

REFERENCES

[1] F. Scioscia and M. Ruta, “Building a Semantic Web of Things:issues and perspectives in information compression,” in Semantic WebInformation Management (SWIM’09). In Proceedings of the 3rd IEEEInternational Conference on Semantic Computing (ICSC 2009). IEEEComputer Society, 2009, pp. 589–594.

[2] N. Kushalnagar, G. Montenegro, and C. P. Schumacher, “IPv6 overLow-Power Wireless Personal Area Networks (6LoWPANs): Overview,Assumptions, Problem Statement, and Goals,” RFC Editor, Fremont,CA, USA, RFC 4919, Aug. 2007.

[3] C. Bormann, A. Castellani, and Z. Shelby, “Coap: An applicationprotocol for billions of tiny internet nodes,” Internet Computing, IEEE,vol. 16, no. 2, pp. 62–67, 2012.

[4] D. Guinard and V. Trifa, “Towards the Web of Things: Web Mashupsfor Embedded Devices,” in Workshop on Mashups, Enterprise Mashupsand Lightweight Composition on the Web (MEM 2009), in proceedingsof WWW (International World Wide Web Conferences), Madrid, Spain,2009.

[5] M. Compton, P. Barnaghi, L. Bermudez, R. Garcia-Castro, O. Corcho,S. Cox, J. Graybeal, M. Hauswirth, C. Henson, A. Herzog et al., “TheSSN ontology of the W3C semantic sensor network incubator group,”Web Semantics: Science, Services and Agents on the World Wide Web,vol. 17, pp. 25–32, Dec. 2012.

[6] S. Colucci, T. Di Noia, A. Pinto, A. Ragone, M. Ruta, and E. Tinelli,“A Non-Monotonic Approach to Semantic Matchmaking and RequestRefinement in E-Marketplaces,” International Journal of ElectronicCommerce, vol. 12, no. 2, pp. 127–154, 2007.

[7] M. Ruta, F. Scioscia, G. Loseto, F. Gramegna, A. Pinto, S. Ieva, andE. Di Sciascio, “A logic-based CoAP extension for resource discoveryin semantic sensor networks,” in 5th International Workshop on Seman-tic Sensor Networks (SSN 2012), ser. CEUR Workshop Proceedings,C. O. Henson C., Taylor K., Ed., vol. 904. CEUR-WS, nov 2012, pp.17–32.

[8] A. Ragone, T. Di Noia, E. Di Sciascio, F. M. Donini, S. Colucci, andF. Colasuonno, “Fully Automated Web Services Discovery and Compo-sition through Concept Covering and Concept Abduction,” InternationalJournal of Web Services Research (JWSR), vol. 4, no. 3, pp. 85–112,2007.

[9] M. Ruta, F. Scioscia, E. Di Sciascio, F. Gramegna, and G. Los-eto, “Mini-ME: the Mini Matchmaking Engine,” in OWL ReasonerEvaluation Workshop (ORE 2012), ser. CEUR Workshop Proceedings,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 UniversityPress, 2002.

[11] M. Ruta, E. Di Sciascio, and F. Scioscia, “Concept Abduction andContraction in Semantic-based P2P Environments,” Web Intelligenceand Agent Systems, vol. 9, no. 3, pp. 179–207, 2011.

[12] M. Kovatsch, S. Mayer, and B. Ostermaier, “Moving Application Logicfrom the Firmware to the Cloud: Towards the Thin Server Architecturefor the Internet of Things,” in Proceedings of the 6th InternationalConference on Innovative Mobile and Internet Services in UbiquitousComputing (IMIS 2012), Jul. 2012.

[13] W. Colitti, K. Steenhaut, N. De Caro, B. Buta, and V. Dobrota, “RESTEnabled Wireless Sensor Networks for Seamless Integration with WebApplications,” in 8th IEEE International Conference on Mobile Adhocand Sensor Systems (MASS 2011), 2011, pp. 867–872.

[14] A. Dimitrios, G. Vasileios, G. Dimitrios, and C. Ioannis, “EmployingInternet of Things technologies for building automation,” in 17th IEEEConference on Emerging Technologies & Factory Automation (ETFA2012), 2012, pp. 1–8.

[15] D. J. Russomanno, C. R. Kothari, and O. A. Thomas, “Building a SensorOntology: A Practical Approach Leveraging ISO and OGC Models,” inThe 2005 International Conference on Artificial Intelligence, 2005, pp.637–643.

[16] C. Bizer, T. Heath, and T. Berners-Lee, “Linked data-the story sofar,” International Journal on Semantic Web and Information Systems(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 Symposiumon. IEEE, 2010, pp. 362–370.

[18] S. Mayer and D. Guinard, “An extensible discovery service for smartthings,” in 2nd International Workshop on Web of Things, ser. WoT ’11.New York, NY, USA: ACM, 2011, pp. 7:1–7:6.

[19] A. Broring, P. Maue, K. Janowicz, D. Nust, and C. Malewski,“Semantically-enabled sensor plug & play for the sensor web,” Sensors,vol. 11, no. 8, pp. 7568–7605, 2011.

[20] P. Barnaghi, M. Presser, and K. Moessner, “Publishing Linked SensorData,” in Proceedings of the 3rd International Workshop on SemanticSensor Networks, 2010.

[21] D. Pfisterer, K. Romer, D. Bimschas, O. Kleine, R. Mietz, C. Truong,H. Hasemann, M. Pagel, M. Hauswirth, M. Karnstedt et al., “SPITFIRE:Toward a Semantic Web of Things,” Communications Magazine, IEEE,vol. 49, no. 11, pp. 40–48, 2011.

[22] D. Le-Phuoc, H. Q. Nguyen-Mau, J. X. Parreira, and M. Hauswirth,“A middleware framework for scalable management of linked streams,”Web Semantics: Science, Services and Agents on the World Wide Web,vol. 16, pp. 42–51, Nov. 2012.

[23] K.-N. Tran, M. Compton, and R. G. Jemma Wu, “Semantic SensorComposition,” in 3rd International Workshop on Semantic Sensor Net-works. Proceedings of the 9th International Semantic Web Conference(ISWC 2010), ser. CEUR Workshop Proceedings, D. R. D. Taylor K.,Ayyagari A., Ed., vol. 668. CEUR-WS, nov 2010, pp. 33–48.

[24] C. Perera, A. Zaslavsky, P. Christen, M. Compton, and D. Georgakopou-los, “Context-aware Sensor Search, Selection and Ranking Model forInternet of Things Middleware,” in IEEE 14th International Conferenceon Mobile Data Management (MDM 2013), jun 2013, to appear.

[25] K. Taylor and L. Leidinger, “Ontology-driven complex event processingin heterogeneous sensor networks,” The Semanic Web: Research andApplications, pp. 285–299, 2011.

[26] M. Ruta, T. Di Noia, E. Di Sciascio, and F. Donini, “Semantic-EnhancedBluetooth Discovery Protocol for M-Commerce Applications,” Interna-tional Journal of Web and Grid Services, vol. 2, no. 4, pp. 424–452,2006.

[27] M. Ruta, F. Scioscia, T. Di Noia, and E. Di Sciascio, “A hybrid Zig-Bee/Bluetooth approach to mobile semantic grids,” Computer SystemsScience and Engineering, vol. 25, no. 3, pp. 235–249, May 2010.

[28] R. De Virgilio, E. Di Sciascio, M. Ruta, F. Scioscia, and R. Torlone,“Semantic-based RFID Data Management,” in Unique Radio Innovationfor the 21st Century: Building Scalable and Global RFID Networks.Springer, 2011, pp. 111–142.

534