With the growing popularity of Internet of Things (IoT) technologies and sensors deployment, more and more cities are leaning towards the initiative of smart cities. Smart city applications are mostly developed with aims to solve domain-speci c problems. Hence, lacking the ability to automatically discover and integrate heterogeneous sensor data streams on the y. To provide a domain-independent platform and take full bene ts from semantic technologies, in this paper we present an Automated C omplex E vent I mplementation S ystem (ACEIS), which serves as a middleware between sensor data streams and smart city applications. ACEIS discovers and integrates IoT streams in urban infrastructures for users' requirements expressed as complex event requests, based on semantic IoT stream descriptions. It also processes complex event patterns on the y using semantic data streams.
An increasing number of cities have started to embrace the idea of smart cities and are in process of building smart city infrastructure for its citizens. Such infrastructures, including the deployment of sensors, provision of open data platforms and smart city applications, can improve the day to day life for the citizens. A typical example of smart city applications is the provision of real-time tracking and timetable information for the public transport within the city1. City of Aarhus provides an open data platform called ODAA2, which contains city related information generated by various sensors deployed within the city, e.g., tra c congestion level, air quality and trash-bin level etc. ODAA also encourages usage of their open data platform for building smart city applications. In the foreseeable future, more and more urban data will be made available. The enormous amount of the data produced by sensors in our day to day life need to be harnessed to help smart city applications taking smart decisions on the y.
However, the uptake of smart city applications is hindered by various issues,
such as di culty of discovering the capabilities of the available infrastructure
and once discovered, integrating heterogeneous data sources and extracting
upto-date information in real-time. The smart city data needs to be integrated from
various domains in a federated fashion. Integrated information should be further
processed, aggregated and higher-level abstractions should be created from the
data to make it suitable for complex event processing in real-time. Existing
semantic service discovery and composition approaches (e.g., WSMO3,
OWLS4) are based on Input, Output, Precondition and E ect. They are not suitable
for describing complex event processing services with event patterns. Moreover,
IoT streams are inherently dynamic and resource constrained. Providing support
for quality-aware distributed event systems consuming IoT streams is still a
challenge [
In this paper, we present ACEIS, which is an automated discovery and integration system for urban data streams. We design a semantic information model to represent complex event services and utilize this information model for the discovery and integration of sensor data streams. ACEIS assumes that all available sensor data streams are annotated using Semantic Sensor Network (SSN)5 and stored in a repository. Various Quality of Service (QoS) and Quality of Information (QoI) metrics are also annotated for each sensor data stream. ACEIS receives an event service request described using our complex event service information model and automatically discovers and composes the most suitable data streams for the particular event request. ACEIS then transforms the event service composition into a stream query to be deployed and executed on a stream engine to evaluate the complex event pattern speci ed in the event service request. The contributions of this paper can be summarised as below: We present an Automated Complex Event Implementation System serving as a middleware between Smart City applications and sensor data streams. We introduce an information model (Complex Event Service Ontology) and demonstrate its usage in describing semantic event services and service requests.
We elaborate the mechanisms for QoS-aware discovery and integration of semantic event services.
We implement an automatic query transformation system to formulate continuous queries over semantic sensor data streams.
Structure of the Paper: In Section 2, we lay the foundations of our study by identifying various types of sensor data streams and challenges faced by smart city applications while using these sensor data streams. We presented a conceptual architecture of our proposed system (ACEIS) in Section 3. Detailed description of the sensor data streams discovery and integration is provided in Section 4. Section 5 discusses our automated query transformation algorithm.We 3 Web Service Modeling Ontology: http://www.wsmo.org/ 4 OWL-S ontology: http://www.w3.org/Submission/OWL-S/ 5 SSN ontology: http://www.w3.org/2005/Incubator/ssn/ssnx/ssn positioned our work by comparing it with state of the art in Section 6 before concluding in Section 7. 2
In this section, rstly, we discuss di erent types of sensor data streams which can be potentially utilized by the smart city applications and later we discuss the requirements and challenges faced by these smart city applications. 2.1
Sensors are nowadays part of our every day life. IoT technologies not only provide an infrastructure for the sensor deployment but also provide a mechanism for better communication among these sensors. Data being produced by these sensors is enormous and there is a strong need to tame these data streams and build applications to take smart decision by performing analysis of these data streams in real-time. Data streams produced by various sensors can be categorised into three di erent categories: Physical Sensors: Various sensors are being deployed by city administration with an aim to closely observe and monitor the city infrastructure. Tra c congestion, air quality, temperature, water pressure and trash bin level sensors are few examples of the sensors deployed within most of the modern cities. Additionally, various sensors are being deployed in buildings (e.g. airports, train stations) to detect critical events happened therein.
Mobile and Wearable Sensors: Contrary to the physical sensors deployed by city administrations and organizations, sensors attached to mobile devices provide additional information about the context of their carrier. Nowadays, a modern smart phone, owned and carried by majority of the citizens in the smart cities is equipped with 10 to 15 sensors on average, including location, temperature, light and proximity sensors. Modern cars also contain plenty of sensors to continuously monitor the performance as well as to provide assistance to the users. Many wearable sensors are gaining popularity and many people are adopting to the use of wearable sensors particularly in the health care domain.
deployed by integrating multiple physical sensors and provide a cost e ective alternative. Social media data streams can also be considered as virtual sensors. Social media data streams are a major source of information in smart city infrastructure and mostly provide latest information about the city events, e.g. Twitter feeds can provide latest information about the city events like accident and trafc jams etc. Although, trust, reliability and provenance are major concerns over the information arising from social media streams, but various social streams analysis methods have been already developed to overcome these concerns. 2.2
Smart city applications face many challenges because of highly distributed and dynamic nature of the IoT infrastructures deployed in the smart cities. Below we discuss few of the requirements and challenges faced by smart city applications. Federation of heterogeneous data streams: Data Federation combines heterogeneous sets of data to provide a uni ed view. In the context of smart city data, data federation is a key challenge due to the dynamicity and heterogeneity of various IoT streams. Querying and accessing the data in many cases will require real-time (or near-real-time) discovery and access to the streams (and their data) and the ability to integrate di erent kinds of heterogeneous streaming data from various sources. Smart city frameworks should provide mechanisms to (i) seamlessly integrate real world data streams, (ii) automated search, discovery and federation of data streams, and (iii) adaptive techniques to handle fail-overs at run-time.
not only require to e ciently process large scale IoT streams but also need e cient methods to perform data analytics in dynamic environment by aggregating, summarizing and abstracting sensor data on demand. Current analytic frameworks have to be evaluated for applicability in the smart city environment and the impact on privacy has to be taken into account.
Real-time IoT information extraction, event detection and stream reasoning: Smart city applications should be able to process event streams in a real time, extract relevant information and identify values that do not follow the general trends. Beyond the identi cation of relevant events, extraction of high level knowledge form heterogeneous, multi-modal data streams is an important component of IoT. Existing stream reasoning techniques use background knowledge and streaming queries to reason over data streams. Current techniques of stream reasoning do not cater to the needs of IoT due to the lack of proper treatment of uncertainty (e.g. possible reasons of tra c jam vs. most probable reason of tra c jam) in the IoT environment.
quality issues and provenance play an important role in smart city scenarios. Smart city frameworks should provide methods and techniques (i) to evaluate accuracy, trustworthiness, and provenence of IoT streams, (ii) to resolve con icts in case of contradictory information, and (iii) continous monitoring and testing to dynamically update QoI and trustworthiness.
QoI/QoS
Stream Description Data Mgmt, Indexing, Caching
ACEIS Core
Resource Management Data Federation
Query Results
Event Request
Resource Discovery Event Service Composer
Composition Plan Subscription Manager Query Transformer
Query Engine Semantic Annotation
Adaptation
Manager Constraint Validation Constraint Violation Data Store
IoT Data Stream
Social Data
Stream To address the data stream federation and (partially) reliable information processing challenges identi ed in Section 2.2 , various solutions are developed and integrated into ACEIS. We will discuss brie y the functionalities of the components in ACEIS as well as their interactions. Figure 1 illustrates the architecture view of ACEIS. The architecture consists of three main components: Application Interface, Semantic Annotation and ACEIS Core component. The application interface interacts with end users as well as ACEIS core modules. It allows users to provide inputs required by the application and presents the results to the user in an intuitive way. It also augments the users' queries, requirements and preferences with some additional, implicit constraints and preferences determined by the application domain or user pro le. For example, in a travel navigation scenario, a user may specify only the start and target location on the map, with a constraint on the travel time t, because she needs to get there on time. The application may add some additional constraints on the Primitive
Event Service 2
Complex Event Service 1 Event Stream 1 Event Stream 2
Event Engine
Event Pattern
Complex
Event Service 2 Complex
Event Service 3 IoT data streams used to calculate the travel time, such as the frequency of the data streams should be more than 1=t, otherwise the user may not receive any updates on the tra c condition during her trip and the detour suggestions for tra c jams will never happen.
These augmented user inputs are transformed into a semantically annotated complex event service request (event request for short). The event request is consumed by ACEIS core components to discover and integrate urban streams w.r.t. the functional and non-functional constraints speci ed within the event request. 3.2
The semantic annotation component receives IoT/data streams (e.g., ODAA realtime tra c sensors data6) as well as static data stores (e.g., ODAA tra c sensors metadata7) as inputs. It annotates syntactical information with semantic terms de ned in ontologies. The outputs of semantic annotation will be semantic IoT/data streams and static semantic data stores.
With semantic annotations of both static resource and dynamic data, ACEIS gains additional data interoperability both at design time for event service discovery/composition and at runtime for semantic event detection. 3.3
The ACEIS core module serves as a middleware between low level IoT data streams and upper level Smart City applications. ACEIS core is capable of discovering, composing, consuming and publishing complex event processing capabilities as reusable services. We call these services (primitive or complex) event services. An example of event service network is shown in Figure 2. ACEIS core consists of two major components: resource management and data federation. In the following, we introduce their functionalities and interactions. 6 Realtime Tra c Data in Aarhus: http://ckan.projects.cavi.dk/dataset/ bliptrack-alpha/resource/d7e6c54f-dc2a-4fae-9f2a-b036c804837d 7 Tra c Sensor Metadata: http://ckan.projects.cavi.dk/dataset/ bliptrack-alpha/resource/e132d528-a8a2-4e49-b828-f8f0bb687716 Resource Management The resource management component is responsible for discovering and composing event services based on static service descriptions. It receives event requests generated by the application interface containing users' functional/non-functional requirements and preferences, and creates composition plans for event requests, specifying which event services are needed to address the requirements in event requests and how they should be composed.
Resource management component contains two sub-components: resource
discovery component and event service composer. The resource discovery
component uses conventional semantic service discovery technique to retrieve IoT
services delivering primitive events. It deals with the primitive event requests
speci ed within event requests. The event service composer creates service
composition plans to detect the complex events speci ed by event requests based
on event patterns. We refer readers to [
Data Federation The data federation component is responsible for implementing the composition plan over event service networks and process complex event logics using heterogeneous data sources. The composition plan is rstly used by the subscription manager which will make subscriptions to the event services involved in composition plan. Later, the query transformer transforms the semantically annotated composition plan into a set of stream reasoning queries to be executed on a stream query engine.
The query transformer produces two kinds of stream queries: regular event queries that detect the complex events speci ed by event requests and constraint validation queries that monitor the constraints speci ed in event requests. Thus the query engine produces two kinds of results: (i)event query results are forwarded to the application interface and (ii)constraint violations are detected by constraint validation queries and sent to the adaptation manager. Adaptation manager decides whether an automatic adaptation is possible. If so, it creates and deploys a new composition plan that conforms with the constraints to replace the existing one. Otherwise, dispatches a noti cation to there application interface. 4
In this section, the ontology used for describing event services and event requests are presented, the discovery and integration mechanism for the sensor data streams are discussed. 4.1
A Complex Event Service (CES) ontology is developed to describe event services and requests. CES ontology is an extension of OWL-S. OWL-S is a standardized ontology to describe, discover and compose semantic web services. Figure 3 illustrates the overview of CES ontology. An event service is described with a Constraint
hasConstraint EventRequest hasPreference Preference hasWeight xsd:double QosWeight Preference rdf:_x (contains)
PrimitiveEvent
Service rdf:_x (contains) Pattern
hasPattern rdf:_x (contains) Namespaces: default: <http://www.insight-centre.org/ces#> rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> owls: <http://www.daml.org/services/owl-s/1.2/Service.owl#> owls-sp: <http://www.daml.org/services/owl-s/1.2/ServiceParameter.owl#> EventService ComplexEven
tService owls:presents EventProfile
owls:ServiceProfile owls-sp:serviceParameter owls-sp:ServiceParameter hasNFP
NFP Legend:
Class Object property subClassOf
Data property Grounding and an EventPro le. The concept of Grounding in OWL-S informs an event consumer, how to access the event service by providing information on service protocol and message formats etc. An EventPro le is comparable to the ServicePro le in OWL-S, which describes the events transmitted by the service.
An Event Pro le describes a type of event with a Pattern and Non-Functional Properties (NFP). A Pattern describes the correlations between a set of member events involved in the pattern. An event pattern may have other patterns or (primitive) event services as sub-components, making it a tree structure. An event pro le without a Pattern describes a primitive event service, otherwise it describes a complex event service. NFP refers to the QoI and/or QoS metrics, e.g., precision, reliability, cost and etc, which are modelled as sub-classes of ServiceParameter in OWL-S.
An EventRequest is speci ed as an incomplete EventService description, without speci c bindings to the set of federated event services used by the requested complex event. Constraints can be speci ed by users to declare their requirements on the event pattern and NFPs in EventRequests. Preferences can be used to specify a weight between 0 to 1 over di erent quality metrics representing users' preferences on QoS metrics: higher weight indicate the user cares more on the particular QoS metric. 4.2
The task of sensor stream discovery is to nd candidate sensor services based on sensor service descriptions and request speci cations. A sensor stream is an atomic unit in IoT stream discovery and integration. It is described both as a PrimitiveEventService in CES ontology, as well as a Sensor device in SSN ontology. The CES ontology is mainly used to describe the non-functional aspects of sensor service requests/descriptions, including sensor event types, quality parameters and sensor service groundings. SSN ontology is used to describe the functional aspects, including ObservedProperties and FeatureOfInterest.
Listing 1. Tra c sensor service description
A sensor service description is denoted as sdesc = (td; g; qd; Pd; F oId; fd), where t is the sensor event type, g is the service grounding, qd is a QoS vector describing the QoS values, Pd is the set of ObservedProperties, F oId is the set of FeatureOfInterests and fd : Pd ! F oId is a function correlating observed properties with their feature-of-interests. Similarly, a sensor service request is denoted sr = (tr; qr; Pr; F oIr; fr; pref; C). Compared to sd, sr do not specify service groundings, qr represents the constraints over QoS metrics, pref represents the QoS weight vector specifying users' preferences on QoS metrics and C is a set of functional constraints on the values of Pr. sd is considered a match for sr i all of the following three conditions are true: { tr subsumes td, { qd sati es qr and { 8p1 2 Pr; 9p2 2 Pd =) T (p1) subsumes p2 ^ fr(p1) = fd(p2), where T (p) gives the most speci c type of p in a property taxonomy.
Listing 1 shows a snippet of a tra c sensor description in turtle syntax. The
trafc senosr monitors the estimated travel time, vehicle count and average vehicle
speed on a road segment. Listing 2 shows a snippet of an sensor service request
matched by the tra c sensor service. When the discovery component nds all
service candidates suitable for the request, a Simple-Additive-Weighting
algorithm [
Sensor stream discovery deals only with primitive event service discovery. To discover and integrate (composite) sensor streams for complex event service requests, the event patterns speci ed in the complex event service requests/descriptions need to be considered.
Listing 3. Complex event service request : SampleEventRequest a ces : EventRequest ;
owls : presents : SampleEventProfile . : SampleEventProfile rdf : type owls : EventProfile ; ces : hasPattern [ rdf : type ces :And , rdf : Bag ; rdf : _1 : locationRequest ; rdf : _2 : seg1CongestionRequest ; rdf : _2 : seg2CongestionRequest ; rdf : _4 : seg3CongestionRequest ; ces : hasWindow "5"^^ xsd : integer ]; ces : hasConstraint [ rdf : type ces : NFPConstraint ; ces : onProperty ces : Availability ; ces : hasExpression [ emvo : greaterThan "0.9"^^ xsd : double ]] , [ rdf : type ces : NFPConstraint ; ces : onProperty ces : Accuracy ; ces : hasExpression [ emvo : greaterThan "0.9"^^ xsd : double ]].
In the context of integrated sensor stream discovery and composition, the de nition of sensor stream description is extended to denote composite sensor stream descriptions Sd = (epd; Qd; G),where epd consists of a set of sensor stream descriptions sd and/or a set of composite sensor stream descriptions Sd0, and a set of event operators including Sequence, Repetition, And, Or, Selection, Filter and Window, qd is the aggregated QoS metrics for Sd and G is the grounding for the composite sensor stream. Similarly, a complex event service request is denoted as Sr = (epr; Qr; pref ), where epr is a canonical event pattern consisting of a set of primitive sensor service requests sr and a set of event operators, Qr describes the QoS constraints for the requested complex event service and pref speci es the weights on QoS metrics.
An Sd is a match for Sr i epd is semantically equivalent to epr and Qd
satis es Qr. When no matches are found during the discovery process for Sr, it
is necessary to compose Sr with a set of Sd and/or sd which are reusable to Sr.
Informally, these (composite) sensor streams describe a part of the semantics of
epr and can be reused to create a composition plan, which contains an event
pattern with concrete service bindings. The composition plan can be used as a
part of the event service description for the composed event service. The
discovery or composition results can be ranked w.r.t the QoS metrics and preferences
in the same way as sensor stream discovery. We refer readers to [
To implement a composition plan, the subscription manager needs to make subscriptions to the relevant event sources using the service bindings provided in the composition plan. Then, the query transformer creates (regular and constraint validation) stream reasoning queries and registers the queries at the stream engine. In this section, the algorithms for transforming regular queries are discussed.
In the current ACEIS implementation, CQELS[
Listing 4. Tra c sensor stream data : O b s e r v a t i o n _ 1 a ssn : O b s e r v a t i o n ; ssn : ob ser ve dB y : s a m p l e T r a f f i c S e n s o r ssn : o b s e r v e d P r o p e r t y [ a ces : E s t i m a t e d T i m e ]; ssn : f e a t u r e O f I n t e r e s t : FoI_1 ; ssn : o b s e r v a t i o n R e s u l t : o b s e r v a t i o n R e s u l t _ 1 . : o b s e r v a t i o n R e s u l t _ 1 ssn : hasValue [ ssn : h a s Q u a n t i t y V a l u e " `25" '^^ xsd : integer ;
muo : u n i t O f M e a s u r e m e n t muo : second ]. 5.1
To ensure the query transformation creates queries that detect the right event patterns, it is required to map the semantics of event operators to query operators. Each event service description sd or Sd in event patterns should map to a CQELS StreamGraphPattern (SGP)8 for the ssn:Observations transmitted in the event stream. A Sequence operator requires its sub-events to occur in a temporal order. Currently CQELS (version 1.0.0) do not provide functions to access the timestamps of the stream triples, therefore Sequence is not supported. 8 SGP is an extension of GraphPatternNotTriples in SPARQL 1.1 grammar, CQELS language grammar and examples available at: https://code.google.com/p/cqels/ wiki/CQELS_language Repetition is a generalization of sequence, it indicates a sequence pattern should be repeated several times, therefore it is also not supported. An And operator indicates all its sub-events should occur, it can be mapped to the Join operator. An Or operator indicates at least one of its sub-events should occur, it can be mapped to LeftOuterJoin operator in CQELS (OPTIONAL keyword) with bound lters. Selection is mapped to Projection in CQELS to select the message payloads for complex events. Filter and Window operators in event patterns can be mapped to Filter and Window operators in CQELS, respectively. Table 1 summarizes the semantics alignment between event operators and CQELS operators. Previously (see Section 4.1), we brie y described how event patterns are specied in CES ontology. An event pattern can be recursively de ned with sub event patterns and event service descriptions, thus formulating an event pattern tree. In this section we elaborate algorithms for parsing event pattern trees and creating CQELS queries. In an event pattern tree, the nodes can be either any of the following four types of event operators: Sequence,Repetition,And and Or, or other event service descriptions. The edges in the tree represent the provenance relation in the complex event detection: the parent node is detected based on the detection of the child nodes. Using a top-down traversal of the event pattern tree and querying the semantics alignment table for each event operator encountered during the traversal, the event pattern in the composition plan is transformed into a CQELS query following the divide-and-conquer style. Algorithm 1 shows the pseudo code of the main parts of query transformation algorithm.
Lines 1 to 6 in Algorithm 1, construct the CQELS query with three parts: a pre-de ned query pre x, a select clause derived from the getSelectClause() function and a where clause derived from the getWhereClause() function. Lines 7-27 de ne the getWhereClause() function in a recursive way. It takes as input the event pattern in the composition plan (Line 7) and nds the root node in the event pattern (Line 8). Then, it investigates the type of the root node: if it is a Sequence or Repetition operator, the transformation algorithm terminates, currently transformation cannot be applied for Sequence or Repetition because of the limitations of the underlying query language (CQELS) (Lines 9-10). If the root node is an event service description, a getSGP() function creates the Stream Graph Patterns (SGP) in CQELS (Lines 11-12) describing the triple patterns of the observations delivered by the event service, and this SGP is returned Algorithm 1 Transform event patterns into CQELS queries.
Require: Composition Plan: comp, Query Pre x String pref ixStr Ensure: CQELS Query String: queryStr 1: procedure transform(comp; pref ixStr) 2: selectClause getSelectClause(comp:ep) 3: whereClause getWhereClause(comp:ep) 4: queryStr pref ixStr + "SELECT " + selectClause + "W HERE" + whereClause 5: return queryStr 6: end procedure Require: Event Pattern: ep Ensure: Where Clause String: whereClause 7: procedure getWhereClause(ep) 8: root getRootNode(ep); whereClause ; 9: if root 2 Opseq [ Oprep then 10: fail and terminate 11: else if root 2 EventServiceDescription then 12: whereClause getSGP(ep; root) 13: else if root 2 Opand then 14: for subP attern getSubPatterns(ep; root) do 15: whereClause whereClause + getWhereClause(subP attern) 16: end for 17: else if root 2 Opor then 18: for subP attern getSubPatterns(ep; root) do 19: whereClause whereClause + "optional" + getWhereClause(subP attern) 20: end for 21: whereClause whereClause + getBoundFilters(ep) 22: end if 23: if f ilters getFilters(ep) 6= ; then 24: whereClause whereClause + getFilterClause(f ilters) 25: end if 26: return "f" + whereClause + "g" 27: end procedure as a (part of the) where clause. If the root node is an And or Or operator, the algorithm invokes itself on all sub-patterns of the root node and combines the where clauses derived from the sub-patterns (Lines 13-20). In addition, if the root is an Or operator, an OPTIONAL keyword is inserted for each where clause of the sub-pattern and a bound lter is created indicating at least one of the sub-patterns has bound variables (at least one sub-events occurs, Line 21). If there are lters speci ed in the event pattern, a getFilterClause() function is invoked to add the lter clauses to the where clause (Lines 23-25). Finally, the where clause is returned with a pair of brackets (Line 26). Listing 5 shows the transformation result for event request in Listing 3.
Listing 5. CQELS query example Select * Where { Graph < http :// purl . oclc . org / NET / ssnx / ssn #> {? ob rdfs : subClassOf ssn : Observation } Stream < locationStreamURL > [ range 5s] {? locId rdf : type ? ob . ? locId ssn : observedBy ? es4 .
? locId ssn : observationResult ? result1 . ? result1 ssn : hasValue ? value1 . ? value1 ct : hasLongtitude ? lon . ? value1 ct : hasLatitude ? lat . ? loc ct : hasLongtitude ? lon . } Stream < trafficStreamURL1 > [ range 5s] {? seg1Id rdf : type ? ob . ? seg1Id ssn : observedBy ? es1 . ? seg1Id ssn : observationResult ? result2 . ? result2 ssn : hasValue ? value2 .
? value2 ssn : hasQuantityValue ? eta1 .} Stream < trafficStreamURL2 > [ range 5s] {...} Stream < trafficStreamURL3 > [ range 5s] {...} } 6
Existing event noti cation services like SAS9 and WSN10 support only
publish and subscribe simple and syntactical events. Recent research on semantic
event processing endeavor to bring semantics to event speci cations. Semantic
event speci cations have more exibility and expressiveness compared to
syntactical ones[
Reusing event queries/subscriptions is also discussed in many other event
based systems, including content-based event overlay networks [
Although the above works in event overlay networks and query rewriting share some objectives to our work in terms of improving the network and event processing e ciency, this paper is di erent because 1) we do not focus on routing algorithms which are central parts of event overlay network research, all nodes in the event service network can host both event producers and consumers and they are visible to all other peers and 2) we do not re-order query operators in a 9 Sensor Alert Service: http://www.ogcnetwork.net/SAS 10 Web Service Noti cation: https://www.oasis-open.org/committees/tc_home.
php?wg_abbrev=wsn way such that cpu usage and latency can be minimized, which is central to query rewriting techniques. Instead, we develop means to create event service compositions based on the semantic equivalence and reusability of event patterns, and then composition plans are transformed into a set of federated stream reasoning queries, enabling a semantic complex event processing over distributed service networks. 7
In this paper, we have identi ed several challenges for Smart City applications. We presented ACEIS to automatically discover and integrate heterogeneous sensor data streams and thus addressing the data stream federation challenge. ACEIS receives requirements from users and applications as event request and discovers or composes the relevant data streams to address both functional or non-functional requirements speci ed in the event requests. The discovery and composition process in ACEIS rely on the CES ontology designed for describing complex event services as extended OWL-S services. Based on the discovery and composition results, ACEIS automatically generates CQELS queries using a query transformation algorithm and registers the queries to a CQELS engine. These queries operate on live semantic data streams produced by various physical as well as virtual sensors to detect complex events for users.
In future, we plan to implement the adaptation component in ACEIS, which can dynamically adapt if any of the underlying data stream stops unexpectedly or has a QoS or QoI update at runtime that violates the quality constraints de ned in the original request. The adaptation component should be able to determine e ciently whether a situation is critical and the adaptation is necessary, and if so, take automatic recovery actions accordingly. De ning optimal window size for live stream queries of complex events while considering individual update frequency of the all underlying data streams is also part of our future agenda for the adaptation component. The adaptation component can partially address the reliable information processing challenge by providing an automatic recovery mechanism. We also plan to evaluate the correctness of the query transformation by evaluating query semantics.