> Jess and Drools appear to agree on the semantics of no-loop.
Here is a test case (in rif-like presentation language)
eg:P(1) eg:Q(1) eg:Q(2) no-loop rule: if eg:P(1) and eg:Q(?x) then do retract eg:P(1) retract eg:Q(?x) assert eg:P(1) assert eg:Q(?x + 10)
in Jess, this will yield
eg:P(1) eg:Q(11) eg:Q(2)
or, depending upon ordering,
eg:P(1) eg:Q(1) eg:Q(12)
but note it will never yield (because of the no-loop)
eg:P(1) eg:Q(11) eg:Q(12)
This is not what I would expect, nor is it particularly nice to specify. If you say Drools has the same peculiar behavior, I'll take your word for it. I think that's a very curious thing, but it is still not what I would expect, nor like to see in a standard.
> Apparently we agree that "Forall ?var such that..." is different from > Jess' or Drools' forall CE. - My point is that RIF-PRD's introduction of > forall in a place where it is implied by systems like Jess or Drools is > apt to confuse.
> I guess it would help readers if there were a clarifying statement > such as that RIF-PRD is representing both FOP quantifiers *explicitly*, > and in a uniform way, close to the usual FOP notation. Practitioners > with Jess or Drools are constantly having troubles with relating > FOP expressions to either language's constructs. (That's why > there is now http://www.jessrules.com/jess/docs/PropPred.pdf.)
It seems the confusion may arise because these 2 FOL statements are not equivalent:
1. Forall ?X (If P(?X) Then Q(1)) 2. If Forall ?X (P(?X)) Then Q(1)
The former is intended by RIF's Forall. The latter is (more or less) intended by the forall CE. Possibly it is the job of the Jess and Drools documentation to note that they intend the second meaning of forall. [As an aside, I am a bit confused by the material in PropPred.pdf because I don't see the FOL implication symbol, often "->", in the FOL translation of Jess rules.]
> Quite so, but given a set of such rules: how do you make sure that > Forall ?v If ?v#Vehicle will catch all Buses, Cars, Trucks, etc.? > How are these relations x##Vehicle established in the first place?
Membership '#' can be asserted for new objects and for unconditional actions (i.e. ground facts). Subclass '##' cannot be asserted because many PRD systems simply reflect some host lanaguage type system such as Java. We could make subclass assertions legal for unconditional actions. Do you feel strongly that we should do this? We expect that PRD systems will import membership and subclass relations from XML or from an object-oriented language such as Java. We are nearing a first public working draft of an XML import proposal. See http://www.w3.org/2005/rules/wiki/RIF%2BXML_data-schema.