ONTAO 术语词典（v0.2，首批 34 词）

九段式固定模板：中文 / 英文 / 定义 / 解决什么问题 / 与相邻概念区别 / 标准 Ontology 对应 / ONTAO 对应 / 实际案例 / 机器表示
用途：①深度学习时的机制对照 ②写理论/方案时的术语校准 ③对外交流时的翻译基准
状态：🟡 建设中（第一批 30 词，随深度研究持续扩充）

1. Ontology

• 中文：本体论 / 本体
• 英文：Ontology
• 定义：对某一领域的概念化显式规格说明（Gruber 定义）——明确"世界由什么构成、这些事物如何分类、有哪些关系与约束"的共享语义契约。哲学上问"存在什么"（Being），工程上问"如何把共识写成机器可读的规格"。
• 解决什么问题：解决"每个系统各说各话"——名词不同义、同名不同义、隐含假设不可验证。本体把领域共识显式化，让人类与 AI、系统与系统共享同一套语义。
• 与相邻概念区别：Taxonomy 只分层级（树），Ontology 还有关系/属性/约束（图+规则）。知识图谱是"填充了实例数据的本体+数据"；本体本身是模式（schema）层。
• 标准 Ontology 对应：本体本身。W3C 栈中本体用 OWL 表达，模式验证用 SHACL。
• ONTAO 对应：ONTAO 是"企业 AI 场景下的 Operational Ontology"——不仅描述世界（传统本体），还描述 AI 如何在世界里行动（动作/规则/权限）。定位声明：ONTAO 是应用框架，不是重定义整个学科。
• 实际案例：广告系统里"广告单元"到底是对象还是属性？多家上游对"曝光"口径不同（有效曝光/计费曝光）——本体显式声明每个概念的精确定义与计量口径。
• 机器表示：ontology.yaml（ONTAO 机器读版）/ ontology.owl（W3C 标准版）/ OWL 公理集。

2. Entity

• 中文：实体
• 英文：Entity
• 定义：存在之物——世界中可被独立指认、识别、跟踪的"东西"。可以是具体物（一个广告账户）、抽象物（一份合同）、事件（一次点击）。
• 解决什么问题：回答"世界由什么组成"的原子单位。实体是身份（identity）的载体——可被引用、被比较"是不是同一个"。
• 与相邻概念区别：Entity 是最宽概念；Object 在 ONTAO/Palantir 语境是"业务上值得独立跟踪的实体"；Class 是实体的类型（个体 vs 类：Socrates 是实体个体，Person 是类）。
• 标准 Ontology 对应：RDF Resource（万物皆资源）；OWL Individual（个体）；BFO 里分 Continuant（持续物）与 Occurrent（发生物）。
• ONTAO 对应：对象（Object）≈ 值得独立识别/跟踪/操作的实体；ONTAO 不建模所有实体，只建模"决策链上值得跟踪的"。
• 实际案例：拾光传媒 ontology.yaml 的 16 个对象（供应商/链接/广告单元/域名…）就是精选实体集。
• 机器表示：RDF triple 的主语/宾语；OWL NamedIndividual；YAML 中 objects: 一节。

3. Object

• 中文：对象
• 英文：Object
• 定义：业务中值得独立识别、跟踪、操作的实体（Palantir/ONTAO 用法）。区别于哲学 Object——它是"业务语义单位"，带唯一 ID、有属性、可被动作作用。
• 解决什么问题：给 AI 可操作的"抓手"——AI 说"暂停链接 92"时，"链接"必须有可寻址的对象与唯一 ID，否则 AI 无法行动。
• 与相邻概念区别：Object vs Entity：Entity 宽（一切存在物），Object 是"被本体选中的操作单位"。Object vs Class：对象是实例（这单链接），类是类型（链接这个种类）。
• 标准 Ontology 对应：OWL Class + Individual 的组合（对象类型=Class，具体对象=Individual）；RDF Resource；知识图谱 Node。
• ONTAO 对应：六要素之"对象"——本体地图上的节点。ONTAO 对象 = 决策链上值得独立跟踪/操作的东西（对象是地图上的点，动作是按钮）。
• 实际案例：AdAccount / Campaign / Website / AdUnit / Impression——每个都有 ID 可寻址。
• 机器表示：YAML objects: 下每个对象带 id/name/properties/relations；数据库实体表；KG 节点。

4. Class

• 中文：类
• 英文：Class
• 定义：具有共同属性与行为的个体集合的类型定义。Class 定义"什么样的个体属于这一类"（成员资格），可层级化（子类继承父类属性）。
• 解决什么问题：分类与泛化——不用为每个个体写全部属性，声明"广告单元是投放资源的子类"即继承。
• 与相邻概念区别：Class vs Instance/Individual：类是集合/类型，个体是成员。Class vs Type：两者常互换，但 Type 更多用于编程类型系统；本体里 Class 有形式语义（可推理）。
• 标准 Ontology 对应：OWL Class（owl:Class），RDFS Class；子类关系 rdfs:subClassOf。
• ONTAO 对应：对象类型——ONTAO 的对象定义就是"类"（链接、渠道、域名都是类，具体每个链接是实例）。对象之间继承/分类关系即类的层级。
• 实际案例：AdUnit 类下分子类 AnchorAdUnit/InterstitialAdUnit；"App 广告单元"是"广告单元"的子类。
• 机器表示：YAML objects: 条目（类声明）+ subclass_of 字段；OWL Declaration(Class(:AdUnit))。

5. Individual

• 中文：个体（实例个体）
• 英文：Individual / Instance
• 定义：类的具体成员——世界中的一个具体存在，拥有唯一身份。Socrates 是 Person 类的个体；"链接 92"是 Link 类的个体。
• 解决什么问题：把模式（schema）实例化到真实数据——本体定义类，数据填充个体；个体是 AI 查询/操作的具体对象。
• 与相邻概念区别：Individual vs Instance：同义（Instance 偏数据/编程视角）。Individual vs Class：个体是"一个"，类是"一类"。Class 可被实例化为个体，但个体不再有子个体（个体是最小引用单位）。
• 标准 Ontology 对应：OWL NamedIndividual / Anonymous Individual；RDF resource 作主语的具体资源。
• ONTAO 对应：对象的具体实例——数据库里的行（supplier 表 id=24 那行就是 Supplier 类的个体）。
• 实际案例：某个上游账户（如 Supplier id=24）= Supplier 类的一个个体。
• 机器表示：数据库行（主键=个体 ID）；RDF triple 主语；KG 节点。

6. Property

• 中文：属性（宽义，含关系属性与数据属性）
• 英文：Property
• 定义：实体的特征/描述项——广义上包括"数据型属性"（颜色、金额）与"对象型属性"（拥有、属于）。在 RDF/OWL 语境 Property 是"谓词"，连接主语与宾语。
• 解决什么问题：描述世界的"怎么样"——实体之间/实体内部的事实陈述都是属性在承载。
• 与相邻概念区别：Property vs Attribute：Attribute 特指数据型特征（值），Property 在 RDF 里包含关系。ONTAO 区分"关系"（连接对象）与"属性"（对象自身特征）。标准里 Property 是统称。
• 标准 Ontology 对应：RDF Property（所有谓词）；OWL 分 ObjectProperty（连对象）与 DatatypeProperty（连数据值）。
• ONTAO 对应：六要素之"属性"（对象自身状态/特征）+ 六要素之"关系"（对象间连接）——ONTAO 把标准 Property 拆成两个要素。
• 实际案例：链接的"状态=启用/停用"是属性；"链接 → 属于 → 渠道"是关系。
• 机器表示：OWL ObjectProperty(:belongsTo) / DatatypeProperty(:status)；YAML relations: 与 properties: 两节。

7. Attribute

• 中文：属性（数据属性）
• 英文：Attribute（OWL: Datatype Property）
• 定义：实体的数据型特征——值是字面量（数字/字符串/日期），不指向另一个实体。如"链接的 eCPM=3.2"。
• 解决什么问题：描述"世界现在怎么样"的量化/定性状态；是查询、报表、规则判断的数据基础。
• 与相邻概念区别：Attribute vs Relation：属性值是数据（literals），关系指向实体（resources）。"eCPM=3.2"是属性，"eCPM 低于阈值的链接"需要关系+属性联合判断。ONTAO 的属性还有类型体系（plain/time_series/marking）。
• 标准 Ontology 对应：OWL DatatypeProperty；RDF 谓词连 Literal；SHACL 可约束其值域。
• ONTAO 对应：六要素之"属性"——对象状态；属性类型体系（plain 静态值/time_series 时间序列/marking 标记）是 ONTAO 对工程落地（快照 vs 流水）的细化。
• 实际案例：display_revenue（值=12.5）、status（值=active）、last_sync_at（值=时间戳）。
• 机器表示：OWL DatatypeProperty(:displayRevenue) range xsd:decimal；数据库列；KG 属性边。

8. Relation

• 中文：关系
• 英文：Relation（OWL: Object Property）
• 定义：实体之间的连接——表示"谁与谁如何相关"。关系是本体图里的边，连接两个对象节点。
• 解决什么问题：回答"世界怎么连接"——只罗列对象是清单，有了关系才是地图（图结构）；AI 沿关系遍历才能"看到"对象之间的因果/归属/链路。
• 与相邻概念区别：Relation vs Attribute：关系指向实体，属性指向值。Relation vs Link（Palantir）：同义，Palantir 叫 Link Type。关系有方向（supplier → has → link），属性无方向。
• 标准 Ontology 对应：OWL ObjectProperty；RDF Predicate；KG Edge。关系本身可带属性（reification）或作为 n-ary relation。
• ONTAO 对应：六要素之"关系"——对象之间的边。核心链路 supplier → supplier_service → link_id 就是关系链的工业实例。
• 实际案例：supplier owns account、link belongs_to domain、ad_unit generates impression。
• 机器表示：OWL ObjectProperty(:belongsTo) + domain/range 声明；RDF triple 谓词；KG 边；YAML relations:。

9. Object Property

• 中文：对象属性（关系型属性）
• 英文：Object Property
• 定义：OWL 术语——值域是"另一个个体"的属性，即关系。link belongsTo domain——belongsTo 是 ObjectProperty，值是一个 Domain 个体。
• 解决什么问题：区分"关系"与"数据值"两种谓词，推理机才能正确分类与检查一致性（关系可反向、可传递，数值不行）。
• 与相邻概念区别：ObjectProperty vs DatatypeProperty：值是个体 vs 值是字面量。ObjectProperty 可有 inverse（反向）、transitive（传递）、functional（函数式）等特征。
• 标准 Ontology 对应：OWL ObjectProperty；其反向关系 owl:inverseOf。
• ONTAO 对应：六要素之"关系"的标准学名。ONTAO 定义关系时应标注：方向、基数（一对多/多对多）、是否核心链路。
• 实际案例：supplier_service → provides → supplier 的反向 supplier → has_service → supplier_service。
• 机器表示：OWL ObjectProperty(:belongsTo) with domain/range/inverseOf。

10. Datatype Property

• 中文：数据属性（数据类型属性）
• 英文：Datatype Property
• 定义：OWL 术语——值域是数据字面量（数字/字符串/布尔/日期）的属性，即 ONTAO 的"属性"。
• 解决什么问题：描述对象的状态/数值特征，供查询聚合与规则判定（eCPM 小于阈值）。
• 与相邻概念区别：DatatypeProperty vs ObjectProperty：值类型不同（literal vs individual）。DatatypeProperty 不能有 inverse。
• 标准 Ontology 对应：OWL DatatypeProperty；RDF 谓词+Literal；值域用 XML Schema 数据类型（xsd:decimal 等）。
• ONTAO 对应：六要素之"属性"的标准学名；属性类型体系（plain/time_series/marking）即对 DatatypeProperty 的工程细分。
• 实际案例：displayRevenue xsd:decimal、status xsd:string、updatedAt xsd:dateTime。
• 机器表示：OWL DatatypeProperty(:displayRevenue) range xsd:decimal。

11. Event

• 中文：事件
• 英文：Event
• 定义：在某一时刻/时段发生的、改变世界状态的事情。事件是"发生的"，不是"存在的"——一次点击、一次同步、一次暂停操作。
• 解决什么问题：把"状态快照"与"状态变化"分开——事件是流水的记录单元（发生了什么），状态是快照（现在怎么样）。审计/回溯/因果分析都依赖事件。
• 与相邻概念区别：Event vs State：事件是变化的瞬间，状态是变化后的稳定形态。Event vs Action：动作是被执行的操作（有意图/有执行者），事件是发生的事实（可含动作结果）。BFO：Occurrent（发生物）vs Continuant（持续物）。
• 标准 Ontology 对应：BFO Process/Event；OWL Time Ontology（时间本体）；Event 本体（如 SEM/Simple Event Model）。
• ONTAO 对应：ONTAO 属性类型体系里的 time_series（流水）= 事件记录；"属性现在时（查询）/事件过去时（审计）"正是快照+流水的体现。
• 实际案例：sync_log 的每行同步记录 = 事件；audit_log 的每次 AI 动作 = 事件。
• 机器表示：事件表（带 timestamp）；RDF 事件三元组（主语-发生-时间）；OWL Time 个体。

12. State

• 中文：状态
• 英文：State
• 定义：实体在某一时刻的属性取值集合——"现在怎么样"。状态是快照，随时间变化，可被动作改变。
• 解决什么问题：AI 需要知道"世界现在如何"才能决策——状态是决策的输入；状态变化是动作的产出。
• 与相邻概念区别：State vs Property：状态=属性的时点值（那一刻的组合），属性=持续的特征定义。State vs Event：状态是"being"，事件是"happening"。ONTAO 世界模型篇的核心：AI 无状态，本体=外部大脑，状态存本体。
• 标准 Ontology 对应：OWL 本身无内建 State 概念（静态描述逻辑）；情境演算/事件演算（Situation Calculus）建模状态与变化；BFO Continuant 的"状态"侧面。
• ONTAO 对应：六要素之"属性"的时点实例；世界模型（第 10 篇）——状态层=对象+属性实时查询结果；写回所有权三态（source/local/decision）就是状态管理。
• 实际案例：链接状态=启用/停用/待审；同步状态=成功/失败/进行中。
• 机器表示：数据库行当前值；YAML 对象属性值；KG 节点属性快照。

13. Action

• 中文：动作
• 英文：Action
• 定义：对本体的受控写操作——改变对象状态/创建对象/执行流程的"按钮"。动作是本体从"地图"变"引擎"的关键：AI 不做裸写，只按定义好的动作行动。
• 解决什么问题：回答"我能做什么"——把写操作封装为带权限/校验/审计的合规动作，防 AI 乱改、防绕过规则、留全审计。
• 与相邻概念区别：Action vs Rule：动作是执行单元（做什么），规则是判断依据（凭什么做）。Action vs API/Tool：动作是业务语义封装（暂停链接），API 是技术接口——一个动作可调多个 API。动作执行前必须过规则与权限。
• 标准 Ontology 对应：OWL 无 Action 概念（描述逻辑只描述静态世界）；语义网动作建模有 OWL-S/SROIQ 动作扩展、ACT-R/PDDL（规划领域定义）；Palantir Action Type 是工业实现。
• ONTAO 对应：六要素之"动作"——按钮；动作六步流水线（参数校验→权限→业务规则→事务→副作用→审计）；"唯一写通道"原则（所有写操作默认走动作）。
• 实际案例：PauseAdUnit（暂停广告单元）、AdjustRouting（调整路由）、PushSettlement（推送结算）——每个都带参数定义+权限+审计。
• 机器表示：YAML actions: 下每个动作（参数/权限/副作用/审计）；OpenAPI 端点；Palantir Action Type。

14. Rule

• 中文：规则
• 英文：Rule
• 定义：可判定的判断逻辑——把"含糊的经验"逼问成"明确的 if-then 条件"，使 AI 与人按同一标准判断。规则是可执行、可验证、可审计的。
• 解决什么问题：回答"为什么可以做/该怎么做"——把老板脑子里的经营判断显性化（含糊问题清单逼问），让 AI 的判断可解释、可回滚。
• 与相邻概念区别：Rule vs Constraint：规则是判断逻辑（推导/决策），约束是边界（不允许违反）。Rule vs Policy：政策是高层意图，规则是机器可执行的具体化。Rule vs Formula：公式是纯计算，规则可含条件分支与副作用。
• 标准 Ontology 对应：SWRL（语义网规则语言）/ RIF（规则交换格式）；SHACL 约束规则；生产规则引擎（Drools）不属语义网但同思路；描述逻辑公理（subClassOf 等也是规则的一种）。
• ONTAO 对应：六要素之"规则"——可判定依据；规则提案 PR 机制（改规则=提 PR=审批=审计）；规则必须可判定（含糊问题清单逼问）。
• 实际案例：IF eCPM < 阈值 AND 流量质量 < 阈值 THEN 建议暂停链接；拾光传媒 23 条规则（含覆盖率过低等判定）。
• 机器表示：YAML rules: 下 if-then 结构；SWRL 公理；SHACL 约束；规则引擎配置。

15. Constraint

• 中文：约束
• 英文：Constraint
• 定义：本体/数据必须满足的边界条件——不允许违反的结构性限制。约束是"盾"，规则是"剑"。
• 解决什么问题：防止非法状态——数据必须符合 schema、对象关系必须合法、写入必须过校验（如"已停用的供应商不可再暂停"是域约束）。
• 与相邻概念区别：Constraint vs Rule：约束拒绝非法（硬边界），规则决定判断（软逻辑）。Constraint vs Validation：约束是声明式规格，验证是执行检查的动作。
• 标准 Ontology 对应：SHACL Shapes（W3C 约束验证标准）；OWL 公理（cardinality/domain/range）隐含约束；数据库 CHECK/UNIQUE/FK 约束是工程约束。
• ONTAO 对应：动作六步流水线的"业务规则验证"步骤 + 域不变量；规则要素里的约束类规则。
• 实际案例："一个链接必须属于一个域名"（必填约束）；"收入必须 ≥ 0"（值域约束）。
• 机器表示：SHACL shape（sh:minCount 1 等）；YAML 约束字段；数据库外键。

16. Permission

• 中文：权限
• 英文：Permission
• 定义：谁有资格执行什么动作/访问什么数据的授权声明。权限是动作的闸门——决定"谁可以按按钮"。
• 解决什么问题：回答"谁可以做"——防止越权操作；AI 能建议≠AI 能执行；高风险动作永远人审批。
• 与相邻概念区别：Permission vs Role：角色是权限的集合（打包），权限是原子授权。Permission vs Policy：策略是权限+条件+环境的组合（ABAC）。Permission vs Marking：标记是数据分类（机密等级），权限是访问控制（谁可读）——Palantir 五层治理两者都管。
• 标准 Ontology 对应：OWL 无权限概念；RBAC/ABAC 模型；XACML（策略语言）；Palantir 治理五层（Marking/Org/Classification/Granular/Object+Property）。
• ONTAO 对应：六要素之"权限"——权限四层（AI 建议→AI 标记→AI 自动低风险→高风险人审批）+ 数据访问权；先紧后松原则。
• 实际案例：PauseAdUnit：AI→建议，运营→执行，管理员→审批。
• 机器表示：YAML permissions: 下四层矩阵；XACML 策略；Palantir 权限策略。

17. Identity

• 中文：身份
• 英文：Identity
• 定义：实体"是它自己而不是别的"的判定依据——唯一 ID + 判同标准。两个记录是否指同一实体（实体解析）依赖身份定义。
• 解决什么问题：防止重复/错认——同一广告链接在多个上游的 ID 不同，如何确认是同一个？身份是数据合并/去重/引用的根基。
• 与相邻概念区别：Identity vs ID：ID 是标识符（实现），Identity 是"同一性"概念（理论）。Identity vs Type：身份管"是哪一个"，类型管"是哪一类"。
• 标准 Ontology 对应：OWL owl:sameAs（声明两个体同一）；owl:differentFrom；实体解析（Entity Resolution）；RDF 的 URI 作为全局身份。
• ONTAO 对应：对象定义必须有唯一标识（ID）；核心链路 supplier→service→link 的去重规则（domain_id 不参与去重）就是身份判定的实例。
• 实际案例：拾光传媒"一个域名可被多个链接引用，但 domain_id 不参与去重"——身份判定的业务决策。
• 机器表示：对象主键；owl:sameAs 三元组；数据库唯一索引。

18. Type

• 中文：类型
• 英文：Type
• 定义：实体的种类归属——每个实体属于一个或多个类型，类型定义其允许的属性与关系。Type 是分类的基础。
• 解决什么问题：把世界组织成可管理的类别——查询按类型过滤、规则按类型生效、权限按类型授予。
• 与相邻概念区别：Type vs Class：语义网里基本同义（rdf:type 声明个体属于哪个类）；Type 更通用（编程/数据建模视角），Class 有 OWL 形式语义。Type vs Category：分类学视角 vs 形式语义视角。
• 标准 Ontology 对应：rdf:type（类型断言）；RDFS Class；OWL Class。
• ONTAO 对应：对象类型（YAML objects 的每个定义）+ 属性类型体系（plain/time_series/marking）。
• 实际案例：ad_unit.type IN (固定/自动/第三方) 是广告单元的类型维度。
• 机器表示：rdf:type 三元组；YAML type 字段；数据库类型列。

19. Taxonomy

• 中文：分类法（层级分类）
• 英文：Taxonomy
• 定义：基于"is-a/属于"关系的纯层级分类结构——树状组织，节点只有父子关系，无横向关系。分类学（科学）的另一义是生物分类学，此处取信息架构义。
• 解决什么问题：信息组织的第一层——让大量条目可导航、可归属（导航菜单、目录、类目体系）。
• 与相邻概念区别：Taxonomy vs Ontology：分类法只有层级（树），本体有层级+关系+属性+约束（图）。Taxonomy vs Folksonomy：分类法自上而下专家定义，大众分类自下而上用户打标。本体包含分类法，但不止于分类法。
• 标准 Ontology 对应：RDFS subClassOf 层级；SKOS（简单知识组织系统）表达分类体系。
• ONTAO 对应：对象类型的父子分类（可选层）；网站导航"理论体系▾"下拉就是分类法；但 ONTAO 本体远不止分类——六要素的图结构。
• 实际案例：广告格式分类：广告单元 → {固定/自动/第三方}；网站栏目：站点 → {资讯/旅游/汽车}。
• 机器表示：SKOS 概念层级；RDFS 类层级；YAML 树形结构。

20. Knowledge Graph

• 中文：知识图谱
• 英文：Knowledge Graph
• 定义：以图结构（节点=实体，边=关系）组织的事实数据库——本体提供模式，KG 填充实例数据。KG = 本体（schema）+ 数据（instance）的运行时形态。
• 解决什么问题：回答"实体之间如何连接"的查询——沿边遍历、多跳查询、关系推理；比关系型表更直观表达网络结构。
• 与相邻概念区别：KG vs 关系数据库：图查询（遍历）vs 表查询（join），KG 强调语义连接。KG vs Ontology：本体是模式（薄的、定义性的），KG 是实例+模式（厚的、数据性的）。KG vs RAG：RAG 搜文本段落，KG 检索结构化关系——可互补不互斥。
• 标准 Ontology 对应：RDF 数据集 + SPARQL 查询 + 图数据库（Neo4j/JanusGraph）；标准语义网 KG=RDF graph。
• ONTAO 对应：本体定义（yaml/owl）= 模式的机器可读形态；对象+关系+属性填充后即 KG。ONTAO 不强依赖图数据库——关系型实现亦可（拾光传媒即 MySQL 实现）。
• 实际案例：拾光传媒"链接→域名→渠道→供应商"的关联查询 = 图上多跳遍历的 SQL 实现。
• 机器表示：RDF triple store；属性图（Neo4j）；关系表（用外键表达边）。

21. RDF

• 中文：资源描述框架
• 英文：RDF (Resource Description Framework)
• 定义：W3C 标准的数据模型——一切陈述都是"主语-谓词-宾语"三元组（triple），主语/谓词/宾语用 URI 标识，宾语可为资源或字面量。
• 解决什么问题：提供一个统一、可合并、去中心的陈述格式——不同系统的数据只要都转成 RDF 三元组，就可合并推理（web of data 的梦想）。
• 与相邻概念区别：RDF vs 关系表：RDF 是无模式/图模型（可随时加谓词），关系表需先定列。RDF vs JSON：JSON 是文档/嵌套，RDF 是平坦三元组/可合并。RDF 是语法+数据模型，RDFS/OWL 是它的模式语言。
• 标准 Ontology 对应：RDF 本身是最底层；rdf:type 等内建词汇。
• ONTAO 对应：ONTAO 的 yaml 本体可无损表达为 RDF 三元组（对象→类，关系→谓词，属性值→字面量）；但 ONTAO 不强制 RDF 序列化——yaml 是首选机器表示（工程务实）。
• 实际案例：<link92> <belongsTo> <domain88> 就是一条 RDF 三元组。
• 机器表示：RDF/XML、Turtle、N-Triples 三种主要序列化；ONTAO yaml 可 1:1 转换。

22. RDFS

• 中文：RDF 模式（RDF Schema）
• 英文：RDFS (RDF Schema)
• 定义：RDF 的轻量模式语言——提供 class/subClassOf/subPropertyOf/domain/range 等基础词汇，表达分类与属性约束。
• 解决什么问题：给 RDF 数据加"类型层"——声明什么是类、属性作用域（domain）与值域（range），让数据可被理解与校验。
• 与相邻概念区别：RDFS vs OWL：RDFS 是弱表达（只有子类/子属性/域/值域），OWL 是强表达（基数、等价、传递、并交补等描述逻辑公理）；RDFS 推不出复杂结论，OWL 可以。
• 标准 Ontology 对应：rdfs:Class / rdfs:subClassOf / rdfs:domain / rdfs:range / rdfs:label。
• ONTAO 对应：ONTAO yaml 的 objects:（类）+ relations:（带 domain/range）= RDFS 层的对应物；六要素的"对象/关系"就有 RDFS 级别的表达力。
• 实际案例：rdfs:domain belongsTo Link、rdfs:range belongsTo Domain——声明 belongsTo 只能从 Link 指向 Domain。
• 机器表示：Turtle/RDF 中的 rdfs 词汇；ONTAO yaml 的 domain/range 字段。

23. OWL

• 中文：网络本体语言
• 英文：OWL (Web Ontology Language)
• 定义：W3C 标准的强表达本体语言——基于描述逻辑（DL），支持类公理（并/交/补/基数/等价/不相交）、属性特征（传递/对称/函数式/反函数）、个体断言（sameAs/differentFrom），可做自动推理与一致性检查。
• 解决什么问题：把本体写成机器可推理的形式——推理机（reasoner）能从显式声明推出隐含结论、检测矛盾（一致性）。
• 与相邻概念区别：OWL vs RDFS：表达力层级（RDFS 弱，OWL 强）；OWL 有推理，RDFS 基本无。OWL vs SHACL：OWL 是开放世界假设（无声明≠不可能，适合推理），SHACL 是闭合世界验证（无声明=不满足，适合校验）——两者用途不同，常被混淆。
• 标准 Ontology 对应：OWL 2（三个子语言 OWL EL/QL/RL 按推理复杂度取舍）；描述逻辑 SROIQ(D)。
• ONTAO 对应：ONTAO 的对象/关系/属性可表达为 OWL 公理（Object=Class，Relation=ObjectProperty，Attribute=DatatypeProperty）；但 ONTAO 定位"操作本体"，动作/规则/权限超出 OWL 表达范围（OWL 描述静态世界）——这是 ONTAO 相对标准栈的本质增量。
• 实际案例：subClassOf(AnchorAdUnit, AdUnit)；cardinality(hasDomain, 1)（一个链接恰好一个域名）。
• 机器表示：OWL 2 的 RDF 序列化或 Functional Syntax；ontology.owl 文件。

24. SHACL

• 中文：形状约束语言
• 英文：SHACL (SHapes Constraint Language)
• 定义：W3C 标准的 RDF 图验证语言——定义"形状"（shape）描述数据图必须满足的结构约束（必填、基数、值域、类型），用于数据校验与质量把关。
• 解决什么问题：回答"这份数据合法吗"——在写入/集成时验证数据符合本体规格，防脏数据、防破坏约束。
• 与相邻概念区别：SHACL vs OWL：OWL 开放世界（推理、推结论），SHACL 闭合世界（验证、查违规）；OWL 说"可能成立"，SHACL 说"必须满足"。SHACL vs 数据库 CHECK 约束：同思路（数据校验），SHACL 适用于 RDF 图。
• 标准 Ontology 对应：SHACL 本身（sh:minCount/sh:nodeKind/sh:datatype 等）；同类替代：Shex。
• ONTAO 对应：六要素之"约束/规则"的标准验证对应——动作流水线第③步"业务规则验证"；ONTAO 的规则要素若用于"拒绝非法写入"，标准实现就是 SHACL 思路。
• 实际案例：sh:minCount 1 声明"链接必须有 domain"；"收入 ≥ 0" 的值域约束。
• 机器表示：Turtle 写的 shapes.ttl；对 RDF 图执行验证引擎。

25. SPARQL

• 中文：SPARQL 查询语言
• 英文：SPARQL (SPARQL Protocol and RDF Query Language)
• 定义：W3C 标准的 RDF 图查询语言——以图模式匹配方式查询三元组（类似"SQL for graphs"），支持多跳遍历、可选匹配、聚合、构建子图。
• 解决什么问题：从知识图谱中检索结构化的关系答案——"某链接的所有上游收益记录"这类多跳查询在 RDF 图上的标准表达。
• 与相邻概念区别：SPARQL vs SQL：SQL 查关系表（join），SPARQL 查 RDF 图（图模式匹配）；SPARQL 的 WHERE 是三元组模式。SPARQL vs Cypher：Cypher 是属性图查询（Neo4j），SPARQL 是 RDF 标准查询。
• 标准 Ontology 对应：SPARQL 本身；配合 OWL 推理（可查询隐式结论）。
• ONTAO 对应：ONTAO 不强制 SPARQL——拾光传媒用 SQL 实现同构查询；SPARQL 是"如果数据以 RDF/KG 存储"时的查询标准。ONTAO 的概念（对象/关系）在查询层已有映射。
• 实际案例：SELECT ?r WHERE { ?l a :Link . ?l :belongsTo ?d . ?d :owner ?s }——查链接所属域名的所有者。
• 机器表示：SPARQL 查询语句；对应 ONTAO 场景的 SQL/API 查询。

26. Reasoning

• 中文：推理
• 英文：Reasoning（Ontological Reasoning / Inference）
• 定义：从显式声明推导隐含结论的过程——机器根据公理与规则，自动推出未直接声明的事实。OWL 推理机（如 HermiT/Pellet）做描述逻辑推理；规则引擎做 if-then 推理。
• 解决什么问题：让本体"自己会想"——不用把所有事实都显式声明，声明规则/公理即可推出其余；也是一致性检查（发现矛盾）的基础。
• 与相邻概念区别：Reasoning vs Inference：基本同义（推理/推断），Inference 偏"从证据得结论"，Reasoning 偏"按逻辑规则推导"。Reasoning vs LLM 生成：本体推理是确定性的（同样输入同样输出、可证明），LLM 是概率的（不可证明）——ONTAO 用确定性规则约束 AI 的灰色判断。
• 标准 Ontology 对应：描述逻辑推理（OWL DL）；规则推理（SWRL/RIF）；具体推理机：HermiT、Pellet、Jena 推理器。
• ONTAO 对应：ONTAO 的规则要素执行时即推理；"规则可判定"（含糊问题清单逼问）就是让 AI 的判断从概率生成走向确定性推理。
• 实际案例：若规则"eCPM<1 → 低质"，且数据"链接92 eCPM=0.5"，推理机自动得出"链接92=低质"。
• 机器表示：OWL 公理 + 推理机；规则引擎；YAML 规则编译为可执行判断。

27. Inference

• 中文：推断
• 英文：Inference
• 定义：从已知前提得出新结论的过程——不保证绝对真理，保证符合规则/公理的有效性。语义网里 Inference 常指机器从图数据推出隐含三元组。
• 解决什么问题：扩大知识覆盖——不必存储全部事实，存最小前提，运行时推断其余（数据少存、结论多取）。
• 与相邻概念区别：Inference vs Reasoning：同义语，Reasoning 强调过程，Inference 强调结论。Inference vs Deduction：Deduction 是必然推理（一般到特殊），Inference 更宽（含归纳/溯因）。
• 标准 Ontology 对应：RDFS/OWL 推理规则集（RDFS entailment）；SPARQL 的 INF 查询。
• ONTAO 对应：规则引擎/动作前置校验中的推断步骤；"规则提案 PR"里的规则推导链。
• 实际案例：链接92 属于域名88，域名88 属于渠道3 → 推断链接92 属于渠道3。
• 机器表示：推理规则集（entailment rules）；SWRL 规则；代码 if-then。

28. World Model

• 中文：世界模型
• 英文：World Model
• 定义：系统对现实世界的内部表征——实体、状态、关系、变化规则的模型，用于预测与决策。AI 世界模型=AI 用来理解"现在怎样、做了什么会怎样"的结构化心智。
• 解决什么问题：AI 本身无状态（每次对话从零开始）——世界模型是 AI 的外部大脑，让它"记得"世界、理解当前状态、推演动作后果。
• 与相邻概念区别：World Model vs Ontology：本体是世界模型的模式层（用什么概念组织），世界模型=本体+实例状态（当前世界的样子）；本体是字典，世界模型是字典+当前实况。World Model vs KG：KG 是静态事实图，世界模型含动态状态与因果/预测。
• 标准 Ontology 对应：认知科学/RL 领域的 World Model（模型预测控制、JEPA）；语义网里对应"本体+状态数据+规则"的组合；Palantir 的对象+属性+规则+预测属性即工业世界模型。
• ONTAO 对应：第 10 篇《世界模型理论》——AI 没状态是最大问题，本体=AI 外部大脑；对象+属性（实时查询）=状态层，规则=推演层。
• 实际案例：AI 问"昨天哪个链接收入异常"——世界模型=查询 fact 表对象+属性，按规则判定异常，给出处置建议。
• 机器表示：本体 yaml + 数据库状态 + 规则集 + 查询 API 的组合。

29. Operational Ontology

• 中文：操作本体（运行本体）
• 英文：Operational Ontology
• 定义：不仅描述世界"是什么"，还定义 AI 如何在世界里"行动"的本体——在对象/关系/属性之上增加动作、规则、权限、决策链，让 AI 从"读"走向"安全地动"。学术界 2026 年确认：现有企业本体均为数据集成设计，非约束 AI 行为——操作本体是空白。
• 解决什么问题：回答"AI 怎么在业务里干活"——把 AI 从聊天助手变成合规行动者：能理解状态、能按规则判断、能在权限内推动动作、全程留痕。
• 与相邻概念区别：Operational Ontology vs 传统 Ontology：传统只描述（静态世界），操作本体描述+行动（动态世界+动作语义）。Operational vs Enterprise Ontology：企业本体偏数据集成（集成视角），操作本体偏行为约束（运行视角）。Palantir 的 Object/Link/Action + 规则 + 权限 = 操作本体工业实现。
• 标准 Ontology 对应：无直接 W3C 标准（OWL 描述静态世界）；接近语义网+规则+权限的组合（OWL+SWRL+XACML）；Palantir Foundry Ontology 是事实标准。
• ONTAO 对应：ONTAO 的完整定位——面向 AI Agent 的 Operational Ontology 方法论与工程体系；六要素（对象/关系/属性/动作/规则/权限）= 操作本体最小集。
• 实际案例：拾光传媒：对象（供应商/链接）+ 动作（暂停/推送）+ 规则（异常判定）+ 权限（四层）→ AI 检测异常→建议→人审批→动作执行→审计。
• 机器表示：ONTAO yaml（对象+关系+属性+动作+规则+权限六节）；Palantir Ontology 配置。

30. Ontology Engineering

• 中文：本体工程
• 英文：Ontology Engineering
• 定义：构建、维护、演化本体的方法论与工程实践——需求分析、概念抽取、建模（六要素/类/属性/关系）、编码（yaml/OWL）、验证（SHACL/一致性检查）、版本化、演进。不是"写文档"，是"工程系统"。
• 解决什么问题：让本体可维护、可演进、可多人协作——避免"建一个死文档"或"越建越乱"；版本化+变更纪律+回填机制保证本体与业务同步。
• 与相邻概念区别：Ontology Engineering vs Ontology 本身：前者是"怎么建/怎么维护"的过程与方法，后者是"建什么"的产物。vs 软件工程：本体工程偏知识建模与语义验证，软件工程偏代码与系统。
• 标准 Ontology 对应：本体工程方法论：METHONTOLOGY/NeOn；本体评估（competency questions 能力问题法）；本体开发工具（Protégé）；版本化（OWL imports/版本本体）。
• ONTAO 对应：ONTAO 的工程纪律：doc-first 变更（方案→审核→执行）、本体版本化（git 三端对齐）、实战回填（坑点→规则）、项目反哺模板（templates/）、OMA 五维评估（成熟度）。
• 实际案例：拾光传媒 ontology.yaml v0.4 的迭代（从 v0.1 建 → 深度研究后升版 → OMA 重评 3.6）= 一次完整本体工程循环。
• 机器表示：YAML 版本化文件 + git 历史；OWL 版本本体；评估矩阵（OMA）。

31. Touchpoint Completeness

• 中文：载体完备性
• 英文：Touchpoint Completeness
• 定义：可运营对象/概念/字段必须具备完整"载体链"——同一事实从数据存储（DB 列）→ 后端接口（routeTable/API）→ 用户触点（前端表单/表格/详情）逐级可触达；缺任一载体即断层（事实存在但运营无法通过界面操作它）。规则形式：三触点规则（field_touchpoint_rule）。
• 解决什么问题：把 OMA 的 Q1 地图/Q2 按钮落到实现层完备性——地图上有对象、系统里有字段，但界面没入口（典型于 AI/技术绕界面直改库的历史项目）。让"开发完没做界面"从事后事故变成可判定违例；AI 代配（绕过中间载体直写 DB）是它的典型违例样本。
• 与相邻概念区别：Q2 按钮只问"动作存不存在"；载体完备性问"同一事实的每一层载体齐不齐"（DB/API/UI 三载体，任一缺=断）。与字段级 DoD 同族，但上升到对象/概念层。
• 标准 Ontology 对应：无直接对应（经典本体不关心 UI）；接近 Palantir"对象必须可被 Action 操作"的运行理念。
• ONTAO 对应：08 篇 OMA 的 Q1/Q2 判据细化为载体完备性检查；工程侧=routeTable 加字段必须同步前端暴露（拾光传媒"AI 代配不能替代页面"纪律的规则化）。
• 实际案例：拾光传媒 G1/G2（2026-09-02）：routeTable 早含 deploy_target/vps_host_id/vps_path/vps_id 四字段，前端表单未暴露 → 运营只能 AI/DB 代配。
• 机器表示：规则（ontology.yaml field_touchpoint_rule）+ 可执行 diff（routeTable 字段集 vs 前端表单字段集）。

32. Derived State

• 中文：派生状态
• 英文：Derived State
• 定义：由对象事实（属性/关系/子状态）自动推导、只读、可判定的状态——不是人手动维护的字段，而是随时可从事实重算的"结论"（如"就绪度"=模板位是否全配码+是否已部署）。与声明状态互补。
• 解决什么问题：手动状态与事实脱钩——运营改了事实但状态没变，系统对"流程走到哪一步"无感知。派生状态让系统永远知道真实进度，供引导/校验/告警消费。
• 与相邻概念区别：vs 声明状态（人/决策写入，如 disabled 停用）：派生回答"事实算出来是什么"，声明回答"人决定是什么"，两层并存、声明可覆盖派生（停用一个流量正常的站）。vs 属性所有权三态（source/local/decision，05 篇）：那是"值谁写的"，这是"状态怎么来的"——正交维度。
• 标准 Ontology 对应：OWL 推理/entailment；数据库（物化）视图；事件溯源推导。
• ONTAO 对应：02 篇状态建模补"双层模式"（派生+声明）；就绪度=派生状态的标准形态。
• 实际案例：拾光传媒建站就绪度 L1-L4（2026-09-02）：已建站/已配码/已上线/可分发全由 link/site_ad_binding/deployed_at 事实推导，不进 link.status（手动开关保留）。
• 机器表示：SQL/规则推导（只读查询）；ontology.yaml 状态机定义。

33. Declared State

• 中文：声明状态
• 英文：Declared State
• 定义：由人/决策（或动作副作用经决策授权）显式写入的状态——表达"意图/授权"，不保证与事实一致（如 disabled 停用、active 投放中）。与派生状态互补，声明可覆盖派生。
• 解决什么问题：表达"人说了算"的语义——停用/启用、投放判定这类决策不该由事实自动推导（否则无法表达"流量正常但我要停掉它"）；同时防声明状态被误当事实（标签"ready"但代码没配齐）。
• 与相邻概念区别：vs 派生状态见上条；vs 动作副作用自动写状态（如分发→active）：副作用写的是声明状态（系统代行决策），须与派生状态分开建模，防语义混战。
• 标准 Ontology 对应：接近封闭世界假设（CWA）下的显式断言。
• ONTAO 对应：02 篇状态建模双层模式的"人/决策层"；link.status（手动开关+分发自动转 active）是声明状态的工业实例。
• 实际案例：拾光传媒 link.status 保留手动（可用/停用开关），与就绪度并列——已分发但 6/8 配码的站 status=active（声明）且就绪度=未全配（派生），两层信息都对，缺一不可。
• 机器表示：表字段（人工写）；动作副作用（规则声明的后置写）。

34. Postcondition

• 中文：后置条件（动作完成定义）
• 英文：Postcondition / Completion Definition
• 定义：动作执行成功后必须成立的对象事实不变式——动作的"验收标准"。只描述"做什么/什么顺序"（流程链）而不定义"做完后什么必须为真"的动作=裸动作，副作用缺失（断链）无法被检出。
• 解决什么问题：动作断链只能靠运营踩雷发现（做了 A 但 A 该带的 B 没生成）→ 后置条件让"动作完整吗"可判定，AI/健康检查可预判，事故从"人发现"变"系统检出"。
• 与相邻概念区别：vs 前置条件/guard（动作前校验，如分发须 8/8 全配齐）：前置=能不能做，后置=做完必须怎样——动作建模前后都要可判定，缺一不可。
• 标准 Ontology 对应：Hoare 逻辑后置条件（程序验证）；DB 触发器语义；过程层约束（本体层少见）。
• ONTAO 对应：02 篇动作篇（唯一写通道+六步流水线）补"后置条件定义"环节；建模约定=新动作入本体必须带 ≥1 后置条件。
• 实际案例：拾光传媒 qxzaa（2026-09-02）：AutoGenerateLink 建链接后不建 site_ad_binding 骨架（无后置条件定义）→ 广告位配置为空、运营无法定义广告单元；回填 link_create_invariant（模板实例化三件套）后该动作才可判定。
• 机器表示：ontology.yaml 动作节后置条件列表（对象事实谓词）；可被就绪度/健康检查消费。

对照速查表（标准 ↔ ONTAO）

一句话：ONTAO = 标准语义网栈（对象/关系/属性可 1:1 对照 OWL/RDF）+ 操作层（动作/规则/权限是 OWL 表达不了、Palantir 验证过的增量）。理解对照不是"要改用标准栈"，是"能向学术与工业界准确翻译 ONTAO"。