A huge volume of Linked Data has been published on the Web, yet is not processable by Complex Event Processing (CEP) or Event Stream Processing (ESP) engines. This paper presents a framework to bridge this gap, under which Linked Data are rst translated into events conforming to a lightweight ontology, and then fed to CEP engines. The event processing results will also be published back onto the Web of Data. In this way, CEP engines are connected to the Web of Data, and the ontological reasoning is integrated with event processing. Finally, the implementation method and a case study of the framework are presented.
With the development of the Semantic Web, a huge volume of Linked Data has
been published on the Web. On the other hand, with the rise of Complex Event
Processing (CEP) and Event Stream Processing (ESP) [
This paper presents a more practical approach: Linked Data are imported from external sources by being transformed into events conforming to EVOCore, a lightweight but generic ontology. CEP engines process such events with the support of a Java API generated for manipulating the EVO-Core ontology. The results of event processing will be RDF-i ed again and published on the Web of Data. Under this framework, the integration of ontological reasoning and CEP is achieved without any modi cations to the RDF and SPARQL standards.
To demonstrate the work ow of the proposed framework, the development
of a simple analytical system for user logs in iServe is used as a running example
in this paper. iServe [
The rest of this paper is organized as follows: Section 2 reviews the recent work on Semantic CEP. Section 3 summarizes the work ow of the proposed framework at both design time and runtime. Section 4 and Section 5 respectively discuss two critical issues regarding the framework: the event modelling and generation. Section 6 sketches the architecture of the implemented prototype. Section 7 demonstrates the use of the framework. Finally, Section 8 concludes the paper and introduces our future research objectives. 2
Earlier research on semantic event modelling is presented in [
SQL-like and algebra-based event languages are designed to specify the
semantics of events [
At design time, the work to build up an event processor consuming Linked Data includes three stages listed below. Additionally, it also involves some trivial tasks such as con guring the connectors to RDF repositories, setting the options of the CEP engine, etc.
{ Event (Stream) Modelling: De ne domain speci c events and split them into di erent streams. Write SPARQL CONSTRUCT queries, which are executed at runtime to produce event streams. { Code Generation: Automatically generate Java API for manipulating events and the event processing results, using the code generator provided by RDFReactor. It may also require auxiliary coding work to be done manually, e.g. translating instances of Java Calendar into time in the format of milliseconds. { Rule De nition: De ne rules for event processing. If needed, develop some helping functions of, for instance, accessing external SPARQL endpoints on the Web of Data, publishing rule-base reasoning results as Linked Data, etc.
In brief, the results of work done at design time contain: i) an application oriented event model, ii) Java libraries for manipulating event model and processing results, iii) the speci cation of rules for event processing. All of these are inputs to the runtime modules, which work following the ow illustrated by Fig. 1. Event streams are formed by executing SPARQL CONSTRUCT queries
RDFReactor against certain sets of Linked Data on a regular basis, and, when necessary, SPARQL DESCRIBE queries may also be executed to make a snapshot of the concerned entities. If a RDF triple store like BigOWLim4 o ers a noti cation mechanism, the data transformation will be performed when being noti ed by the triple store. With the runtime supports of RDFReactor5 and RDF2Go6, the generated event streams are sent to Drools Fusion in the form of Java objects. Drools Fusion performs rule-based reasoning, as well as temporal reasoning over the received Java objects, then RDF-i es the results and saves into the assigned semantic repository by invoking the Java APIs generated at design time.
The proposed framework aims at bringing together Linked Data and rule-based CEP engines, so the following requirements and issues are taken into account when building the conceptual model of events.
{ Usability: This is made up of two aspects: i) following the Linked Data principles, especially the ability to be interlinked to RDF triples on the Web of Data; ii) ease of being fed into CEP engines such as Drools Fusion. { Extendibility: The event model should be in the form of a generic ontology, rather than a domain speci c one, and must be easy to apply to di erent application areas. { Expressiveness: The model may be able to describe complex events and event streams, as well as the timing, causality, aggregation and hierarchy of events. { Simplicity: Some applications powered by CEP engines, e.g. Business Activity Monitoring (BAM), are real-time or quasi real-time systems. Thus, light-weight semantics of the event model should minimize the impact of ontological reasoning on performance.
owl:Thing ec:Event ec:EventStream xsd:dateTime ec:AtomicEvent ec:ComplexEvent
sp:Construct
Namespaces xoswdl:: hhttttpp::////wwwwww..ww33..oorrgg//22000021//0X7M/oLwSlc#hema# escp:: hhttttpp::////ksmpiin.ordpfe.onr.ga/cs.pu#k/ontologies/evo-core#
As visualized by Figure 2, EVent Ontology Core (EVO-Core) is de ned in RDF Schema to ful ll the presented demands. It contains four key concepts: { Event, is a concept on the highest level of abstraction and the common ancestor of AtomicEvent and ComplexEvent. A particular property timestamp is used to specify the time when the event happens, and subEventOf is for modelling the hierarchy of events. The values of property concerns are external links to instances of owl:Thing. { AtomicEvent, refers to an instantaneous occurrence of interest. { ComplexEvent, may be built up from a set of other events that hold certain temporal relationships or satisfy constraint conditions on their attributes. The property causedBy captures causality among events. { EventStream, is a timely sequence of individual events that come from a data source. The property inStream associates events to streams that come into being by repeatedly executing SPARQL CONSTRUCT queries. Here, the queries are expressed using SPARQL Inferencing Notation (SPIN7), and stored as instances of sp:Construct associated with event streams via generatedBy. SPIN is essentially a set of vocabularies for writing SPARQL queries in RDF. This way, machines can carry out further reasoning over queries, such as checking their correctness. Similar to subEventOf, the property subStreamOf models the hierarchy of event streams.
E orts have already been made to build the conceptual model of events,
and relevant ontologies are found in [
From an arti cial intelligent perspective, it is believed that an event may
have ve key features: a location, a time, active agents, factors and products.
Thus, the Event ontology de nes one property for each of the ve features.
However, at least in some cases like the iServe logging analysis, location might
not be applicable. Because the range of the time property is arbitrary temporal
entities, i.e. either Instant or Interval de ned in the OWL Time Ontology [
EVent Ontology (EVO) is another representative event model [
As highlighted earlier, Linked Data are published by independent providers, following di erent schemas that are not designed for being processed by CEP
engines. Therefore, it requires ontological mappings [
log : hasAction log : Action ; log : hasAgent foaf : Agent . time : Instant a rdfs : Class . time : inXSDDateTime rdfs : domain time : Instant ; rdfs : range xsd : dateTime . log : Action a rdfs : Class . log : ServiceRepositoryLogEntry a log : LogEntry . log : ItemCreation rdfs : subClassOf log : Action ; log : createdItem log : Item . log : ItemDeleting rdfs : subClassOf log : Action ; log : deletedItem log : Item .
Extensions are made to the EVO-Core ontology to describe the iServe user behaviours. Two new concepts ServiceCreated and ServiceDeleted are dened as sub-classes of AtomicEvent. Moreover, two sub-properties of concerns, concernsAgent and concernsService are also added to the ontology. The ServiceCreated event happens when a new service is uploaded to iServe, whereas ServiceDeleted occurs when it is removed by an iServe user. As the name implies, concernsAgent and concernsService respectively keep the user's FOAF ID and the URI of the service. Finally, LoggingSystemError is de ned as a ComplexEvent, which can be caused by not only a wrong temporal relationship, i.e. a ServiceDeleted event occurred before a ServiceCreated event, but also by the absence of the corresponding ServiceCreated event of a ServiceDeleted event.
Formulae (1) and (2) formalize the morphism from the RDF schema of iServe logs to the extended EVO-Core ontology:
ServiceRepositoyLogEntry(l) ^ hasAction(l; a) ^ hasAgent(l; g) ^ hasDateT ime(l; i)^ inXSDDateT ime(i; t) ^ ItemCreation(a) ^ createdItem(a; s) ServiceCreated(e)^ concernsAgent(e; a) ^ concernsService(e; s) ^ timestamp(e; t) ServiceRepositoyLogEntry(l) ^ hasAction(l; a) ^ hasAgent(l; g) ^ hasDateT ime(l; i)^ inXSDDateT ime(i; t) ^ ItemDeleting(a) ^ deletedItem(a; s) ServiceDeleted(e)^ concernsAgent(e; a) ^ concernsService(e; s) ^ timestamp(e; t) (1) (2)
Listing 2 elaborates the SPARQL query written according to formula (1). It is not hard to come up with a similar one from the other mapping formula, which is left out from this paper due to space limitations.
CONSTRUCT { _:v rdf : type ec : ServiceCreated ; ec : timestamp ? time ; ec : concernsAgent ? agent ; ec : concernsService ? service ; ec : inStream ec : iServeStream . } WHERE { ? entry rdf : type log : ServiceRepositoyLogEntry ; ? entry log : hasAgent ? agent ; log : hasAction ? action . ? action rdf : type log : ItemCreation ; ? action log : createdItem ? service . ? entry log : hasDateTime ? instant . ? instant time : inXSDDateTime ? time .}
To enable reasoning on the SPARQL queries for ontology translation, the SPARQL query above is converted into the syntax of SPIN (shown in Listing 3), before being stored in an RDF repository. There have been the tool8 and online bidirectional converter9 between SPARQL and SPIN. _: b1 sp : varName " action "^^ xsd : string . _: b2 sp : varName " service "^^ xsd : string . _: b3 sp : varName " instant "^^ xsd : string . _: b4 sp : varName " agent "^^ xsd : string . _: b5 sp : varName " time "^^ xsd : string . _: b7 sp : varName " entry "^^ xsd : string . [] a sp : Construct ; sp : templates ( [ sp : object ec : ServiceCreated ; sp : predicate rdf : type ; sp : subject _: b6 ] [ sp : object _: b5 ; sp : predicate ec : timestamp ; sp : subject _: b6 ] [ sp : object _: b4 ; sp : predicate ec : concernsAgent ; sp : subject _: b6 ] [ sp : object _: b2 ; sp : predicate ec : concernsService ; sp : subject _: b6 ] [ sp : object ec : iServeStream ; sp : predicate ec : inStream ; sp : subject _: b6 ]) ; sp : where ( [ sp : object log : ServiceRepositoyLogEntry ;
sp : predicate rdf : type ; sp : subject _: b7 ] [ sp : object _: b4 ; sp : predicate log : hasAgent ; sp : subject _: b7 ] [ sp : object _: b1 ; sp : predicate log : hasAction ; sp : subject _: b7 ] [ sp : object log : ItemCreation ; sp : predicate rdf : type ; sp : subject _: b1 ] [ sp : object _: b2 ; sp : predicate log : createdItem ; sp : subject _: b1 ] [ sp : object _: b3 ; sp : predicate log : hasDateTime ; sp : subject _: b7 ] [ sp : object _: b5 ; sp : predicate time : inXSDDateTime ; sp : subject _: b3 ]) .
Listing 4 outlines a log entry in iServe, against which executing the SPARQL query shown in Listing 2, we can get the rst event in Listing 5. log : logEntry1271364976707 a log : ServiceRepositoyLogEntry ; log : hasAction log : action1271364976707 ; log : hasAgent <http :// revyu . com / people / dong > ; log : hasDateTime time : instant1271364976707 . log : action1271364976707 a log : ItemCreation ;
log : createdItem service : VEHICLE_PRICE_SERVICE . time : instant1271364976707 a time : Instant ; time : inXSDDateTime "2010 -05 -15 T20 :56:16.707 Z "^^ xsd :
dateTime .
The other two events in Listing 5 are also generated from the iServe system logs, and serve as the examples of ServiceDeleted and LoggingSystemError. : event101307 a ec : ServiceCreated ; ec : timestamp "2010 -05 -15 T20 :56:16.707 Z "^^ xsd : dateTime ; ec : concernsAgent <http :// revyu . com / people / dong > ; ec : concernsService service : VEHICLE_PRICE_SERVICE ; ec : inStream ec : iServeStream . : event107470 a ec : ServiceDeleted ; ec : timestamp "2010 -04 -15 T20 :56:38.377 Z "^^ xsd : dateTime ; ec : concernsAgent <http :// revyu . com / people / dong > ; ec : concernsService service : VEHICLE_PRICE_SERVICE ; ec : inStream ec : iServeStream .
: event108946 a ec : LoggingSystemError ; ec : timestamp "2010 -04 -15 T20 :56:41.546 Z "^^ xsd : dateTime ; ec : causedBy event101307 ; ec : causedBy event107470 ; ec : inStream ec : iServeStream .
With the helps of RDFReactor on code generation and the Drools' capability of manipulating Java objects, what we need to do to empower Drools Fusion to deal with the ServiceCreated and ServiceDeleted events is just adding the following declarations to the DRL le: declare ServiceCreated @role ( event ) @timestamp ( timestampInMills ) end declare ServiceDeleted @role ( event ) @timestamp ( timestampInMills ) end Here, @role tells the CEP engine the type of the declaring entity, and @timestamp tells which attribute will be used as the source of occurrence time of events. 6
This section concentrates on a case study on applying the proposed framework to the analysis of iServe logs. First, we are going to answer the question: who are the top ten active users of iServe so far? Here, active users refer to those who own the most services in iServe. To this end, two rules (shown in Listing 6) are de ned respectively for processing ServiceCreated and ServiceDeleted events. Upon submission of a new service, the event generator will put an instance of ServiceCreated into the iServe Stream. As the reaction to this event, the event processor nds the user identi ed by the value of concernsAgent, increases HTML Linked Data
SPARQL EndPoint Linked Data Provider
Event Processor Content RDF Negotiator Generator
Page Generator
Event Generator
Drools Fusion
Timer
Web of Data Generated Java API
RDFReactor
RDF2Go
Event Repository (BigOWLim) the number of services he/she uploaded by one, and updates the time of his/her last action on iServe. Correspondingly, when ServiceDeleted event happens, the number of uploaded service will decrease by one, and the last action time will update in the same way. rule " Service Created in iServe " when $e : ServiceCreated ( ) from entry - point " iServe Stream " then String agent = $e . getAllConcernsAgent () . next () . toString () ; LepHelper . get () . increaseUploadedServiceNumber ( agent ); LepHelper . get () . updateLastActionTime ( agent , $e . getAllTimestamp () . next () ); end rule " Service Deleted in iServe " when $e : ServiceDeleted ( ) from entry - point " iServe Stream " then String agent = $e . getAllConcernsAgent () . next () . toString () ; LepHelper . get () . decreaseUploadedServiceNumber ( agent );
LepHelper . get () . updateLastActionTime ( agent , $e . getAllTimestamp () . next () ); end rule " Logging System Error Detecting " when $e : ServiceDeleted ( ) from entry - point " iServe Stream " and ( $e1 : ServiceCreated ( this after $e && concernsService == $e . concernsService ) from entry - point " iServe stream " or not ( $e1 : ServiceCreated ( concernsService == $e . concernsService ) from entry - point " iServe Stream " )) then
LepHelper . get () . createLoggingSystemErrorEvent ($e , $e1 ); end
Secondly, in order to guarantee the accuracy of analysis results and to detect errors in logging system, we de ne the third rule of Listing 6. It detects the complex event LoggingSystemError, which occurs when a ServiceDeleted has a missing ServiceCreated, or when a ServiceDeleted event happens before the ServiceCreated of the same service. Note that, for the ease of understanding, Drools rule attributes, e.g. no-loop, salience, lock-on-active, etc., are omitted from Listing 6. In addition, LepHelper is a Java class wrapping various methods for accessing SPARQL endpoints, invoking EVO-Core API, and persisting the analysis results as RDF triples.
The schema below is a simple vocabulary for describing the analysis results: : Agent rdf : type rdfs : Class . : uploadedServiceNumber a rdf : Property ; rdfs : domain : Agent ;
rdfs : range xsd : nonNegativeInteger . : lastActionTime a rdf : Property ; rdfs : domain : Agent ;
rdfs : range xsd : dateTime .
According to the schema, it is not hard to come up with a SPARQL SELECT query retrieving ten users ordered by the number of services they have uploaded to iServe: SELECT ? agent ? number ? time WHERE { ? agent a ia : Agent ; ia : uploadedServiceNumber ? number ;
ia : lastActionTime ? time . } ORDER BY DESC (? number ) DESC (? time ) LIMIT 10 Especially, when the numbers are the same, they will be ordered by the last time they accessed iServe. The query results are displayed in Fig. 4. For privacy reason, some of the FOAF IDs have been concealed.
In this paper, we present a practical way in which Linked Data can be fed into CEP engines. EVO-Core, a lightweight but generic ontology, is built to describe events in RDF, and SPARQL-based ontological mapping technique is adopted to transform Linked Data into events conforming to EVO-Core. We also introduce the work ow of developing an application equipped with the event processor. The development of a simple analytical system of iServe logs shows that the proposed framework is feasible.
Our future work will focus on the publication of analysis results according
to SDMX-RDF [
Acknowledgements This work was funded by the EU project SOA4All (FP7215219).