接获取答案，通过相似的句式，从多个渠道直接验证答案；也可能将原理推理落实到实例经验，间接验证答案。
某些问题的答案相对抽象，开始是一个简单的结构，后面随着认识的深入，不断展开细节，扩展成更详细的结构。 5思考如何描述：从我的疑问模板理解别人的疑问模板，帮助别人解决疑问。
第四章代码实践备忘
4.1 尝试过的文本和代码
1、库和脚本类：具体名词概念模板苹果；具体概念模板抓；抽象名词模板物体、时间、空间、视觉；至上而下的概念汇集分类概念map；概念库类型-预备概念；词汇表类型；语义串库类型表达；记忆类型句子分析记录 2、过程
加入盘古分词项目，未识别词语的再次解析
围绕独立概念模板，针对概念名、概念属性和属性值的搜索查询 简单的逻辑句式到描述句式的随机搜索转换 未知词语在4万词语的dbf词典中的查询 根据词性组合简单匹配词组
导入概念map一部分，作为静态变量，匹配到词语；在近义词表中匹配出概念map相关内容
字典查询后，匹配同义词、视觉、味道几个简单语义向量，转换为概念-属性-值的格式，写入预备概念库
围绕词汇疑问，计入我的疑问节点，作为疑问雏形 建立并写入《句子分析记录》，作为临时记忆的雏形
实验树形容器控件，尝试后期用于展示分析打开的数据库。 手工分析百度表单，代码提交key，自动打开百度百科获取文本
3核心过程描述： 界面form1
按钮1分词测试 按钮2百度百科 按钮3后台整理 按钮4 综合理解
输入字符小于4，按单个词语进行搜索 word_undersdander.understand_search(inputtextbox.Text)
否则进入句子理解主过程word_undersdander.s_type_under，输出
word_undersdander.ST_inoutrec数组和word_undersdander.s_ana_result的各项结构变量
s_type_under句子理解主过程：
1对输入串进行句型匹配: s_type_match过程 ；
2处理未知词语query_match(input)过程
3通过时间副词和动词判断是否情景（情景一半被认为是经验，进经验库） 4进行概念理解concept_search(s_ana_org)过程 5记录分词和搜索时间
6分析过程写入句子分析记录、情景句子写入情境库、词汇疑问写入理论.我的疑问
S_type_match分析主过程， 被调用：理解主过程调用
1建立句子分析的输入和结果数组和链ReDim s_ana_org(word_list.Count - 1) s_ana_result = New SuperLinkedList(Of w_ana) 分词得到的每个词汇一个作为成员
2 s_ana_org各项结构变量初始化，如词性、
3 词组格式的严格匹配，包含了1层纯词性+常量，和加入2层概念map的格式结构，使用理论.词汇中的<词组格式>
4 使用表达文档中的<阅读句式>，进行句式匹配，选定逻辑句式
concept_search概念理解主过程： 被调用：理解主过程调用
调用studyfr_dateset(unknown_words)
1、从所有XML库文档文件名找有没有分词的概念
2、如果概念文件名含有句子某个词，则进一步找属性名和属性值，即该文件中的文档标签和相关值，如果凑上2，3个，就根据已知知识回答或表态。 3、如果没有则找预备概念文档中的已知解释（只重复字典解释） 4、预备概念中没有则进入查字典过程studyfr_dateset(unknown_words) ****这是一个内容过时的过程，针对苹果具体概念，今后应改为以预备概念库的知识查询为主。
studyfr_dateset字典查询过程
1、打开dbf字典库相关表格，筛选未知词汇条目
2、对释义内容进行匹配undersdand_match(ex!shiyi, ex!cimu)
3、有匹配内容和释义一起写入预备概念库，匹配不成发出疑问表达句型
undersdand_match匹配学习过程
1、整理释义文字段落，分词、导入w_ana集合
2、如果词语位置position能接上，则调用S_type_match分析句子词组和句式。
3、对词组成员做语义匹配（好像与S_type_match中初始化词语链重复了） 4、从语义map中准备好匹配学习的xelement参数
5、在释义第一句中找key的上级概念，条件是：最后一个词=语义map中的分类。否则视为与之有关
6、第一句没配上语义map的概念，且只有1个词，或标点分开的两个词，视为同义词
7、匹配部位和形状颜色味道的属性
8、再做一轮同义词匹配
最新格式扩展：将...替换为$$n，表示任意语块变量，后面的整数0，2表示在句式中的位置，描述和阅读句式的语块变量与第一个逻辑句式对齐-->
在undersdand_match过程中，统一使用句型格式+分词链的参数格式，通过semele_match方式，进行语义串匹配，增强句式学习的功能和可扩展性
3重要类 thinking_act，思维动作，含思维主体、思维对象、思维结果由字符串描述
undersdand_lev1感知级别的理解动作
在文字阅读上用于某一句分词后基本语义的本能反应，如是否疑问、捕捉动词、匹配概念、有没有生词等
3.8 v1.2版，词语的学习
1、增加概念串的词组和语句块描述，阅读匹配。 例如：从A到B；名词A“和、及、与”名词B。
这两个句式中，A和B都可以描述为概念map中任意节点里的不同值 【node】A=any.【value】1，B=【node】A. 【value】2。 （这个写法真心不满意，应该有更好的） 或者干脆：从A到B：：dim A,B as 【value】 A. 【node】=B.【node】
其它方案还有，先写出来用着先：
动宾词组@gn.node.in\思维运动\，@gn.node.in\思维结构\偏正@动词：：gn.node.notin\思维运动\，@gn.node.in\思维结构\（include简写为in）
这个词组结构表示，只有在包含了思维活动的节点下的概念值（自然是动词）和包含了思维结构的概念（自然是名词）组合的时候，才是动宾关系，而其它动词并不能和思维结构名词概念进行动宾组合，所以是偏正关系，表示与A有关的B。
二级句式的描述，首先由纯词性变量，匹配出第一层的句式或词组结构，然后再进行第二层匹配，但这个层次结构在词组格式中建立起来并不简单：要建立二级词组格式<词组语义格式>，并且与相应的一级词组格式（纯词性即<词组格式>）对应起来，目前的一个方案是在<词组格式>和<词组语义格式>中都标注上属性id。在一级句式数量不多的情况下，干脆把二级句式的属性值等于关联一级句式的值好了。
从另一角度看，是不是只有动宾和联合词组（可能还有主谓），需要语义上的搭配才成立，否则都会转化为偏正词组吗？似乎偏正词组的搭配关系最为随意，在
概念map中的跨越性大。
语句块的词汇之间使用连接符，如联合关系之间使用&，动宾之间使用v-n，对名词偏正使用aj-n，对动词偏正使用av-v...等，这样记录到词组经验库时，能独立快捷地识别。
第一级语句格式可以写到4个词汇的组合，后续尝试对简单词组结构进行化简，二次匹配蒋更多词组的结构化简，分析更复杂的句子。
2、预备概念库整理成树结构，记录中增加它的概念串（如果本身没有，则使用上级概念的概念串），加入常用词组及语义块的含义（标识出组合的关系）。 3、在确认词组的情况下，反推未知词汇的意义，可使用如1的例子 4、增加字典中的句式理解，匹配出同义词后，及时扩大同义词表
5、一段文字中多次出现的词汇，则将其预备概念的内容以XML临时变量方式导入内存，加速搜索，
6、词组也可以进行演绎学习，作用域非常广泛。即对同一概念节点下的其它概念值进行类推后，通过搜索引擎或更多文本库求证，大批量生成经验库。
附录：演示代码进度
2016.3月重启代码更新：二层（语义层）的语义串匹配演示实例1：动词+名词，动宾词组的二次匹配修正当不属于同一语义map域时，转为偏正结构。
词组、句式中的元素匹配使用了独立函数elematch，加入in-notin语义串变量，以应对将来更为复杂的语义串描述。
2016.4，调通原来的unkword_match，修订盘古分词的未知部分；调通synmatch即map中的同义词匹配
2016.5月推进：undersdand_match中使用elematch，与$$的任意语义串配合，效果良好。修订了同义词表达中与逻辑句式的协同，增加or效果良好。目标，颜色、属性匹配使用elematch函数和in-notin，增加抽象性。
目前，上级概念查找的句式没有明确方案。目前使用的句式匹配包括两种方案：1是只要存在那几个元素，并按顺序依次排列，这是当前词组匹配方案和最初的undesdand_match生硬匹配方案；2存在几个元素并且按顺序排列即可（没有依次），是目前使用的方案，这个条件目前有效但可能偏于宽松 3阅读句子需要和句式从头开始对应，不能多出来......
由于至少存在三种的匹配方案，后续以词组为基础的语块匹配可能还会增加匹配模式。对$$变量的处理目前也仅仅是仍以内容的最简单方式，将来有可能增加限制而变得复杂。所以目前对句式匹配的函数目前只写到elematch元素匹配这一级。在对句子匹配模式做出总结之后，完成句子匹配函数，增强代码的通用性，能更轻松地扩展理解能力。
6月计划：1词组的二次匹配直到语义块，使用格式扩展快捷方便；2先为属性和同义词匹配迁移到独立函数已初步完成，下一步独立过程增加更严格的匹配模式，仅仅允许$$作为模糊项，实现应该没有困难，而且对词典的分析不会有明显影响，这个匹配类型作为格式匹配的主模式。3以二次匹配后的词组-语义块为基础建立简单词语经验库，按照词组类型（语形）和概念分类两个语义维度分类。 6.2在语义map中增加了确立了“_类型”（原为“.分类”）一层nodename的
意义。用于表达大概念之下，比较抽象的一层子概念，表示具有共同特征比较具体的一组基层子概念的集合。如偶蹄类动物、水鸟、介词等。类型的标准是形容词的属性类型，如“具有偶蹄的、生活在水边的”，这种性质，但又和动物、鸟类的名词结合起来了，总体上是名词性子概念，但它的偏正性质和对属性的描述作用相当突出，有强烈的形容词倾向，因此在结构中使用了“_”。特别在字典中的解释的第一句中，发现它们基本上作为key的上级概念而非同义词描述出现，有抽象类的意思。因此将其独立形成一种语义描述，和结构一样，使用“_”。 6.4为了实现动物“习性”的一系列句式，建立与习性有关词语（概念）集合：如习性情态动词善于、喜欢；习性活动，吃、游泳、飞；习性对象（吃）植物、鼠、鱼、虾等。建立逻辑句式时，可以多列出\的变量项，最后在匹配成功
时删除未替换的项，大大增强了逻辑句式的适应性。同时还考虑增加多个同一类型的逻辑句式，在第一个逻辑句式明显不适应时，换第2，3个。 代码实验结果基本达到预期。意外收获：搜索时间减少了2/3，暂时不能解释。 6.5 语块/词组集合的连续分析：从并列联合的多个“、”组合入手，在某些描述格式下，平行增加<词组E2>类型格式，在该格式基础上向后扩展匹配。对于不确定个数的“、”系列，后续结尾部分大多数为“等”，也可能是“和or或”一类。 描述句式中的元素\改为@SBL（语块），仅用于在逻辑句式中代表变量。 没有后缀常量格式描述，还需要新的设计，是否使用（for和or ）@while“xxx”的格式表达循环？（仅用于E2格式类型），貌似有必要。因此也提出语义串中的变量分层思路：第一层是用于elematch的基础变量，第二层是“$$”和“while”循环，在ele的上层s_format匹配中控制ele匹配的循环。语块循环以后可用于排比句识别。 6.7 词组格式匹配已改为独立过程。词组匹配的第一项位置不定，第一项匹配上之后，后续项除@sbl之后必须仅仅挨着。遇到@sbl则根据上下项计算长度病位移。今后建立词组数据库后，@sbl也不能任意按格式顺延，也需要和已知词组匹配。存在隐患：如果@sbl较长，其中很可能夹杂着能满足下一项条件的分词项，形成混乱。所以@sbl之后，最好跟常量和@gn.node.in之类的准确型变量，避免@名词之类的模糊类型。 脑洞：以后建立@such as“C”系列变量，即就像这个常量（词组或句子）一样。在语法学习的对话中，往往会提供一个简单的常量作为实例。如，字典中先做逻辑解释，然后直接给出一个句子实例，达成逻辑格式和描述格式的对应。 6.9 多项循环代码对j位移影响严重，且适用性不佳，做出来仍然不能识别格式不等的顿号系列，如“某些国家、国家机关、党派或团体某级组织”。不如使用“、”的模糊循环。 单向循环有一定适用性。要不，把循环塞进新的一个子过程吧。为循环代码建立了whileele_match过程，初步可运行。 @such as“$$=”变量，相当有意思，可以处理“三天打鱼、两天晒网”“东一榔头西一棒子”这样关于语法格式的语义向量。 不可思议！词组成员在语义map的简单匹配中，加入了包含“常识”的匹配后，时间居然比原来的（物理）多用了20倍之多，而在map中常识的数量只有物理的1/3左右。但加入not haselement之后，即回复正常。加上物体、认知之后，仍超过20倍。再检查发现使用了把x.value按顿号分开的算法，改为采用整个串.contains的函数后，时间缩短90%。大概contains函数有优化吧。 6.11-12 尝试了$$=@suchas pos.key，初步运行，用于动态识别key的词性；
以词组匹配为基础，输出为逻辑句式， 建立新的strict_match过程，在第一句的匹配中使用了该过程，用于通常很短小的第一句。但明显不适用与属性匹配。解决诸多小bug。 下阶段突破口应该在词组匹配分析和后续的使用。
上半年归纳展望：概念分类变量与词性变量结合的句式描述进展顺利。多个语义向量和维度，也可以用双层语义串格式进行描述。
如果单个语句描述逐渐完善，则进行语句类型的特征描述和分类，语义串的扩展有望进入句群领域，尝试描述三段论、论证、流程、人-物描述、剧本情节…..等段落分析。语义的宏观理解即将象图像压缩那样，拥有分析理论和工具，进入技术实践，这样的开拓难道还不够令人兴奋吗？