On events versus data

The word "data" always reminds me of the android from Star Trek The Next Generation whose name was data. The word data (in computing) typically is very general and refers to anything the is represented on digital media, the picture of data above is also a piece of data, like many other things. The word "event" also has a broad term which means something that happened.

Recently Paul Vincent wondered in his Blog about the difference between event and data, as some people think that events are footnotes to data. Since by the definitions above, obviously event and data are not really the same, I'll try to talk about the touch points among them, since those are the reason of misconceptions.

There are various touch points between events and data:

1. Event representation contains data. Event is represented in the computing domain by "event object" or "event message" which usually is also is called "event" as a short name. This event representation includes some information about -- what is the event type, where it happened, when it happened, what happened, who were the players etc... Example: the event is "enter to the building", the event's payload contains information that answer questions such as: what building? who entered? when ? and maybe more. The payload of the event is data, it may be stored (see event store), or just pass by the system.
2. Data store can store historical events. Event representations can be accumulated and stored in a data store, for further usage. There are large data stores that collect weather events. Note that in order to navigate in historical events, these events may be stored in a temporal database an area that I've dealt with in the past, sometimes if the events are spatial then it have to be stored in spatiotemporal database.
3. Database can be event producer. In active databases the event were database operations; insert, modify, delete and retrieve, in this case the fact that some data-element has been updated or accessed is the "something that happens" (which may or may not reflect something that happens in reality), and the database acts as event producer and emits event for processing by an event processing network. Note that actually all event producer contains some data that is turned into event, for example transaction instrumentation like what IBM has done in CICS as event producer.
4. Derived events as database updates. An event processing application take events from somewhere as input, does something, and creates derived events, and send them somewhere, this is all event processing is in one sentence, a derived event created in this process may go to an event consumer, the event consumer may be a DBMS or another type of consumer whose action is to update some data store.
5. Event enrichment by data during the event processing. During the event processing operations, sometimes enrichments of events is requested, let's return to the event of a person enters a building, the event processing application deals with security access control, and needs to know what is the person security clearance, this information is not provided with the event which provides only identification of the person, and there need to be some enrichment process in which an enrichment event processing agent accesses some global store, in this case reference data, to extract the clearance value and put it inside the event for further processing.

Thus the main issue is not the "versus" issue but the various relationships between the two terms.

On event processing and philosophy

In case you don't know I have a BA in Philosophy, at later phases in life I also studied for MBA, and for Ph.D. in computer science, but I still have a soft spot for philosophy, it was the most fun to study, and I also think that it has been very useful for me to learn clear and exact thinking, this is an important asset I got from these studies. As I moved away, I did not keep much contact with philosophy, although during my Ph.D. studies I took an advanced logic course in the philosophy department with the late Professor Hugues Leblanc, one of the giant scholars I have ever met, one of the leading logicians of our times, and a great person.

Recently I had an Email exchange with an interesting person, Ken Archer from Telogical systems, whom I met in Nashville earlier this month. Ken has participated recently in a tutorial on ontology of events, given by philosophers, I have copied the description he sent me:

These were philosophical ontologists in dialogue with ontology engineers (primary in biomedical domains, where ontologies have found relatively high acceptance). The philosophers’ starting premise was that the top level distinction in ontology is between continuants (entities that endure through time while maintaining their identity) and occurrents (entities that happen, unfold or develop in time). Continuants and occurrents are orthogonal to each other, as continuants participate in occurrents (e.g. surgeons and patients participate in surgery). Following from this premise was the claim that, while continuants have received much attention historically in philosophy, occurrents have not. As a result, we are much more comfortable talking and generalizing about continuants (objects) than we are about occurrents (processes, events), and we often tend to reify occurrents into continuants as a result.

From this starting point, the philosophers embarked on a philosophical ontology of occurrents that they said reflected the best results of current philosophical research. The bulk of what they had to say can be found in the Basic Formal Ontology, beginning on page 59 (the diagram for their occurrent ontology is copied below). I’ve found the Basic Formal Ontology to be very helpful in all of my modeling. As a result, these philosophers would definitely say that we can talk of types of events or processes, as we do in event processing, and argue that the reason we tend not to speak of types of events/processes is this bias for continuants over occurrents. The research project of these ontologists, then, is to provide an upper ontology of occurrents.

I think that while we are constructing our terminology and conceptual models, we can go back to the roots and look at the formal ontology work. I need some free time to digest it, but it looks interesting.

More on this - later.