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

Hi Charith,

Many thanks for the feedback. I created GitHub issues to track your 
comments, see inline.

------ Original message ------
From: "Dave Raggett" <dsr@w3.org>
To: "Charith Perera" <PereraC@cardiff.ac.uk>
Cc: "public-cogai" <public-cogai@w3.org>; "Francois Daoust" <fd@w3.org>
Date: 11/11/2020 12:15:26

>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.
Tracked in https://github.com/w3c/cogai/issues/20

I note that module buffers are part of modules as well, so a module is 
equal to a blue box + a green buffer box in the figure. A blue box alone 
represents a graph of chunks.


>
>
>>  (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
Tracked in https://github.com/w3c/cogai/issues/21


>
>
>>  (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.

Tracked in https://github.com/w3c/cogai/issues/22

>
>
>>(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).
>>
>>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.
Tracked in https://github.com/w3c/cogai/issues/23

>
>
>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.
Tracked in https://github.com/w3c/cogai/issues/24
The whole "Rule engine execution" section needs to be written...

Thanks,
Francois.



>
>
>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> 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
>
>
>
>

Received on Friday, 13 November 2020 15:23:15 UTC