POSETs and EP: a red herring

Update: for a better explanation of the use of POSET in David Luckham’s book The Power of Events, see this post.

Following up on a post by Marc referencing POSETs and the “event cloud”, I wanted to point something out.

AFAIK, when the term POSET is used in blogs discussing EP (CEP), it is a red herring. It’s of little practical use unless you are a mathematician. If you look at everything written by the POSET-loving portion of the EP community, what they do is discuss a particular data set that could be a TOSET, then make some vague reference to another way of processing that works on POSETS. But they never get as far as to discuss anything specific about this other way of processing, other than the fact that it does not use the total ordering.

They-who-talk-about-POSETs seem most often to be parroting some stuff said a while ago by David Luckham. He used the term POSET to try and differentiate between a system that requires ordering of events and one that doesn’t. You will notice that David hasn’t posted anything about POSETs in a while, and that all the examples of using a POSET from his book simply define another relation (like “caused by”) that has nothing at all to do with ordering (and so, could be used equally on a POSET or TOSET). So in David’s past writing, defining a set of events as a POSET is equivalent to stating that we will choose not to use their order when determining causality. It has nothing to do with using the set as a POSET.

A POSET is just an algebraic term. It is a little less restrictive than a TOSET, so if you can prove something for a POSET rather than a TOSET, then you have made a more general, and thus better, statement. But beyond algebraic proofs, POSETs are not useful and here’s why:

A POSET is a set on which some pairs of elements don’t relate via ordering. Fine, that’s understandable. But every method of detecting patterns requires exactly at least one relation between the elements (events). There are uncountably many relations that don’t exist on every set. But to do anything with your data, you need to find relations that do apply.

So here is the one example of a useful way to use a POSET: If you have a POSET (some people might call this a “cloud”) then some of your events do relate via some ordering. So you can partition your events into sets that are ordered by this ordering (and you could call these “streams” but I think this is misleading). Now you have just found a relation that you might be able to use in detecting patterns. Of course, there are probably several ways to order events.

Other than this, you can’t model a POSET because there is specifically nothing to model. To start modeling, you have to locate the relations that do apply between events, in addition to recognizing the ones that don’t.