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
> 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),
Right, that's what I was asking. So:
create table c_commonsense (
) without oids;
Those string lengths are just approximate and easy to increase if
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
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