Re: Unexpected Powerloom truth maintenance behavior....

Srini,

actually, the rules do match what you wrote, even though somewhat
counterintuitively:

(defrelation married ((?x live-person) (?y live-person)))

means the following:

(defrelation married (?x ?y))
(nth-domain married 0 live-person)
(nth-domain married 1 live-person)

In turn, the domain assertions mean that

(=> (married ?x ?y) (and (live-person ?x) (live-person ?y)))

BUT: this rule is not (yet) explicitly represented and currently only
enforced for top-level assertions (with some caveats - see an earlier
message).  The reason is primarily efficiency, since we do not want to
unconditionally create all the additional type assertions for each
asserted relation, and we also don't want to do this via rules and
infer types via backward inference, since type rules often have high
fanout.  So, for now we punted the ball on this in your corner and let
you explicitly assert such type inference rules if you deem them
necessary.  And yes, you won't yet find this anywhere in the manual.

Now, this

(defrelation married ((?x live-person) (?y live-person))
  :<=> (spouse ?x ?y))

currently means the following:

(defrelation married (?x ?y))
(nth-domain married 0 live-person)
(nth-domain married 1 live-person)
(forall (?x ?y) (<=> (married ?x ?y) (spouse ?x ?y)))

So, as you observed, the rule is built without the variable types
which explains the inferences and rules you saw.  You can of course
fold in the type constraints explicitly, e.g.,

(defrelation married ((?x live-person) (?y live-person))
  :<=> (and (live-person ?x)
            (live-person ?y)
            (spouse ?x ?y)))

or you can write the rule outside the relation definition in any which
way you want to enforce the type tests.

But, this behavior has been confusing to people (including myself) in
the past, and we have to think a bit more whether we should change
it or not.  So, stay tuned.

Hans

--------------------------------------------------------------------------
Hans Chalupsky, PhD                     USC Information Sciences Institute
Project Leader, Loom KR&R Group         4676 Admiralty Way
<[email protected]>                          Marina del Rey, CA 90292
(310) 448-8745
--------------------------------------------------------------------------

>>>>> Srini Ram <[email protected]> writes:

> I just tried to check the rules for my second version of married below and found:
> (print-rules married)

> (/PL-KERNEL-KB/FORALL (?x1 ?x2)
>    (<= (SPOUSE ?x1 ?x2)
>        (MARRIED ?x1 ?x2)))

> (/PL-KERNEL-KB/FORALL (?x1 ?x2)
>    (<= (MARRIED ?x1 ?x2)
>        (SPOUSE ?x1 ?x2)))

> This does not match what I wrote:

> (defrelation married ((?x live-person) (?y live-person))
>     :<=> (and (spouse ?x ?y) ))

> For some reason, the rules are not converted to 

> FORALL ((?x1 live-person) (?x2 live-person))
    (<= (MARRIED ?x1 ?x2)
>       (SPOUSE ?x1 ?x2)))

> but specified universally. This is why married continues to hold even
> if jack is no longer live, and why the explanations and traces show
> married follwign directly from an assertion?

> Srini



> --- On Fri, 8/22/08, Srini Ram <[email protected]> wrote:
> From: Srini Ram <[email protected]>
> Subject: Re: [PowerLoom Forum] Unexpected Powerloom truth maintenance behavior....
> To: [email protected]
> Date: Friday, August 22, 2008, 11:23 AM

> Hi Hans





> Can do...Will assert types explicitly.





> I am experiening the following issue:


> With following definitions:


> (defconcept person (?x))

> (defrelation alive (?x))



> (defconcept live-person (?x person)

>   :<=> (alive ?x)

>   )

> (defrelation spouse ((?x person) (?y person))

>   :axioms (symmetric spouse))





> ;; (defrelation married ((?x person) (?y person))

> ;;    :<=> (and (spouse ?x ?y) (live-person ?x) (live-person ?y) ))



> (assert (spouse jack jill))

> (assert (and (alive jack) (alive jill)))





> I get the following correct response;


STELLA> (retrieve all (married ?x ?y))

> There are 2 solutions:

>   #1: ?X=JILL, ?Y=JACK

>   #2: ?X=JACK, ?Y=JILL

STELLA> (retract (alive jack))

> |P?|(ALIVE JACK)

STELLA> (retrieve all (married ?x ?y))

> No solutions.





> But by changing the definition of married as follows:


> (defrelation married ((?x live-person) (?y live-person))


>     :<=> (and (spouse ?x ?y) ))





> I get an erroneous answer


STELLA> (retrieve all (married ?x ?y))

> There are 2 solutions:

>   #1: ?X=JACK, ?Y=JILL

>   #2: ?X=JILL, ?Y=JACK

STELLA> (retract (alive jack))

> |P?|(ALIVE JACK)

STELLA> (retrieve all (married ?x ?y))

> There are 2 solutions:

>   #1: ?X=JACK, ?Y=JILL

>   #2: ?X=JILL, ?Y=JACK

STELLA> (retrieve all (married ?x ?y))

> There are 2 solutions:

>   #1: ?X=JACK, ?Y=JILL

>   #2: ?X=JILL, ?Y=JACK



> Just to check


STELLA> (ask (live-person jack))

> UNKNOWN






> Explanations not helpful:


STELLA> (set-feature justifications)

> |l|(:JUSTIFICATIONS :EMIT-THINKING-DOTS :JUST-IN-TIME-INFERENCE)

STELLA> (retrieve (married ?x ?y))

> There is 1 solution so far:

>   #1: ?X=JACK, ?Y=JILL

STELLA> (why)

> |kv|(<|i|@PRIMITIVE-STRATEGY,|i|@EXPLANATION-INFO>)

> 1 (MARRIED JACK JILL)

>     follows





> Nor does this:


STELLA> (set-feature trace-subgoals)

> |l|(:TRACE-SUBGOALS :JUSTIFICATIONS :EMIT-THINKING-DOTS :JUST-IN-TIME-INFERENCE)

STELLA> (retrieve (married ?x ?y))

> There is 1 solution so far:

>   #1: ?X=JACK, ?Y=JILL



> PATTERN: [F,F]

> | GOAL: (MARRIED ?x ?y)

> | SUCC: ?X=JACK ?Y=JILL truth=T






> This is a bit disappointing since the ability of PL to classify
> dynamically and have rules being applicable based on that dynamic
> classification is very useful. In the above example, it does not seem
> that the dynamic classification is happening.





> I tried to force re-evaluation just in case the reevaluation of married needed a trigger:


STELLA> (process-definitions)

> COMMON-LISP:NIL

STELLA> (retrieve (married ?x ?y))

> There is 1 solution so far:

>   #1: ?X=JACK, ?Y=JILL





> but that didnt work...





> Thanks


> Srini

> --- On Thu, 8/21/08, Hans Chalupsky <[email protected]> wrote:
> From: Hans Chalupsky <[email protected]>
> Subject: Re: [PowerLoom Forum] Unexpected Powerloom truth maintenance behavior....
> To: [email protected]
> Cc: "Thomas Russ" <[email protected]>, [email protected]
> Date: Thursday, August 21, 2008, 4:09 PM

> Yes, we have to see how to improve this.  Currently, the type
> assertions inferred from the domains of a relation are handled by a
> special mechanism if *type-check-policy* is
> :AUTOMATICALLY-FIX-TYPE-VIOLATIONS (the default).  They are asserted
> in the top-level module and not the inference cache, and we can't
> blindly remove them, since they might have been asserted explicitly or
> be the result of other assertions as well.  We only want to assert
> them if we have to,
>  which is why they are handled somewhat differently
> from other inferred information.

> One way to work around this for now is to set *type-check-policy* to
> :REPORT-TYPE-VIOLATIONS and then assert all types explicitly, in which
> case it is your responsibility to assert and retract them, but at
> least you won't be surprised by PowerLoom doing things behind the
> scenes.

> Hans

>>>>> Thomas Russ <[email protected]> writes:

>> On Aug 21, 2008, at 9:31 AM, Srini Ram wrote:

>>> (defmodule "TEST"
>>> :includes ("PL-USER"))
>>> (in-module "TEST")
>>> 
>>> ;(clear-module "TEST")
>>> (reset-features)
>>> 
>>> (defconcept person (?x))
>>> (defrelation spouse ((?x person) (?y person))
>>> :axioms (symmetric spouse))
>>> 
>>> (assert (spouse jack jill))  ; expect (person jack) (person jill) to  
>>> be also
>  asserted because of  domain of  person
>>> 
>>> (ask (person jack))
>>> TRUE                                      ;; as expected
>>> 
>>> (retract (spouse jack jill))          ;; expect (person jack) to  
>>> also be retracted by truth maintenance system
>>> 
>>> (ask (person jack))
>>> TRUE                                     ;; unexpected
>>> 
>>> Am I missing something.

>> No.  PowerLoom is missing something.
>> This is a bug.

>> I'm not sure about how to fix it, though.

>> _______________________________________________
>> powerloom-forum mailing list
>> [email protected]
>> http://mailman.isi.edu/mailman/listinfo/powerloom-forum