第15章　对象匹配

15.1 提出背景

在前面的理论中，**对象（Object）**是场景、属性、关系、状态以及行为的基本承载单元。系统能够建立当前场景和目标场景之后，还必须解决一个更加基础的问题：

当前场景中的对象，究竟对应哪个已知对象？

例如，系统当前感知到一个“杯子”，知识系统中可能已经存在多个杯子对象：

杯子A
杯子B
杯子C

仅仅识别出“这是杯子”还不够，还需要判断：

当前对象 → 哪一个对象？

这就是对象匹配。

对象匹配不是单纯的名称比较，而是从对象类别、对象实例、属性、状态多个层次进行结构比较，从而确定两个对象是否属于同一对象、同一类别，或者具有足够的结构相似性。

因此，本章建立：

对象识别 → 类匹配 → 对象实例匹配 → 属性匹配 → 状态匹配

并进一步形成：

$Objectcurrent→ObjectknowledgeObject_{current} \rightarrow Object_{knowledge}$

这一过程是后续场景匹配、目标场景匹配、关系匹配和行为认知的重要基础。

15.2 对象匹配的定义

**对象匹配（Object Matching）**是将当前认知系统中的对象，与已有对象类别、对象实例或目标对象进行结构比较，并确定二者对应关系的认知过程。

设当前对象为：

$OcO_c$

候选对象为：

$OiO_i$

则对象匹配可以表示为：

$Match(Oc,Oi)Match(O_c,O_i)$

其结果可以是：

匹配
不匹配
部分匹配
候选匹配

对象匹配的核心不是判断两个对象“名字是否一样”，而是判断：

两个对象在对象类型、实例特征、属性以及状态等结构上是否具有对应关系。

因此，对象匹配具有层级性。

15.3 对象识别

**对象识别（Object Recognition）**是根据当前获得的对象信息，确定对象属于什么对象类别的过程。

例如当前系统获得：

Object
 ├── 形状：圆柱
 ├── 材质：陶瓷
 ├── 颜色：白色
 └── 状态：静止

系统首先需要确定：

对象 → 杯子

这里得到的“杯子”属于对象类（Object Class），而不是某一个具体杯子实例。

因此：

$ObjectInstance→ObjectClassObjectInstance \rightarrow ObjectClass$

例如：

当前对象：
O101

识别结果：
Cup

表示：

O101 ∈ Cup

即对象实例 O101 属于“杯子”这一对象类。

15.4 类匹配

**类匹配（Class Matching）**是判断两个对象是否属于相同或兼容对象类别的过程。

例如：

当前对象：
杯子

知识对象类：
Cup

则：

$MatchClass(Cup,Cup)=1MatchClass(Cup,Cup)=1$

表示类别完全匹配。

如果：

当前对象：
马克杯

知识类别：
杯子

则可能形成：

$MatchClass(Mug,Cup)=1MatchClass(Mug,Cup)=1$

但这里不是简单的名称相同，而是因为：

马克杯 → 属于 → 杯子

存在类别关系。

因此类匹配需要支持对象类别之间的结构关系。

可以表示为：

Object Class
     │
     ├── 类别相同
     ├── 子类
     ├── 父类
     ├── 类型兼容
     └── 类型不匹配

例如：

杯子
 ├── 马克杯
 ├── 玻璃杯
 ├── 水杯
 └── 茶杯

当当前对象识别为“马克杯”时，系统可以同时知道：

马克杯 → 杯子

因此类匹配可以存在层级关系。

15.5 对象实例匹配

类匹配只能回答：

它们是不是同一类对象？

但不能回答：

它们是不是同一个具体对象？

因此需要进一步进行对象实例匹配（Object Instance Matching）。

例如系统已经建立：

Cup Class
 │
 ├── Cup001
 ├── Cup002
 └── Cup003

当前场景中发现：

CurrentObject = OX

首先识别：

OX → Cup

然后需要进一步判断：

OX → Cup001？
OX → Cup002？
OX → Cup003？

这就是实例匹配。

15.6 对象实例的唯一性

对象实例匹配必须区别：

同类对象

和

同一个对象。

例如：

杯子A
杯子B

二者：

$Class(A)=Class(B)Class(A)=Class(B)$

但是：

$Instance(A)≠Instance(B)Instance(A)\neq Instance(B)$

因此：

类别相同 ≠ 实例相同

这是对象匹配理论中的一个重要原则。

例如当前场景中有两个杯子：

桌面
 ├── 杯子A
 └── 杯子B

系统不能因为：

Class(A)=Cup
Class(B)=Cup

就认为：

A=B

必须继续使用属性、状态、关系以及其他对象信息进行实例区分。

15.7 属性匹配

**属性匹配（Attribute Matching）**是比较两个对象所具有的属性及其属性值是否对应的过程。

设对象 $O1O_1$ 的属性集合为：

$A1A_1$

对象 $O2O_2$ 的属性集合为：

$A2A_2$

则：

$MatchAttribute(O1,O2)MatchAttribute(O_1,O_2)$

用于判断：

$A1↔A2A_1 \leftrightarrow A_2$

例如：

对象A
 ├── 颜色：白色
 ├── 材质：陶瓷
 └── 形状：圆柱

对象B
 ├── 颜色：白色
 ├── 材质：陶瓷
 └── 形状：圆柱

则三个属性均可以形成匹配。

15.8 属性匹配不是属性名称匹配

对象属性匹配至少需要比较两个层次：

第一层：属性类型

例如：

颜色 ↔ 颜色
材质 ↔ 材质
位置 ↔ 位置
重量 ↔ 重量

第二层：属性值

例如：

颜色：
白色 ↔ 白色

表示属性值一致。

如果：

颜色：
白色 ↔ 黑色

则：

属性类型匹配
属性值不匹配

因此：

$AttributeTypeMatch≠AttributeValueMatchAttributeTypeMatch \neq AttributeValueMatch$

可以进一步表示：

属性匹配
 ├── 属性类型匹配
 └── 属性值匹配

15.9 属性匹配的部分匹配

现实中的对象信息并不一定完整。

例如当前对象：

杯子
 ├── 颜色：白色
 └── 材质：陶瓷

知识对象：

杯子001
 ├── 颜色：白色
 ├── 材质：陶瓷
 ├── 高度：10cm
 └── 状态：静止

当前对象没有提供高度信息。

因此不能因为：

高度未知

就直接判断对象不匹配。

应该区分：

相同
不同
未知

即：

$AttributeMatch∈{Same,Different,Unknown}AttributeMatch \in \{Same,Different,Unknown\}$

这样对象匹配就能够处理不完整对象信息。

15.10 状态匹配

**状态匹配（State Matching）**是比较两个对象当前状态是否具有对应关系的过程。

例如：

对象A：
状态 = 开启

对象B：
状态 = 开启

则：

$MatchState(A,B)=1MatchState(A,B)=1$

如果：

对象A：
状态 = 开启

对象B：
状态 = 关闭

则：

$MatchState(A,B)=0MatchState(A,B)=0$

状态与属性不同。

属性描述：

对象具有怎样的特征。

状态描述：

对象当前处于怎样的状态。

例如：

机器
 ├── 属性：
 │    类型 = 洗衣机
 │    颜色 = 白色
 │
 └── 状态：
      开启

因此：

对象
 ↓
属性
 ↓
状态

属于不同层次的信息。

15.11 状态变化与对象匹配

对象匹配不能因为状态变化就直接认为对象已经改变。

例如：

T1：
机器001
状态 = 关闭

T2：
机器001
状态 = 开启

虽然：

$StateT1≠StateT2State_{T1}\neq State_{T2}$

但是：

$ObjectT1=ObjectT2Object_{T1}=Object_{T2}$

因此：

状态不同，不代表对象不同。

这一区分对于动态场景理论尤其重要。

对象本身可以保持不变，而对象状态不断变化：

$Object→State1→State2→State3Object \rightarrow State_1 \rightarrow State_2 \rightarrow State_3$

所以对象匹配必须优先判断对象身份，而不能简单依据状态判断对象是否相同。

15.12 对象匹配的层级结构

综合对象识别、类匹配、实例匹配、属性匹配和状态匹配，可以建立如下层级：

当前对象
    ↓
对象识别
    ↓
对象类
    ↓
类匹配
    ↓
候选对象实例
    ↓
实例匹配
    ↓
属性匹配
    ↓
状态匹配
    ↓
对象匹配结果

进一步形成：

$Oc→Class(Oc)→Candidate(O)→AttributeMatch→StateMatch→ObjectMatchO_c \rightarrow Class(O_c) \rightarrow Candidate(O) \rightarrow AttributeMatch \rightarrow StateMatch \rightarrow ObjectMatch$

这说明对象匹配不是一个单一判断，而是一个逐层收缩候选范围的认知过程。

15.13 对象匹配结果

对象匹配最终可以产生多种结果。

13.13.1 完全匹配

对象类别、实例特征、属性和状态均能够对应：

当前对象
    ↓
已知对象001
    ↓
完全匹配

13.13.2 类匹配

只能确定属于同一对象类别：

当前对象
    ↓
杯子类
    ↓
类别匹配

但无法确定具体是哪一个杯子。

13.13.3 部分匹配

部分属性和状态能够对应，但信息不足以确认实例：

当前对象
 ├── 类型 ✓
 ├── 颜色 ✓
 ├── 材质 ✓
 └── 其他信息 ?

结果：

部分匹配

13.13.4 不匹配

关键对象结构无法对应：

当前对象：
杯子

候选对象：
手机

结果：
不匹配

15.14 对象匹配模型

可以将对象匹配表示为：

$MO=f(C,A,S,I)M_O=f(C,A,S,I)$

其中：

$MOM_O$ ：对象匹配结果；
$CC$ ：类别匹配；
$AA$ ：属性匹配；
$SS$ ：状态匹配；
$II$ ：实例匹配。

这里的 $ff$ 表示对象匹配规则。

例如：

$MO=ClassMatch∩InstanceMatch∩AttributeMatch∩StateCompatibilityM_O= ClassMatch \cap InstanceMatch \cap AttributeMatch \cap StateCompatibility$

这里的“ $∩\cap$ ”表示这些匹配条件按照规定的认知规则共同参与对象匹配，并不意味着所有场景下每个条件都必须完全一致。

因为：

类别 → 确定对象是什么
实例 → 确定是哪一个对象
属性 → 确定对象特征
状态 → 确定对象当前状态

四者共同构成对象认知结构。

15.15 对象匹配与场景匹配

对象匹配是场景匹配的基础。

一个场景通常由多个对象组成：

$Scene={O1,O2,O3,…,On}Scene=\{O_1,O_2,O_3,\dots,O_n\}$

当需要比较两个场景时，首先必须确定：

场景A中的对象
        ↓
对应
        ↓
场景B中的对象

例如：

当前场景：

桌面
 ├── 杯子A
 └── 手机A

目标场景：

桌面
 ├── 杯子A
 └── 手机A

只有首先匹配：

杯子A ↔ 杯子A
手机A ↔ 手机A

之后才能继续比较：

杯子属性
杯子状态
杯子位置
手机属性
手机状态
手机位置

因此：

$对象匹配→场景匹配对象匹配 \rightarrow 场景匹配$

对象匹配是场景结构比较的基础层。

15.16 对象匹配与目标场景

上一章建立了：

$当前场景→目标场景当前场景 \rightarrow 目标场景$

本章进一步解决其中一个关键问题：

当前场景中的对象，如何与目标场景中的对象建立对应关系？

例如：

当前场景：
杯子A → 左侧

目标场景：
杯子A → 右侧

对象匹配首先确认：

当前杯子A
        ↕
目标杯子A

然后发现：

对象相同
属性基本相同
状态相同
位置不同

因此得到：

对象匹配成功
+
属性/状态匹配
+
位置关系差异

最终可以形成：

$ObjectMatch→AttributeMatch→StateMatch→RelationDifferenceObjectMatch \rightarrow AttributeMatch \rightarrow StateMatch \rightarrow RelationDifference$

这样，目标场景理论中的“场景差异”就可以建立在可靠的对象对应关系之上。

15.17 工程映射

对象匹配理论进入WSaiOS工程后，可以建立对应的对象模型。

ObjectRecognizer
    |
    └── recognize()

ClassMatcher
    |
    └── matchClass()

ObjectInstanceMatcher
    |
    └── matchInstance()

AttributeMatcher
    |
    └── matchAttributes()

StateMatcher
    |
    └── matchState()

ObjectMatcher
    |
    └── match()

整体运行结构：

ObjectRecognizer
        ↓
ObjectClass
        ↓
ClassMatcher
        ↓
CandidateObjects
        ↓
ObjectInstanceMatcher
        ↓
AttributeMatcher
        ↓
StateMatcher
        ↓
ObjectMatcher
        ↓
ObjectMatchResult

对应的数据结构可以表示为：

ObjectMatchResult
 ├── objectId
 ├── classId
 ├── instanceMatch
 ├── attributeMatch
 ├── stateMatch
 ├── matchType
 └── matchStatus

例如：

matchType：
class
instance
attribute
state
full

matchStatus：
matched
partial
unknown
unmatched

这样，理论中的对象匹配就能够转换为明确的程序对象、匹配规则和运行结果。

15.18 本章核心模型

本章可以归纳为以下对象匹配模型：

进一步形成：

$对象识别→类匹配→实例匹配→属性匹配→状态匹配→对象确定对象识别 \rightarrow 类匹配 \rightarrow 实例匹配 \rightarrow 属性匹配 \rightarrow 状态匹配 \rightarrow 对象确定$

而对象确定之后，又可以进入：

$对象确定→关系匹配→场景匹配→目标场景比较对象确定 \rightarrow 关系匹配 \rightarrow 场景匹配 \rightarrow 目标场景比较$

因此，本章实际上建立了从对象认知到场景认知的中间桥梁。

15.19 本章总结

对象匹配解决的是认知系统中的基本对应问题：

当前认知到的对象，与已有对象之间是什么关系？

对象识别解决“它是什么”；类匹配解决“它属于什么类别”；对象实例匹配解决“它具体是哪一个对象”；属性匹配解决“它具有什么特征”；状态匹配解决“它当前处于什么状态”。

因此形成完整链条：

$对象识别→类匹配→对象实例匹配→属性匹配→状态匹配对象识别 \rightarrow 类匹配 \rightarrow 对象实例匹配 \rightarrow 属性匹配 \rightarrow 状态匹配$

其中必须特别区分：

$类别相同≠实例相同类别相同 \neq 实例相同$

以及：

$状态不同≠对象不同状态不同 \neq 对象不同$

对象可以保持同一实例，而属性或状态随时间发生变化。

最终，对象匹配成为场景认知的基础：

$对象匹配→关系匹配→场景匹配→场景差异→目标场景对象匹配 \rightarrow 关系匹配 \rightarrow 场景匹配 \rightarrow 场景差异 \rightarrow 目标场景$

由此，WSaiOS可以从单个对象的认知逐步进入多个对象组成的场景结构认知，为后续关系匹配、场景匹配以及动态场景变化建立理论基础。

第15章 对象匹配

第15章 对象匹配

15.1 提出背景

15.2 对象匹配的定义

15.3 对象识别

15.4 类匹配

15.5 对象实例匹配

15.6 对象实例的唯一性

15.7 属性匹配

15.8 属性匹配不是属性名称匹配

第一层：属性类型

第二层：属性值

15.9 属性匹配的部分匹配

15.10 状态匹配

15.11 状态变化与对象匹配

15.12 对象匹配的层级结构

15.13 对象匹配结果

13.13.1 完全匹配

13.13.2 类匹配

13.13.3 部分匹配

13.13.4 不匹配

15.14 对象匹配模型

15.15 对象匹配与场景匹配

15.16 对象匹配与目标场景

15.17 工程映射

15.18 本章核心模型

15.19 本章总结