RE: [Heartlogic-dev] rumination prototype

[William L. Jarrold]

On Wed, 11 May 2005, Joshua N Pritikin wrote:

> On Tue, 2005-05-10 at 22:52 -0500, William L. Jarrold wrote:
> > BUT, enough with my ceaseless procrastination!!!, here is a rough stab.
>
> Yes, that is key.  ;-)
>
> > For each item there will be...
> >
> > a) an item id
> >
> > b) THING-TO-RATE: a hunk of html text that when plugged into your
> > doodad is the thing that they will be rating.
> >
> > c) BACKGROUND: another hunk of html text that will be viewable if the
> > participant wants to see where b) came from.  (this would contain info
> > like "This item was reversed.  Click here to see what we mean by
> > reversed." or "This item was actually a deduction that HAL made after
> > doing some thinking.  This is the chain of deductions that HAL made in
> > order to come up with that deduction."
> >
> > ...in the beginning we will hand craft b) and c).  In our stary-eyed
> > futures we will have a program generate b) and c) based on the output
> > of an AI (such as Cyc or KM plus its CLib).
> >
> > ...Also I hope you can do this so that we can add more fields beyond a, b
> > and c if we need to.  Is that posssible?
>
> Yah, you can do anything but you have to _decide_ and get to the point
> of actually doing it so we can get on with actually running the
> pilot!  ;-)
>
> > Also, the item id should encode what condition the item was in.  E.g. (i) was
> > it a deduction or a ground fact?  (ii) Was it from Cyc or KM?  (iii) Was
> > it reversed or unreversed?....Hrm, perhaps the better idea is to leave the
> > item id be any unique char string and have other fields for (i), (ii),
> > (iii).
>
> Right, that's what I was asking.  So:
>
> create table c_commonsense (
> id int,
> c_commonsense_is_reversed boolean,
> c_commonsense_statement varchar(512),
> c_commonsense_explanation varchar(1024)
> ) without oids;
>
> Those string lengths are just approximate and easy to increase if
> needed. OK?

you are the programmer but i think id would be better if the is_reversed
var were at the end.  since there are likely to be other vars that we will
add soon.

also, i think is_reversed should be a string of length, oh, 16.  memory
is cheap and people are v v expensive.  i think we will have several
levels of reversal.  right now i can see e.g. several places in which
to put the not.  plus reversal might be a different animal for
rules.

we should also have an extra variable for gaf vs rule.

anyway, this is a pilot so it need not be perfect.

> So write a perl script or a carefully formatted file which can be used
> to populate such a database table.

you recently sent an email with an attachment named simple.  you wanted 
me to tweak the item content in there to my liking.  my guess is that this 
was an example of a carefully formated file which can be used to populate 
such a database table.  is that correct?

> > Yes.  (As a parity check I will restate wha is hopefully obvious) We
> > definitely would *not* tell them before they rate it that it is reversd.
> > If we did tell them before, this would tip them off that they should rate
> > it unbelievable.
>
> Yes, of course.  Parity check succeeded.  ;-)
>
> > > Most experts agree that this statement is highly unbelievable.
> >
> > Minor point:  I would phrase this as "HAL thinks" rather than "Most
> > experts agree."
>
> OK, I have removed the part about how other people have rated this piece
> of commonsense knowledge.

well, what we actually want is both.  we want...

hal thinks blah.

please rate this

1) high un 2) mod un 3 neut 4 mnod belief 5 hightly believable

...then after the user finishes we want some representation of what people 
think...

e.g. the average believability rating that other human raters gave was 4.
3 other's have rated this so far.

...What do you guys think...what is the best way to rep "what other human 
raters believe" here?  mean and number of respondants?  mean alone?  mean 
plus sdev?  a histogram?....my preferennce is mean  and number of 
respondants.

> > Maybe.  I was thinking that the "This item is reversed" clue would be
> > stored in "c) BACKGROUND:".
>
> If we can parameterize things and store the reverse attribute as a flag
> then that will be better from an programming point of view.  A flag is
> something we can search on later.  On the other hand, storing everything
> in an html blob is also OK.  Your choice.

I trust your judgement.  Let's put reversal as an attribute.

> > But as I alluded above, we might not want to overload the item id and
> > thus there are other reasons to have a field include whether the item
> > is reversed or unervrsed or who-knows-what.
>
> Yah, the best way is to keep all the descriptive facts about the item as
> separate fields.

Okee dokee.  Sounds good.

Bill

> --
> If you are an American then support http://fairtax.org
> (Permanently replace 50,000+ pages of tax law with about 200 pages.)