Le 19 mars 2014 à 18:46, Dave Reynolds <[email protected]> a écrit :
> > On 19/03/14 16:46, Christophe FAGOT wrote: >> Hi Jena folks, >> >> since I need to use Jena with its RETEEngine, I’m actually investigating >> what is actually feasible / usable with this engine functionalities. >> >> I would like to develop my own BuiltIn, used in the head of a forward rule, >> and doing some actions when a new rule context appears (due to triples >> adding) for the body rule, while doing some other actions when a rule >> context disappears (dur to triples removal) for this body rule. >> >> It appears in the RETEConflictSet (line 180) that a BuiltIn can receive only >> … added RETERuleContext. Hence a BuiltIn action can only be called when a >> RETERuleContext is added, never when a RETERuleContext is removed. >> >> Is their a reason for that ? > > The existing head builtins expect to only be fired when a potitive deduction > is made. This is a legacy of the fact that the rule system was designed for > monotonic inference and all the remove/non-monotonic processing is a hack. I don’t see the relationship between monotonic inference and remove prohibited. A monotonic inference only means that when adding some facts in the knowledge base, the previous inferred data can’t be removed, while when removing some facts, new facts can’t be produced. And this is exactly what Jena Rete engine perfectly does with « standard » triple patterns. But when the head is a BuiltIn, that BuiltIn does not have a single chance to act the same way. The BuildIn can only react to added triples. And the only mandatory thing for a BuiltIn is to declare is it is monotonic or not. But it’s behavior and the triples it adds/removes in the inference graph are never verified to check if it really has a (non-)monotonic behavior. But this is another story. > It was added due to requests on the user's list but was a mistake. > > Note also that since there's no reference counting in the rule system it's > notion of removal is not reliable. > >> Would it be possible to add in the context whether it’s a context added or >> removed, and to call the BuiltIn head action in both cases ? > > No because that would change behaviour for existing rules sets, especially > any with custom builtins. For sure, if some changes occurs, they have to fully respect and ensure the way the existing rules sets behave. > > I guess you could have a custom sort of builtin which does support firing a > head-action on a remove and modify RETEConflictSet to check for such builtins > and allow those (and only those) to fire - passing the isAdd flag as part of > the call. That was exactly what I had in mind. Adding a flag to BuiltIn so that they declare if they need to receive the removals, set the default value to false in BaseBuiltIn, modify a little bit RETEConflictSet, and fire the remove only to the BuiltIn requiring it. Chris. > > Dave > : : . . . . . . . . . . . . . . . . . . . . . . . : : Christophe FAGOT, PhD Responsable R&D informatique intactile DESIGN : : Création d’interfaces subtiles : : +33 (0)4 67 52 88 61 +33 (0)9 50 12 05 66 20 rue du carré du roi 34000 MONTPELLIER, France http://www.intactile.com Hugh MacLeod : "It's not what the software does, it's what the user does" Les informations contenues dans cet email et ses documents attachés sont confidentielles. Elles sont exclusivement adressées aux destinataires explicitement désignés ci-dessus et ne peuvent être divulguées sans consentement de son auteur. Si vous n'êtes pas le destinataire de cet email vous ne devez pas employer, révéler, distribuer, copier, imprimer ou transmettre le contenu de cet email et devez le détruire immédiatement.
