Do “events” have “durations”?

This might seem an odd question, but there are 2 schools of thought here:

  1. An event is a point in time.
  2. An event is an activity that can take a period of time.

Taking the latter view, we can say things like:

  • Earthquake MMM took place from date-time D1 to date-time D2
  • Fraudulant act on account NNN took place from date-time D3 to date-time D4
  • Flight QQ123 was delayed in the period date-time D3 to date-time D4, when it completed disembarkation time T1 late
  • World War 2, an historical event, took place from 1 September 1939 to 2 September 1945.

The problem with this view is that activities, and therefore processes, can therefore be viewed as “events”, which in IT terms can lead to confusion and generalisation. And what about “historical events” like World War 2, which definitely have a duration. But in reality “world war” was a “state” the various nations affected found themselves entangled in – for sure it had a start event (invasion of Poland) and an end event (surrender of Japan), and many many events in between. And indeed many many “predictor events” (or even “causal events”) beforehand.

In event processing terms, we want to predict certain events – when will Earthquake MMM start, and with what strength? – as well as states – Flight QQ123 is now in a “delayed” state. In effect, in the real world, we are concerned not just with event patterns, but also state management and processing. Passengers might not care about the events that lead to their flight being delayed, but they may certainly care about being delayed!

The EPTS Glossary specifies events as points in time as “instantaneous events”. From the EPTS perspective, the 1929 Stock Market Crash was a complex event. At the time it was a “crashing state” for the Wall Street markets – within a period of instability, local rises interspersed with sharp falls. Top-to-bottom, the period covered Sept 1929 to July 1932, and an overall 89% decline in the Dow.

So perhaps History should be formalised, as a science, using event terminology?

Events versus Data

Event processing embeds, but not subsumes, data processingA recent question came up regarding the difference between “events” and “data”. After all, to a DBA, an “event” is just another data record but with a timestamp! Of course, that is the “static” view of an event – useful only for archiving and “post (-event) processing” activities like data mining, BI and analytics.

However, a more technical answer is that data is derived from events. Customer data? Derived from customer registrations and associated checks – all events. Amount owed? Derived from purchase events. And so forth. So a better answer for the DBA is that “data” is just “information collected from, and associated with, prior events“.

In Complex Event Processing, of course, we are processing this “event data” as it occurs (within the limitations of our system latency, of course!). Typically this event data is correlated with previous events which can be either “relatively recent” (and considered as stored events or event objects) or “historic” (and considered as traditional data), although these are necessarily imprecise concepts. Access to historic data is typically carried out in CEP tools through good-old-database-services: calling the operational data store associated with legacy systems, for example. Another approach is to “event-ise” the legacy applications, extracting new events from logs and data sources as they occur.

TIBCO examples of the above approaches to data access in event processing are TIBCO BusinessEvents’ database interface (what we call DBConcepts) and TIBCO Adapters (e.g. for ERP and HR systems).

Notes:

The EPTS glossary does not define “data” but does mention that event objects contain data…