关系含义对称，为什么不等于存了两条Reference：读OPC UA的方向文字

OPC UA Part 3第5.3.2节中的Symmetric，判断的是ReferenceType从源节点与目标节点两侧看时，含义是否相同。文档举“Connects To”和“Communicates With”为例：无论从哪一端出发，关系都表达相同意思，所以两方向都被视为forward。这里先谈语义，并未在这一句话里说服务器必然保存了两条关系记录。

“Contains”提供了不同参照。它从SourceNode一侧表达源包含目标；从TargetNode一侧看，则是“Contained In”，即被包含。两种说法联系同一组节点，却不是含义完全相同的一句关系。文档因此为非对称ReferenceType要求设置InverseName，说明从目标端看到的意思；使用这一反向名称的Reference被称为inverse。

“Receives From”与“Sends To”是原文列出的另一对非对称例子。二者能够相互对应，不会因此自动成为对称类型。区别在于，从两端转述时，接收与发送的角色随之转换；而“Connects To”的两个方向仍使用相同语义。正向、反向和对称这几个词，分别依赖所读的具体关系，不能只看到有两个方向就合并。

对称类型还带一项名称条件：InverseName应省略。与之相对，非对称类型须提供这个属性。因此，这不是先为所有关系安排一对正反名称，再选择显示哪一个；文档以是否具有同样含义，区分了需要反向名称和不需要反向名称的情况。

当服务器实际同时实例化非对称类型的forward与inverse Reference时，文档将其称为bidirectional，并明确说它按两条独立Reference建模。原文也提醒，服务器不一定总能同时实例化两者。这样，“含义是否对称”与“正反两条是否实际存在”成为不同问题：双向存在的包含关系，仍保留包含与被包含的语义差别。

信号接收端与信号源的例子把单向情况具体化。原文说，接收端往往知道自己的信号源，信号源却不一定知道接收端。于是，接收端有指向信号源的“Sourced By”，源端没有对应指向各接收端的“Sourced To”。这里记录的是哪一端知道、保存了什么关系，并不要求现实中的信号源和接收端都各自持有一套相反记录。

关系类型本身还可以组织一般含义和约束。IsAbstract表示类型是否抽象，抽象ReferenceType不能实例化，只用于组织一般语义或供子类型继承约束；具体类型的直接或间接子类型则不得改变父类型的Symmetric定义。层级上的继承并没有让对称属性在后代中任意翻转。

该节另以No Loop说明名称之外的约束：从节点A出发，只沿这一类型或其子类型的关系前进，不能回到A。它描述一种关系使用限制，而不是在本文中运行遍历或构建服务器。本文依据实际页面标示v1.05.06的连续文字，不读Figure 15或执行代码，也不据这些定义判断真实控制系统已经合规、安全或具备完整连接。