Thursday, June 4, 2009

On temporal semantics of events - or when has the shimpent not arrived ?




In the early 199o-ies, my home away from home, has been Berkeley, where I stayed for a joint work with Arie Segev on temporal databases. In one of the weekends I have strolled along the famous SF Fisherman's wharf, and there was some store for left handed people, since I am part of the deprived minority of left handed people, I was curious and entered the store, among the different items there (mostly not very practical), I saw this clock, if you notice, it is a backwards clock, which goes anti-clockwise. I am sure that the owner of the store was right handed -). Anyway, I recalled this clock, when working on a final version of a paper entitled "Temporal perspectives in event processing" that has been accepted recently for publication, and re-read the paper (as any paper, it is written, submitted, and then after a few months a review arrives and the author has to be reminded what it was, revise according to the comments, send back, and so on, until it is either accepted or rejected), and thought that temporal semantics of events can be a good topic to write about here. The temporal semantics of a backwards clock is, of course, different than that of the regular clock, and this brings me to the temporal semantics of derived events. Some background: event may have two time-stamps (or intervals) associated with it: occurrence time and detection time. Occurrence time is the time that the event happened in reality, detection time is the time in which the event processing system detected the event message sent to it. It is easier to make the processing of the events (when did they happen ? in what order ?) according to the detection time, however, for some applications, this may yield incorrect results. There are several issues around obtaining the correct occurrence time, but let's assume that we know how to do it. While the occurrence time of a raw event (events that has arrived from an external producer that assigns the value) is explicitly provided, the question is what is the occurrence time of derived events. Let's take a simple example: In May 2nd, 10:30 the customer John Galt has issued an order for books, with a guaranteed delivery of 48 hours (see my story with Amazon in its early days as a footnote to this postings). In May4th, 10:30 Mr. Galt looked at his (forward going) watch and said: "the shipment has not arrived by its deadline". The fact that he has not reported on arrival by the deadline caused the event processing system to derive the event "shipment did not arrive", which is a time-out event (or non-event event as some vendors call it). Now the question is WHEN did this event happen ? the detection time is easy, when some computational process derived the event and emitted it to the event processing system then the detection time is set. Let's say that this happened in May 4th in 10:32. The occurrence time is more tricky. Actually I can think of three different interpretations:

1. The occurrence time of the "shipment not arrived" is the same as its detection time, which means May 4th, 10:32.

2. The occurrence time of the "shipment not arrived" is the deadline of when it should have arrived, in this case, May 4th, 10:30

3. The occurrence time of the "shipment not arrived" is the entire interval of the 48 hours, since the shipment did not arrive during this interval [May 2nd 10:30, May 4th 10:30].

What is the right answer for semantics ? there is no right answer, as some more cases in event processing, the system designer should chose among these (and may be other) alternatives.

More about temporal semantics -- later.


Footnote: A story from the early days of Amazon.

I was an early customer of Amazon, buying, science fiction books through the web (I still do it). Typically it took 3 week for a shipment to arrive to Israel, so once after three and half weeks in which the packaged did not arrive, I've sent Email to Amazon customer service to ask about it. Their response was surprising -- we don't know what happened, we are re-sending you the books. After two more days I received the original package, and since I thought that may be the substitute package still can be stopped, I send another Email to Amazon friendly customer service, and got event more amazing response -- after we issue the reservation we cannot control the rest of the process-- so please keep the extra book with our compliments. At that time I thought that this company is not going to survive... Of course, since then they have much better logistic system... and I have two copies of each of the books in this shipment.

4 comments:

Unknown said...

There is at least one more 'timestamp': the period time sent until now - after all it still hasn't arrived, presumeably. Which indicates the problem: you can't make a non-event into an event you can only define an consequent event with its own semantics: the point in time the delivery is first overdue, the point you first notice it's overdue, every hour on the hour it remains overdue...

As you say, there is no 'right' and 'wrong' semantics but it is important to define each event precisely as a time something happened so that the interpreters of an event stream can determine the precise semantics of consequent events. For example, an event every Timeout-overdue delivery can be different to an event every overdue-on-eventual-receipt delivery depending on the timeout logic. If you need the events to trigger some incident, you need the former. If the event stream is part of an SLA governance mechanism the the latter might be more appropriate. The important thing is to know exactly to what the event refers.

Opher Etzion said...

Hi Michael. You are talking about "time-out" semantics. IMHO, there it is not associated with event type, since the same event type, for different processing purposes may have different time-outs.

cheers,

Opher

Unknown said...

Not really. I'm saying that you can't represent a non-event with an event. The only thing you can do is define a real event with meaning: timeouts are one way, an event triggered on eventual receipt is another. The events may provide different inferences depending on how they were created.

Opher Etzion said...

Right. A "non event" is not an event, it is a pattern on one or more events, see previous posting on this topic here: http://epthinking.blogspot.com/2007/11/non-events-again-much-ado-about-nothing.html

cheers,

Opher