Srini,
comments in-line:
>>>>> Srini Ram <
srini_ramaswamy_i@...> writes:
> Hi Hans
> What you say below may work in a limited way (unassert followed by assert) but can still fail as the following shows
> (defconcept person)
> (defconcept rich (?x person))
> (defconcept poor (?x person))
> (assert (disjoint rich poor)) ;; person can be rich or poor but not both
> (assert (rich jim))
> (retrieve all (rich ?x))
> #1: ?X=JIM ;; ok
> (retrieve all (poor ?x))
> No solutions. ;; ok
> (retrieve all (not (poor ?x)))
> No solutions. ;; why dont i get jim, system can infer that jim is not poor
> ;; since jim is rich, and rich/poor are disjoint.
> ;; still, not important at this point
The reason is that disjointness reasoning hasn't been all the way
completed yet. Most of the infrastructure is there, but it hasn't
been hooked into the inference engine yet. I'll see what it takes to
get that working, I don't think all that much. The main reason I
think why we've still been hedging on this were some performance
implications.
> (unassert (poor jim)) ;; whether it was asserted or not
> (assert (poor jim)) ;; jim is now poor..Note because of disjunction it should not be necessary
> ;; to state jim is no longer rich.
Well, no. Even if our disjointness module were complete, this is not
the behavior you would get. We distinguish between two kinds of
truths, if you will (or epistemological status): assertions, where the
user told us that something holds, and inferences, which follow from
assertions and rules of logical inference. The fact that poor <=> not
rich is an inference we (should) get from the disjointness assertion
which then contradicts the explicit assertion that he is rich. But at
that point PowerLoom doesn't know what to do, you've told it two
(actually three) things that lead to a contradiction, which one is the
correct one? It's not always the last one, since that could have
simply been a mistake on your part.
If you unassert poor, PowerLoom will not go out and try to infer all
things that logically contradict it and unassert those also. Even if
it tried that, there are in fact two things required to support that
contradiction, the rich assertion and the disjointness assertion,
retracting either one would solve the conflict. So which one should
we choose? A standard dilemma in belief revision. Of course, one
could special case this, but that would go a bit far, I think.
What you should get (sometime during backward or forward inference),
is a contradiction and an indicator what the reason is for the
contradiction, so that you can then make up your mind what you really
mean, i.e., whether Jim is really rich or poor or whether the two are
maybe not disjoint, and you can then perform the appropriate
maintenance.
Hans
> STELLA(28): (retrieve all (rich ?x))
> There is 1 solution:
> #1: ?X=JIM ;; error, doesnt seem to have gone away
> STELLA(29): (retrieve all (poor ?x))
> There is 1 solution:
> #1: ?X=JIM
> STELLA(30): (retrieve all (not (poor ?x)))
> No solutions.
> STELLA(31): (retrieve all (not (rich ?x)))
> No solutions.
> Maybe I need to add more rules to make this work, but then what is the point of having the disjoint statement?
> Thanks
> Srini
> ----- Original Message ----
> From: Hans Chalupsky <
hans@...>
> To:
srini_ramaswamy_i@...
> Cc:
powerloom-forum@...
> Sent: Friday, September 26, 2008 6:10:21 PM
> Subject: Re: Assertion followed by retraction leads to error state...
> Srini,
> a proposition has at most one truth value per module or context. So,
> when you asserted `(not (person jim))', it replaced the previously
> asserted default truth value with FALSE (had the previous assertion
> been a strict truth, it would have complained about a contradiction).
> PowerLoom doesn't keep a history of prior truth values, so there is no
> way to get back to the previous truth value with a retraction.
> You might be able to get half of what you want by using `unassert'
> instead of retract. With `unassert' you don't have to remember
> whether you asserted a truth or falsity. So, you can simply call
> `unassert' before each new assertion that might override a previous
> truth value. Conceivably, we could invent a command that combines the
> two into one. For example,
> STELLA(3): (defconcept person)
> |c|PERSON
> STELLA(4): (unassert (person joe)) ;; ok, even if nothing was asserted yet
> |P?|(PERSON JOE)
> STELLA(5): (assert (not (person joe)))
> |P|(NOT (PERSON JOE))
> STELLA(6): (unassert (person joe))
> |P?|(PERSON JOE)
> STELLA(7): (assert (person joe))
> |P|(PERSON JOE)
> STELLA(8):
> Hans
>>>>> Srini Ram <
srini_ramaswamy_i@...> writes:
>> I am experimenting with default truths and retraction...
STELLA> (presume (person jim))Ã Ã ; assume that jim is a person
>> |p|(PERSON JIM)
STELLA> (ask (person jim))
>> TRUE
STELLA> (assert (not (person jim)))Ã ;; we are told
>> specifically that jim is not a
>> personà à à à à à à à à à à à Ã
>> |P|(NOT (PERSON JIM))
STELLA> (ask (person jim))Ã Ã Ã Ã Ã Ã Ã Ã Ã ; ok
>> FALSE
STELLA> (retract (not (person jim)))Ã ;; retract
>> |P?|(PERSON JIM)
STELLA> (ask (person jim))
>> UNKNOWNÃ Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã
>> ;; wrong, we still have the presume
>> ;; so by adding and retracting a fact we wound up
>> ;; at a different state from where we started
>> What I would like to happen is that new facts should be able to
>> override old facts for cases where something can either be true or
>> false...Since jim is either a person or not a person, I should not have
>> to remember that I asserted that jim was not a person, and have to
>> retract it before asserting the new knowledge that jim is in fact a
>> person..From a maintenance perspective, this simplifies life a lot if
>> we can assert new knowledge and have it simply replace prior (default)
>> knowledge.
> <html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial,helvetica,sans-serif;font-size:10pt"><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt;">Hi Hans<br><br>What you say below may work in a limited way (unassert followed by assert) but can still fail as the following shows<br><br>(defconcept person)<br>(defconcept rich (?x person))<br>(defconcept poor (?x person))<br>(assert (disjoint rich poor)) ;; person can be rich or poor but not both<br><br><br>(assert (rich jim))<br><br>(retrieve all (rich ?x))<br>#1: ?X=JIM ;; ok<br>(retrieve all (poor ?x))<br>No solutions. ;;
> ok<br><span style="color: rgb(127, 0, 63);">(retrieve all (not (poor ?x)))</span><br style="color: rgb(127, 0, 63);"><span style="color: rgb(127, 0, 63);">No solutions. ;; why dont i get jim, system can infer that jim is not poor</span><br style="color: rgb(127, 0, 63);"><span style="color: rgb(127, 0, 63);"> ;; since jim is rich, and rich/poor are disjoint.</span><br style="color: rgb(127, 0, 63);"><span style="color: rgb(127, 0, 63);"> ;; still, not important at this point</span><br><br>(unassert (poor jim)) ;;
> whether it was asserted or not<br>(assert (poor jim)) ;; jim is now poor..Note because of disjunction it should not be necessary <br> ;; to state jim is no longer rich.<br><br>STELLA(28): (retrieve all (rich ?x))<br>There is 1 solution:<br> #1: ?X=JIM <span style="color: rgb(255, 0, 0);">;; error, doesnt seem to have gone away</span><br>STELLA(29): (retrieve all (poor ?x))<br>There
> is 1 solution:<br> #1: ?X=JIM<br>STELLA(30): (retrieve all (not (poor ?x)))<br>No solutions.<br>STELLA(31): (retrieve all (not (rich ?x)))<br>No solutions.<br><br>Maybe I need to add more rules to make this work, but then what is the point of having the disjoint statement?<br><br>Thanks<br>Srini<br><br><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;">----- Original Message ----<br>From: Hans Chalupsky <
hans@...><br>To:
srini_ramaswamy_i@...<br>Cc:
powerloom-forum@...<br>Sent: Friday, September 26, 2008 6:10:21 PM<br>Subject: Re: Assertion followed by retraction leads to error state...<br><br>
> Srini,<br><br>a proposition has at most one truth value per module or context. So,<br>when you asserted `(not (person jim))', it replaced the previously<br>asserted default truth value with FALSE (had the previous assertion<br>been a strict truth, it would have complained about a contradiction).<br>PowerLoom doesn't keep a history of prior truth values, so there is no<br>way to get back to the previous truth value with a retraction.<br><br>You might be able to get half of what you want by using `unassert'<br>instead of retract. With `unassert' you don't have to remember<br>whether you asserted a truth or falsity. So, you can simply call<br>`unassert' before each new assertion that might override a previous<br>truth value. Conceivably, we could invent a command that combines the<br>two into one. For example,<br><br>STELLA(3): (defconcept person)<br>|c|PERSON<br>STELLA(4): (unassert (person joe)) ;; ok, even if nothing was
> asserted yet<br>|P?|(PERSON JOE)<br>STELLA(5): (assert (not (person joe)))<br>|P|(NOT (PERSON JOE))<br>STELLA(6): (unassert (person joe))<br>|P?|(PERSON JOE)<br>STELLA(7): (assert (person joe))<br>|P|(PERSON JOE)<br>STELLA(8): <br><br>Hans<br><br>>>>>> Srini Ram <<a ymailto="mailto:
srini_ramaswamy_i@..." href="mailto:
srini_ramaswamy_i@...">
srini_ramaswamy_i@...</a>> writes:<br><br>> I am experimenting with default truths and retraction...<br>STELLA> (presume (person jim))à à ; assume that jim is a person<br><br>> |p|(PERSON JIM)<br><br>STELLA> (ask (person jim))<br><br>> TRUE<br><br>STELLA> (assert (not (person jim)))à ;; we are told<br>> specifically that jim is not a<br>> personà à à à à à à à à à à à à <br><br>> |P|(NOT (PERSON JIM))<br><br>STELLA> (ask (person
> jim))Ã Ã Ã Ã Ã Ã Ã Ã Ã ; ok<br>> FALSE<br><br>STELLA> (retract (not (person jim)))Ã ;; retract<br>> |P?|(PERSON JIM)<br><br>STELLA> (ask (person jim))<br><br>> UNKNOWNÃ Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã Ã <br>> ;; wrong, we still have the presume<br>> ;; so by adding and retracting a fact we wound up<br><br>> ;; at a different state from where we started<br><br>> What I would like to happen is that new facts should be able to<br>> override old facts for cases where something can either be true or<br>> false...Since jim is either a person or not a person, I should not have<br>> to remember that I asserted that
> jim was not a person, and have to<br>> retract it before asserting the new knowledge that jim is in fact a<br>> person..From a maintenance perspective, this simplifies life a lot if<br>> we can assert new knowledge and have it simply replace prior (default)<br>> knowledge.<br></div></div></div><br>
> </body></html>_______________________________________________
> powerloom-forum mailing list
>
powerloom-forum@...
>
http://mailman.isi.edu/mailman/listinfo/powerloom-forum_______________________________________________
powerloom-forum mailing list
powerloom-forum@...
http://mailman.isi.edu/mailman/listinfo/powerloom-forum
Some parts of this message have been removed.
Learn more about Nabble's 