Consolidate most attentionbank code to just one location

[linas]

The attentionbank code was starting to get invasive, causing dependency problems.

This isolates most of that code to just one directory.

[linas]

@misgeatgit please look this over. This defines a new guile module, which will require you to say (use-modules (opencog attention-bank)) to get the usual scheme cog-av, and cog-af and etc. functions. I imagine that there is scheme code in the opencog repo that will need to change to add the use-modules but I am not sure where that code is.

[linas]

After grepping, I see that the following need to say (use-modules (opencog attention-bank)):

ghost/matcher.scm
ghost/procedures/schemas.scm
ghost/stimulation.scm
ghost/test.scm
openpsi/action-selector.scm
nlp/chatbot/chat-utils.scm

I think this is the full, exhaustive list.

[misgeatgit]

@linas correct. those are the places that need these change. What was the reason for changing the name though?

[linas]

changing what name? I don't think I changed the name of anything ...

[misgeatgit]

Oh, it's a new module...got it!

[linas]

I'll merge in a few hours, unless you have comments ...

[linas]

pull req opencog/opencog#3098 needed to use the new module

[amebel]

@linas Why would you want to record the list of atoms in the attention-focus, explicitly in the atomspace?

[amebel]

This could create a nested list of MemberLinks if prev_af has MemberLinks used to represent the set of atoms in the attentional-focus(af). The logic = the representative sets are likely to be in the af because they are connected to atoms that are in the af, and sti will diffuse to them as a result of which they are likely to enter the af.

[linas]

Hi @amebel to answer both your questions: the API was designed to return an (unordered) list. There are two ways to represent a list in the atomspace: with a SetLink, or a MemberLink. I picked MemberLink, because SetLink has a variety of technical drawbacks. The technical reasons for this are detailed in #1502.

A different API, that might be better, would be to use the NextLink construct proposed in #1507 - however, that is not yet implemented, and it's not yet clear how such an API should be used.

As to diffusing STI to anchors: the answer is real simple: don't do that! Diffuse the STI to things that actually matter, for whatever problem you are trying to solve. Don't diffuse STI to core infrastructure. Perhaps it would be better to have an AnchorLink, with a rule that says "never diffuse to AnchorLink". There's a long, long list of link types that you never want to diffuse to: BindLink, or and subtype of PatternLink, VariableNode, or any of the VariableTypes, LambdaLink, and probably not the function links -- roughly, you never want to diffuse to any link type that is executable or evaluatable.

[ngeiswei]

It's probably deriving to an off topic discussion, but I feel diffusion should be user programmable, the user should be able to overwrite the defaults by providing some scheme function(s) that dictate(s) how STI should be diffused. Not offering that greatly lowers the usability of the attention allocation module, IMO.

[linas]

@ngeiswei @amebel I just opened opencog/opencog#3107 to track this as an attention-allocation agent issue. That way we can be on-target for that discussion.