[Heartlogic-dev] Re: towards putting the model on the web

[Joshua N Pritikin]

On Fri, 2004-12-31 at 18:19 -0600, William L. Jarrold wrote: 
> So, you are agreeing that priority one is to get the model working live at
> the website.  Have people interact with it and rate its output in a
> fashion sorta like the hot-or-not website, right?  (just like, I think it
> was, Josh W's idea).

Yah.

> Your webinterface will somehow hook call this Km model thing.  It will
> take scenarios and appraisals and present them one by one to a www user
> for a rating.   It will also reverse the valences (e.g. put up Sad when
> Happy was inferred by the model) in a (random?) subset of the scenarios
> presented to a given user so as to test experimental hypotheses.  It will
> record when it is reversing the valence and it will record the user's
> believability rating for each presented .  So far so good?

Yah.

> Maybe next we'll allow the user to pick what happens to Tracy.
> 
> Like so...ohl website presents user with...
> 
> "Tracy wants and apple."
> "Mommy gives Tracy a <X>."

Fine.

> Also, over time, the user will have more control over specifying what
> kind of situation tracy is faced with.
> 
> E.g. at first the scenario will only have one dimension, i.e....
> 
> "Mommy gives Tracy a <X>"
> 
> ....but then it might be, say, *two* dimensional....
> 
> "Mommy <ACTION> Tracy <INDIRECT-OBJECT>."
> 
> ... Am I asking for the moon?

No, but I have two comments: (1) structural dependency between
parameters and (2) which dimensions / parameters to add.  The other
thing I want is say up front is that this email may seem too
theoretical.  I promise to get to the point ASAP.  Let's start with (1).

Last year, you suggested adding believability ratings like "How
believable is the affect?", "How believable is the reason?", and "How
believable is the affect and the reason together?".  I presume the aim
of these questions is to get a more precise assessment of where the
scenario is going wrong (or right).  You may be aware that I implemented
your idea.  You can play around with it on the web.

The problem is that as the number of parameters increase, the need for
multiple believability ratings also increase. I don't think that
multiple ratings are going to fit into the hot-or-not mold.  We need to
minimize the number of clicks per page.  I have a proposal.

Recall that, according to Cognitive Appraisal Theory, the affective
state is a function of the appraisal.  There is a dependency
relationship. Hence, we should ask "How believable is the
reason/appraisal?" _then_ ask "How believable is the affect?".
Furthermore, it doesn't serve much purpose to ask about the
believability of the affect if the reason/appraisal is totally
unbelievable.  Hence, first we get a rating for:

Goal: Tracy wants a banana.
Situation: Mommy gives Tracy an apple for lunch.
Question: How will Tracy feel when mummy gives her an apple for lunch?
Reason: At least she gets to have fruit.

And if this is believable (on average) then we get a rating for:

Goal: Tracy wants a banana.
Situation: Mommy gives Tracy an apple for lunch.
Question: How will Tracy feel when mummy gives her an apple for lunch?
Reason: At least she gets to have fruit.
Affect: Sad

If the reason/appraisal is not believable then we don't bother asking
about the believability of the affect.  Am I repeating myself?  Oops,
anyway ...

Now I'm going to talk about which parameters to add.  I'm not sure if I
can explain this clearly but let's give it a try.  I am going to make a
distinction between two different types of parameters.

One type of parameter is like <INDIRECT-OBJECT>.  There are infinitely
many variations which can bind to <INDIRECT-OBJECT> and this is where we
can benefit from a large commonsense KB.  In the example above, we'll
probably want to be able to determine if the binding of
<INDIRECT-OBJECT> is a type of fruit or a type of food.

That's one type of parameter.

The other type of parameter can change the structure of the appraisal.
For example, if I bind "observes" to the <ACTION> (Mommy observes Tracy)
then there is no place/need for an <INDIRECT-OBJECT>.  So
<INDIRECT-OBJECT> _depends_ on a particular appraisal structure (a
"gives" binding to <ACTION>).  On the other hand, there can be an
infinite variety of bindings for <ACTION> which do not affect the
structure of the appraisal.  All of "offers" "gives" "places nearby"
"carefully gives" "slowly gives" "tosses to" etc, all these bindings
create approximately the same appraisal structure.

To review:

type-a                 type-b
---------------------- ---------------------------
structural             non-structural
check dependencies     dependencies unaffected
finite variation       infinite variation

I'm just roughing things out.  I haven't proved that type-a parameters
have finite variation.  So where I am going with this?  For each type-a
parameter, we can sub-divide the questions (and ratings) according to
the dependency chain.  For example, if add an appraisal for goal-status
(Goal, AntiGoal, or NoGoal) then we can ask:

Situation: Tracy wants a banana.
Tracy has a Goal.

Believable?  Or:

Situation: Tracy wants a banana.
Tracy has a NoGoal.

Believable?

As we link all these sub-appraisals together we arrive back at:

Goal: Tracy wants a banana.
Situation: Mommy gives Tracy an apple for lunch.
Question: How will Tracy feel when mummy gives her an apple for lunch?
Reason: At least she gets to have fruit.
Affect: Sad

Except that the situation is nicely parameterized and we have a bunch of
believability ratings already done to establish that this scenario is
something which is already fairly believable so we aren't wasting
people's time asking about 1000s of unbelievable scenarios.

> Does this all sound cool and doable?

Yah, what do you think?

> p.s. Glad to know that you are well inland and far away from Tsunami
> (Pune, sorta near Mumbai (aka Bombay) right?).  Hope you did not know
> anyone in that mess, did you?

Personally I don't know anyone who was affected.

-- 
A new cognitive theory of emotion, http://openheartlogic.org

signature.asc
Description: This is a digitally signed message part