Re: Adopting chunks graph data and rules as a Draft CG Report

Hi Charith,

Thanks for your feedback which is much appreciated.  I am adding François to the Cc list as he is the editor for the draft spec. We should use GitHub for issue tracking as appropriate to each point you raise. François, could you please handle that?

Comments below.

Best regards,
Dave

> On 2 Nov 2020, at 08:09, Charith Perera <PereraC@cardiff.ac.uk> wrote:
> 
> Hi Dave,
>  
> Few comments.
>  
> (1) I wasn't sure how to visualise 'modules' in related to Figure 1. In your figure 1, are modules represented in blue colour?

Yes, as are the yellow input and output boxes.  The application code implementing input and output can use the scripting API on modules, including defining module operations that extend the rule language, e.g. to control a robot, or to set the context and focus for visual processing. Sensory processing can be handled in terms of dynamically updating chunks that model perceived state, and by queuing chunks to module buffers that trigger rule execution to handle sensory events. The queue ensures that closely spaced events aren’t lost, something I learned from work on the robot demo.

It thus sounds like the diagram needs some explanatory text. We should update the diagram to the one used in:

 https://github.com/w3c/cogai/blob/master/chunks-and-rules.md

which uses a dark grey background for the cortical modules including perception and action.

>  (2) In Section 4.1 you talk about a special case. Is it possible to give example? (I could imagine how it looks like based on the information you provided, but I felt it would be better if you provide just in case if we misinterpret). 

Indeed, this needs to be added. An example and explanation is given in : 

“Additional features” in https://www.w3.org/Data/demos/chunks/chunks.html

>  (3) In Section 4.2, you mentioned that identify is optional. Is it possible to give an example to show how it looks like?

Good idea. The spec should further say something to the effect that the chunk ID is optional, and if missing, will be automatically assigned when adding the chunk to a graph. If the graph already has a chunk with the same ID, it will be replaced by this one. 

> (4) I got a bit confused by the use of the term 'KindOf'. what would be the difference between (Type, Type of or Is-a) Vs 'KindOf'. As a non-native to English speaker, I initially interpreted 'KindOf' as '…used when you are trying to explain or describe something, but you cannot be exact…' (https://dictionary.cambridge.org/dictionary/english/kind-of <https://dictionary.cambridge.org/dictionary/english/kind-of>).
>  
> I wasn't sure whether you are trying to use 'KindOf' as an alternative to 'Is-a' or do you expect 'KindOf' to be able to handle ambiguity (some sort of probability)

This needs a clearer description in the spec. The intent is to distinguish between an instance of some type and a subtype of some type, and to provide built-in support in the rule language for convenience in matching along chains of subtypes. Names with built-in, i.e. reserved, semantics should start with an @, hence  we could here use @isa and @kindof or similar names.

Turtle uses “a” for instance of, and as convenient abbreviation for the following URI:

 http://www.w3.org/1999/02/22-rdf-syntax-ns#type

Likewise the subtype relation is denoted by the following URI:

 http://www.w3.org/2000/01/rdf-schema#subClassOf

Note that we will also need support for fuzzy matching based upon properties, where the matches are ranked according to statistical considerations that are influenced by past experience. This is important in respect to inductive learning and the likelihood of noisy data.

>  (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'?

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.

Either way, efficient matching of rules calls for compiling rule conditions into a discrimination network so that changes to module buffers propagate dynamically to update the current set of matching rules. John Anderson claims that the discrimination network corresponds to the Striatum in the human brain. It is analogous to Charles Forgy’s RETE algorithm for production rule languages like OPS5.  This makes a plausible case for having a single rule module corresponding to the Striatum, Pallidum and Thalamus.

You can write rules that add new rules or update existing ones since rules are actually modelled as linked chunks.  There is also support for compiling declarative representations of rules from other modules, see:

 https://www.w3.org/Data/demos/chunks/chunks.html#compilation

This follows the theory of skill retention with three stages of learning and forgetting:

 1. Declarative
 2. Declarative + Procedural
 3. Procedural

I want to work on some demos to show this in operation, along with the use of heuristics to modify rules, and hierarchical reinforcement learning to update the expected utility of individual rules following the approach taken with ACT-R. We need more developers to help with the demos envisaged in the roadmap.

>  
> Cheers,
> Charith
>  
> From: Dave Raggett <dsr@w3.org> 
> Sent: 19 October 2020 02:44 PM
> To: public-cogai <public-cogai@w3.org>
> Subject: Adopting chunks graph data and rules as a Draft CG Report
>  
> On behalf of the chairs of the Cognitive AI Community Group, I would like to ask the Community Group for approval for formally adopting the chunks graph data and rules specification [1] as a Draft CG Report. If you have any objections, please email this list before next Monday (26 November 2020).
>  
> We also very much welcome review of the draft specification and expect to iterate it further before calling for formal approval for releasing it as an official CG Report.
>  
> [1] https://w3c.github.io/cogai/ <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fcogai%2F&data=04%7C01%7Cpererac%40cardiff.ac.uk%7C44c4ed441a99412d9a7608d874351349%7Cbdb74b3095684856bdbf06759778fcbc%7C1%7C0%7C637387118592885237%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NoRhlZKuBVFaY6BCS5Q2LPMkNa%2BmwPmshQZdrk5aCZs%3D&reserved=0>
>  
> Many thanks,
>  
> Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>> http://www.w3.org/People/Raggett <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2FPeople%2FRaggett&data=04%7C01%7Cpererac%40cardiff.ac.uk%7C44c4ed441a99412d9a7608d874351349%7Cbdb74b3095684856bdbf06759778fcbc%7C1%7C0%7C637387118592895184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=R%2FXO7L%2BvVOrIHeiPzw7rDTHX2iQBveGPSGd2btcuhFQ%3D&reserved=0>
> W3C Data Activity Lead & W3C champion for the Web of things 

Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
W3C Data Activity Lead & W3C champion for the Web of things