RE: [Heartlogic-dev] OHL v2 alpha test

[Joshua N Pritikin]

On Tue, 2005-03-22 at 00:30 -0600, William L. Jarrold wrote:
> * most of the text i had no idea what it meant....e.g. this...
> 
> "orange juice is a matter of might (as opposed to law)."
> 
> ...huh?  might, as in might makes right instead of rule by law

Yes.

If daddy doesn't give Toby the orange juice that he's after then on what
basis is daddy able to deny Toby?  Is it a matter of law, which compares
withholding orange juice to stealing a car?  Or is it merely that daddy,
as the parent, can make a unilateral decision (might)?

Suggestions about how to make this more clear are welcome.

> * as you prolly recall, in the dissertation, what you have as "story" was
> split up into "overriding goal" and "situation."  it might be better to
> keep that distinction.  i'm not sure.

I haven't integrated all the levels of appraisal but this would be easy
to do.  Each level (should) depends on earlier levels.  So by the time
we get to level 'm' (the level of your dissertation), there is a
empirically tested believable overriding goal from level 'g'.

As soon as you report that you have toured all the levels then I will
adjust the database so that it grows by level instead of jamming
everything together, like it is now.

> * regarding "tortured prose". e.g. this...
> 
> In tobys opinion, his dad wants to avoid something about orange juice for 
> himself. (TODO: how to disambiguate whom the trailing himself/herself 
> refers without tortured prose?)
> 
> ...those seem like issues that are very tightly intertwined with the tasks 
> of re-building the model, aligning the model with CLib (e.g. in my model
> I used the term gender but in CLib they use sex).  I would not work on 
> any detailed KM model stuff until we decide how tightly we want to align 
> with CLib.  (I'm assuming you know that KM has a text gen facility and 
> are using that to generate the text and not your own hand-rolled text 
> gen system).

Incidentally, my database uses sex instead of gender.  However, that's
beside the point.

What is worth stating is that there is a pretty clear separation between
the model and the database.  I can provide a list of queries I run on
the KM model.  The database only stores the cues, possible appraisals,
and, optionally, the expected believability.

What I like about the new database design is that the appraisals are
stored in a tree-like structure.  Statistics are kept in real-time.
Branches which are not believable are not searched.

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