On relationships among: derived event, composite event, complex event and situation

This is the water park "Luna Gal" where I am planned to spend the late afternoon with my children (it is my wife's turn to have a business trip this week) as part of a fun day for employees, meanwhile I am again at my (air-conditioned) office with the morning coffee and the Blog. One of my somewhat neglected obligations that I am trying to catch up these days are writing some terms to the encyclopedia of database systems, since we are in the glossary era, I would like to answer a FAQ question about the relationship between four terms: derived event, composite event, complex event and situation. The first three are glossary terms, the last is not, but is being used a lot in the community jargon. Tim Bass has recently posted in his Blog a simple solution model which is originated in the experimental psychology research.


The following illustration clarifies the relationships:

Derived event is an event that is created as a result of a computational derivation process as a function of one or more events.

Complex event is an event that is an abstraction of other events.

Composite event consists of collection of events that satisfy some pattern.

These are not the glossary definitions but they are explanations of the definitions that will enable to determine the relationships. As we can see not every derived event is a complex event - a derived event can be just an enrichment of a single event, and as such not a complex event, on the other hand, complex event can be created by explicit grouping of events and not by computational derivation, thus a complex event may not be a derived event. The relationships between derived events and complex event are - partial overlapping.

On the other hand, composite event is a subset of both complex event (since it is a collection of event and as such an abstraction) and derived (since it is derived by a computational process). Interestingly composite event is not the intersection between derived event and complex event, since the intersection also include scalar derived events that aggregate the raw events but don't keep the collection of events. Thus composite event is a subset of the intersection.

How does situation fit in ? - well, situation is a different beast, it is not some syntactic operation on event, but it is a semantic abstraction that denotes -- something that requires reaction. An event of any type may designate or approximate a situation, for example: fraud suspicion is the situation and a certain pattern is an indication (either exact or approximate) to the occurence of this situation, when there is a determination that a situation has occurred - a derived event may be issued to designate this situation, and the pattern is the condition (again - exact or approximate) for the situation. Note that an event pattern may have some certainty measure (e.g. probability) for the fact whether it designates a situation , not all cases are deterministic.

Does every derive event represent a situation? --- not really. A derived event can be used as an interim event or part of dissemination system and not have semantic role of situation. The same is true for all other event types.

Last but not least --- Paul Vincent in his Blog reported on a tutorial he has given about the ETPS glossary (useful presentation, I'll ask permission to borrow it). He asks a question - whether event inheritence is derived event ? well - let's check the definition of derived -- creating an event as a result of computational process as a function of one or more events. Does it describe the inheritance process ? -- IMHO it does, thus I think that inherited event is a type of derived event, though the derivation process is somewhat different from the derivation process in other cases. more - later.

On the EPTS Glossary

Today, EPTS has announced on the first version of the EPTS event processing glossary. The glossary has been edited by Roy Schulte and David Luckham, with contribution of many people throughout the community. The editors had quite a big challenge, as different vendors have been using different terminology, and this confuses the customers and sometimes owrselves. As you can see in the press release, there are support quotes from the entire community -- vendors, analysts, academic people and customers; this is an indication that the community prefers to have a common terms that everybody will use, instead on constant debates on terms.

The glossary can be downloaded from the EPTS website.

This glossary as one of the editors noted is a "living document" and will be updated periodically, since the area of event processing is still evolving. It is a starting point only, however, since it has been available in various draft forms on David Luckham's CEP portal, the glossary only received traction, and I am meeting people in various places who say that they adopted the terminology. Would I personally define all terms the way it has been defined in the glossary -- not really, and I guess this is true for many people, but since the glossary is a consolidation of various opinions and proposals, the editors have done a pretty good job of making everybody relatively happy, and the EPTS steering committee that consist of people who had initially used different terms, has unanimously approved it - as good enough to serve as first version.

What next ? - if you wish to propose to add more terms, or to modify the definition of existing terms - please use the Wiki on the EPTS website to make comments.

Citing my Irish friend, Brian Connel : friends, romans, countrymen - this is your glossary, help shape its future ! (I am the last year in Israel that has learned Shakespeare's Julius Caeser - so I can identify the source).