Re: Creating new skolems within a rule

On Jul 11, 2007, at 10:58 AM, Prasan Samtani wrote:

> I’m in the process of creating a multiagent system in Powerloom.  
> I’m looking for a way to create a new skolem within a rule without  
> explicitly naming it. Let’s say I have a rule that defines how an  
> agent reacts in a particular situation:
>
>
>
> (defrule greeting-rule
>
>    (=>
>
>       (and (conv-opening ?s) (act-addressee ?s Pierre) (greeted  
> Pierre FALSE)
>
>            (act-speaker ?s ?a) (= (act-time ?s) (system-time  
> TLTWorld)))
>
>       (and (conv-opening pierre-greet) (act-speaker pierre-greet  
> Pierre)
>
>            (act-should-execute pierre-greet TRUE) (greeted Pierre  
> TRUE) (act-addressee pierre-greet ?a) )
>
> ))
>
>
>
> Every time this rule is triggered, the value of the skolem pierre- 
> greet is overwritten. Is there a way to create a new skolem in the  
> right hand side of the rule, such as:
Well, yes and no.

Creating a skolem is easily accomplished by introducing the new  
variable with an EXISTS clause, so if you wrap the consequent with an  
(exists (?spr) ...) form, you will have created a new skolem.

    (defrule greeting-rule

        (=>

             (and (conv-opening ?s) (act-addressee ?s Pierre)  
(greeted Pierre FALSE)

                  (act-speaker ?s ?a) (= (act-time ?s) (system-time  
TLTWorld)))

             (exists (?spr)

                (and (conv-opening ?spr) (act-speaker ?spr Pierre)

                     (act-should-execute ?spr TRUE) (greeted Pierre  
TRUE) (act-addressee ?spr ?a) ))))



But this may not result in what you really want, and in particular  
won't necessarily create an new skolem if there is an existing skolem  
that already satisfies the clauses in the consequents.
> This way, every time the rule is triggered, a new skolem is created  
> that has the correct values in its slots. This way, the values of  
> the older skolems are not overwritten. Is it possible to do this in  
> PowerLoom, or would you recommend an alternate approach?
The fundamental issue is that it seems that you want to use the  
logical inference rules as if they were (procedural) production  
rules.  Although the formalisms are similar there are some important  
differences between them.  Logical inference rules are used to encode  
axioms that are universally true.  They should be used to conclude  
the consequences of the information in the knowledge base.  They are  
not intended to model reactions to changing circumstances, which is  
why introducing new instances isn't easy [although I think Hans  
Chalupsky may have some modifications that can
change this.]  Logical rules in PowerLoom are also non-monotonic,  
which means that the conclusions can be later retracted if the  
underlying facts change.  This is one of their strengths.  You can  
also run into problems if you include things which are logical  
inconsistencies in the rules, such as a rule of the form:
     A => (not A)
I suspect that you have something like this with the (greeted Pierre  
TRUE/FALSE) clause in your rule.

Production rules, on the other hand, are a method of procedural  
programming, which perform a match-act cycle and can be used to (in  
general) perform arbitrary changes to the knowledge base.  Some  
familiar production rule systems are JESS, OPS5 and the MYCIN  
derivatives.  There is generally no automatic retraction, since by  
the procedural nature of the rule paradigm, things are expected to  
change as a result of the rules, and one does not want to undo  
things.  In particular, production rules don't have a problem with  
retracting items in their antecedent, whereas doing this via negation  
(or the resetting of functional relation properties) in logical  
inference rules is a problem.

PowerLoom does not have a production rule system associated with  
it.*  It just has the logical inference rules.

Now, as to an alternate approach:  Since there is no real production  
rule system in PowerLoom, you would need to construct some of that  
functionality using code on your own.  You can use queries to look  
for matches and then introduce assertions.  This is not as efficient  
a matching strategy as the rete-nets found in production systems, but  
unless you have to do this often, it may be acceptable.  Constructs  
such as ASSERT-FROM-QUERY may be useful in such cases.  One other  
downside is that PowerLoom won't monitor the KB and react to  
particular updates.  Again, there are tools (such as associating  
DAEMONs with predicates) that you can use to handle this part of it.   
It is a bit more work, though, but these sorts of tools will do the  
job more reliably.


-Tom.

* The predecessor Loom system did have a production rule system, but  
that doesn't really help.


--
Thomas A. Russ, Ph.D.  Senior Research Scientist             [email protected]
USC/Information Sciences Institute              WWW:  http://www.isi.edu
4676 Admiralty Way, Marina del Rey, CA 90292              (310) 448-8775