Semantic Discovery and Integration of Urban Data Streams
-
Upload
ali-intizar -
Category
Education
-
view
110 -
download
2
description
Transcript of 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
Smart City Applications - Infrastructure
• Virtual Sensors (Social Media)
19/10/2014 6
Smart City Applications - Infrastructure
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
Smart City Applications - Challenges
Real-time Information Extraction and Event Detection
19/10/2014 10
Smart City Applications - Challenges
Reliable Information Processing
19/10/2014 11
Smart City Applications - Challenges
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;
ssn:isPropertyFor :Seg_1],
[ 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 ;
owls:serviceCategory [ a ces:TrafficReportService ;
owls:serviceCategoryName "traffic_report "^^ xsd:string ].
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
ACEIS - Architecture
19
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
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
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;
ssn:isPropertyFor :Seg_1],
[ 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 :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 ]].
:requestProfile a ces:EventProfile ;
owls:serviceCategory [ a ces:TrafficReportService ;
owls:serviceCategoryName "traffic_report "^^ xsd:string ].
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:
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
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;
ssn:isPropertyFor :Seg_1],
[ 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 :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 ]].
:requestProfile a ces:EventProfile ;
owls:serviceCategory [ a ces:TrafficReportService ;
owls:serviceCategoryName "traffic_report "^^ xsd:string ].
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:
19/10/2014
ACEIS - Architecture
22
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
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
ACEIS - Architecture
25
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
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;
rdf:_3 :seg2CongestionRequest;
rdf:_4 :seg3CongestionRequest;
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
ACEIS - Architecture
32
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
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)