Which modules get created by default?

[tidoust]

See related comment from @ngcharithperera:

(5) You have identified 'goal module' as a special module which will be created by the rule engine. Based on your diagram (Figure 1) I assume there will be 1 goals module and 1 rules module. Is this correct? Is there anything special about 'rules module'? Will 'rules module' get created automatically (similar to 'goal module')? Is it correct to assume long term memory (local and remote) are 'facts modules'?

@draggett noted that:

The rule engine assumes the “goal” module for a condition or action chunk if the module name is not given explicitly with @module. This is for convenience in authoring rules, and based upon experience in writing demos.

The rule engine assumes that the rules are held as chunks in the “rules” module following a similar approach in ACT-R. Another design choice would be to allow applications to register modules as containing rules, and for modules to contain a mix of facts and rules.

The specification needs to clarify:

• which modules get created by default
• whether it is expected that additional modules can be created
• whether modules can mix chunks of different types (facts and rules) and can be targeted interchangeably as facts or rules buffers
• whether modules can be read-only
• ...

The Rule engine execution section would be the perfect place to write these rules down.

[draggett]

I am unconvinced about modules being created by default as that sounds like something for a scripting specification. For this specification, we just need to note that "goal" is the default value for each condition and action chunk in the absence of an explicit @module declaration in that chunk.

[draggett]

The scripting API allows applications to create as many modules as needed and to declare additional operations for each module, but it assumes that at least the "goal" and "rules" module are created. This is, however, beyond the scope of this specification.

[draggett]

For now, I think it is safer to assume that rules are only in the "rules" module. The mapping mechanism can be used to "compile" rules from other modules to the "rules" module. I am looking forward to work on compiling rule conditions to a RETE style discrimination network for scaling up to much larger sets of facts and rules. Reinforcement learning of rules will involve a richer API, e.g. for copying and mutating rules.

[draggett]

whether modules can be read-only

That is an interesting idea and also relates to what metadata is needed to manage access when different clients have different restrictions on what they can do. I suggest we defer this until we have the corresponding implementation experience.