heartlogic-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Heartlogic-dev] Re: appraisee (was Re: squeak)


From: William L. Jarrold
Subject: [Heartlogic-dev] Re: appraisee (was Re: squeak)
Date: Sat, 13 Dec 2003 18:16:19 -0600 (CST)

On Sat, 13 Dec 2003, Joshua N Pritikin wrote:

> On Fri, Dec 12, 2003 at 10:03:13AM -0600, William L. Jarrold wrote:
> > On Fri, 12 Dec 2003, Joshua N Pritikin wrote:
> > > Here's a change I want to make as soon as possible which I doubt
> > > you will find controversial.
> > >
> > > I want to explicitly parameterize the appraising-agent.
> > >
> > > This change doesn't have any impact on your Study #3.  However,
> > > it will be required information for participant submitted
> > > cues & appraisals.
> >
> > Short Answer: At this level of detail it sounds like a fine change.
> >
> > Long Answer: For the first set of web studies we do where the goal is to
> > replicate my dissertation findings this change would be invisible to
> > research subjects, right?
>
> Correct.

Good.

>
> > But, yes, once the research subjects
> > have done their dutiful participation in the replication study
> > we definitely want to be able to allow them vary the appraising
> > agent.  E.g. if toby wants a cookie and daddy turns on the television
> > how would george bush feel about it?
>
> OK, now if we have parameterized "appraiser" then we can
> parameterize "appraisee" also?

Sure.  But I think appraisee is a misleading name.  Appraisee suggest
that it is an object of the appraiser's appraisal.  This is not,
in general true.  Tracy might feel appreciation toward Mommy.  In this
case Mommy is the object appraised, and appraisee might be a good name
for Mommy's role.  But Tricy might feel happy about the event.  In this
case Mommy is not the object appraised, but the event is.  But calling
an event the appraisee is even more confusing since we expect -ee's to
be agents.

Thus, drawing on my experience with Cyc, I think that Mommy is an actor
in the situation but participant is an even better name for her role.
participatingAgent is a spec slot of participant...And, of course, Mommy
plays the role of "givingAgent" which is a spec slot of
participatingAgent.

The slot hierarchy looks like this, roughly...

participant
   ^
   |
   |
participatingAgent
   ^
   |
 (skip a few slots)
   |
givingAgent

>
>   Cue: Mommy gives Tracy an apple.

Btw, emotion eliciting situation is what Clark Elliot
has called the cue....Sorry for my obsession with names,
but I think it really helps develop a shared understanding
of a domain to have very good, non-misleading names.

>
>   How does Tracy feel about getting an apple?
>     (appraiser=Tracy, appraisee=Tracy)
>
>   How does Tracy think Mommy feels about giving her an apple?
>     (appraiser=Tracy, appraisee=Mommy)

Right, but, as I said I don't like the name "appraisee".  The apple
and the giving event might be appraisee's too.

>
> > i'm not categorically against
> > adding more variables to the model, but also believe you have to
> > walk before you can run...in other words, we might want to focus our
> > modeling effort on handling a relatively constrained set of cases
> > before tackling full blown complexity.
>
> Yes, of course.  A KR model can output appraiser=appraisee style
> appraisals.  I'm worried about limiting the choas with participant
> submitted appraisals.

Me too.

Might be slightly better to say "I'm worried about ordering the chaos
in participant submitted appraisals."

Bill

>
> --
> A new cognitive theory of emotion, http://savannah.nongnu.org/projects/aleader
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]