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 16:10:10 -0700
Message-ID: <637B7E7B51291C48838F5AE1F2ACA1D749298A@NA-PA-VBE02.na.tibco.com>
To: "Alex Kozlenkov" <alex.kozlenkov@betfair.com>
Cc: <public-rif-wg@w3.org>

Ah - obviously I misunderstood your requirement / use case:

- you get multiple events of the same type with the same content
- only some of these are appropriate in certain patterns.

You'll need to specify the discriminator in more detail: in other words,
for
<< we want this sequence to invalidate a simple C<=AB pattern >>,
*when* do you want to invalidate this pattern? 
e.g. It could be that only 1 C event is allowed in a certain time
window. 

Paul Vincent
TIBCO | Business Optimization | Business Rules & CEP
 

> -----Original Message-----
> From: Alex Kozlenkov [mailto:alex.kozlenkov@betfair.com]
> Sent: 03 September 2008 22:08
> To: Paul Vincent
> Cc: public-rif-wg@w3.org
> Subject: RE: Congratulations on Christian's and co. courage
> 
> I am referring to legitimate events that must not be de-duplicated as
> they are used in various ways in the engine. The approach with
negation
> does not scale with the number of condition event increasing to even
> 5-10, which would create a heck of a rule. The approach with cleansing
> is very awkward, error-prone and does not scale either.
> 
> -----Original Message-----
> From: Paul Vincent [mailto:pvincent@tibco.com]
> Sent: 03 September 2008 22:00
> To: Alex Kozlenkov
> Cc: public-rif-wg@w3.org
> Subject: RE: Congratulations on Christian's and co. courage
> 
> 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.
> >
> >
>
________________________________________________________________________
> 
>
________________________________________________________________________
> 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 23:11:10 GMT

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