Better visualize modules in introduction

[tidoust]

@ngcharithperera commented:

(1) I wasn't sure how to visualise 'modules' in related to Figure 1. In your figure 1, are modules represented in blue colour?

First step would be to update the figure to:

It would probably be good to update the diagram to clearly delineate the modules: a module both encompasses a graph of chunks (the blue/yellow box) and a module buffer (the green box).

In any case, explanatory text should be added.

[draggett]

The current explanation is that each buffer corresponds to the bundle of nerve fibres connecting to particular cortical region. That is why the buffers are drawn as boxes above the connections from the rule engine to the modules. Another analogy, is that the buffers can be likened to HTTP clients whilst the modules can be likened to HTTP servers. This analogy has been strengthened by the choice of names for accessing and updating chunks in each module, e.g. get, put, patch, delete.

[draggett]

I forgot to add that the HTTP client/server analogy is important in respect to accessing remote cognitive databases. That would be in scope for another specification that defines a messaging protocol on top of HTTP, and complementing a specification on scripting.

Web Sockets may also be interesting, especially in respect to event streams that update buffers remotely. My experience with the Web of Things has shown that Web Sockets works very nicely as a messaging conduit.