第八章 · 开源生态地图
8.4 语义基础设施：解析、推理、校验、存储
十四块地基，十年没怎么变过
这一格是「沉默的大多数」：rdflib 建于 2012 年、Jena 2013 年、Protégé 相关的 OWLAPI 也是 2013 年。它们不增长，但整个生态建在它们上面。两次分裂值得注意：推理机在萎缩（Pellet 2017 年停更、Openllet 2025 年停更），校验在增长（SHACL 相关全部活跃）。
判据：需要「缺了什么」用 SHACL，需要「能推出什么」用推理机。业务系统问的永远是前者。
RDFLib
SPython 的 RDF 图操作库：解析、序列化、命名空间、SPARQL 1.1。几乎所有 Python 本体工具都建在它上面。但它是内存图加朴素查询引擎，没有优化器，不是数据库。
何时采纳需要写一次性脚本做本体体检、格式转换或小规模查询时。
Apache Jena
AJava 的 RDF / SPARQL 全栈：ARQ 查询引擎、TDB2 原生存储、Fuseki HTTP 端点，外加 RDFS 与规则推理。注意它不自带完整 OWL DL 推理机。
何时采纳要在 JVM 上起一个 SPARQL 服务、且需要事务与持久化时。
OWL API
AOWL2 的 Java 对象模型与推理机接口。它的真正价值是标准化了「换推理机不改代码」这件事：HermiT、ELK、Openllet、Konclude 都实现同一套接口。
何时采纳需要在 Java 里操作 OWL 结构、或对比多个推理机时。
Neosemantics
ANeo4j 与 RDF / SHACL 之间的桥：把 RDF 导入属性图、在库里跑 SHACL 校验、维护本体作为「schema 子图」。它证明了属性图与 RDF 不是二选一。
何时采纳已有属性图、需要接一层本体约束时。
Eclipse RDF4J
BEclipse 的 Java RDF 框架，以 Repository 为中心抽象存储，GraphDB 的底座。比 Jena 多一个能力：SHACL Sail 把校验放进写入路径。
何时采纳需要「坏数据根本进不来」而不是「事后报表」时。
pySHACL
SPython 的 SHACL 校验器，覆盖 Core、SPARQL、Advanced Features 与 JS 扩展，可先推理再校验。退出码非零，可以直接当 CI 闸门，不需要解析输出。
何时采纳要一份能执行的 schema 文档、并且真的会拒绝坏数据时。
TopBraid SHACL
B基于 Jena 的 SHACL 实现，覆盖 Core + SPARQL + Advanced Features，也是规范参考实现之一。维护者联系信息已转到外部团队，后续活跃度需观察。
何时采纳JVM 技术栈、需要完整 SHACL-AF 规则时。
OWL-RL
SOWL2 RL 的前向链规则闭包，跑在 RDFLib 之上，同时支持基础 RDFS 推理。它是「不装推理机也能推一点」的折中：能推规则，但不会告诉你缺了什么。
何时采纳只需要子类继承、传递闭包这类规则推导时。
Reasonable
BRust 写的 OWL2 RL 推理机，基于 DataFrog 的差分数据流，提供 CLI 与 Python 绑定，README 直接给了与 OWL-RL、Allegro 的性能对比。
何时采纳Python 侧闭包太慢、又不想起 JVM 时。
Openllet
BPellet 的活跃维护分支，OWL2 DL 推理，实现 OWLAPI 接口，保留了解释（explanation）能力。2025 年 8 月后无提交。
何时采纳需要 Pellet 行为兼容、且能接受 AGPL 时。
ELK Reasoner
AOWL2 EL 推理机，consequence-based 算法，多项式时间，为 SNOMED 级（数十万类）规模设计，支持增量分类。它的价值不是「推理」而是「大规模分类的可维护性」。
何时采纳词表分类树大到人工维护必错时。
Konclude
BC++ 的 SROIQV(D) 推理机，tableau + 并行，性能取向，可当 HTTP 服务用。作者自己在 README 里写「当前版本可能含有 bug」。
何时采纳需要 DL 推理的吞吐上限、或做推理机性能基线时。
ERGS
B在属性图上做 RDF 与推理：RDF→属性图编码、SPARQL→Gremlin 转换、RDFS 加少量 OWL。名字里的 Expressive 是目标而非现状。
何时采纳阅读「RDF 如何编码进属性图」的具体方案时。
Pellet
C经典的 OWL2 DL 推理机，2017 年后彻底停更。它存在的意义是提醒：DL 推理这个方向的开源供给正在萎缩。
何时采纳只在阅读推理机发展史时。