- From: Peter F. Patel-Schneider <pfps@inf.unibz.it>
- Date: Fri, 02 Jun 2006 10:54:29 -0400 (EDT)
- To: sandro@w3.org
- Cc: bry@ifi.lmu.de, public-rif-wg@w3.org
From: Sandro Hawke <sandro@w3.org> Subject: Re: Fitting PR and RR into logical rules Date: Fri, 02 Jun 2006 10:36:16 -0400 > > > > Thinking of an interchange between deductive and production/eca rules is > > in my humble opinion naive because it raises extremely complicated issues > > that are far from being solved and most probably never will be. > > > > Otherwise, one af the great dreams of software engineering would be > > achieved: automatically generating a imperative program from a > > declarative specification or vice versa. > > I'm not suggesting building an automatic mechanism to tranform all PR > rulesets into FO rulesets. Rather I'm suggesting that if we look at the > use cases for PR we'll see that semantically they fit nicely in with FO. > > 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? > This does not mean that an FOL theorem prover would be an effective way > to execute real-world ECA rule sets, but it does mean that any results > it was able to compute would be correct. (That is, it supports the > Soundness requirement I've been advocating.) I'm not convinced even of this, as the semantics of ECA conditions might not match up with the semantics of FOL. Perhaps someone might want to take a crack at answering this particular technical question? > I do expect that some easy > ECA rulesets would work with resolution-style reasoners using this > approach, but that's more a confirmation than a goal. (This proposal > does not address the split in semantics between LP and FOL - that's a > separate question.) > > If you want to argue against this proposal, please just point to rules > from our use cases for which you think this approach will be bad and we > can look at an implementation sketch in detail. > > -- Sandro peter
Received on Friday, 2 June 2006 14:54:50 UTC