Re: RIF: Fitting PR and RR into logical rules

> Let me see how this maps to ECA/PR...

I don't see any obvious problems with the mapping here.  Do you? 

(Your message touches a lot on the "Program Data" issue [1], interfacing
with Java.  Is that something you're concerned about for phase 1?)

     -- Sandro

[1] http://www.w3.org/2005/rules/wg/charter#data-sources0


> > > > Specifically, here's my strawman.   I propose the ECA/Reaction
> rule:
> > > >
> > > >     on Event
> > > >     when Condition
> > > >     then Action
> > > >
> > > > be treated semantically as the Horn rule (FOL implication):
> > > >
> > > >     if eventHappened(Event) and Condition
> > > >     then actionRequested(Action)
> > > >
> > > > and similarly for production rules (just drop the event part).
> > >
> > > I'm not sure that this would result in *any* inferences in a FOL
> system.
> > > How are you going to put the eventHappened and actionRequested into
> the
> > FOL
> > > (or other deductive) framework in such a way that supports, for
> example,
> > > chaining of rules?
> >=20
> > I'll refine the sketch a little:
> >=20
> >  1. When an event occurs, facts are added to the rulebase
> >     to describe the occurance.  To use RIF-UCR 1.1 and
> >     make the delivery of a perishable item an event, the
> >     facts that get added to the rule base might be:
> >=20
> >        eventHappened(ev331).
> >        deliveryEvent(ev331, item7, date(2006,06,02)).
> 
> [PV>] In an event rule / ECA rule, the "event" is likely to be some
> object creation / specification. For example, this might be implemented
> by a listener method (defined via API). From this you can rightly assume
> that registration of new events is usually (but not always) a
> maintenance rather than runtime task. [Having said that, the event type
> could be abstracted so I look for generic events and then test the event
> type in the rule condition.]=20
> PS: a pseudo syntax used below
> >=20
> >     where "ev331" is some new identifier made up by the component that
> >     adds things to the rule base.  The rulebase would probably already
> >     contain stuff about item7, like:
> >=20
> >        perishable(item7).
> >        scheduledDelivery(item7, date(2006,05,02)).
> 
> [PV>] So here I might have a new Java object that is goodsDelivery that
> has attributes representing whether it is perishable ( a Boolean) and
> its scheduled and actual delivery timestamps.
> >=20
> >  2. The rule
> >=20
> >          "If an item is perishable and it is delivered more than 10
> days
> >          after the scheduled delivery date then the item will be
> >          rejected."
> >=20
> >     might be written in FOL (+date math) like this, keeping the ECA
> >     spirit of that rule:
> >=20
> >         all Event Item DateDelivered DateDeliveryScheduled (
> >              ( eventHappened(Event) &
> >                deliveryEvent(Event, Item, DateDelivered) &
> >                perishable(Item) &
> >                scheduledDelivery(Item, DateDeliveryScheduled) &
> >                late(DateDelivered, DateDeliveryScheduled)
> >              ) -> (
> >                exists Action (
> >                  actionRequested(Action, deliveryRejection(Item))
> >              ))
> >         ).
> 
> [PV>] Assuming an event rule (as opposed to PR):
> On a creation event for a goodsDelivery do
> If perishable=3Dtrue and delivery >=3D scheduled + 10 days
> Then rejected is set to true
> >=20
> >  3. For the action to be performed in this sketch, some component
> >     outside the reasoner will need to query for actionRequested
> things.
> >     So we query for
> >=20
> >         actionRequested(ActionID, Details))
> >=20
> >     which in a resolution theorem prover is done by asserting the
> >     negation and looking for a contradiction; ie asserting:
> >=20
> >         -(exists ActionID Details actionRequested(ActionID, Details)).
> >=20
> >     and then looking in the proof to see how Action was instantiated
> in
> >     that proof step.  Really, you'll have to look for all the proofs
> and
> >     keep track of which Actions you've already performed.  In a normal
> >     resolution theorem prover, Action will be Skolemized into a
> function
> >     term like sk1(Event, Item, DateDelivered, DateDelieveryScheduled)
> --
> >     something which will work as a unique identifier to prevent the
> same
> >     action from running twice.
> 
> [PV>] In a rule engine (ECA/PR), the object model (terms) are typically
> predefined, and usually defined externally to the rules (eg in a Java
> object model or a XML schema). There is assumed to be some other
> business process that utilizes the fact that some goods are now defined
> as rejected in some subsequent process.
> >=20
> 
> [PV>] Note that the PR version would assume that the event handling is
> external ie I pass new event objects to be processed as transactions.
> This is effectively the same except I don't need to detect the event -
> it is implicit in the definition of the rule service and ruleset.
> 
> > I did happen to run this through the classic FOL theorem prover Otter
> > (using a manual assertion: late(date(2006,06,02), date(2006,05,02))
> for
> > now) and the proof included the deduction:
> >=20
> > actionRequested($f1(ev331,item7,date(2006,06,02),date(2006,05,02)),
> >                 deliveryRejection(item7)).
> >=20
> > Again, I'm not saying I'd expect Otter or any other FOL theorem prover
> > to be an effective ECA engine, I'm using it to be clear about this
> > approach to mostly-unified semantics.
> >=20
> > I'll be interested to hear how these semantics differ from those
> > implemented in RR/PR systems, and which semantics business rule
> > developers would prefer.
> >=20
> 
> [PV>] I didn't run this rule but it is pretty straightforward. Reminds
> me of a rules use case from 10 yrs ago where a v large European food
> "manufacturer" used similar rules to determine how much to pay their
> suppliers (ie they mapped their contract rules to a PR system, and
> linked it to their accounting system).
> This email and any files transmitted with it are confidential, proprietar=
> y
> and intended solely for the individual or entity to whom they are address=
> ed.
> If you have received this email in error please delete it immediately.
> =0D

Received on Tuesday, 6 June 2006 10:08:12 UTC