RE: [RIF] Reaction to the proposal by Boley, Kifer et al --> ECA vs PR

Alex: just some views on ECA from a vendor in this space...

> -----Original Message-----
> Dave, Uli
> 
> I understand the requirements for RIF to express, e.g., RDF deduction
> directly and Michael's statement does not contradict this. I agree
that
> having RDF triples in body alone does not suffice.
> 
> I appreciate your effort in trying to pin down the issues. Let me
> clarify on reaction rules. Reaction rules of event-condition-action
> (ECA) type go beyond production rules in several respects. What may be
> distinguishing here is that detection of situations may be done based
on
> various events, not just data changed. 

[PV>] Note that this is (mostly) an execution aspect. If I have an ECA
rule that occurs on event A, it looks very similar to a PRule with a
condition of the type "event A occurred".

> Also the action language may
> allow for atomic action sequencing including the ability to perform
> epistemic and communication actions a minimum. Sequencing may be
> critical here because it may be done precisely while production rules
> may fire in a different order so the order of actions may not be
> predicated in advance. This all calls for actual action language that
> may become as powerful as Petri nets or pi-calculus including splits
and
> joins (see for example, BPEL).[PV>] 

[PV>] I'm not sure I follow this part at all. The semantics for action
execution of ECA rules and PRules would normally be identical, with
order being significant, and actions may be immediate or queuing or
invoking some service. The references to pi-calculus implies to me (from
a discussion with Steve Ross-Talbot a few months back) that you are
talking about choreography? If so, again I'm not sure how that
differentiates PR vs ECA (there is no reason why I could not choreograph
some services via a PR).

> The ability to detect situations in a flexible way and react to
> situations in specified patterns may require a special flavor of RIF
> that can be annotated appropriately. This may not necessarily
contradict
> anything, just complement it, as you are suggesting. We are keen to
work
> on behavioral aspects of RIF and reaction rules in particular.

[PV>] Au contraire: ECA rules should be included in RIF (although I
can't recollect which use case particularly stipulated ECA). "Events"
are just a special kind of "condition", and of course the execution
semantics are different. 

> 
> Alex
> 
> -----Original Message-----
> From: public-rif-wg-request@w3.org
[mailto:public-rif-wg-request@w3.org]
> On Behalf Of Dave Reynolds
> Sent: 03 May 2006 16:48
> To: Alex Kozlenkov
> Cc: public-rif-wg@w3.org
> Subject: Re: [RIF] Reaction to the proposal by Boley, Kifer et al
> 
> 
> Alex Kozlenkov wrote:
> 
> > I am not sending a message against OWL or RDF. I am simply asking
> > whether _querying_ RDF and OWL in rule antecedents is enough or not
> for
> > RIF at this time.
> 
> As I've already said in my response to the proposal,
external-query-only
> 
> is not sufficient from my point of view. I need to be able to express
at
> 
> least deduction rules over RDF and an external query approach doesn't
> facilitate that. I would prefer a tighter embedding of RDF into RIF
> (e.g. either a three place predicate or the ability to interpret any
> atoms over binary relations as RDF triple patterns).
> 
> > Reaction rules may involve a sequence of actions as opposed to one
> > action. Semantics of these sequences of actions may be based on
> > transaction logic or be even based on process algebras. OWL and RDF
> > semantics are likely to be complementary to those.
> 
> Complementary is different from incompatible.
> 
> What specific problems do production rules raise when processing RDF
> data that don't get raised when processing, for example, XML data?
> 
> [I'm not trying to deny there are subtleties there but I am try to pin
> down what specific problems make you unhappy with the more integrated
> approach.]
> 
> Dave
> 
> 
> 
> 
>
________________________________________________________________________
> In order to protect our email recipients, Betfair use SkyScan from
> MessageLabs to scan all Incoming and Outgoing mail for viruses.
> 
>
________________________________________________________________________
> 

This email and any files transmitted with it are confidential, proprietary
and intended solely for the individual or entity to whom they are addressed.
If you have received this email in error please delete it immediately.

Received on Wednesday, 3 May 2006 18:26:28 UTC