RE: [Heartlogic-dev] rumination prototype

[Joshua N Pritikin]

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?

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

> 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.

> 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.

> 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.

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

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