RE: [Heartlogic-dev] rumination prototype

[William L. Jarrold]

On Tue, 10 May 2005, Joshua N Pritikin wrote:

> On Tue, 2005-05-10 at 10:50 -0500, William L. Jarrold wrote:
> > On Tue, 10 May 2005, Joshua N Pritikin wrote:
> > > On Tue, 2005-05-10 at 02:02 -0500, William L. Jarrold wrote:
> > > > Jesus loves his father. [q]
> > > >
> > > > ...and then later, they can click on this and see why.  I.e. they would
> > > > see the premises which were:
> > > >
> > > > Sons love their fathers. [p1]
> > > > Jesus is God's son. [p2]
> > >
> > > Hrm, do you want to do this (click to see reasons) for the pilot?
> >
> > Yes, the would be my moderately strong preference.
> >
> > We must remember that we are building a platform for doing all sortsa
> > experiments.
>
> OK.
>
> The web interface is easy, but we have to load the data into the
> database.  In what scriptable format do you want to provide this
> information?

By data, I assume you mean the content of the items, right?

(Here is where I be comin' from: I usually think of data as somethign that 
we scientist collect rather than put in our experimental apparatus.)

So, assuming I am correct, I would like to defer on this until we nail 
down design issues such as the look and feel of the interface, the nature 
of the reversed, or mutated etc type items.

BUT, enough with my ceaseless procrastination!!!, here is a rough stab.

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?

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).  Well, Joshua, you are the programer dude.  Your call.

> > > Hrm, instead of telling me which items you want, why not just modify the
> > > attached script?
> >
> > Sure, will do, but not right now.
>
> One more question, for the reversed items do we tell people after they
> rate the item?

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.

> For example:
>
> HAL believes the following statement is FALSE:
>
>  Water is lighter than air.
>
> Most experts agree that this statement is highly unbelievable.

Minor point:  I would phrase this as "HAL thinks" rather than "Most 
experts agree."

> If you want it to look like this then we need to store a flag somewhere
> indicating that the assertion is reversed.  Hrm.  I'll think about it.

Maybe.  I was thinking that the "This item is reversed" clue would be
stored in "c) BACKGROUND:".

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.

Bill

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