Main restraints curbing a deep integration of Semantic Sensor Networks with complex and articulated architectures, basically reside in too elementary allowed discovery capabilities. Several studies agree advanced querying and retrieval mechanisms are needed to truly fulfill the potential of the SSN paradigm. This paper presents a novel SSN framework, supporting a resource discovery grounded on semantic-based matchmaking. Offered contributions are: a backward-compatible extension of Constrained Application Protocol (CoAP) resource discovery; data mining exploitation to detect high-level events from raw data; employment of non-standard inference services for retrieving and ranking resources; adoption of W3C standard SSN-XG ontology to annotate data, events and device features. The effectiveness of the proposed approach is motivated by a case study regarding fire risk prevention and air conditioning control in a university building.
Typically, Wireless Sensor Networks (WSNs) only include homogeneous sensors
and are application-dependent and engineering-oriented [
In latest years, main research studies have shifted toward the integration of
SSNs with the Internet and World Wide Web, following the Internet of Things
and (Semantic) Web of Things visions [
In this paper a novel SSN framework is proposed, enabling semantic-based
annotation and discovery, by adapting formalisms and technologies borrowed from
Semantic Web and Internet of Things research. Data streams, sensors and
actuator devices, objects and subjects, high-level events and services can be connoted
by a description having a well defined meaning w.r.t. a shared domain
conceptualization (i.e., ontology). The proposal is based on slight backward-compatible
extensions to CoAP and CoRE Link Format1 resource discovery protocol for
sensor and actor networks. A simple and computationally efficient data mining
component permits to detect and annotate high-level events from raw data
collected from sensing devices in the field. The SSN-XG ontology of W3C (World
Wide Web Consortium) [
The remainder of the paper is organized as follows. In Section 2 relevant related work is briefly surveyed. The proposed discovery framework is thoroughly outlined in Section 3, also providing details about CoAP extensions and event mining. Section 4 reports on a case study about fire risk prevention and air conditioning control in a university building, in order to highlight features of the proposed approach; finally Section 5 closes the paper. 2
SSN frameworks are based on reference ontologies to annotate data, devices
and services. Many ontology proposals exist, largely varying in aim and scope.
OntoSensor [
1 June 2012, http://www.ietf.org/id/draft-ietf-core-link-format-14.txt
From the infrastructure perspective, some interesting protocols are assuming relevance for their lightweight impact on storage and computation. Particularly, CoAP [14] is an alternative to HTTP for interconnected objects, exploiting a binary data representation and a subset of HTTP methods (GET, PUT, POST, DELETE). It follows the REST paradigm for making data and resources accessible. Both 6LoWPAN and CoAP use UDP for 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.
Recent projects, such as Sense2Web [15] and SPITFIRE [16], combine
semantic and networking technologies to build full frameworks, but only allow
elementary queries in SPARQL3 fragments on RDF4 annotations. More effective
techniques such as ontology-based complex event processing [17] and
semantic matchmaking [
Finally, a not negligible related issue is the verbosity of XML-based ontological languages, which calls for devising and implementing efficient compression techniques needed to cope with WSN scenarios, characterized by low throughput of wireless links and strict processing, memory and energy limitations of devices. When evaluating encoding algorithms for such contexts, compression ratio is not enough: processing/memory requirements and efficiency of queries on compressed data become critical parameters, too. High-compression generalpurpose approaches such as the PAQ family [22] or XML-specific ones like XMill [23] do not offer the best trade-off. The EXI W3C standard (Efficient XML Interchange, http://www.w3.org/XML/EXI/) exploits some basic ideas of XMill, while adding several optimizations. Specific experimental algorithms for the Semantic Web of Things, such as DIGcompressor and COX [24], aim at either maximum compression ratio or high query efficiency, while keeping the computational costs low. 3
In what follows the approach we present will be thoroughly described, particularly detailing the proposed CoAP enhancements as well as the semantic matchmaking framework adopted for event mining and resource discovery.
http://www.w3.org/TR/rdf-sparql-query/
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ 3.1
Following the REST architectural style, CoAP adopts a loosely coupled client/server model, based on stateless operations on resource representations [14]. Every resource is a server-controlled abstraction, unambiguously identified by a URI (Uniform Resource Identifier). Clients access resources via synchronous request/response interactions, using HTTP-derived methods GET, PUT, POST, and DELETE (basically mapping the fundamental Read, Create, Update and Delete operations of data management).
CoAP messages are encoded in a simple binary format. A message consists of a 32-bit header followed by option fields in Type-Length-Value (TLV) format and a payload. The header determines the request method (or response status) and the number of options. Possible request methods, option types and response statuses are distinguished by means of binary codes, listed in CoAP specification5. Some CoAP options are derived from HTTP header fields (e.g., content type, headers for conditional requests and proxy support), while some other ones have no counterpart in HTTP. In particular, the target resource URI for a CoAP request (which must refer to the coap or coaps scheme) is split in a Uri-Host, a Uri-Port (default UDP port is 5683) and a Uri-Path option, with one Uri-Query option for each field in the query URI portion. If an option value is longer than 270 B, it is split in consecutive option fields of the same type. Moreover, the Observe option6 allows a client to register w.r.t. the server as an observer of the resource, so that the server will notify the client of further changes to the resource state automatically, without the need of polling. This capability is lacking in HTTP; it was introduced in CoAP specifically for scenarios like WSNs, where data have to be monitored over a time span.
In CoAP-based WSN scenarios, each sensor is basically seen as a server, exposing both sensor readings and internal information as resources toward clients, which act on behalf of end-user applications. Different data series will be identified by distinct URIs. Further URIs will identify sensor device status and operating parameters; clients will be able to read or modify them as appropriate. For example, a temperature sensor S can expose the latest temperature reading at the URI coap://[S-address]/temperature; in order to access it, a client should issue a GET request with Uri-Host=S1-address and Uri-Path=/temperature options. In case of success, it will receive status code 2.05 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 of a set of (possibly more constrained) sensor nodes deployed in an area, exploiting caching and decreasing the load at the edge of the network. This feature allows also the adoption of data fusion and mining techniques at vari
ing Group Internet-Draft, latest version: 11, http://www.ietf.org/id/draft-ietf-core-coap-11.txt
ing Group Internet-Draft, latest version: 5, 12 http://tools.ietf.org/id/draft-ietf-core-observe-05.txt CoRE 16
July CoRE March
Work2012, Work2012, ous levels along the path from sensors in the field to nodes managing high-level application logic.
Resource discovery is needed to know what resources a given CoAP server is making available. The CoAP discovery protocol is defined in the CoRE Link Format specification. It allows any host to expose its resources, as well as to act as a directory service for other hosts that want to register their resources. A client will access the reserved URI path /.well-known/core on the server with POST method to register a resource, or with GET to discover available ones. GET requests can include URI-query fields to retrieve only resources with specific attributes. Standardized query attributes include: – href (hypertext reference): a regular expression to filter resources based on their path (e.g., “/temperature” or “/temperature/*”); – type (media type): MIME (Multipurpose Internet Mail Extensions) type/subtype for the resource; – rt (resource type): an opaque string representing an application-specific meaning of a resource (e.g., “outdoor-temperature”); – if (interface description): an opaque string used to provide a name or a URI which indicates what operations can be performed on the resource and their meaning; it typically references a machine-readable document.
Further non-reserved attributes can be freely used. Response payload consists of a comma-separated list of resource paths, each having optionally a list of semicolon-separated attributes. 3.2
As evident, CoAP resource discovery protocol only allows a syntactic
stringmatching of attributes, lacking every explicit and formal characterization of the
resources semantics. In [
Sensor Networks basically produce large amounts of raw data which have to be collected and interpreted to extract application-oriented information. This is particularly relevant in case of event detection where (semi) automatic procedures are strongly required. The proposed framework includes a simple and resource-efficient data mining process, distributed along several steps and aimed at a semantic-based event annotation from low-level data audit. Each sink device in the SSN collects data from sensors in the field and analyzes them. Whenever an event is detected, a dedicated CoAP resource record is updated by adding a semantic description. The record will also contain extra-logical context parameters such as a timestamp and geographic information about the monitored area (coordinates and size). After detection, the sink will serve as a CoAP gateway, waiting for resource discovery requests coming from client applications searching for either: (a) sensors needed to detect events in the area or (b) actuators that can effectively act upon a given detected event.
As said, the procedure for identification of sensory events via surveys comprises several stages. 1. Data are read from sensors in the field through standard CoAP GET requests, possibly using Observe option to be notified of updates. Then a list of elements is built, consisting of three fields: ID, storing the identifier of the sensor and therefore the type of data; value, where the detected data is stored; timestamp. This list will group measurements in time slots of application-defined period T , which are used to compute statistical indexes. 2. For each data set, the average, variance and standard deviation values are computed for the current time slot, to assess the variability of collected information within the monitored area. 3. Statistical indexes of elapsed periods are then exploited to compute an incremental ratio able to evidence trends and significant event changes inside the monitored area. 4. For every data collection, the application defines a binary or multiple classifier, to reveal a situation when given conditions occur. In fact identification is performed by taking into account threshold values for statistical indexes (see Table 2 in the case study section for an extensive explanation). 5. The output of each classifier is mapped to a logic-based expression according to knowledge modeled in the reference ontology. The final semantic description is produced by composing the logical conjunction of all expressions.
S A
S
Sink 1
S Sink 2
S
Sink 3
A S
S
S
A Client (application)
It is important to note that semantic-enhanced CoAP discovery per se does not impose restrictions on where data mining happens, whether in clients running application logic, in sink nodes or in sensors having processing capabilities enough. These three main SSN configurations can even be combined according to application or environmental requirements. 3.4
The basic SSN architecture is depicted in Figure 1. Each group of sensors and
actuators deployed in a given area will communicate through a local sink node,
acting as a cluster head for resource-constrained devices in the field.
Particularly, sink nodes will: (i) allow sensors/actuators to register their semantic
annotation as CoAP resources and (ii) embed a lightweight semantic matchmaker
[27]. Local or remote applications are CoAP clients and: (i) use semantic-based
discovery to search for sensors or actuators, based on annotated descriptions of
their properties and capabilities and produced data; (ii) get raw data and/or
event descriptions via standard CoAP primitives. The SSN-XG ontology [
In order to support the novel semantic-based resource retrieval, slight extensions were devised to the CoAP discovery protocol outlined in Section 3.1. They are based only on an innovative usage of standard URI-query options and on the addition of new ones. Consequently, the resulting framework is still fully backward compatible: servers which do not support semantics will simply reply to requests returning no resource records.
When receiving a request, a CoAP server will start a matchmaking process
comparing it w.r.t. all stored annotations referred to the same ontology. The
semantic matchmaking is carried out by executing CAP non-standard inference
between request and each resource description, in order to find what elements of
the request are lacking in the retrieved resource. A normalized semantic distance
in the [
At the moment, 1 is assigned to CAP. – sr (semantic threshold): this new attribute is used in discovery requests to specify a minimum score threshold. Resources having an overall score w.r.t. 7 Efficient XML Interchange, http://www.w3.org/XML/EXI/ the request lower than this threshold will not be returned to the client. This allows to modulate the granularity of discovery and to limit data transfers when many resources are available. In replies to discovery, this field contains the overall score of a resource w.r.t. the request. – lg (longitude) and lt (latitude): they are two novel and optional attributes (expressed in degrees). Within a request, they specify a reference geographical location in order to measure distances of discovered resources and grade matchmaking outcomes; in replies or registrations they simply express the resource location. – md (maximum distance): in a request it indicates the maximum acceptable distance (in meters) from the reference location set with the pair < lg, lt >. The adoption of a (center,distance) constraint allows the server to pre-filter resources, so avoiding the relatively expensive semantic matchmaking for resources outside the requested area. In replies, the attribute is used to specify the actual distance of a resource from the reference location.
Some toy examples will clarify both structure and content of registration, request and reply messages in the semantic-enhanced variant of CoAP protocol. Semantic annotations will be voluntarily omitted here for the sake of clarity: several examples will be provided in the case study report in Section 4.
Registration. A sensor acting as a CoAP server wants to expose a resource representing its own features and capabilities. The corresponding semantically annotated description is expressed in OWL/RDF language w.r.t. SSN-XG ontology and compressed with gzip. The sensor has (latitude,longitude) coordinates of (41.109, 16.878). The sensor will therefore issue a POST CoAP request to: coap://localhost:5683/.well-known/core?rt=xxxxxx &ro=http://purl.oclc.org/NET/ssnx/ssn&at=30004&lg=16.878<=41.109
Discovery request. An application queries an SSN sink having 193.204.59.75 IP address to find sensors best matching a semantic description expressed in OWL/RDF language w.r.t. Ontosensor ontology and compressed with gzip. The application is interested only in sensors located within 100m from the location at (41.1566734, 16.884755) coordinates. Furthermore, it sets a score threshold of 70% to retrieve only good matches. The application will therefore send a GET CoAP request to: coap://193.204.59.75:5683/.well-known/core? &ro=http://www.memphis.edu/eece/cas/onto sensor/OntoSensor.txt &rt=yyyyyy=&at=30004&lg=41.1566734<=16.884755&md=100&st=1&sr=70
Discovery reply. Let us suppose that two sensors match the above request. The CoAP server response payload will be: </HumidSens204>;ct=0;ct=41;at=30004;lg=41.1566735;lt=16.884754; md=19.4;ro=http://www.memphis.edu/eece/cas/onto sensor/OntoSensor.txt; rt=aaaaaaa;sr=76.4;title="Humidity-Sensor-204", </HumidSens111>;ct=0;ct=30004;lg=41.1566732;lt=16.884756; md=60.9;ro=http://www.memphis.edu/eece/cas/onto sensor/OntoSensor.txt; rt=bbbbbbb;sr=82.1;title="Humidity-Sensor-111"
In what follows, illustrative examples are presented to better explain flexibility and potentialities our approach provides and to let its novelty emerge. The proposed enhancement has been applied and tested in two different case studies: (i) fire risk prevention; (ii) air conditioning. Both focused on an environment composed of three rooms of the Technical University of Bari equipped with several devices. All of them refer to one or more sink nodes representing the interface of the SSN toward external applications. The CoAP server runs on a sink node based on Android 2.3.3 platform. It is able to accept GET/POST messages –for example a sensor discovery request– and send responses to clients. For our experiments the Californium CoAP framework [28] was extended with the semantic-based enhancement proposed in Section 3.4. Copper plugin [29] for Firefox was used to simulate the requests coming from applications.
Device arrangement is shown in Figure 2: the rooms contain different kinds
of sensors –in green– and actuators –in red. Sensor and actuator descriptions are
represented by conjunctive concept expressions referring to the same ontology,
which extends SSN-XG [
The first scenario refers to disaster prevention, focusing on discovering possible fire risks in given areas. Thanks to a continuous monitoring of sensed parameters, possible hazards can be quickly detected and recovery procedures rapidly started to take danger under control for both people and structures. The first step is to discover sensors in the environment able to monitor useful data. Application-defined sensor requirements play the role of “request” and the device descriptions the ones of “supplied resources”. Let us suppose a temperature sensor is needed in room C with a large measurement range –able to take both low and high values of temperature–, a medium sampling frequency and low accuracy and resolution –temperature changes quickly during a blaze, so high accuracy and resolution are not required. At the same time, the application requires that sensor has a battery with medium lifetime. Using concepts defined in the domain ontology the request can described as follows: (R1)FireRisk Request ≡ T emperatureSensor ⊓ ∃ hasMeasurementCapability ⊓ ∀ hasMeasurementCapability.( ∃ hasMeasurementP roperty ⊓ ∀ hasMeasurementP roperty.(HighMeasurementRange ⊓ MediumF requency ⊓ LowAccuracy ⊓ LowResolution)) ⊓ ∃ hasSubSystem ⊓ ∀ hasSubSystem.(Battery ⊓ ∀ hasSurvivalP roperty.(MediumBatteryLifetime)).
!!"#$%"!&"'(%)&*%+ /L9!#!.425-!!89+ <%03%/-1./%$%"!=/+
/L9!#!.425-!!89+ >,?@<%03%/-1./%$%"!=/+ !!"#I-!$.4!6!1%0+ A-"-!="&*JK>BDJ>2+ /L9!#!.425-!!89+ /L9!#!.425-!!89+
F-G%/6+ /L9!#!.425-!!89+ !!"#;"%/'6(%)&*%+ H&'I>&9%<&0%F-G%/6+ !!"#I-!$./)&)-5A/=3%/16+ 7-5H)4"I(",'J4",$-+,") *A) *D) *?)
!" *C) 5A) 5?) #" *B) *E) 3--%)
Fig. 3. Temperature sensor modeling
Notice that a sensor could also have more subsystems. In that case, related features are conjunctive concept expressions in the filler of the hasSubSystem property. With reference to contextual query attributes in the GET request, let us suppose to select devices positioned in Room C with a maximum distance of 25m from the reference location P and a threshold discovery score of 65%. The sink acts as a CoAP gateway w.r.t. deployed sensors. It executes a preprocessing step to exclude components outside the user-specified range. Hereafter the concept expressions for some of the sensor instances inside the measurement area in Figure 2 are summarized. (S1)TSic306TemperatureSensor ⊑ T emperatureSensor ⊓ ∃ hasMeasurementCapability ⊓ ∀ hasMeasurementCapability.(T sic306T emperatureMeasurementCapability) ⊓ ∃ hasSubSystem ⊓ ∀ hasSubSystem.(EnixEnergies RS 689).
Tsic306TemperatureMeasurementCapability ≡ ∃ hasMeasurementP roperty ⊓ ∀ hasMeasurementP roperty.(MediumResolution ⊓ HighAccuracy ⊓ MediumF requency ⊓ LowMeasurementRange ⊓ MediumP recision).
EnixEnergies RS 689 ⊑ Battery ⊓ ∀ hasSurvivalP roperty.(LowBatteryLifetime). (S2)LM70TemperatureSensor ⊑ T emperatureSensor ⊓ ∃ hasMeasurementCapability ⊓ ∀ hasMeasurementCapability.(LM70T emperatureMeasurementCapability) ⊓ ∃ hasSubSystem ⊓ ∀ hasSubSystem.(P anasonic V RLA LC).
LM70TemperatureMeasurementCapability ≡ ∃ hasMeasurementP roperty ⊓ ∀ hasMeasurementP roperty.(LowResolution ⊓ LowAccuracy ⊓ MediumF requency ⊓ HighMeasurementRange).
Panasonic VRLA LC ⊑ Battery ⊓ ∀ hasSurvivalP roperty.(HighBatteryLifetime). (S3)SE95TemperatureSensor ⊑ T emperatureSensor ⊓ ∃ hasMeasurementCapability ⊓ ∀ hasMeasurementCapability.(SE95T emperatureMeasurementCapability) ⊓ ∃ hasSubSystem ⊓ ∀ hasSubSystem.(P hilips F R 6LB).
SE95TemperatureMeasurementCapability ≡ ∃ hasMeasurementP roperty ⊓ ∀ hasMeasurementP roperty.(HighResolution ⊓ HighAccuracy ⊓ HighF requency ⊓ HighMeasurementRange).
Philips FR 6LB ⊑ Battery ⊓ ∀ hasSurvivalP roperty.(MediumBatteryLifetime). (S4)MX6GasSensor ⊑ GasSensor ⊓ ∃ hasMeasurementCapability ⊓ ∀ hasMeasurementCapability.(MX6GasMeasurementCapability) ⊓ ∀ hasSubSystem.(P anasonic V RLA LC) ⊓ ∃ hasSubSystem.
MX6GasMeasurementCapability ≡ ∀ hasMeasurementP roperty.(HighResolution ⊓ MediumAccuracy ⊓ HighF requency ⊓ MediumP recision) ⊓ ∃ hasMeasurementP roperty.
For each device annotation, the sink node apply CAP resolution w.r.t. R1 in order to evidence requested capabilities missing in the device structure. For example, S2 has a different battery lifetime w.r.t. the request, therefore it is a nearly full match. On the contrary, S3 refers to a different type of sensor and does not match the required resolution, accuracy and frequency constraints. H(R1,S2) ≡ ∀ hasSubSystem.( ∀ hasSurvivalP roperty.(MediumBatteryLifetime)). H(R1,S3) ≡ ∀ hasMeasurementCapability.( ∀ hasMeasurementP roperty.(MediumF requency ⊓ LowAccuracy ⊓ LowResolution)).
Afterwards, the sink replies to the client request with the list of suitable sensors in relevance order. The arrangement score is computed via the following utility function: f (R, S) = 100 ∗ 1 − s match (R, S) s match (R, ⊤) ∗ 1 + distance (R, S) d where s match measures the CAP-induced semantic distance between a request R and resource description S; this value is normalized dividing by the semantic distance between R and the universal concept –Top or Thing– which depends only on axioms in the ontology. Geographical distance –normalized by userspecified maximum range d– is combined as weighting factor. The top results ID URI S2 /sink/LM70TemperatureSensor S3 /sink/SE95TemperatureSensor S1 /sink/TSicTemperatureSensor S4 /sink/MX6GasSensor of discovery are reported in Table 1. Sensor S2 has the best rank because its description is very similar to the request, in fact it has a semantic distance of 0.050. Nevertheless, its final score is about 90% because it is 20m far from the reference location P .
Now the application can select sensors to query/observe; subsequently it can apply mining procedures on retrieved data –as explained in Section 3.3– and even detect risk events. For example, let us suppose that temperature sensor S2, having a f = 0.5Hz sampling rate, produces the following data point series in Celsius degrees: (22.3, 22.5, 25.5, 29.4, 38.7, 49.3, 60.4, 75.5). Let us also suppose the fire prevention application adopts an observing window T = 8s. Then the following data mining steps are executed: – Data are divided in N = f T = 4-sample blocks: B1 = (22.3, 22.5, 25.5, 29.5); B2 = (38.7, 49.3, 60.4, 75.5). – Average, variance and standard deviation are computed: μ1 = 24.9; σ12 = –8.3In;cσr1em=en3t.3a;l rμa2ti=o i5s6.ΔΔ0f;t σ=22 μ=t−1μ8t7−.19;thσe2r=efo1r5e.8Δ.temp = 56.0−24.9 = 3.9.
T Δt 8 – Based on studies and laws on fire risk prevention, we designed a classifier able to detect one of the five common fire stages, reported in Table 2. In the example, the classifier detects that fire propagation is occurring in the environment. It is useful to point out that the example just used the average temperature for the sake of clarity; in the case study, temperature variance, relative humidity, CO and CO2 concentrations are also taken into account.
The event description then becomes a query for the actuator discovery phase. In this way, the application can find all devices able to prevent a given dangerous event or perform recovery procedures. Each actuator can be modeled defining, in addition to operating specification, also the context description that, if verified, should lead to an activation. Different kinds and stages of fire events have been modeled mainly through temperature, extension, propagation speed and toxicity parameters. For example, detection of a propagation event can be characterized by high temperature, moderate extension, low propagation speed and moderate toxicity. In such case, actuator request and fire suppressor devices can be described as:
ID URI A2 /sink/FireSuppressionTypeB A1 /sink/FireSuppressionTypeA
Distance Semantic Rank Final Rank 11.01 m 0.000 100.00 % 5.41 m 0.150 81.75 % The paper proposed a novel SSN framework, supporting logic-based matchmaking of meaningful and semantically rich event/device/resource annotations via simple and backward-compatible CoAP extensions. Peculiarities of the proposed solution have been outlined w.r.t. a case study showing its benefits.
Future work includes a thorough experimental campaign on a large testbed, in order to accurately evaluate performance issues, the integration of novel nonstandard inferences (such as Concept Contraction and Concept Covering), to make semantic matchmaking even more detailed as well as the extension of underlying logic toward E L/E L++ for increasing allowed expressiveness of resource and request descriptions.
The authors acknowledge partial support of EU ECTP 2012-14 project “GAIA: Generalized Automatic exchange of port Information Area”. 12. Patni, H., Henson, C., Sheth, A.: Linked Sensor Data. In: Collaborative Technologies and Systems (CTS), 2010 International Symposium on, IEEE (2010) 362–370 13. Page, K., De Roure, D., Martinez, K., Sadler, J., Kit, O.: Linked Sensor Data: RESTfully serving RDF and GML. Proceedings of the 2nd International Workshop on Semantic Sensor Networks (2009) 49–63 14. Bormann, C., Castellani, A., Shelby, Z.: Coap: An application protocol for billions of tiny internet nodes. Internet Computing, IEEE 16(2) (2012) 62–67 15. Barnaghi, P., Presser, M., Moessner, K.: Publishing Linked Sensor Data. In: Proceedings of the 3rd International Workshop on Semantic Sensor Networks. (2010) 16. Pfisterer, D., Romer, K., Bimschas, D., Kleine, O., Mietz, R., Truong, C., Hasemann, H., Pagel, M., Hauswirth, M., Karnstedt, M., et al.: SPITFIRE: Toward a Semantic Web of Things. Communications Magazine, IEEE 49(11) (2011) 40–48 17. Taylor, K., Leidinger, L.: Ontology-driven complex event processing in heterogeneous sensor networks. The Semanic Web: Research and Applications (2011) 285–299 18. Ruta, M., Di Noia, T., Di Sciascio, E., Donini, F.: Semantic-Enhanced Bluetooth Discovery Protocol for M-Commerce Applications. International Journal of Web and Grid Services 2(4) (2006) 424–452 19. Ruta, M., Scioscia, F., Di Sciascio, E.: Mobile Semantic-based Matchmaking: a fuzzy DL approach. The Semantic Web: Research and Applications (2010) 16–30 20. Ruta, M., Scioscia, F., Di Noia, T., Di Sciascio, E.: A hybrid ZigBee/Bluetooth approach to mobile semantic grids. Computer Systems Science and Engineering 25(3) (May 2010) 235–249 21. De Virgilio, R., Di Sciascio, E., Ruta, M., Scioscia, F., Torlone, R.: Semanticbased RFID Data Management. In: Unique Radio Innovation for the 21st Century: Building Scalable and Global RFID Networks. Springer (2011) 111–142 22. Mahoney, M.: Adaptive Weighing of Context Models for Lossless Data Compression. Technical report, Florida Tech. Technical Report CS-2005-16, 2005 23. Liefke, H., Suciu, D.: Xmill: an efficient compressor for xml data. SIGMOD Rec.
29(2) (2000) 153–164 24. Scioscia, F., Ruta, M.: Building a Semantic Web of Things: issues and perspectives in information compression. In: Semantic Web Information Management (SWIM’09). In Proceedings of the 3rd IEEE International Conference on Semantic Computing (ICSC 2009), IEEE Computer Society (2009) 589–594 25. Baader, F., Calvanese, D., Mc Guinness, D., Nardi, D., Patel-Schneider, P.: The
Description Logic Handbook. Cambridge University Press (2002) 26. Ruta, M., Di Sciascio, E., Scioscia, F.: Concept Abduction and Contraction in Semantic-based P2P Environments. Web Intelligence and Agent Systems 9(3) (2011) 179–207 27. Ruta, M., Scioscia, F., Di Sciascio, E., Gramegna, F., Loseto, G.: Mini-ME: the Mini Matchmaking Engine. In Horrocks, I., Yatskevich, M., Jimenez-Ruiz, E., eds.: OWL Reasoner Evaluation Workshop (ORE 2012). Volume 858 of CEUR Workshop Proceedings., CEUR-WS (2012) 52–63 28. Kovatsch, M., Mayer, S., Ostermaier, B.: Moving Application Logic from the Firmware to the Cloud: Towards the Thin Server Architecture for the Internet of Things. In: Proceedings of the 6th International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS 2012). (July 2012) 29. Kovatsch, M.: Demo Abstract: Human-CoAP Interaction with Copper. In: Proceedings of the 7th IEEE International Conference on Distributed Computing in Sensor Systems (DCOSS 2011). (June 2011)