Semantic Discovery and Integration of Urban Data Streams

Semantic Discovery & Integration of Urban Data Streams

Feng Gao, Ali Intizar and Alessandra Mileo

19/10/2014

Smart City Applications- Overview

2 * http://www.nec.com

19/10/2014

Smart City Applications - IoE

3 http://www.thepowerofplace.biz/2013/06/23/a-road-map-for-smart-cities-and-bim/

•  Physical Sensors

19/10/2014 4

Smart City Applications - Infrastructure

•  Mobile/Wearable Sensors

19/10/2014 5


•  Virtual Sensors (Social Media)

19/10/2014 6


19/10/2014 7

Smart City Applications - City Pulse

19/10/2014 8

Smart City Applications - Challenges

Federation of Heterogeneous Data Streams

19/10/2014 9


Real-time Information Extraction and Event Detection

19/10/2014 10


Reliable Information Processing

19/10/2014 11


Federation of Heterogeneous Data Streams

19/10/2014 12

Smart City Applications - Challenges •  Virtualisation

•  Federation of heterogeneous data streams •  Processing user’s queries in terms of requirements rather

than hard-bind queries

•  Optimal data source selection while taking users constraints and preferences into account

•  Automated composition of primitive data services/streams into complex events

•  Automated generations of queries from the complex event’s composition plan

19/10/2014 13

ACEIS - Features •  Automated Complex Event Implementation System

•  Enables users to provide requirements rather than hard bind streams

•  Automatically discovers the relevant data streams

•  Selects optimal data stream after evaluating user’s constraints and preferences

•  On demand data federation using complex event patterns

•  Transformation of complex event into stream queries

19/10/2014

ACEIS - Architecture

14

Semantic Annotation

ACEIS Core

ResourceManagement

Application Interface

Knowledge Base

QoI/QoS

Stream Description

Data Mgmt, Indexing, Caching

User Input

Event Request

Data Federation

Resource Discovery

Event Service Composer

Composition Plan

Subscription Manager

Query Transformer

Query Engine

Query

Results

Constraint Validation

Constraint Violation

Adaptation Manager

Data Store IoT Data Stream

Social Data Stream

19/10/2014

Complex Event Service Ontology – Overview (1/2)

15

The Complex Event Service Ontology (CES ontology) is an extension of OWL-S ontology.

CES ontology is used together with SSN (Semantic Sensor Network)

ontology, SSN is used to describe the sensor aspects An Event Service is described with a Grounding and an Event Profile. 1.  Groundings specify how to access and interact with event services. 2.  Event Profiles describe the events provided by the services with Patterns and

Non-Functional Properties (NFP).

An Event Request is specified as an incomplete Event Service description, without concrete service bindings.

19/10/2014

Complex Event Service Ontology – Overview (2/2)

16

EventService

EventProfile

owls:Grounding

Pattern

PrimitiveEventService

owls:Service owls:supports

ComplexEventService

EventRequest

owls:presents

hasPattern

rdf:_x (contains)

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#>

Legend:

Class

Object property

subClassOf

owls:ServiceProfile

owls:presents

owls-sp:ServiceParameter

NFP

Constraint

Preference

hasPreference

hasConstraint

QosWeightPreference

hasWeight

xsd:double

rdf:_x (contains)

owls-sp:serviceParameter

Data property

hasNFP

19/10/2014

Complex Event Service Ontology – Event Pattern

17

EventProfile

Pattern

ComplexEventService

owls:presents

hasPattern

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#>

Legend:

Class (unimplemented)Object property

subClassOf

Sequence

Repetition And

Or

rdf:Bagrdf:Seq

EventService

rdf:_x (contains)

FilterAggregation SlidingWindow

hasFilter

ClassValueAssignment

hasWindow

EventService EventPayload Expression

onEvent onPayload hasExpression

rdf:_x (contains)

19/10/2014

Stream Discovery – Sensor Stream Annotation

18

A sensor service description is annotated as: sdesc = (td, g, qd, Pd, FoId, fd)

type grounding QoS Observed Properties

Feature Of Iterest

Pd → FoId

PrimitiveEventService in CES ontology, as well as a Sensor device in SSN on-tology. The CES ontology is mainly used to describe the non-functional aspectsof sensor service requests/descriptions, including sensor event types, quality pa-rameters and sensor service groundings. SSN ontology is used to describe thefunctional aspects, including ObservedProperties and FeatureOfInterest.

Listing 1. Tra�c sensor service description

:sampleTrafficSensor a ssn:Sensor ,ces:PrimitiveEventService;

owls:presents :sampleProfile ;

owls:supports :sampleGrounding;

ssn:observes [ a ces:AverageSpeed;

ssn:isPropertyFor :Seg_1],

[ a ces:VehicleCount;


[ a ces:EstimatedTime;

ssn:isPropertyFor :Seg_1].

:sampleProfile a ces:EventProfile ;

owls:serviceCategory [ a ces:TrafficReportService ;

owls:serviceCategoryName "traffic_report "^^ xsd:string ].

Listing 2. Tra�c sensor service request

:sampleRequest a ssn:Sensor ,ces:EventRequest;

owls:presents :requestProfile ;

ssn:observes [ a ces:EstimatedTime;

ssn:isPropertyFor :FoI_1].

:requestProfile a ces:EventProfile ;



A sensor service description is denoted as sdesc = (td, g, qd, Pd, FoId, fd),where t is the sensor event type, g is the service grounding, qd is a QoS vectordescribing the QoS values, Pd is the set of ObservedProperties, FoId is the setof FeatureOfInterests and fd : Pd ! FoId is a function correlating observedproperties with their feature-of-interests. Similarly, a sensor service request isdenoted sr = (tr, qr, Pr, FoIr, fr, pref, C). Compared to sd, sr do not specifyservice groundings, qr represents the constraints over QoS metrics, pref repre-sents 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 matchfor sr i↵ all of the following three conditions are true:

– tr subsumes td,– qd satifies qr and– 8p1 2 Pr, 9p2 2 Pd =) T (p1) subsumes p2 ^ fr(p1) = fd(p2), where T (p)

gives the most specific type of p in a property taxonomy.

Listing 1 shows a snippet of a tra�c sensor description in turtle syntax. The traf-fic senosr monitors the estimated travel time, vehicle count and average vehiclespeed on a road segment. Listing 2 shows a snippet of an sensor service request

19/10/2014


19

Semantic Annotation

ACEIS Core

ResourceManagement


Knowledge Base

QoI/QoS

Stream Description


User Input

Event Request

Data Federation

Resource Discovery


Composition Plan


Query Transformer

Query Engine

Query

Results



Adaptation Manager


Social Data Stream

19/10/2014

Stream Discovery – Event Request Annotation

20

Similarly, a sensor service request is annotated: sr = (tr, Pr, FoIr, fr, pref, C)

type Requested Properties

Feature of Interest

Pd → FoId



















ssn:isPropertyFor :Seg_1];

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 ]].






19/10/2014

Stream Discovery – Event Request Annotation

21

Similarly, a sensor service request is annotated: sr = (tr, Pr, FoIr, fr, pref, C)

type Requested Properties

Feature of Interest

Pd → FoId

no grounding

NFP Constraint&Prefer

ences



















ssn:isPropertyFor :Seg_1];

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 ]].






19/10/2014


22

Semantic Annotation

ACEIS Core

ResourceManagement


Knowledge Base

QoI/QoS

Stream Description


User Input

Event Request

Data Federation

Resource Discovery


Composition Plan


Query Transformer

Query Engine

Query

Results



Adaptation Manager


Social Data Stream

19/10/2014

Stream Discovery – Matching Condition

23

A sensor service description Sd matches a service request Sr iff the following three conditions are true:

1.  tr subsumes td:

2.  qd satifies C:

3.  ∀p1 ∈ Pr,∃p2 ∈ Pd ⇒ T(p1) subsumes T(p2) ∧ fr(p1) = fd(p2):

19/10/2014

Stream Discovery – Matching Condition

24

A sensor service description Sd matches a service request Sr iff the following three conditions are true:

1.  tr subsumes td: Requested service type is same or a super-type of provided service type.

2.  qd satifies C: Quality-of-service properties of the provided sensor service satisfy the constraints specified in the service request.

3.  ∀p1 ∈ Pr,∃p2 ∈ Pd ⇒ T(p1) subsumes T(p2) ∧ fr(p1) = fd(p2): Provided sensor service observes all requested physical properties from the requested feature-of-interest (a geographical location or physical entity from which the observations are made).

19/10/2014


25

Semantic Annotation

ACEIS Core

ResourceManagement


Knowledge Base

QoI/QoS

Stream Description


User Input

Event Request

Data Federation

Resource Discovery


Composition Plan


Query Transformer

Query Engine

Query

Results



Adaptation Manager


Social Data Stream

19/10/2014

Stream Integration – Complex Event Service

26

•  A Complex Event Service (CES) integrates different sensor streams to detect complex events based on event patterns.

•  An Event Pattern describes the correlations of integrated streams.

– tr subsumes td,– qd satifies qr and– 8p1 2 Pr, 9p2 2 Pd =) T (p1) subsumes p2 ^ fr(p1) = fd(p2), where T (p)

gives the most specific type of p in a property taxonomy.

Listing 1 shows a snippet of a tra�c sensor description in turtle syntax. The traf-fic senosr monitors the estimated travel time, vehicle count and average vehiclespeed on a road segment. Listing 2 shows a snippet of an sensor service requestmatched by the tra�c sensor service. When the discovery component finds allservice candidates suitable for the request, a Simple-Additive-Weighting algo-rithm [5] is used to rank the service candidates based on qd, qr and pref.

4.3 Sensors Streams Integration

Sensor stream discovery deals only with primitive event service discovery. Todiscover and integrate (composite) sensor streams for complex event service re-quests, the event patterns specified in the complex event service requests/de-scriptions 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;



ces:hasWindow "5"^^ xsd:integer ].

In the context of integrated sensor stream discovery and composition, thedefinition of sensor stream description is extended to denote composite sensorstream descriptions Sd = (epd, Qd, G),where epd consists of a set of sensor streamdescriptions sd and/or a set of composite sensor stream descriptions S0

d, and a setof event operators including Sequence, Repetition, And, Or, Selection, Filter andWindow, qd is the aggregated QoS metrics for Sd and G is the grounding for thecomposite sensor stream. Similarly, a complex event service request is denotedas Sr = (epr, Qr, pref), where epr is a canonical event pattern consisting of a setof primitive sensor service requests sr and a set of event operators, Qr describesthe QoS constraints for the requested complex event service and pref specifiesthe weights on QoS metrics.

An Sd is a match for Sr i↵ epd is semantically equivalent to epr and Qd

satisfies Qr. When no matches are found during the discovery process for Sr, itis 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 ofepr and can be reused to create a composition plan, which contains an event

19/10/2014

Stream Integration – Matching condition

27

Discovery and composition of complex event services are based on matching event patterns (and aggregated NFP values).

Procedure: 1.  Derive canonical forms of event patterns of CESs. 2.  Apply tree isomorphism algorithms over the canonical event patterns and the

requested event pattern to identify reusable or equivalent event patterns. 3.  Generate all possible composition plans. 4.  Aggregate NFPs based on event patterns and compare aggregated NFP values

against requested constraints to filter out unsatisfied composition plans. 5.  Rank the remaining composition plans based on preferences (soft constraints).

Create complete event patterns

Canonical Event Pattern (1/2)

e1 e2

ES1

ES2 ES3

Or

And Seq

e3 e4

ES2

Or

And Seq

e1 e2 e3 e4

getCompletePattern()

19/10/2014 28

ES3

Create reduced event patterns

Canonical Event Pattern (2/2)

e1

SEQ

SEQ SEQ

e2 e3e2

e1

SEQ

e2 e3e2 e1

SEQ

REP x2 e3

e2

AND

e1 AND

e1 e2

e1

AND

e2e1 e1

AND

e2

REP x2

REP x3

e1

REP x6

e1

REP x2

SEQ

e1 e2

e1

REP x2

e1 e2e1

REP x2

e2REP x2

e1

Sequential Lift Sequential Merge

Parallel Lift Parallel Merge

Repetition Lift(1)

Repetition Lift(2)

Repetition Merge

Figure 4: Examples of syntax tree reduction operations

Incoming edges on the child node are removed while alloutgoing edges will attach their sources to the parentnode. The payload and filters attached to the removednode are merged with the parent.

• Sequential Merge: when a node is a sequence op-erator and there is a repeating sequence in its childnodes (recurring primitive event or DST sequences), arepetition node is inserted as a child node of the se-quence operator. Repeated sequences are merged intoone and relocated under the inserted repetition node.The cardinality of the repetition node is determinedby the number of occurrences of the sequence.

• Parallel Lift: when a node and its child are the sametype of parallel operator (conjunction or alternation),the child node can be removed (as the sequential lift).

• Parallel Merge: when child nodes of a parallel op-erator has duplicates (recurring primitive events orDSTs), duplications are removed. When the only dif-ferences of two child nodes n1, n2 are the filters at-tached, and each filter in n1 (or T (n1)) is covered

3 bythe corresponding filter in n2 (or T (n2)), then thesetwo nodes (or DSTs) can be merged. For conjunctionoperators in this case, n1 (T (n1)) is kept, for alterna-tion operators, n2 (T (n2)) is kept. Additionally, thereis a special case for conjunctional merge: when a con-junction operator has two repetition DSTs with onlydi�erent cardinalities, the DST with less cardinality isremoved.

• Repetitional Lift: when a node is a repetition op-erator (with cardinality n), and it has only one child

3f1 covers f2 ⌅⇧ P (f1) ⇤ P (f2), where P (f1), P (f2) arethe notifications produced by filters f1, f2, respectively.

node which is also a repetition (with cardinality m),the child node is removed and the cardinality of theparent node is changed into n �m. Otherwise, if thechild node is a sequence operator, the child node isremoved.

• Repetitional Merge: merging operation for repeti-tion nodes is the same as a sequential merge.

• Special Lift: when a sequence or parallel operatorhas only one child, this operator is removed. Suchsituations only happen during the reduction process.

4.4 Syntax Tree Reduction AlgorithmThe algorithm to create irreducible syntax trees is shown inAlgorithm 1. The algorithm traverses a syntax tree fromthe bottom to the top. The algorithm starts with lifting thewhole tree to remove redundant operators. Then, it tries tomerge sub-trees on the maximum depth, i.e., sub-trees whoseroot depths are equal to the height of the whole tree minusone. If these sub-trees are merged, we check if they can belifted again because merging could create further redundantoperators. After merging and lifting all sub-trees on samedepth, we decrease the depth and repeat the merging andlifting process until the whole tree is merged (and possiblylifted again).

In the algorithm, line 2 uses the method getHeight to com-pute the height (maximum maximal depth) of a syntax tree.Line 9 uses the method getSubTreesByDepth to retrieve allsub-trees within a syntax tree whose root is of a certaindepth. The merge method used in Line 11 merges the directsub-trees of a certain node. The liftTree method in Line 7and 13 carries out the lifting operations on a sub-tree.

19/10/2014 29

Create event reusability hierachy Reusable relation: R(ep1,ep2) holds if Rd(ep1,ep2) or Ri(ep1,ep2) holds.

Event Composition via Reusability

Definition 5 Rd ⌅ P ⇥ P where P is a set of eventpatterns. Rd(p1, p2) holds for p1, p2 P ⌥� ↵T (v) ⇤fcanonical(p2)(fcanonical(p1) = T (v)). We denote p1 isdirectly reusable to p2 on node v.

An event pattern ep1 is in-directly reusable to ep2, denotedRi(ep1, ep2), i� ep1 is not directly reusable to ep2, butep1 can be transformed into ep01 using a sequence of op-erations on the canonical syntax tree of ep1, as a result, itmakes Rd(ep

01, ep2) hold. These operations have four types:

Ffilter : T ⇥ F �⌃ T attaches filters to the roots of syntaxtrees; Fmultiply : T ⇥ N+ �⌃ T multiplies the cardinalityof repetition of the roots; Fappend : T ⇥ T �⌃ T adds a se-quence of DSTs to the sequential roots as prefixes or su⇥ces;Fadd : T ⇥T �⌃ T adds a set of DSTs to the parallel roots.In the above function definitions, T is a set of syntax trees,F is a set of filters. We formally define in-directly reusablerelation Ri in Definition 6

Definition 6 Ri ⌅ P ⇥ P where P is a set of eventpatterns. Given T = {the set of all syntax trees},N+ = {positive integers}, F = {the set of all filters},Ffilter, Fmultiply, Fappend, Fadd ={sets of transformation functions};Ri(p1, p2) holds for p1, p2 P ⌥� ¬Rd(p1, p2)✏↵p01 P, T 0 ⌅ T, F 0 ⌅ F, n N+, T1 = fcanonical(p1), T

01 =

fcanonical(p01), r = {the root node of T1}, ff

Ffilter, fm Fmultiply, fadd Fadd, fapp Fappend(Rd(p

01, p2)✏

T 01 =

⇥⇧⌅

⇧⇤

ff (fm(T1, n), F0) type(r) = Rep

ff (fm(fapp(T1, T0), n), F 0) type(r) = Seq

ff (fm(fadd(T1, T0), n).F 0) type(r) = And|Or

�

⌥⌃ .

Similarly, we denote p1 is in-directly reusable to p2 onnode r.

We now formally define the reusable relation on event pat-terns R in Definition 7. An example of reusable relations isdepicted in Figure 7

Definition 7 R = (Rd �Ri)

5.3.2 Event Pattern Reusability HierarchyUsing the reusable relation, a hierarchy of canonical eventsyntax trees can be built, called an Event Reusability Hier-archy (ERH). An ERH is a Directed-Acyclic-Graph (DAG),denoted ERH = (T,R) where T is a set of nodes (canon-ical trees derived from patterns) and R ⌅ T ⇥ T is a setof edges (reusable relations) connecting nodes. Given anERH erh = (T,R), P is the set of event patterns of treesin T , ⌦(t1, t2) E, R(p1, p2) holds and @p3 P such that

e1

SEQ

e2

OR

e4

e3

e1

SEQ

e2 e3

SEQ

e2 e3

directly reusable in-directly reusable

in-directly reusable

Figure 7: Example of event pattern reusability

R(p1, p3)✏R(p3, p2), where p1, p2 P are event patterns oft1, t2. According to this definition, if we build an ERH forthe three event patterns in Figure 7, the edge at the top-right is ignored. The nodes do not reuse any other nodesare called roots in the ERH, the nodes cannot be reused byother nodes are leaves.

Constructing an ERH requires iteratively inserting canoni-cal trees of event patterns into the hierarchy. If not all nodescan be inserted into a single ERH, we obtain a set of sepa-rated ERHs, called a Event Reusability Forest (ERF). Thealgorithm that inserts a node into a given ERF is shown inAlgorithm 3.

Algorithm 3 Insert an canonical tree t to reusability foresterf.

Require: Canonical Tree t, ERF erf .1: procedure insert(t, erf )2: roots⇧ getRoots(erf ), leaves⇧ getLeaves(erf )3: erf .addNode(t)4: parents⇧ getReusable(roots, t)5: drawEdges(parents, t)6: childNodes⇧ getChildNodes(parents, erf )7: parents � getReused(childNodes, t)8: drawEdges(parents, t)9: remove redundant edges10: if parent is modified then11: go to 612: end if13: perform reversed operations on leaves14: end procedure

The above algorithm takes the canonical tree t of event pat-tern ep and an event reusability forest as inputs. As thefirst step, it finds all p P where P is the set of nodes inthe forest such that R(p, t) holds, starting from the roots(line 4). Then the algorithm draws all edges for (p, t) andremoves the redundant edges. As the second step, it drawsall necessary edges for (t, p0), where p0 P ✏ R(t, p0) holds.During the navigation of nodes, if a tree t0 = t is found, thealgorithm terminates. This step is omitted in Algorithm 3for brevity.

As mentioned above, finding reusable components or substi-tutes for a certain pattern can be achieved by the first stepof the node insertion algorithm. Compared to Algorithm 2

19/10/2014 30

Example of a composition plan:

Stream Integration – Composition Plan

e1

SEQ

e2

OR

e3

Query

e1

SEQ

e2

type= e4loc=loc4

e3

e2e1

type= e3loc=loc3

type= e2loc=loc2

type= e1loc=loc1

OR

e3

Composition Plan

e4

loc=loc4 loc=loc3

Event Service 1 Event Service 2

Event Service 3 Event Service 4

19/10/2014 31

19/10/2014


32

Semantic Annotation

ACEIS Core

ResourceManagement


Knowledge Base

QoI/QoS

Stream Description


User Input

Event Request

Data Federation

Resource Discovery


Composition Plan


Query Transformer

Query Engine

Query

Results



Adaptation Manager


Social Data Stream

Goal: transform the composition plan into a stream query which can be evaluated by a stream reasoning engine over RDF data streams Requirements: •  Alignments of event pattern operators to stream query operators •  Transformation Algorithm Alignments for CQELS query language: •  Sequence and Repetition not supported by CQELS. •  Sensor requests mapped to Stream Graph Pattern. •  AND operator mapped to stream join. •  OR operator mapped to OPTIONAL keyword (left-outer-join).

Query Transformation – Semantic Alignment

19/10/2014 33

Repetition is a generalization of sequence, it indicates a sequence pattern shouldbe repeated several times, therefore it is also not supported. An And operatorindicates all its sub-events should occur, it can be mapped to the Join opera-tor. An Or operator indicates at least one of its sub-events should occur, it canbe mapped to LeftOuterJoin operator in CQELS (OPTIONAL keyword) withbound filters. Selection is mapped to Projection in CQELS to select the messagepayloads for complex events. Filter and Window operators in event patternscan be mapped to Filter and Window operators in CQELS, respectively. Ta-ble 1 summarizes the semantics alignment between event operators and CQELSoperators.

Table 1. Semantics Alignment

Event Pattern sd

Sequence Repetition And Or Selection Filter WindowCQELS Operator SGP - - Join Optional Projection Filter Window

5.2 Transformation Algorithm

Previously (see Section 4.1), we briefly described how event patterns are speci-fied in CES ontology. An event pattern can be recursively defined with sub eventpatterns and event service descriptions, thus formulating an event pattern tree.In this section we elaborate algorithms for parsing event pattern trees and cre-ating CQELS queries. In an event pattern tree, the nodes can be either any ofthe following four types of event operators: Sequence,Repetition,And and Or, orother event service descriptions. The edges in the tree represent the provenancerelation in the complex event detection: the parent node is detected based on thedetection of the child nodes. Using a top-down traversal of the event pattern treeand querying the semantics alignment table for each event operator encounteredduring the traversal, the event pattern in the composition plan is transformedinto a CQELS query following the divide-and-conquer style. Algorithm 1 showsthe 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-defined query prefix, a select clause derived from the getSelectClause()function and a where clause derived from the getWhereClause() function. Lines7-27 define the getWhereClause() function in a recursive way. It takes as inputthe event pattern in the composition plan (Line 7) and finds the root node inthe event pattern (Line 8). Then, it investigates the type of the root node: if itis a Sequence or Repetition operator, the transformation algorithm terminates,currently transformation cannot be applied for Sequence or Repetition becauseof the limitations of the underlying query language (CQELS) (Lines 9-10). If theroot node is an event service description, a getSGP() function creates the StreamGraph Patterns (SGP) in CQELS (Lines 11-12) describing the triple patternsof the observations delivered by the event service, and this SGP is returned

Query Transformation –Transformation Example

19/10/2014 34

Example of composition plan CQELS Query Transformation Result:

seg2traffic

AND Event textual description:

Monitor the user's current location as well as the traffic

conditions (estimated travel time) of all the 3 street segments on

the chosen routeseg1traffic

seg3traffic

userloc

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 Related Work

Existing event notification services like SAS9 and WSN10 support only pub-lish and subscribe simple and syntactical events. Recent research on semanticevent processing endeavor to bring semantics to event specifications. Semanticevent specifications have more flexibility and expressiveness compared to syn-tactical ones[12]. However, most existing event ontologies, (e.g., [14, 17, 18]) lackthe ability to describe comprehensive event operators and non-functional con-straints. Moreover, they do not discuss the mechanisms of complex event servicediscovery and reusability.

Reusing event queries/subscriptions is also discussed in many other eventbased systems, including content-based event overlay networks [2, 3, 10, 8, 11, 6,13] and CEP query optimisation[1, 15]. In event overlay networks, event sub-scriptions are reused to facilitate the ”downstream replication” and ”upstreamevaluation” principles (as described in [2]) and reduce the tra�c over the net-work. In event query rewriting and optimisation, sub-queries can be delegatedto existing event processing nodes/agents when their patterns match, in orderto reduce processing burden of event engines.

Although the above works in event overlay networks and query rewritingshare some objectives to our work in terms of improving the network and eventprocessing e�ciency, this paper is di↵erent because 1) we do not focus on routingalgorithms which are central parts of event overlay network research, all nodesin the event service network can host both event producers and consumers andthey 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/SAS10 Web Service Notification: https://www.oasis-open.org/committees/tc_home.

php?wg_abbrev=wsn

19/10/2014

Conclusion

35

•  Automated Complext Event Implementation System •  Information model for dynamic discovery and selection of sensor

data streams i.e. Complex Event Ontology, Event Pattern Ontology and Event Reuest/Profile

•  Algorithm to create optimal composition plan using event reusability heirachy

•  Transfoormation of the composition plan into stream queries (CQELS)

Semantic Discovery and Integration of Urban Data Streams

Education

Transcript of Semantic Discovery and Integration of Urban Data Streams