Processing Ubiquitous Personal Event Streams to Provide User-Controlled Support

Transcription

1 Processing Ubiquitous Personal Event Streams to Provide User-Controlled Support Jeremy Debattista, Simon Scerri, Ismael Rivera, and Siegfried Handschuh Digital Enterprise Research Institute, National University of Ireland, Galway Abstract. The increase in use of smart devices nowadays provides us with a lot of personal data and context information. In this paper we describe an approach which allows users to define and register rules based on their personal data activities in an event processor, which continuously listens to perceived context data and triggers any satisfied rules. We describe the Rule Management Ontology (DRMO) as a means to define rules using a standard format, whilst providing a scalable solution in the form of a Rule Network Event Processor which detects and analyses events, triggering rules which are satisfied. Following an evaluation of the network v.s. a simplistic sequential approach, we justify a trade-off between initialisation time and processing time. 1 Introduction The increase in the use of smart mobile devices provides us with ample data regarding the users surroundings, activities and information. This data can be collected from various applications, embedded physical sensors (such as GPS), and users online presence. As this information is heterogeneous in nature, it cannot be readily unified under a common domain model. This limits the potential of having smart devices operating on this combined user data, in order to provide added value. If this limitation is addressed, smart devices can become increasingly aware of a user s activities, situations and habits. As a result, daily repetitive tasks (e.g. changing the mobile mode to silent when arriving at work) can be automated or suggested to the user. The di.me 1 project addresses the above limitation by unifying the user s personal information across various heterogeneous sources, including social networks and personal devices, into one standardised data representation format. di.me restricts the working Knowledge Base (KB) to cover a personal closed-world environment; introducing and extending ontologies modeling the user s Personal Information Model (PIM). Thus we represent both information about me 2 (such as current location, nearby persons, live This work is supported in part by the European Commission under the Seventh Framework Program FP7/ (digital.me ICT ) and in part by Science Foundation Ireland under Grant No. SFI/08/CE/I1380 (Líon-2) term coined by David Karger in the blog:

2 2 Lecture Notes in Computer Science posts, etc) and for me 2 (such as calendar, s, contacts, etc), rather than just the latter, as covered by the Social Semantic Desktop [8]. The availability of the di.me PIM enables us to tap this personal data and allow users to define declarative rules. In di.me, we develop a scalable solution that assists the user with daily repetitive tasks within a personal information sphere. This paper s objectives are to: 1. Enable the declarative representation of event patterns and associated actions (i.e. rules), so as to enable both human users and their machines to make sense of them; 2. Create an Event Processor that interprets declarative rules, detects events and triggers the desired actions; 3. Evaluate the performance and scalability of the Event Processor implemented. The rest of this paper is organised as follows: Section 2 compares related work; Section 3 and 4 focus on the DRMO ontology and Event Processor respectively; whereas Section 5 presents the process and results of our evaluation. Future work will be discussed in the concluding remarks in Section 6. 2 Related Work Every solution which implements event processing requires an underlying rulelanguage. Systems such as [2] propose rule languages which are specific to their particular framework. One major issue in such approaches is that the modelled rules cannot be easily reused on other frameworks. RuleML 3 is an XML markup language which allows rules to be defined using a formal notation. Since our user-defined rules are dependant on PIM data, the use of the Resource Description Framework (RDF) to model rules was a natural choice. In contrast to XML-based frameworks, RDF helps us achieve semantic interoperability more easy [4]. Since in di.me we strive to have one unified model to represent the user s KB, XML based rules would need to be transformed into RDF prior to being stored in the user s PIM. Another advantage of RDF over XML is that known knowledge can be reused in rule instances having the same semantics, thus for example saved rule conditions can be reused in other rule instances. Complex Event Processing (CEP) and Rule-based systems are commonly used to allow rules to define how perceived data (or events) is processed. Whilst CEP (using the Event-Condition-Action pattern) rules are only triggered by specific events and do not need advanced matching techniques such as RETE, production rules are constantly being monitored for activation using such algorithms. The DRMO vocabulary allows users to express rules whose conditions can be expressed in a sequential fashion using the succeeded by and preceded by operators, though rules are not necessarily activated via specific events. Therefore DRMO rules can be classified as production rules with the added value of temporal constraints. Our approach in creating an event processor is to exploit CEP properties that enable the use of temporal constraints in rules and perceive data from multiple sources, whilst having a rule processing algorithm to filter and trigger relevant rules. Traditionally, the Rete algorithm [5] is used in rule-based systems to match facts with rule patterns. This algorithm was extended by various efforts 3

3 Lecture Notes in Computer Science 3 including in [9], where the authors tackle the missing temporal aspect to support complex event detection. One main problem of the original Rete Algorithm is that values in the network should be explicit, where non-constants and variables requiring further querying in a KB are not allowed. In this paper we create a Rule Network based on the idea of the Rete network, supporting the two mentioned shortcomings; temporal aspect, and allowing implicit values in the tree. Unlike Rete, the proposed Rule Network will be used to efficiently filter rules, rather than to match conditions with nodes. 3 di.me Rule Management Ontology (DRMO) The Rule Management Ontology (Figure 1) concepts are inspired by the Event- Condition-Action (ECA) pattern. The ECA pattern is used in event-driven architectures, where the event specifies what triggers the rule, what conditions to specify, and what actions are executed, unlike in our case where DRMO rules do not expect any transaction event signals (such as on update or on delete ) to invoke the rule. The DRMO is based on the following rule pattern: if R = {a 1,.., a n } ; R = {c 1,..., c m } ; C m = {c m1,..., c mn } (1) where R represents a rule that consists of a combination of conditions c m, triggering one or more resulting actions a n. c m consists of a number of constraints c mn, possibly recursive. In theory, constraints can be applied recursively, thus allowing an infinite number of embedded conditions. For practical reasons, we expect applications of DRMO to set a limit on the amount of embedded conditions (more on this later). We refer the reader to [3] or the schema online 4 for a full description of the ontology. 3.1 Defining Rules Fig. 1. An extract of the Rule Management Ontology 5 Figure 2 demonstrates how a user can define a rule using the intelligent di.me User Interface(UI) [7]. The defined rule consists of three adjoined conditions (a specific usercreated Situation, a Contact and an Image) and an action (share image). The latter two conditions have been constrained. The full rule can be described as: When in Situation going out and in the vicinity of any Contact(s) belonging to a Group Friends and a new Image is created then: Share the Image with that Contact(s). This functionality The full visualisation and description of the DRMO ontology can be found online:

4 4 Lecture Notes in Computer Science is similar to that used in IFTTT 6 services, where users can define rules in terms of condition blocks and actions. JSON 7 is used as a communication interface between the DRMO instances stored in the PIM and the UI. Fig. 2. Creating rules using the Rule Manager in di.me userware 4 Rule Network Event Processor For the Rule Network Event Processor, a network is generated based on the idea of Forgy s Rete network [5], where DRMO rule instances are registered in the event processor, forming a network structure. Rule instances are also transformed into SPARQL queries, each of which is stored in a level above the network s terminal node. An algorithm based on the K-Shortest Path [10] is proposed to filter and trigger candidate rules from the network. The system architecture is illustrated in Figure 3. Different sources send data about the user s activities, surroundings and information as registered in the PIM. A broadcaster broadcasts the new events to the registered processes (the rule network), which is then processed to trigger any rules relevant to the newly perceived event. A garbage collection (GC) service is attached to the rule network to discard any expired partial results stored in join nodes. Below, we first discuss how rules are transformed into a rule network carrying SPARQL queries. Then, we explain the event object and its lifetime in the rule network. Finally we show how the network is processed to filter and trigger those which are satisfied. Fig. 3. General System Architecture Fig. 4. A Rule Network Example

5 Lecture Notes in Computer Science Building the Network In our rule network we define six different nodes. The Root node is the one with no incoming vertices and the Terminal node is the one with no outgoing vertices. Figure 4 is an example of a rule network. Each rule instance registered to the event processor is fed through the root node of the network to start the process of adding rules to the network and transforming them into SPARQL queries. A rule instance is first broken down into a number of conditions defined by the property drmo:iscomposedof. These conditions and their constraints are attached to the network s root as nodes, starting with the Object-Type node (in Figure 4, nmo: ) and finishing with the Rule node (represented as circle nodes : R1, R2, R3), storing the transformed SPARQL query. Then, for each of condition s constraints, we check the drmo:hasconstraintonproperty and add the node to the network (attached to the previously added Object-Type node), followed by the associated constraint value (subject/object) node. These last two mentioned nodes are Triple-type nodes (shown as rectangles in Figure 4) and store the triple patterns required to create the final query. Two conditions (in a rule) can be joined together using the Join node, apart from those linked together with a drmo:or operator. In the latter case, the event processor handles the drmo:or joined conditions as two distinct rules triggering the same action since these are independent from each other (see all supported operators in [3]). An advantage of this decision is that for such queries the response time is decreased, as we are adding less triple patterns to the queries. A Join node refers to two ordered inputs. For each input we store the intermediate query and intermediate result. The advantage of storing intermediate results is that during processing they enable us to check if a rule can be triggered based on the intermediate result. Intermediate queries are used in order to avoid using SPARQL FILTERS to compare the event s occurrence time for rule conditions joined by the drmo:succeededby and drmo:precededby operators. Another advantage of storing intermediate results is that unlike the sequential processor defined in [3], there is no need for an Event Log to keep track of the perceived events. Similar to [9] the ordered inputs are used to check the temporal constraints of a rule. If the join node is a succeededby node, then the left input must be satisfied first in order to trigger the right input (and vice-versa for a preceededby node, where the right input is the first input to be satisfied). There is no particular order for and join nodes. The rule transformation ends with the Rule node, in which the transformed SPARQL query [3] and the action instances are stored. SPARQL allows the fast querying of the perceived events stored in the user s KB. These queries also help in filling the blank in a rule which does not have an explicit value, for example a rule Receive an from <urn:person1> would require a further query to the PIM to get all the addresses linked to <urn:person1>, since the event metadata would contain a raw address (e.g. person1@ .com ) rather than the URI defined in the user s PIM. 4.2 Events and Validity Events perceived by the sensors and stored in the user s KB (PIM), can trigger any userdefined rule. When events are perceived (this could be a created, modified or deleted resource in the PIM), semantic lifting is performed on relevant graphs in order to store

6 6 Lecture Notes in Computer Science the metadata for the event perceived. The event s resource type together with a timestamp, a pointer to the graph this resource is stored in, and the event operation (e.g. Resource Modified), is then broadcasted to the event processor. The lifetime of an event is difficult to predict since different event types might have different time-spans when correlated to other events in rules. In order for the rule If I receive an succeededby a new document created to trigger, two events (receive an ) and (new document created) need to occur after each other. This could lead the rule to trigger at an indefinite time if the first event does not expire after a certain time. On the other hand, premature event expiry might also lead to relevant rules being missed. In our system we employ the consumption mode technique, maximum event lifetime technique, and the time-based windows technique, similar to how these are described in [9]. The first technique is used to keep the most recent resource URI in a join node. On the other hand the maximum event lifetime expires resource URIs in join nodes after an X amount of time, irrelevant of the resource type, whilst for the last technique, these expire according to a time period assigned to the respective resource type. Events defining a context state [1] (e.g. current availability) are automatically invalidated and removed from the join nodes according to the changed state. 4.3 Processing the Network Algorithm Algorithm 1: Processing Rule Network to trigger rule(s) from detected events Data: Perceived Event E; Rule Network N; ResultSet S get resource type T for event E ; P L ksp(n,t) ; from P L find common subpaths C p ; while path P in P L do if path P contains join node J then inputpath get left or right input of P in J ; if J = AndNode then inputpath.result execute(inputpath.query) ; checkeventjoinnode(n, inputp ath, J) ; continue iteration ; else if path execute(p.rule) null then remove all paths in P L where P is not a subpath (C p) ; S.add(P.rule) remove all paths in P L where P is a subpath (C p) ; Procedure checkeventjoinnode(n,p,j) Input: Rule Network N; InputPath P ; JoinNode J if J = SucceededByNode then if inputpath is the left input then inputpath.result execute(inputpath.query) ; else if left input result is not empty then if execute(inputpath.query) null then S.add(P.rule) ; if J = PrecededByNode then if inputpath is the right input then inputpath.result execute(inputpath.query) ; else if right input result is not empty then if execute(inputpath.query) null then S.add(P.rule) ;

7 Lecture Notes in Computer Science 7 In contrast to the Rete Algorithm [5], the improved processor we introduce does not process the network by matching patterns, but aims to efficiently filter and find candidate rules. This is done by forming a subgraph, with the perceived resource type as the root node. Algorithm 1 shows how the processing of the network is done. Candidate rules are filtered (P L ) using Yen s K-Shortest Path algorithm [10]. Common subpaths (C p ) are also discovered during the execution of the k-shortest path algorithm. This has the benefit of reducing the number of queries performed to check for potential rules to be triggered. Once a set of paths is ordered, these are iterated and the query in the rule node is executed. Rules whose queries return a result (indicating a rule triggered) are stored in a set which is then passed to the action executor. The rule matcher runs its matching process until all paths (in P L ) are checked. At worst, the matcher iterates on all candidate paths found by the KSP algorithm. When a rule is matched, all other paths which do not have the same condition as the rule in question, are removed and not checked by the matcher. This approach is due to the non-repetitive nature of the network, where rules with the same condition are represented by the same branch in the network. 5 Evaluation Our evaluation serves two purposes: to compare the efficiency of the new networkbased approach to the sequential approach proposed earlier [3], and to investigate its scalability. We base our investigation on a study on the performance of event processing systems [6], which focus on the bottlenecks and the degrading of performance as the load is increased. The authors suggest benchmarking various factors, including the selection and pattern detection. The key performance aspects to prove the scalability of the proposed event processor are: The initialisation of the Rule Network; The selection of rules on event detection; The maximum load of events the event processor can handle. For these tests, we require a knowledge base (KB), DRMO rule instances and event data. As a KB, we use a sample di.me PIM containing data based on various OSCAF 8 ontologies. Test rules were manually created. In the context of di.me, we limit the number of recursive conditions (defined in Section 3 - equation (1)) to 2. For these evaluation tests no repeated rules were used so that the Rule Network event processor is not given an advantage over the Sequential. We also propose the following limits: 50 different rules each having 5 conditions, based on the sample PIM and following a small user study. For the generation of the event data we developed an event generator that generates realistic 9 daily events based on the given PIM and scenarios. The evaluation tests have been carried out on a Macbook Pro, Intel Core i5 with 2.4Ghz processor speed and 4GB of RAM. Data is stored in-memory using Sesame All data and evaluation results can be found:

8 8 Lecture Notes in Computer Science 5.1 Initialisation Test The aim of this test is to measure the time taken to register rule instances in both event processors (sequential vs rule network). We initialise our event processors ten times each, starting with five rules and progressively incrementing the number of loaded rules by five. Figure 5 shows the time taken (in milliseconds), against the number of rules loaded in the event processors with each initialisation. The graph shows that the behaviour of the time consumed in relation to the number of rules loaded in the system is linear. The rule network event processor consistently took more time to initialise than the sequential event processor, due to the extra overhead needed to update the network. Fig. 5. Time taken to initialise Event Processors Fig. 6. No. of distinct events perceived over time 5.2 Filtering Test In this test we measure the time taken (in ms) by the processors to select candidate rules with each event perceived. We use data generated over 24-hours, thus assuming that events in the event log (required only for the sequential event processor) remain valid throughout this period. After loading all 50 rules in both processors, the test was repeated four times, each time producing a number of events until the desired number of distinct types were available on the event log. For the experiment we require that the filtering algorithm returns candidate rules satisfying either of the following criteria: 1. A rule with one condition where the associated resource type (drmo:hasresourcetype) is the same as the perceived event s type; 2. A multiple-condition rule such that one of it s conditions is satisfied by the type of the new event. The graph in Figure 6 shows how the sequential process grows in time as the number of distinct event types increase in the event log, whilst the network filtering process remains constant. This result was expected, since the sequential s filtering process needs to go through all the rules to check their resource types against the distinct event types on the event log, in order to satisfy either of the mentioned criteria. On the other hand the network is built such that the associated rules can be automatically found by forming a sub-graph, using the resource type as the start vertex. The network filtering process takes time in order to sort the possible rules by shortest path first, allowing simple rules to be evaluated before the more complex ones.

9 Lecture Notes in Computer Science Load Testing The aim of this experiment is to understand to which extent the event processors can work sufficiently and in an acceptable manner. For this experiment we created a producer/consumer service, where the producer sends a stream of generated events to the consumer (the event processor), which filters and triggers rules simultaneously. After both processors were loaded with the 50 rules, we ran this test five times, progressively increasing the event load up to a maximum events. We established that an acceptable time-frame for the processing of consumed events should be less than 20 seconds. Since the sequential process failed this test outright, with 100 events being processed in seconds, it was subsequently eliminated from this experiment. Figure 7 shows time time taken (in seconds) to perform all consumed events for the rule network event processor. In particular, we observe that events were consumed and processed in around 2 seconds. In the di.me userware, we do not foresee a user to have anything near events being perceived at the same time. More realistically, we observe that the rule network event processor can process up to 2000 events in a reasonable time ( 0.4 sec), with 100 events being processed in less than 0.1 sec. Fig. 7. Testing time taken to process events From these results we conclude that although during the initialisation stage the Rule Network event processor takes longer than the Sequential event processor, the runtime process for filtering and triggering takes considerably less time, regardless of the load of events being consumed by the processor. The trade-off between the time taken to initialise the rule, and to process events, is justified for the following reasons: 1. The initialisation process is done only once; 2. The difference in milliseconds between both event processors is almost insignificant (to initialise 50 rules, the network takes < 100ms more); 3. The filtering of events takes considerably less time in the network event processor; 4. Even with a load of events, the rule network performs within a reasonable time-frame. 6 Conclusion In this paper we describe an ontology-driven event processor which operates on personal, activities and context; as perceived by various devices and online sources. The

10 10 Lecture Notes in Computer Science event processor compares event streams to the antecedent of declarative rules, defined by a user through an intelligent UI. Prospectively, a JSON-LD 11 serialisation would enable us to interchange DRMO instances, ensuring that the full semantics are retained event at the UI level. Rules consist of various conditions corresponding to items in a unified PIM, and one or more resultant actions. Due to the nature of the rule conditions and their constraints, we propose to represent them by a rule management ontology. This also means that in theory, the personalised user-defined rules can be processed by various platforms. In the future, we also intend to investigate the possibility to enable the automatic rule learning and discovery based on the availability of a user s context history. Defined rules are transformed and registered in a Rule Network, which is then operated upon by the event processor. After initialising the rule network, the system is ready to start perceiving events from multiple datasources. With each new event, the rule network filters candidate rules and triggers any which are satisfied. The proposed network-based event processor is compared to an earlier sequential approach. Evaluation results show that although the rule network takes more time at the initialisation stage, it performs considerably better than the alternative, during both the filtering and triggering processes. In particular, our event processor can process 100 events in less than 0.1 seconds. References 1. J. Attard, S. Scerri, I. Rivera, and S. Handschuh. Ontology-based situation recognition for context-aware systems. In I-SEMANTICS 2013, V. Beltran, K. Arabshian, and H. Schulzrinne. Ontology-based user-defined rules and context-aware service composition system. In Proceedings of the 8th international conference on The Semantic Web, ESWC 11, Berlin, Heidelberg, Springer-Verlag. 3. J. Debattista, S. Scerri, I. Rivera, and S. Handschuh. Ontology-based rules for recommender systems. In Proceedings of the International Workshop on Semantic Technologies meet Recommender Systems & Big Data, S. Decker, S. Melnik, F. van Harmelen, D. Fensel, M. Klein, J. Broekstra, M. Erdmann, and I. Horrocks. The semantic web: the roles of xml and rdf. Internet Computing, IEEE, 4(5):63 73, C. L. Forgy. Rete: A fast algorithm for the many pattern/many object pattern match problem. Artificial Intelligence, 19(1):17 37, M. R. N. Mendes, P. Bizarro, and P. Marques. A performance study of event processing systems. In TPCTC, pages , S. Scerri, A. Schuller, I. Rivera, J. Attard, J. Debattista, M. Valla, F. Hermann, and S. Handschuh. Interacting with a context-aware personal information sharing system. In Proceedings of the 15th International Conference on Human-Computer Interaction (HCI2013), M. Sintek, S. Handschuh, S. Scerri, and L. van Elst. Technologies for the social semantic desktop. In Reasoning Web. Semantic Technologies for Information Systems, volume 5689 of Lecture Notes in Computer Science, pages Springer Berlin / Heidelberg, K. Walzer, T. Breddin, and M. Groch. Relative temporal constraints in the rete algorithm for complex event detection. In DEBS, pages , J. Y. Yen. Finding the K Shortest Loopless Paths in a Network. Management Science,