In search of intention language for event processing: revisiting the decision model

I have written recently about the need to establish intention language that will serve as higher level abstractions for event processing.  Last week, I had almost a day without laptop, when my laptop went to the system guys for re-installation of Windows (and thus all the software), due to some repeating failures.  I used one hour for my daily walk, some of the time to bother other people in the team, and had some time left for reading, so I decided to return to the copy of the "decision model" book that I have in my office, something that I had in mind doing since the visit of Larry Goldberg in my lab.    The decision model provides a tabular way of looking at decisions, with various propositions that are intended to enforce consistency, and normalization forms inspired from the relational model.    This expresses decisions that are assertion based,  and are intedned to serve as a semantic layer abouve business rules.   The event processing area is somewhat richer, as decisions can be based on events but also on situations that are based on detection of event patterns, or on aggregation or composition of events.  The results of event processing are derived events that may either trigger an action or issue a notification (which is also a kind of action).   The interesting question is whether this relatively simple tabular model can enrich its semantics in order to express the intentions behind event processing functions.    Getting such a cannonic way may be quite appealing,  however I am not sure it is going to be easy -- one direction to consider in search of intention language for event processing -- more on this one later. 

On intention language - take one

I am in a one week vacation now (not related to the big fire in the Carmel mountain),  had some vacation days to finish before the end of the year, and thought that the week of Hannukah is a good timing.   When I lived in the USA I surprisingly found out that Hannukah became a major Jewish holiday, but this was done due to its proximity to Christmas so that the Jewish children would not be deprived of the holiday season spirit, and the gifts.   In Israel, Hannukah is a minor holiday, people are working (unless they take vacation), and it is a week vacation in schools, thus the timing of my own vacation, spending time with my daughters. 

Driving one of my daughters today got me a good example why an "intention language" is needed if we want "business users" to program event processing systems.  I have a Bluetooth support in my Toyota Verso car, and with some effort I succeeded to program my mobile phone to connect to it, so if I am getting a call while driving I don't have to touch the phone, but can answer using the car's buttons, and hear the voice on the car's radio system.   

Today,  I realized that I need to reset the phone, something was not working properly, and I closed and opened it again -- did it while parking, I am not playing with the phone while driving!   when the phone came to live again it was working properly, but did not connect to the car's Bluetooth.  I realized that the connection is event-driven, assuming that the phone is operating when one enters the car, and the car is the one who is starting, so I tried to validated this theory by turning the car's engine off, and then turning it on again, and as I assumed, this did the trick.   


What I really want to have is an intention language:  whenever the car engine and the phone are both working, the phone should be connected to the car's Bluetooth.   


The way it really works is:   When the car is starting and the phone is already working, connect it to Bluetooth.


In most cases there is no difference between the two, but in case where the car is already working, it really does not.


When writing things in event-driven way -- it sometimes difficult to capture all possible cases, so we need and intention language which should be then translated to an event-driven one.    This is not an easy task, but one of the big challenges ahead.  I wonder if there are any relevant work, not just for simple cases like this one.
More - later.