知识图谱推理：规则、OWL 与推理机

显式知识（存进图谱的）：
  张三 WORKS_AT X公司
  X公司 rdf:type 科技公司

隐式知识（没写但能推）：
  张三 WORKS_AT 科技公司  ← 沿子类关系推出
  X公司 subclassOf 企业    ← 子类传递推出

→ 推理 = 用本体 + 规则把「隐含」变「显式」

- 数据补全：补上缺失的关联（省人工标注）
- 一致性：发现矛盾（一个节点属于两个不相交类）
- 查询增强：查询能命中「逻辑等价」的数据
- 数据压缩：只存基础事实，派生知识靠推理
→ 推理 = 「少存多算」 + 「发现矛盾」 + 「增强查询」

1. 本体推理（Schema 层）：
   RDFS/OWL 的类层级/属性性质 → 自动派生
   例：子类传递、domain/range 检查、等价关系

2. 规则推理（数据层）：
   自定义业务规则（Datalog/SWRL）
   例：若 A 雇佣 B 且 A 是公司 → B 是员工
→ 本体推理管「语义结构」，规则推理管「业务逻辑」

- 前向链（Forward）：从已知事实推出新事实（物化）
  - 推到数据库里（推导结果显式存储）
  - 查询快（不用实时推），更新慢（要重推）
- 后向链（Backward）：查询时反推（即时推理）
  - 不物化，查询时沿规则反向求解
  - 更新快，查询可能慢
→ 物化 vs 即时 = 查快更新慢 vs 更新快查询慢

- 规则稳定 + 高频查询 → 物化（前向）
- 规则多变 + 图频繁更新 → 即时（后向）
- 混合：基础派生物化 + 复杂查询即时
→ 按「规则稳定性 × 查询频率」选策略

1. 子类传递：
   A subclassOf B, B subclassOf C → A subclassOf C
   例：科技公司⊂公司，公司⊂企业 → 科技公司⊂企业

2. 实例-子类：
   x rdf:type A, A subclassOf B → x rdf:type B
   例：X rdf:type 科技公司 → X rdf:type 公司

3. 子属性传递：
   hasChild subPropertyOf hasDependent
   → 凡是 hasChild 也是 hasDependent

4. domain/range：
   若 p domain: Person 且 x p y → x rdf:type Person
   若 p range: Company 且 x p y → y rdf:type Company
   → 沿属性的定义域/值域反推类型
→ RDFS 推理 = 沿「类层级 + 属性层级 + domain/range」派生

本体（TBox）：
  科技公司 rdfs:subClassOf 公司
  公司    rdfs:subClassOf 企业
  worksAt rdfs:domain Person
  worksAt rdfs:range  Company

数据（ABox）：
  张三 worksAt X公司
  X公司 rdf:type 科技公司

推理派生：
  X公司 rdf:type 公司      （实例-子类）
  X公司 rdf:type 企业      （子类传递 + 实例）
  张三 rdf:type Person     （domain 反推）
  X公司 rdf:type Company   （range 反推）
→ 一个 worksAt 事实派生出一堆类型

- 最常用：子类 + domain/range（简单且有用）
- 成本低：规则少、可判定、可大规模推理
- 语义温和：不会产生「矛盾」（比 OWL 温和）
- 物化友好：派生结果稳定（前向可接受）
→ RDFS 是大多数图谱「够用」的推理层

- 不能表达：等价、不相交、基数、反关系
- 无否定/数量约束（比 OWL 弱）
- 不检查矛盾（不判断类冲突）
→ 需要更强语义 → 上 OWL（第 3 节）

1. 等价：
   Person ≡ Human（类等价 → 互推实例）
   hasSpouse ≡ 夫妻关系（属性等价）
   SameAs（实例相同：别名合并）

2. 不相交：
   Person disjointWith Animal
   → 若 x:Person 且 x:Animal → 矛盾（一致性检查）

3. 基数约束：
   Person hasExactly 1 birthDate
   → 少于/多于 1 个 birthDate → 违反约束

4. 反关系：
   parentOf inverseOf childOf
   → x parentOf y ↔ y childOf x（自动补反边）

5. 传递属性：
   ancestorOf 是传递的 → A ancestorOf C
→ OWL 能表达「等价、约束、反/传递」，也会发现矛盾

本体：
  Person owl:equivalentClass Human
  Parent rdfs:subClassOf Person
  hasSpouse owl:propertyChainAxiom ...
  Person owl:disjointWith Company

数据：
  张三 rdf:type Person
  李四 rdf:type Human
  张三 hasSpouse 李四

推理派生：
  张三 rdf:type Human        （等价）
  李四 rdf:type Person       （等价）
  李四 hasSpouse 张三        （反关系自动补）
→ 等价 + 反关系 = 图谱自动补全

- 检查图谱是否「自洽」（无逻辑矛盾）
- 矛盾示例：
  x rdf:type Person 且 x rdf:type Company
  （若 Person disjointWith Company → 矛盾）
- 一致性 = 图谱的「逻辑体检」
- 生产价值：清洗/导入后跑一致性，发现脏数据
→ OWL 推理 = 补全 + 一致性检查双价值

- OWL 2 有三个 profile：
  EL：轻量（可大规模，适合大型图谱）
  RL：规则可映射（工程常用，可扩展）
  QL：面向查询（数据库友好）
  Full：完全表达力（不可判定，工程不用）
- OWL DL 推理可能非常昂贵（不可判定区域）
→ 工程选 profile（EL/RL/Ql），别用 Full

- 表达力强 → 但推理昂贵、物化结果大
- 一致性检查强 → 但可能把「脏数据」全暴露
- 规则（RL profile）→ 用 Datalog 实现（可扩展）
→ OWL 不是越强越好，按图谱规模选 profile

形式：IF 条件 THEN 结论
  IF A雇佣B 且 B是技术人员 THEN B是员工
  IF x位于y 且 y位于z THEN x位于z（传递）

→ 规则 = 业务知识的「可执行表达」

Datalog 规则：
  employee(X) :- works_at(X, Y), company(Y).
  grandparent(X,Z) :- parent(X,Y), parent(Y,Z).

特点：
  - 声明式：描述「什么是真」，不管怎么算
  - 固定点语义：反复应用直到稳定
  - 可判定、可扩展（比 OWL Full 可控）
→ Datalog = 工程推理的「甜点区」规则语言

SWRL 规则示例：
  Person(?p) ∧ hasParent(?p, ?parent)
  ∧ hasParent(?parent, ?grand)
  → hasGrandparent(?p, ?grand)

特点：
  - 与 OWL 本体结合（规则里可用 OWL 类/属性）
  - 是 OWL DL + 规则（可能不可判定 → 谨慎）
  - 工程常用其「子集」（Datalog 风格）
→ SWRL = 想结合本体与规则时的选择，用子集

- 规则库管理：规则集中管理、版本化
- 规则测试：单元测试（给定事实 → 断言派生）
- 规则优化：减少中间派生、物化热门结论
- 规则冲突：多条规则给矛盾结论 → 需消解
→ 规则也是「代码」，要测试、版本、治理

Rete 算法（经典前向链）：
  1. 编译规则为网络（共享条件）
  2. 事实流入 → 匹配条件 → 触发动作
  3. 新事实再流入（循环直到无新结论）
→ Rete = 高效前向链（共享条件避免重复匹配）

- 本体（RDFS/OWL）：通用语义结构（类/关系性质）
- 规则（Datalog/SWRL）：特定业务逻辑（领域规则）
- 组合：本体定义「世界的类别结构」，规则定义「业务的推导逻辑」
→ 本体 + 规则 = 语义结构与业务逻辑的分工合作

1. RDF 推理机（Jena/OWL API/GraphDB 语义库）：
   处理 RDF 三元组 + 本体推理（RDFS/OWL profile）
   例：Apache Jena、GraphDB、Stardog

2. 图数据库内置/扩展：
   Neo4j 生态：semantics 库 / n10s（RDF 转图 + 推理）
   属性图 + Cypher 规则（自定义）
   例：Neo4j neosemantics

3. 通用规则引擎：
   Drools、Datalog 引擎（Soufflé）
   与图谱数据对接做业务规则推理
→ 选型看「数据模型 + 推理深度 + 规模」

- RDF + OWL 深推理 → Jena/GraphDB（原生本体推理）
- 属性图 + 轻推理 → Cypher 规则 / n10s（够用）
- 大规模 Datalog → Soufflé（高可扩展）
- 业务规则（与图耦合）→ Drools + 图谱数据
→ 数据模型决定推理机生态，规模决定引擎能力

- 支持 profile：RDFS / OWL EL/RL/QL / Full
- 推理模式：前向物化 vs 后向即时 vs 查询时推理
- 可扩展性：百万/亿级三元组的推理能力
- 增量推理：图变化后是否增量更新结论
→ 评估五维：表达力、模式、规模、增量、一致性支持

// Apache Jena：内存推理机（RDFS 前向）
InfModel inf = ModelFactory
    .createRDFSModel(schemaModel, dataModel);
// 查询派生结论
String sparql = "SELECT ?x WHERE { ?x rdf:type <ex:Company> }";
// 包含物化的派生结果

- GraphDB 内置规则集（RDFS/OWL-RL/自定义）
- 推理模式：前向（规则更新后物化）
- 增量：规则推理可增量维护
- 查询：SPARQL 自动含派生结果（可选排除）
→ GraphDB = RDF 图谱推理的生产级选择

可靠性（Soundness）：
  - 推出的结论「都是真的」（不产生错误事实）
  - 前提真 + 规则真 → 结论真

完全性（Completeness）：
  - 所有该推出的结论「都能推出」
  - 若某结论逻辑蕴含 → 推理必得之

→ 好推理机：可靠 + 完全（理想）
→ 实际权衡：追求完全会牺牲效率（可能不可判定）

- 可判定：算法必然终止（能确定答案）
- 不可判定：可能不终止/无法确定
- OWL Full：不可判定（表达力过强）
- RDFS / OWL EL/RL/QL：可判定（工程可用）
- Datalog：可判定（固定点终止）
→ 选「可判定的表达力」，工程不出确定性 bug

- RDFS：P 类（多项式，可大规模）
- OWL EL：多项式（大型图谱可推）
- OWL RL：多项式（规则可映射）
- OWL QL：多项式（查询对数/线性）
- OWL DL：可能指数/更高（受限可判定）
- OWL Full / SWRL 全量：不可判定
→ 越靠上越便宜可扩展，越靠下越贵不可控

- 物化不完全：漏推（规则不全 → 结论缺失）
- 物化过推：推出不该有的（规则过宽）
- 增量错误：图变化后结论未及时更新（陈旧）
- 数据矛盾被推理掩盖：推理把矛盾「中和」了
→ 推理要「可验证」：对已知答案断言正确性

- 基准测试：已知答案的图 → 断言推导结果
- 对拍：两种推理机结果比对
- 随机图测试：随机数据 + 随机规则验证
- 生产抽样：定期抽查派生结论人工验证
→ 推理正确性 = 测试 + 对拍 + 抽查三保障

- n10s 把 RDF 数据导入属性图 + 提供本体推理
- 导入：RDF/OWL 本体映射为标签/关系
- 推理：rdfs:subClassOf 等沿本体层级派生
- 查询：Cypher 命中派生结构
→ n10s = Neo4j 里的「RDF 语义能力」

1. 定义规则集（Cypher 物化查询清单）
2. 定时/触发执行（新数据 → 重跑规则）
3. 物化结果入库（派生标签/关系显式存储）
4. 查询直接用物化结果（不用实时推）
→ Neo4j 物化推理 = 规则查询 + 定时重跑 + 显式存储

- 全量重跑：简单但大图贵
- 增量：只重算受影响子图（新节点/新关系的局部）
- 触发机制：写入时钩子（应用层）
- 异步批处理：低峰期重跑物化
→ 增量 vs 全量 = 精确性 vs 简洁性的权衡

- 属性图无「原生本体层」（需 n10s/自建）
- OWL 级推理（等价/基数）属性图难原生表达
- 无统一规则语言（Datalog 需外部引擎）
- 一致性检查要靠自定义查询
→ 属性图推理「够用但原生能力弱」，深推回 RDF 生态

- 图谱缺边缺类 → 沿本体/规则自动补
- 例：补「张三 WORKS_AT 企业」的派生类型
- 补反关系边（SPOUSE_OF ↔）
- 补传递关系（祖先/依赖链）
→ 补全 = 「少标注多推理」，省人力

- 导入后跑本体一致性 → 发现矛盾数据
  - 节点同时属于不相交类
  - 基数约束被违反（一个人两个出生日期）
  - 反关系不对称（parentOf 而无 childOf）
- 冲突列表 → 修复流程
→ 一致性 = 图谱「逻辑体检」，自动发现脏数据

- 矛盾三元组：同一事实两个相反值
- 检测：OWL disjointWith / SameAs 冲突
- 修复：置信度/来源优先级决定保留哪个
- 记录修复过程（血缘可追溯）
→ 冲突 = 检测（推理）+ 决策（来源优先级）+ 记录

- 问答系统：问「谁是 X 公司的母公司？」
  → 沿子类/传递推理得到答案（未显式存储）
- GraphRAG：推理补全的知识参与检索
  → 检索更全（逻辑等价也命中）
- 推荐：推理出的「隐性关联」做推荐特征
→ 推理增强 = 问答/检索/推荐「答得更全更准」

- 本体版本升级：旧数据需按新本体重推
- 类拆分/合并 → 全图重新物化类型
- 属性改名 → 全图重映射
- 推理规则变更 → 物化结果失效重算
→ 本体/规则演进 = 推理结果管理（重算/失效）

1. 定义本体 + 规则（建模）
2. 选推理机 + 推理模式（选型）
3. 导入数据 → 跑推理（补全/一致性）
4. 物化或即时查询（落地）
5. 验证正确性（基准/抽查）
6. 持续增量更新（监控）
→ 落地 = 建模 → 选型 → 推理 → 验证 → 维护

图查询：按「显式存储」的结构找答案
  例：MATCH (:Person)-[:WORKS_AT]->(:Company)
  → 只命中「已存的关系」

推理：按「逻辑蕴含」的语义找答案
  例：张三 WORKS_AT X公司，X公司⊂科技公司
  → 逻辑上张三也 WORKS_AT 科技公司（未存）
→ 查询答「库里有什么」，推理答「逻辑上是什么」

- 物化推理 + 普通查询：查询命中物化结果（简单）
- 查询时推理：SPARQL 推理模式（Jena 自动含派生）
- 手动扩展：查询里写规则逻辑（Cypher 内联推导）
- 混合：基础物化 + 复杂逻辑查询时算
→ 组合模式 = 按「规则稳定性 × 查询频率」选

- 需要「逻辑等价」命中（查询做不到）
- 派生知识稳定且高频使用 → 物化推理
- 业务规则复杂 → 规则引擎（非手写查询）
- 一致性验证 → 推理机（非手写检查查询）
→ 推理的用武之地：等价命中、稳定物化、规则复杂、一致性

- 简单结构匹配（查询直接、快）
- 规则变化频繁（物化维护成本高）
- 实时数据（物化跟不上更新）
- 分析性探索（ad-hoc 查询更灵活）
→ 查询的用武之地：直接匹配、多变、实时、探索

- 基础层：显式数据（存储）
- 语义层：本体 + 规则（推理定义）
- 物化层：稳定派生结果（加速）
- 查询层：Cypher/SPARQL（使用）
→ 四层架构：存底层数据、定义推导、物化稳定结论、查询使用