W3C home > Mailing lists > Public > public-rif-wg@w3.org > September 2008

RE: Congratulations on Christian's and co. courage

From: Paul Vincent <pvincent@tibco.com>
Date: Wed, 3 Sep 2008 14:00:23 -0700
Message-ID: <637B7E7B51291C48838F5AE1F2ACA1D7492983@NA-PA-VBE02.na.tibco.com>
To: "Alex Kozlenkov" <alex.kozlenkov@betfair.com>
Cc: <public-rif-wg@w3.org>

So you have identical content in events A1, A2.
Then event B occurs.
Apply rule C <= AB
You get C1, C2.

Unless... you apply a higher priority rule to "remove" / invalidate A2
(or cleanse the event stream first in a separate process / ruleset).

Or if dupes are common, you might handle it in your rules:
C <= AB & !(AAB)

[In TIBCO's CEP-rule engine, and without regard to RIF sensitivities, we
might handle this by running event de-duping in the "event
pre-processor" - allows for event handling before activating the rule
engine. In a RIF context, or another BRE, I would simply have a separate
de-dedupe ruleset and run that before the C <= AB rule(set)].

Hope this helps.

Paul Vincent
TIBCO | Business Optimization | Business Rules & CEP
 

> -----Original Message-----
> From: Alex Kozlenkov [mailto:alex.kozlenkov@betfair.com]
> Sent: 03 September 2008 21:44
> To: Paul Vincent
> Cc: public-rif-wg@w3.org
> Subject: RE: Congratulations on Christian's and co. courage
> 
> What happens if the duplicate events A;A are truly different, with
> different timestamps, and we want this sequence to invalidate a simple
> C<=AB pattern? The rule happily emitting two detections given the
input
> A;A;B may be something entirely incorrect.
> 
> -----Original Message-----
> From: Paul Vincent [mailto:pvincent@tibco.com]
> Sent: 03 September 2008 20:48
> To: Alex Kozlenkov
> Cc: public-rif-wg@w3.org
> Subject: RE: Congratulations on Christian's and co. courage
> Importance: Low
> 
> As this qu is CEP-related, I guess I should give an answer too.
> 
> 1. Gary is correct from the logical perspective, of course.
> 
> 2. Events can be duplicates either in their transmission or their
> meaning:
> 
> In middleware terms, it is normally the responsibility of the
middleware
> to ensure duplicates don't happen!
> 
> In event terms, though, I can receive multiple events which signify
the
> same information. For example I may be polling a hardware device and
> getting the same result, or someone may hit the "Buy" button in their
> web browser twice.
> 
> In the latter case, there are 2 order events but they represent the
same
> order, so there might be some rules / logic in the system to handle
this
> (de-dupe). Those rules could presumably be represented in RIF, e.g.
> 
> If ?BetA and ?BetB occur within 5 secs of each other AND sameContent(
> ?BetA, ?BetB)
> Then // assume BetB is a dupe
> ?BetB.dupe = TRUE, ?BetB.IsDupeOf = ?BetA, ?BetB.Status = invalid.
> 
> ...
> 
> Paul Vincent
> TIBCO | Business Optimization | Business Rules & CEP
> 
> 
> > -----Original Message-----
> > From: public-rif-wg-request@w3.org
> [mailto:public-rif-wg-request@w3.org]
> > On Behalf Of Gary Hallmark
> > Sent: 03 September 2008 18:31
> > To: Alex Kozlenkov
> > Cc: public-rif-wg@w3.org
> > Subject: Re: Congratulations on Christian's and co. courage
> >
> >
> > no such thing as 2 identical facts.  Relations are sets.  Frames
have
> a
> > unique OID.
> > Note that PRD currently has no way to create a new object, and that
is
> a
> > problem we need to fix.
> >
> > Alex Kozlenkov wrote:
> > > And one more comment about the minimality I'm discussing in my
> previous
> > > post. This is not an idle question. If there exist two identical
> facts,
> > > will there be two actions executed or only one? In the language
> dialect
> > > for event processing that the JBoss guys are developing, I was
> trying to
> > > understand whether A<=B,C given B and C matching incoming events,
if
> C
> > > was detected twice, would the action A be executed twice? What I
> mean is
> > > that there may be situation when we want to only detect one
> situation so
> > > that the sequence of events CCB should execute A only once.
> > >
> > >
> > >
>
________________________________________________________________________
> > > In order to protect our email recipients, Betfair Group use
SkyScan
> from
> > > MessageLabs to scan all Incoming and Outgoing mail for viruses.
> > >
> > >
>
________________________________________________________________________
> > >
> > >
> 
> 
>
________________________________________________________________________
> In order to protect our email recipients, Betfair Group use SkyScan
from
> MessageLabs to scan all Incoming and Outgoing mail for viruses.
> 
>
________________________________________________________________________
Received on Wednesday, 3 September 2008 21:01:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:54 GMT