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
_______________________________________________ Heartlogic-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/heartlogic-dev
