We’ve moved to http://www.haleyAI.com

March 14, 2008

In the names of CEP and BPM

Have you heard the one about how to drive BPM people crazy?

Ask them the question that drives CEP people crazy!

Last fall, at the RuleML conference in Orlando, was the first time I heard a consensus that a standard ontology of events and processes was sorely needed.  I’ve had a number of discussions with others on this over the interim until today’s posts by Paul Vincent, summing up an OMG meeting in Washington, DC, and Sandy Kelmsley’s comments on a survey of 590 business process modeling notation users.  

  1. Apparently, the broader OMG feels the same need for “event semantics” we discussed in Florida.
  2. In addition, BPMN users indicate that too many event types complicate process modeling.
  3. Finally, Bruce Silver dives a little deeper in two recent posts, one which responds to the authors of the BPMN survey and the other discussing whether BPMN will actually become portable, among other things, including events.

For me, the Great BPMN Debate boils down to two things:

  1. Whether BPMN has too many features
  2. That BPMN is missing semantics

I like BPMN.  I wound not want to sacrifice much.  But as a customer, I would think interchange is critical.  Regrettably, Mr. Silver points out some problems serializing to XPDL and other issues with vendor coverage.  We are a ways from effective standards for rules or BPM, it appears.  By effective, I mean standards supported by vendors that actually facilitate interchange between vendors.

  1. XPDL may not be enough for BPM.
  2. Rule vendors at the Business Rules Forum openly agreed that PRR is too low level for effective interchange given all their value-added (which I do not question)
  3. RIF will be much better than PRR but it will still not facilitate effective interchange between BRMS vendors
  4. SBVR has little traction and no effective implementation (yet)

One problem with all these standards, and even the web ontology language (OWL), is that they lack a common ontology.  That is, they are syntax lacking shared semantics.  Until they share some semantics, integrating or interchanging between them will remain imprecise , unproductive, and overly technical.  Everything but technical rules and models (e.g., vocabulary) will remain locked in.

BPMN is overwhelmed by events

Just reading Mr. Silvers post, you find start and end events, throwing and catching events, intermediate events, exclusive events, timer, message, error and terminate events.  And there are more.  Too many, BPMN users agree, according to the survey cited above.

How many different kinds of events are there (or should there be)?  For now, I’m going with 2.

What is an event?

Ask any complex event processing (CEP) vendor!  It will drive them crazy or you will get a long-winded answer. Or, like me, they might say that it is something that happens or occurs.

At first, most people think of events as occurring at a point in time.  After some discussion, however, most people agree that events are things that we view as occurring instantaneously, even if they take a day, such as last year’s 4th of July picnic, which we might also call an occasion.  Events, like the lights going on or a starting gun firing, might indeed be effectively instantaneous, in which case we would not call them occasions.

There is more to the difference between occasions and instantaneous events, however.

What occurs or happens?

Is an event an occurrence or something that occurs?  The difference is  similar to the difference between days, such as Friday versus March 14, 2008.  One is what BPMN would call an event type and the other is an event.  Well, not exactly, I doubt BPM folks would be happy thinking of a day as an event.  Perhaps they would prefer that the start or end of each Friday was a type of an event and that the start of this Friday (i.e., today) was a specific instance of the “start of a Friday” event type.

For those who read about understanding time, the difference between event types and events is similar to the difference between specific and recurring times.  The semantics of introducing different types for starting and ending events is troublesome, however.  Especially if how they are different is not specified semantically.

Generally, for all X, I do not like X “types”. When we talk with friends other than colleagues, using the word “type” confuses them.  When talking to non-technical folks, instead of saying “event types”, why not just say “events”?  Come to think about it, why don’t we talk about process types?  (I’m sure someone thinks BPMN needs them!)

When is a process not an event?

Most people would agree that things happen.  Most people would also agree that events happen.  The word “occur” is interchangeable with “happen” here.  Do you agree that processes, like events, also occur or happen?

If specific instances of events are occurrences of “event types”, what is a specific instance of a process?

If celebrating the 4th of July is a process and last year’s 4th of July picnic was an event, could an instance of a process be an event?  Or, is every instance of an event type an occurrence of a process?

Yes and No.  Yes, but, for all X, I do not like X “instances”, for the same reason that I do not like X “types”.  In other words, yes, occurrences of processes can be viewed as events.

But no, some events are not processes.  For example, the start of a process can be viewed as an event, as BPMN views it, but the start of a process is not necessarily a process in and of itself.  We could recurse into philosophy on this one, I guess, but at some level, the beginning of an explosion stops being interesting from a process perspective.

Avoiding philosophy as much as possible while remaining semantic:

  1. Occurrences of processes “are” (can be viewed as) events.
  2. Events occur instantaneously or over an interval of time.
    • That is, events occur at a point in time or they have a duration.
    • In other words, an event is either instantaneous or durative.
  3. Durative events are occurrences of processes.
  4. Instantaneous events occur at the beginning or end of processes.

Ontologically, a process is disjoint from an instantaneous event but both are events.

Getting this right is important, not only for helping CEP cross the chasm, but also for integrating BPMS with BRMS.  Whether or not they agree with me, OMG and others need to answer the question:

Are processes and event different and, if so, how?



  1. Hi paul,

    I’m curious to hear what you think OWL. I’ve studied it a bit over the last few years and I am left with several important questions.

    1. since very few tools use OWL to model entities and/or domain models, would OWL be better, if it extended XML Schema instead. Atleast that way, most of the modeling tools out there could work with it.

    2. Should the relationships between instances of entities be captured as rules? More specifically, OWL has sameAs, and differentFrom. In my mind, that should be captured with rules using Knowledge base techniques.

    3. should OWL include a rule language? I ask this because people need a way to reason over the ontology.

    4. although many consider building ontologies a different activity than object modeling, the average developer thinks in terms of object modeling. For an ontology to be practical, effective and widely used, doesn’t it have to address object modeling?

    5. OWL is often associated with and used with RDF. I find the triplet design of RDF flawed from a modeling and reasoning perspective. If you could start over and design RDF, what would you have done differently?

    I like the idea of using Ontologies to enhance BRMS, BPM and CEP, but none of the current public specifications seem to be appropriate for real world use.


    Comment by woolfel — March 14, 2008 @ 11:53 am

  2. Although RDF lacks niceties of XML Schema, its generality allowed convergence on the standard. Whether same or different are implemented as rules, there is still a need to represent them. OWL definitely needs a rule language. A few variants of SWSL are there now and RIF is headed there.

    The notion of “object” is really wrong. Developers need to understand that concepts are not necessarily objects. Object-orientation is very implementation-oriented. For example, money or time are not objects, but they are concepts and their semantics is important. Replacing uses of “object” with “concept” is a good first step towards clear semantics and longer lasting designs.

    I have a few pet peaves about RDF, everybody does! The fact is that its uniformity is both powerful but inconvenient. I wish it could represent quantities without a ton of links and that links could reference other links, but it’s good enough and the train has left the station.

    I am not too caught up on the specifications. The arguments are and should be on what common concepts are and mean. With meaningful standard-independent consensus on such definitions, any standard would be good enough for many practical applications.

    Comment by paul@haleyAI.com — March 19, 2008 @ 6:18 pm

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: