Richard, > the instance nodes are such an > important mechanism that everything depends on the details of how they > are handled.
Correct. > So, to consider one or two of the details that you mention. You would > like there to be only a one-way connection between the generic node (do > you call this the "pattern" node?) 1) All nodes are equal. 2) Nodes can point to each other. Yes, connection should be one way. (E.g.: You know George Bush, but he doesn't know you :-)) Two-way connection can be easily implemented by two separate connections. > For instance, we are able to see a field of patterns, of > different colors, and then when someone says the phrase "the green > patterns" we find that the set of green patterns "jumps out at us" from > the scene. It is as if we did indeed have links from the generic > concept [green pattern] to all the instances. Yes, that's good way to store links: All relevant nodes are connected. > Another question: what do we do in a situation where we see a field of > grass, and think about the concept [grass blade]? "Field or grass" concept and "grass blade" concept are obviously directly connected. This link was formed, because we saw "Field of grass" and "Grass blade" together many times. > Are there individual instances for each grass blade? If you remember individual instances -- then yes. > Are all of these linked to the generic concept of [grass blade]? Some "grass blades" may be directly connected to "field of grass". Other may be connected only through other "grass blade" instances. It would depend on if it's useful for brain to keep these direct associations. > What is different is that I see many, many possible ways to get these > new-node creation mechanisms to work (and ditto for other mechanisms > like the instance nodes, etc.) and I feel it is extremely problematic to > focus on just one mechanism and say that THIS is the one I will > implement because .... "I think it feels like a good idea". > The reason I think this is a problem is that these mechanisms have > system-wide consequences (i.e. they give rise to global behaviors) that > are not necessarily obvious from the definition of the mechanism, so we > need to build a simulation to find out what those mechanisms *really* do > when they are put together and allowed to interact. I agree -- testing is important. In fact, it's extremely important. Not only we need to test several models [of creating & updating nodes and links), but within single model we should try several settings values (such as "if node1 and node2 were activated together -- how much should we increase the strength of the link between them). That's why it's important to carefully design tests. Such tests should work reasonably fast and be able to indicate how good did system work. What is good and what is not good -- has to be carefully defined. Not trivial, but quite doable task. > I can show you a paper of mine in which I describe my framework in a > little more detail. Isn't this pager public yet? ----- This list is sponsored by AGIRI: http://www.agiri.org/email To unsubscribe or change your options, please go to: http://v2.listbox.com/member/?member_id=8660244&id_secret=73487197-bbb1fa
