The term "derived events" is frequently used in the event processing terminology. Here is an example taken from the Gigaspaces Blog of using the term "derived event". Recent discussion with somebody who is just learning the event processing area, made me realized that we overload the term "derived event". On one hand we define event as "something that happens", and say that a derived event is an event, thus one may assume that derived events also happen. However, the way this term is typically used has some semantic overloading. There are actually different types of derived events.
One type of derived event is really an event that we did not observe directly, but concluded that it happened by observing other events. Such cases is the case of fraud detection, money laundering detection and system problem diagnostics.
Another type of derived event is a notification. We are doing a calculation based on events and the result is notified to some person of application. For example: derived event that calculates the highway fees, based on exit and entry events on the highway, and rate calculated by load on the highway. This is a derived event, however - it does not really stands for something that happens, the happening here is a notification to the driver how much the fees are, there are many derived events of this type.
The question is whether we should make distinction between the two cases. From semantic point of view they are clearly distinct. From execution model and language point of view -- they are indistinguishable; both take events as input, apply some assertions and functions over a collection of event, and create a structured message sent on some channel. From semantic point of view there is a difference, the question is from pragmatic point of view, is this distinction important for somebody that takes any role in the life-cycle of the application. More -later.
