tag:blogger.com,1999:blog-7831813422886730737.post6573737809551355364..comments2023-10-08T10:44:28.524+03:00Comments on Event Processing Thinking: If SQL extensions are the answer then what is the question ?Opher Etzionhttp://www.blogger.com/profile/10791357917675270335noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-7831813422886730737.post-38945566924625815402007-09-16T16:59:00.000+02:002007-09-16T16:59:00.000+02:00Dear Opher, please allow me to spice it up even mo...Dear Opher, please allow me to spice it up even more.<BR/>We are assuming that event processing is somehow exclusively related to pattern matching. Within the boundaries of this assumption, some suggest that SQL is well suited to express a set of patterns. You are clearly suggesting that there might be some, possibly more viable, alternatives. Here I do not want to discuss about alternatives to SQL (that might or might not be well suited to support pattern matching), however, in the past, we have certainly seen some quite powerful alternatives based on strongly declarative syntax. Talking about religion(s) and Prolog, you might remember that we were once divided in two tribes – the former worshipping backward chaining, the latter forward chaining. I was a devoted member of the second tribe and I have been working quite a lot with tools like the Automated Reasoning Tool (Inference). This kind of tool (like others) was implemented in Lisp and exposed a very expressive set of constructs to support pattern matching. The same tool (like others) was rule based, each rule being made of a Left Hand Side (expressing the pattern) and a Right Hand Side (expressing the action to be fired). The rule executive was based (like others “production” systems) on the RETE algorithm. Here I’m not suggesting to adding yet another floor to THE tower, I’m just reminding that there is a history of alternatives. (I have to admit, though, that it was quite nice to see some of these historical milestones reappearing, here and there, recently ).<BR/>What if we contemplated another possibility? What if we started to think about event processing as something not exclusively related to pattern matching?<BR/>In this alternate landscape, it might be less expensive to tackle the kind of problems you have submitted to the CEP Interest Group. In general, I think that a very subtle assumption that might be exposed by a pattern matching/aggregation approach is that, in general, a reaction might depend on the capability to establish a relationship amongst a <B>set</B> of assertions (or events, in our case). This might, even more subtly, lead to a logic that is quite batch oriented, rather than event driven: it might be quite daring to assume that a <B>set</B> of events will happen at the same time or that a <B>set</B> of events will have happened at a certain point in time. Thus whenever we describe a pattern referencing a <B>set</B> of events we are, likely, looking at something that has happened in the past, we are aggregating a set of assertions (or facts) and possibly we are not doing anything really different from what analytics do, such as <B>“finding trends in time-series”</B>.Anonymousnoreply@blogger.com