tag:blogger.com,1999:blog-7831813422886730737.post273974472188345159..comments2023-10-08T10:44:28.524+03:00Comments on Event Processing Thinking: On temporal semantics of events - or when has the shimpent not arrived ?Opher Etzionhttp://www.blogger.com/profile/10791357917675270335noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-7831813422886730737.post-42665725629882667252009-06-08T18:40:01.061+03:002009-06-08T18:40:01.061+03:00Right. A "non event" is not an event, it...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<br /><br />cheers,<br /><br />OpherOpher Etzionhttps://www.blogger.com/profile/17070103285719046013noreply@blogger.comtag:blogger.com,1999:blog-7831813422886730737.post-18044245664404091912009-06-08T18:09:29.577+03:002009-06-08T18:09:29.577+03:00Not really. I'm saying that you can't repr...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.Anonymoushttps://www.blogger.com/profile/08464631130510118379noreply@blogger.comtag:blogger.com,1999:blog-7831813422886730737.post-62252755935957242852009-06-08T17:56:33.979+03:002009-06-08T17:56:33.979+03:00Hi Michael. You are talking about "time-out&q...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.<br /><br />cheers,<br /><br />OpherOpher Etzionhttps://www.blogger.com/profile/17070103285719046013noreply@blogger.comtag:blogger.com,1999:blog-7831813422886730737.post-22413416443919027332009-06-08T17:50:36.425+03:002009-06-08T17:50:36.425+03:00There is at least one more 'timestamp': th...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...<br /><br />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.Anonymoushttps://www.blogger.com/profile/08464631130510118379noreply@blogger.com