In the previous posting I've shown some possible anomalies when dealing with derived events. The picture above shows a snowfall as a derived event, actually where I am located, in Haifa, this is a very rare event (once every 20 years for a few minutes). There are various types of derived event, this time I'll discuss derived events of two different patterns: sequence pattern, and time-out pattern. Example 1: The pattern is: if a sequence of events E1 and then E2 occur, derive event E3.
Let's assume that event E1 occurs at 9:00 and arrives to the system at 9:02, and event E2 occurs at 9:30, and arrives to the system at 9:31. The derived event is derived by the system in 9:33. The question is when does event E3 occurs. One can think of three logical possibilities:
I: E3 occurs when it is produced in 9:33; the rationale: since it is a virtual event, it does not occur in reality, and exists only since it is derived by the system.
II: E3 occurs when the last event that triggers the pattern matching occurs, in this case, in 9:30; the rationale: the derived event occurs when the patterns conditions are satisfied in reality, and this occurs when E2 occurs.
III: E3 occurs over the interval [9:00, 9:30]; the rationale: the derived event occurs over the interval of all participating events.
Example 2: The pattern is time-out (absence event). Example: if there is no bid for an auction by the end of the auction time, derive an event "no bidders".
Scenario: A bid was issued in 9:00 and is valid for 2 hours, in 11:00 it is closed without any bidders, in 11:02 the system issues the derived event.
We have similar three alternatives here:
I: The no bidders event occurs in 11:02, the time that the derived event is issued.
II: The no bidders events occurs in 11:00, when the "bid close" event occurs, which completes the pattern.
III: The no bidders event occurs during the interval [9:00, 11:00] --- since the "absent" event relates to the entire interval.
Like some other cases, there is no single solution that fits all cases; and the actual semantics of a specific case is a matter of policies, we see here three policies, which seem to cover most cases, but not necessarily all, that's why there is a need also to enable explicit derivation of the occurrence time of a derived event, i.e. the value of the occurrence time itself can be computed and derived.
More about temporal issues -- later.
2 comments:
Once while discussing modeling of events over beer, it happened that some of the participants were getting very caught up in the idea of "when something happens" to the point of distracting from the goal of the modeling (it was not an exercise in abstract thinking).
In the end, it was decided to forget about the question of when something happens, because it is too philosophical. Instead, ask more descriptive questions such as "what time should be used to compare this event to other events for the purpose of processing?" or "what time should be displayed to the user as a stamp for this event?"
Incidentally, the answer to the question of processing order seems to be that an event may be sorted in different ways by different system components. In a complex case, it might even be confusing to label a particular time as the time of occurrence, since multiple orderings are used within the same EPN.
Hi Hans.
As you rightly point out, the philosophical question is not that interesting, what is interesting is the practical implication, such as: the relative order to other events.
Displaying time-stamp to the use also falls in this category.
cheers,
Opher
Post a Comment