Semantic Discovery and Integration of Urban Data Streams
2 likes1,155 views
Number of Urban Data Streams available in the smart cities are in continuous increase. We presented an automated discovery and integration system which not only discovers the most relevant data streams for the citizens based on their requirements and context. But also composes the primitive data streams into complex events and executes over existing stream query reasoning engines.
![Stream Discovery Sensor Stream Annotation
A sensor service description is annotated as:
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 aspects
Pd FoId
of sensor service requests/descriptions, including sensor event types, quality pa-rameters
and sensor service groundings. SSN ontology is used to describe the
19/10/2014
18
sdesc = (td, g, qd, Pd, FoId, fd)
type grounding QoS Observed
Properties
Feature Of
Iterest
functional aspects, including ObservedProperties and FeatureOfInterest.
Listing 1. Trac 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. Trac sensor service request
:sampleRequest a ssn:Sensor ,ces:EventRequest;
owls:presents :requestProfile ;](https://image.slidesharecdn.com/sscworkshopiswc2014-141020005114-conversion-gate01/85/Semantic-Discovery-and-Integration-of-Urban-Data-Streams-18-320.jpg)
![Stream Discovery Event Request Annotation
Similarly, a sensor service request is annotated:
19/10/2014
20
sr = (tr, Pr, FoIr, fr, pref, C)
type
Requested
Properties
Feature of
Interest
Pd FoId
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. Trac 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 vector
describing the QoS values, Pd is the set of ObservedProperties, FoId is the set](https://image.slidesharecdn.com/sscworkshopiswc2014-141020005114-conversion-gate01/85/Semantic-Discovery-and-Integration-of-Urban-Data-Streams-20-320.jpg)
![Stream Discovery Event Request Annotation
Similarly, a sensor service request is annotated:
19/10/2014
21
sr = (tr, Pr, FoIr, fr, pref, C)
type
Requested
Properties
Feature of
Interest
Pd FoId
no
grounding
NFP
ConstraintPrefer
ences
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. Trac 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 vector
describing the QoS values, Pd is the set of ObservedProperties, FoId is the set](https://image.slidesharecdn.com/sscworkshopiswc2014-141020005114-conversion-gate01/85/Semantic-Discovery-and-Integration-of-Urban-Data-Streams-21-320.jpg)
![Stream Integration Complex Event Service
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.
19/10/2014
26
matched by the trac sensor service. When the discovery component finds all
service 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. To
discover 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, the
0d
definition 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 S, and a set
of event operators including Sequence, Repetition, And, Or, Selection, Filter and](https://image.slidesharecdn.com/sscworkshopiswc2014-141020005114-conversion-gate01/85/Semantic-Discovery-and-Integration-of-Urban-Data-Streams-26-320.jpg)
![Query Transformation Transformation Example
Example of composition plan
AND Event textual description:
seg2
traffic
Monitor the user's current
location as well as the traffic
conditions (estimated travel time)
of all the 3 street segments on
seg1
traffic
seg3
traffic
user
loc
CQELS Query Transformation Result:
the chosen route
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] {...} }
34 19/10/2014
6 RelatedWork](https://image.slidesharecdn.com/sscworkshopiswc2014-141020005114-conversion-gate01/85/Semantic-Discovery-and-Integration-of-Urban-Data-Streams-34-320.jpg)
More Related Content
Similar to Semantic Discovery and Integration of Urban Data Streams (20)
Recently uploaded (20)
Semantic Discovery and Integration of Urban Data Streams
- 1. Semantic Discovery & Integration of Urban Data Streams Feng Gao, Ali Intizar and Alessandra Mileo
- 2. Smart City Applications- Overview 19/10/2014 2 * http://www.nec.com
- 3. Smart City Applications - IoE 19/10/2014 3 http://www.thepowerofplace.biz/2013/06/23/a-road-map-for-smart-cities-and-bim/
- 4. Smart City Applications - Infrastructure Physical Sensors 4 19/10/2014
- 5. Smart City Applications - Infrastructure Mobile/Wearable Sensors 5 19/10/2014
- 6. Smart City Applications - Infrastructure Virtual Sensors (Social Media) 6 19/10/2014
- 7. Smart City Applications - City Pulse 7 19/10/2014
- 8. Smart City Applications - Challenges Federation of Heterogeneous Data Streams 8 19/10/2014
- 9. Smart City Applications - Challenges Real-time Information Extraction and Event Detection 9 19/10/2014
- 10. Smart City Applications - Challenges Reliable Information Processing 10 19/10/2014
- 11. Smart City Applications - Challenges Federation of Heterogeneous Data Streams 11 19/10/2014
- 12. Smart City Applications - Challenges Virtualisation Federation of heterogeneous data streams Processing users 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 events composition plan 12 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 users constraints and preferences On demand data federation using complex event patterns Transformation of complex event into stream queries 13 19/10/2014
- 14. 19/10/2014 ACEIS - Architecture 14 Semantic Annotation Application Interface ACEIS Core Resource Management 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 Adaptation Manager Constraint Validation Constraint Violation Data Store IoT Data Stream Social Data Stream
- 15. Complex Event Service Ontology Overview (1/2) The Complex Event Service Ontology (CES ontology) is an extension of 19/10/2014 15 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.
- 16. Complex Event Service Ontology Overview (2/2) owls:ServiceProfile 19/10/2014 16 EventService EventProfile owls:Grounding PrimitiveEvent Service rdf:_x (contains) Pattern owls:Service owls:supports ComplexEven tService EventRequest owls:presents hasPattern rdf:_x (contains) hasConstraint 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:presents owls-sp:ServiceParameter NFP Constraint Preference hasPreference QosWeight Preference hasWeight xsd:double rdf:_x (contains) owls-sp:serviceParameter Data property hasNFP
- 17. Complex Event Service Ontology Event Pattern EventService rdf:_x (contains) rdf:_x (contains) rdf:Seq rdf:Bag 19/10/2014 17 ComplexEvent Service owls:presents EventProfile hasPattern Pattern 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 Or Repetition And hasFilter Aggregation Filter SlidingWindow Class ValueAssignment hasWindow onEvent onPayload hasExpression EventService EventPayload Expression
- 18. Stream Discovery Sensor Stream Annotation A sensor service description is annotated as: 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 aspects Pd FoId of sensor service requests/descriptions, including sensor event types, quality pa-rameters and sensor service groundings. SSN ontology is used to describe the 19/10/2014 18 sdesc = (td, g, qd, Pd, FoId, fd) type grounding QoS Observed Properties Feature Of Iterest functional aspects, including ObservedProperties and FeatureOfInterest. Listing 1. Trac 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. Trac sensor service request :sampleRequest a ssn:Sensor ,ces:EventRequest; owls:presents :requestProfile ;
- 19. 19/10/2014 ACEIS - Architecture 19 Semantic Annotation Application Interface ACEIS Core Resource Management 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 Adaptation Manager Constraint Validation Constraint Violation Data Store IoT Data Stream Social Data Stream
- 20. Stream Discovery Event Request Annotation Similarly, a sensor service request is annotated: 19/10/2014 20 sr = (tr, Pr, FoIr, fr, pref, C) type Requested Properties Feature of Interest Pd FoId 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. Trac 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 vector describing the QoS values, Pd is the set of ObservedProperties, FoId is the set
- 21. Stream Discovery Event Request Annotation Similarly, a sensor service request is annotated: 19/10/2014 21 sr = (tr, Pr, FoIr, fr, pref, C) type Requested Properties Feature of Interest Pd FoId no grounding NFP ConstraintPrefer ences 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. Trac 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 vector describing the QoS values, Pd is the set of ObservedProperties, FoId is the set
- 22. 19/10/2014 ACEIS - Architecture 22 Semantic Annotation Application Interface ACEIS Core Resource Management 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 Adaptation Manager Constraint Validation Constraint Violation Data Store IoT Data Stream Social Data Stream
- 23. Stream Discovery Matching Condition A sensor service description Sd matches a service request Sr iff the following three conditions are true: 1. tr subsumes td: 3. p1 Pr,p2 Pd T(p1) subsumes T(p2) fr(p1) = fd(p2): 19/10/2014 2. qd satifies C: 23
- 24. Stream Discovery Matching Condition A sensor service description Sd matches a service request Sr iff the following three conditions are true: 1. tr subsumes td: 19/10/2014 24 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).
- 25. 19/10/2014 ACEIS - Architecture 25 Semantic Annotation Application Interface ACEIS Core Resource Management 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 Adaptation Manager Constraint Validation Constraint Violation Data Store IoT Data Stream Social Data Stream
- 26. Stream Integration Complex Event Service 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. 19/10/2014 26 matched by the trac sensor service. When the discovery component finds all service 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. To discover 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, the 0d definition 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 S, and a set of event operators including Sequence, Repetition, And, Or, Selection, Filter and
- 27. Stream Integration Matching condition 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 19/10/2014 27 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).
- 28. Canonical Event Pattern (1/2) Create complete event patterns ES1 ES2 ES3 e1 e2 Or And Seq e3 e4 ES2 Or And Seq e1 e2 e3 e4 getCompletePattern() ES3 28 19/10/2014
- 29. Canonical Event Pattern (2/2) Create reduced event patterns e1 SEQ SEQ SEQ e2 e2 e3 e1 SEQ e2 e2 e3 e1 SEQ REP x2 e3 e2 AND e1 AND e1 e2 e1 AND e1 e2 e1 AND e2 REP x2 REP x3 e1 REP x6 e1 REP x2 SEQ e1 e2 e1 REP x2 e1 e1 e2 REP x2 e2 REP 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 29 19/10/2014
- 30. Event Composition via Reusability Create event reusability hierachy Reusable relation: R(ep1,ep2) holds if Rd(ep1,ep2) or Ri(ep1,ep2) holds. a set of event % T(v) We denote p1 is reusable to ep2, denoted reusable to ep2, but sequence of op-erations ep1, as a result, it have four types: the roots of syntax multiplies the cardinality T adds a se-quence prefixes or suces; the parallel roots. set of syntax trees, in-directly reusable a set of event e1 SEQ e2 OR e4 e3 e1 directly reusable in-directly reusable SEQ e2 e3 SEQ e2 e3 in-directly reusable Figure 7: Example of event pattern reusability R(p1, p3) R(p3, p2), where p1, p2 P are event patterns of t1, t2. According to this definition, if we build an ERH for the three event patterns in Figure 7, the edge at the top-right is ignored. The nodes do not reuse any other nodes are called roots in the ERH, the nodes cannot be reused by other nodes are leaves. 30 19/10/2014
- 31. Stream Integration Composition Plan Example of a composition plan: e1 SEQ OR e2 e3 Query Event Service 1 Event Service 2 e1 e2 Event Service 3 Event Service 4 e1 SEQ type= e4 loc=loc4 e2 e3 type= e3 loc=loc3 type= e2 loc=loc2 type= e1 loc=loc1 Composition Plan OR e3 e4 loc=loc4 loc=loc3 31 19/10/2014
- 32. 19/10/2014 ACEIS - Architecture 32 Semantic Annotation Application Interface ACEIS Core Resource Management 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 Adaptation Manager Constraint Validation Constraint Violation Data Store IoT Data Stream Social Data Stream
- 33. Repetition is a generalization of sequence, it indicates a sequence pattern should be repeated Query several Transformation times, therefore it is also Semantic not supported. Alignment An And operator indicates 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 can Goal: transform the composition plan into a stream query which can be evaluated by a stream reasoning engine over RDF data streams be mapped to LeftOuterJoin operator in CQELS (OPTIONAL keyword) with bound filters. 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. Ta-ble Requirements: Alignments of event pattern operators to stream query operators Transformation Algorithm 1 summarizes the semantics alignment between event operators and CQELS operators. Table 1. Semantics Alignment Alignments for CQELS query language: Event Pattern sd Sequence Repetition And Or Selection Filter Window CQELS Operator SGP - - Join Optional Projection Filter Window 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). 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 event patterns and event service descriptions, thus formulating an event pattern tree. In this section we elaborate algorithms for parsing event pattern trees and cre-ating 33 19/10/2014
- 34. Query Transformation Transformation Example Example of composition plan AND Event textual description: seg2 traffic Monitor the user's current location as well as the traffic conditions (estimated travel time) of all the 3 street segments on seg1 traffic seg3 traffic user loc CQELS Query Transformation Result: the chosen route 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] {...} } 34 19/10/2014 6 RelatedWork
- 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) 19/10/2014 Conclusion 35