-----Original Message-----
From: address@hidden
[mailto:address@hidden
On Behalf Of William L. Jarrold
Sent: Tuesday, May 10, 2005 8:53 PM
To: Joshua N Pritikin
Cc: 'Open Heart Logic, dev mailing list'
Subject: RE: [Heartlogic-dev] rumination prototype
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.)
_______________________________________________
Heartlogic-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/heartlogic-dev