第266章　Relation API｜关系 API

266.1 提出背景

在 ICAI 机器认知工程中，前面的三个 API 分别建立了不同层次的工程接口。

Element API 解决：

现实数据
↓
Element

Object API 解决：

Element
↓
Object

Attribute API 解决：

Object
↓
Attribute

但是，现实世界中的对象并不是相互孤立的。

一个对象可能位于另一个对象附近，可能接触另一个对象，可能位于另一个对象之上，也可能抓住、推动、连接、包含或者远离另一个对象。

例如：

Hand
↓
Touch
↓
Egg

又例如：

Egg
↓
On
↓
Table

或者：

Robot
↓
Near
↓
Table

这些对象之间的结构不是 Attribute 本身能够完整表达的。

因此，ICAI 必须建立独立的 Relation（关系）工程层。

这个工程层通过 Relation API（关系 API）实现。

其基本结构为：

Element API
↓
Element
↓
Object API
↓
Object
↓
Attribute API
↓
Attribute
↓
Relation API
↓
Relation
↓
State
↓
Scene
↓
Cognition

因此：

Relation API 是 ICAI 机器认知系统中负责建立、查询、更新、删除、验证和传播对象之间关系的标准工程接口，是对象从独立存在进入结构化场景的重要工程边界。

266.2 Relation API 的定义

Relation API 是 ICAI 系统针对 Object Relation（对象关系）建立的标准工程接口。

关系可以定义为：

$R=(Os,T,Ot,V,S,t)R=(O_s,T,O_t,V,S,t)$

其中：

$OsO_s$ ：Source Object，关系源对象；
$TT$ ：Relation Type，关系类型；
$OtO_t$ ：Target Object，关系目标对象；
$VV$ ：Relation Value，关系值；
$SS$ ：Relation State，关系状态；
$tt$ ：关系产生或更新时间。

例如：

Hand
↓
Touch
↓
Egg

可以表示为：

$R=(Hand,Touch,Egg,V,S,t)R=(Hand,Touch,Egg,V,S,t)$

其中 $VV$ 可以表示接触程度、距离等关系参数， $SS$ 表示关系当前是否有效。

因此：

Relation
├── Source
├── Type
├── Target
├── Value
├── State
└── Time

构成一个完整的动态关系对象。

266.3 Relation API 的核心目的

Relation API 的目的不是简单增加一张关系表，而是建立机器认知系统中的对象结构连接层。

它主要解决：

对象之间是否存在关系？
↓
是什么关系？
↓
关系具有什么参数？
↓
关系当前是否成立？
↓
关系什么时候发生？
↓
关系如何变化？
↓
关系如何影响对象和场景？

因此：

Object A
+
Object B
↓
Relation API
↓
Relation

关系进一步进入：

Relation
↓
Object State
↓
Scene Structure
↓
Cognition

因此 Relation API 是从对象层进入场景结构层的重要接口。

266.4 为什么 Object 需要 Relation

如果系统只有 Object 和 Attribute：

Object A
├── Attribute
└── State

Object B
├── Attribute
└── State

系统只能知道：

A 是什么
B 是什么
A 有什么属性
B 有什么属性

但无法完整表达：

A 在 B 上面
A 靠近 B
A 接触 B
A 属于 B
A 连接 B
A 包含 B
A 推动 B

因此：

$Object+Object≠SceneObject+Object\neq Scene$

必须加入 Relation：

$Scene=F(Object,Relation,State,Environment,Space,Time)Scene=F(Object,Relation,State,Environment,Space,Time)$

所以：

Object
↓
Relation
↓
Scene

是 ICAI 场景结构形成的基础。

266.5 关系的方向

部分关系具有明确方向。

例如：

Hand
↓
Touches
↓
Egg

与：

Egg
↓
Touches
↓
Hand

在工程语义上虽然描述同一接触事件，但 Source 和 Target 仍然需要明确。

例如：

$R=(Os,T,Ot)R=(O_s,T,O_t)$

其中：

$OsO_s$ ：关系发起方；
$OtO_t$ ：关系目标方。

对于：

Robot
↓
Push
↓
Box

系统必须知道：

Source = Robot
Target = Box
Type = Push

因此 Relation API 必须保存关系方向。

266.6 对称关系

有些关系具有对称性。

例如：

A
↔
Near
↔
B

通常：

$Near(A,B)=Near(B,A)Near(A,B)=Near(B,A)$

但是，即使关系具有对称性，工程系统仍然应该保存明确的 Source 和 Target，或者通过 Relation Type 的属性定义其对称规则。

因此可以定义：

Relation Type
├── Directional
└── Symmetric

例如：

Push
↓
Directional

Near
↓
Symmetric

Touch
↓
通常可以视具体定义采用对称关系

这样关系的数学性质和工程实现可以分开管理。

266.7 关系类型

Relation API 可以支持不同类型的关系。

例如空间关系：

Near
Far
Inside
Outside
Above
Below
Left
Right
Front
Behind

接触关系：

Touch
Contact
Connected
Attached

动作关系：

Push
Pull
Hold
Grasp
Move
Release

结构关系：

Contains
PartOf
BelongsTo
ComponentOf

社会或逻辑关系：

Own
Control
Follow
Depend

因此：

Relation Type
↓
Relation Structure

而不是把所有关系都作为普通字符串处理。

266.8 关系值

部分关系不仅需要 Type，还需要 Value。

例如：

Near
Distance = 20cm

可以表示：

$R=(A,Near,B,20cm,S,t)R=(A,Near,B,20cm,S,t)$

或者：

Contact
Pressure = 0.15MPa

因此 Relation Value 可以是：

Scalar
Vector
Boolean
String
Structured Value

例如：

Near
Value = 20

Touch
Value = {
    pressure: 0.15,
    area: 10
}

Relation API 因此不仅记录“关系存在”，还可以记录关系的动态参数。

266.9 动态关系

与 Attribute 一样，Relation 也具有动态性。

例如：

t1
Hand
↓
Far
↓
Egg

t2
Hand
↓
Near
↓
Egg

t3
Hand
↓
Touch
↓
Egg

t4
Hand
↓
Grasp
↓
Egg

关系随时间发生变化：

$Rt→Rt+1R_t\rightarrow R_{t+1}$

因此 Relation API 必须支持关系更新。

例如：

Near
↓
Distance 50cm

变成：

Near
↓
Distance 20cm

再变成：

Touch
↓
Distance ≈ 0

最终：

Grasp

这意味着关系本身就是一个动态认知对象。

266.10 关系状态

关系可以具有自己的 State（状态）。

例如：

Touch
↓
Active

或者：

Connection
↓
Broken

或者：

Near
↓
Valid

因此：

$Rt=(Os,T,Ot,V,S,t)R_t=(O_s,T,O_t,V,S,t)$

其中 $SS$ 表示关系当前状态。

例如：

Robot
↓
Connected
↓
Device

如果连接断开：

Robot
↓
Connection
↓
Device

State = Broken

这不仅改变 Relation，也会影响对象状态和场景状态。

266.11 Relation 与 Attribute

Relation 与 Attribute 是两个不同层次。

Attribute 描述：

Object 自身具有什么特征

Relation 描述：

Object 与其他 Object 之间具有什么结构关系

例如：

Egg
├── Mass = 0.06kg
├── Position = P
├── Temperature = 25℃
└── Stability = Stable

这些是 Attribute。

而：

Egg
↓
On
↓
Table

是 Relation。

因此：

$Attribute(Object)Attribute(Object)$

与：

$Relation(Object,Object)Relation(Object,Object)$

具有不同的结构。

可以概括为：

Attribute
=
Object → Property

Relation
=
Object → Object

这一区分对于 ICAI 的对象工程非常重要。

266.12 Relation 与 Object State

对象状态可能由对象属性和关系共同决定。

定义：

$St=F(At,Rt,Ct)S_t=F(A_t,R_t,C_t)$

其中：

$StS_t$ ：对象状态；
$AtA_t$ ：对象属性；
$RtR_t$ ：对象关系；
$CtC_t$ ：对象类别。

例如：

Egg
+
Position
+
Velocity
+
Touch(Hand,Egg)
+
Force

可能形成：

State = Grasping

因此：

Attribute
+
Relation
↓
State

关系不是场景的附属信息，而可能直接参与对象状态计算。

266.13 Relation 与 Scene

Scene 是多个对象、关系、状态、环境、空间和时间共同形成的动态结构。

可以表示为：

$Sct=F(Ot,Rt,St,Et,Pt,Tt)Sc_t=F(O_t,R_t,S_t,E_t,P_t,T_t)$

其中：

$OtO_t$ ：当前对象集合；
$RtR_t$ ：对象关系集合；
$StS_t$ ：对象状态集合；
$EtE_t$ ：环境；
$PtP_t$ ：空间信息；
$TtT_t$ ：时间。

因此：

Objects
+
Relations
+
States
↓
Scene

关系决定了对象之间如何连接。

例如：

Hand
↓ Touch
Egg
↓ On
Table

三个对象通过两个 Relation 形成一个结构：

Hand
  ↓
Touch
  ↓
Egg
  ↓
On
  ↓
Table

这已经不是三个孤立 Object，而是一个 Scene Structure（场景结构）。

266.14 Relation API 与场景变化

当关系变化时，场景可能发生变化。

例如：

t1
Hand
↓
Near
↓
Egg

变为：

t2
Hand
↓
Touch
↓
Egg

再变成：

t3
Hand
↓
Grasp
↓
Egg

于是：

Relation Change
↓
Scene Change
↓
Cognition Change

因此：

$Rt→Rt+1R_t\rightarrow R_{t+1}$

可能导致：

$Sct→Sct+1Sc_t\rightarrow Sc_{t+1}$

进一步导致：

$Ct→Ct+1C_t\rightarrow C_{t+1}$

这就是 Relation API 在动态机器认知中的重要作用。

266.15 Relation API 与对象匹配

关系还可以参与 Object Matching（对象匹配）。

例如系统需要寻找：

与 Hand 接触的物体

则查询条件可以是：

Source = Hand
Type = Touch
Target = ?
State = Active

系统可以得到：

O1001 = Egg

形成：

Hand
↓ Touch
?
↓
Egg

因此 Relation API 不仅保存关系，还可以作为机器认知系统进行对象查询和结构匹配的数据来源。

266.16 Relation API 与目标场景

如果目标是：

抓取 Egg

系统可能需要寻找：

Object = Egg
Relation(Hand, Egg) = Near

然后随着动作发生：

Near
↓
Touch
↓
Grasp

目标场景发生变化：

Initial Scene
↓
Approach
↓
Contact Scene
↓
Grasp Scene

因此目标不是孤立作用于 Object，而是作用于：

Goal
+
Object
+
Attribute
+
Relation
+
State
+
Scene

Relation API 为这一目标场景匹配提供结构数据。

266.17 Relation API 的验证

关系进入系统之前需要进行 Validation（验证）。

定义：

$Valid(R)=Valid(Os)∧Valid(T)∧Valid(Ot)∧Valid(V)∧Valid(t)Valid(R)= Valid(O_s) \land Valid(T) \land Valid(O_t) \land Valid(V) \land Valid(t)$

其中：

$Valid(Os)Valid(O_s)$ ：源对象存在；
$Valid(T)Valid(T)$ ：关系类型合法；
$Valid(Ot)Valid(O_t)$ ：目标对象存在；
$Valid(V)Valid(V)$ ：关系值合法；
$Valid(t)Valid(t)$ ：时间合法。

例如：

Object A
↓
UnknownRelation
↓
Object B

如果 UnknownRelation 不属于系统定义的关系类型，则：

Valid(T)=0

关系不能进入正常认知结构。

266.18 Relation API 的接口

Relation API 可以提供：

/api/relation/create
/api/relation/get
/api/relation/update
/api/relation/delete
/api/relation/list
/api/relation/query
/api/relation/history
/api/relation/validate

也可以使用对象资源形式：

/api/objects/{object_id}/relations
/api/objects/{object_id}/relations/{relation_id}

例如：

GET
/api/objects/O1001/relations

可以返回：

{
    "object_id": "O1001",
    "relations": [
        {
            "id": "R2001",
            "type": "touch",
            "target": "O2001",
            "state": "active"
        }
    ]
}

这里的 JSON 只是关系运行数据的交换形式。

266.19 Relation Engine

在 PHP OOP 工程中，可以建立 RelationEngine：

class RelationEngine
{
    public function create($source, $type, $target, $value = null)
    {
        return array(
            'source' => $source,
            'type'   => $type,
            'target' => $target,
            'value'  => $value,
            'state'  => 'active',
            'time'   => time()
        );
    }

    public function updateState(&$relation, $state)
    {
        $relation['state'] = $state;

        return $relation;
    }
}

其基本运行过程：

Source Object
+
Relation Type
+
Target Object
↓
Relation Engine
↓
Validation
↓
Relation Creation
↓
Relation Storage
↓
Relation Event

RelationEngine 的职责是处理关系逻辑，而不是承担整个场景或者认知计算。

266.20 Relation Model

RelationModel 可以表示运行时关系对象：

class RelationModel
{
    protected $id;
    protected $sourceId;
    protected $type;
    protected $targetId;
    protected $value;
    protected $state;
    protected $timestamp;

    public function setValue($value)
    {
        $this->value = $value;
    }

    public function setState($state)
    {
        $this->state = $state;
    }

    public function getSourceId()
    {
        return $this->sourceId;
    }

    public function getTargetId()
    {
        return $this->targetId;
    }
}

其本质是：

Object
↓
Relation Runtime Object
↓
Object

因此 RelationModel 是对象关系在软件运行环境中的结构化表达。

266.21 Relation Controller

RelationApiController 负责 API 请求：

class RelationApiController
{
    protected $service;

    public function create($request)
    {
        return $this->service->create(
            $request['source'],
            $request['type'],
            $request['target'],
            isset($request['value'])
                ? $request['value']
                : null
        );
    }
}

运行结构：

HTTP Request
↓
RelationApiController
↓
RelationService
↓
RelationEngine
↓
RelationModel
↓
RelationRepository
↓
MySQL

这样 Relation API 与 Object API、Attribute API 保持一致的工程结构。

266.22 Relation 数据库结构

关系可以使用独立的数据表，例如：

cognitive_relations

基本字段可以包括：

id
source_object_id
relation_type
target_object_id
relation_value
relation_state
source
timestamp
created_at
updated_at

历史关系可以进一步保存：

cognitive_relation_history

例如：

R1001
Near
t1

R1001
Touch
t2

R1001
Grasp
t3

这样系统能够追踪：

Relation History
↓
Relation Change
↓
Scene Change

266.23 Relation API 的事件机制

关系发生变化时，可以产生 Relation Event（关系事件）。

例如：

Relation Created
Relation Updated
Relation Activated
Relation Deactivated
Relation State Changed
Relation Deleted

运行链：

Object Update
↓
Relation API
↓
Relation Change
↓
Relation Event
↓
Scene Engine
↓
State Engine
↓
Cognitive Engine

例如：

Hand Near Egg
↓
Distance < Threshold
↓
Relation Change
↓
Near → Touch
↓
Scene Update
↓
Cognition Update

这样关系变化可以实时传播到更高层。

266.24 Relation 与动态场景

ICAI 不需要预先建立世界中所有可能出现的场景。

当前场景可以根据当前：

Object
+
Attribute
+
Relation
+
State
+
Environment
+
Space
+
Time

动态构建。

因此：

$Sct=F(Ot,At,Rt,St,Et,Pt,Tt)Sc_t=F(O_t,A_t,R_t,S_t,E_t,P_t,T_t)$

Relation API 提供的正是其中的 $RtR_t$ 。

当对象关系发生变化：

R_t
↓
R_{t+1}

场景也可以重新构建：

Scene_t
↓
Relation Change
↓
Scene_{t+1}

这使 ICAI 能够处理不断变化的现实场景，而不是依赖固定场景记录。

266.25 Relation API 与认知闭环

Relation API 最终进入 ICAI 的动态认知闭环：

World
↓
Real-Time Data
↓
Element API
↓
Element
↓
Object API
↓
Object
↓
Attribute API
↓
Attribute
↓
Relation API
↓
Relation
↓
State
↓
Scene
↓
Cognition
↓
Method
↓
Behavior
↓
Action
↓
Device
↓
World Change
↓
Feedback
↓
Element API
↓
Object Update
↓
Attribute Update
↓
Relation Update
↓
Scene Update
↓
Re-Cognition

由此，Relation 不再是静态数据库中的一条记录，而成为动态认知系统中的结构变化。

266.26 Relation API 的工程边界

Relation API 主要负责：

关系创建
关系读取
关系更新
关系删除
关系查询
关系验证
关系状态
关系参数
关系历史
关系事件

它不直接负责：

复杂认知
行为规划
动作执行
设备控制

因此必须保持层次边界：

Object API
↓
对象

Attribute API
↓
属性

Relation API
↓
关系

State API
↓
状态

Scene API
↓
场景

Cognition API
↓
认知

每一个 API 对应一个明确的机器认知结构层。

266.27 Relation API 的核心工程价值

Relation API 的真正价值，是建立机器世界中的对象连接结构。

没有 Relation：

Object A
Object B
Object C

只是三个独立对象。

加入 Relation：

A
↓
Relation
↓
B
↓
Relation
↓
C

对象之间开始形成结构。

因此：

$Object+Relation→StructureObject+Relation\rightarrow Structure$

进一步：

$Object+Attribute+Relation+State→SceneObject+Attribute+Relation+State\rightarrow Scene$

最终：

$Scene+Goal→CognitionScene+Goal\rightarrow Cognition$

所以 Relation API 是从“对象集合”走向“机器世界结构”的关键工程接口。

266.28 本章总结

第266章建立了 Relation API 的工程定义。

Relation API 是 ICAI 系统中负责维护对象之间动态关系的标准工程接口。

关系定义为：

$R=(Os,T,Ot,V,S,t)R=(O_s,T,O_t,V,S,t)$

其中：

$OsO_s$ ：源对象；
$TT$ ：关系类型；
$OtO_t$ ：目标对象；
$VV$ ：关系值；
$SS$ ：关系状态；
$tt$ ：时间。

关系与属性具有不同的工程意义：

Attribute
=
Object → Property

Relation
=
Object → Object

对象关系进一步参与状态和场景形成：

$St=F(At,Rt,Ct)S_t=F(A_t,R_t,C_t)$ $Sct=F(Ot,At,Rt,St,Et,Pt,Tt)Sc_t=F(O_t,A_t,R_t,S_t,E_t,P_t,T_t)$

因此：

Object
↓
Attribute
+
Relation
↓
State
↓
Scene
↓
Cognition

Relation API 使 ICAI 能够把现实世界中的对象从相互独立的实体组织成具有空间、接触、结构、动作以及其他动态关系的机器世界结构。

最终形成：

Element API
↓
Object API
↓
Attribute API
↓
Relation API
↓
State API
↓
Scene API
↓
Cognition API

第263章解决：

现实数据如何进入 ICAI。

第264章解决：

数据如何形成机器对象。

第265章解决：

对象如何获得动态属性。

第266章解决：

对象之间如何形成动态关系。

由此，ICAI 的机器世界开始从：

Object

发展为：

Object
+
Attribute
+
Relation
↓
Structured Machine World

这为下一章 第267章 State API｜状态 API 建立了直接基础：当对象具有属性、对象之间具有关系之后，系统需要进一步确定对象当前处于什么状态，以及状态如何随着属性和关系变化而变化。

第266章 Relation API｜关系 API