开始的时候我们使用的Protégé运行的推理机发现

这里无法构建个体

然后转向用代码来实现效果上的对比。

FaCT++ vs HermiT 推理机对比测试报告 (Maven 版)

本报告基于 OWL API 5.1.20 + JFact 5.0.3 (FaCT++ 的纯 Java 移植版) + HermiT 1.4.3.517 在 Windows 10 (JDK 17) + Maven 3.9.9 下的实测结果。 项目通过 [pom.xml](file:///e:/ccks/reasoner/pom.xml) 管理依赖，测试代码: [src/main/java/Test.java](file:///e:/ccks/reasoner/src/main/java/Test.java)，原始数据: [test_output.txt](file:///e:/ccks/reasoner/test_output.txt)。

1. 测试目的

• 验证两套 OWL 2 DL 推理机（JFact 替代原 FaCT++、HermiT）能否在本机 Maven 环境正常加载、初始化并完成推理；
• 在多种 OWL 2 特性与典型本体上，对比二者的功能正确性与性能差异；
• 为本项目（CCKS 知识图谱推理）选定合适的推理机后端提供数据依据；
• 探索使用 Maven 替代手动 lib/ 依赖管理的可行性。

2. 测试环境

2.1 Maven 项目结构

1
2
3
4
5
6
7
8
9
10
11
12

reasoner/
├── pom.xml                          # Maven 配置 (OWL API 5.1.20 + JFact 5.0.3 + HermiT 1.4.3.517)
├── src/main/java/Test.java          # 8 组测试 (T1-T8)
├── ontologies/
│   ├── pizza.owl                    # 939 axioms (大本体基准)
│   └── families.owl                 # 9 axioms (含实例的真实本体)
├── target/
│   ├── OWLReasonerTest-1.0-SNAPSHOT.jar   # 构建产物
│   ├── classes/                     # 编译输出
│   └── lib/                         # maven-dependency-plugin 复制出来的所有依赖
├── test_output.txt                  # 完整运行日志 (UTF-8)
└── reasoner_comparison_report.md    # 本报告

2.2 复现命令

1
2
3
4
5

# 编译 + 打包 + 复制依赖到 target/lib/
mvn package -DskipTests

# 运行测试 (UTF-8 输出)
java -Dfile.encoding=UTF-8 -cp "target\classes;target\lib\*" Test

Maven 版本调整说明：原始 [pom.xml](file:///e:/ccks/reasoner/pom.xml) 中指定的 org.semanticweb.hermit:hermit:1.4.3.519 在 Maven Central 不存在，已替换为同 group 下 net.sourceforge.owlapi:org.semanticweb.hermit:1.4.3.517（OWL API 官方维护的坐标）。net.sourceforge.jfact:jfact:4.0.4 也已修正为 net.sourceforge.owlapi:jfact:5.0.3（更新、纯 Java、OWL API 5 兼容）。

3. 推理机简介

关于 FaCT++ → JFact 的迁移：原项目使用的 FaCTpp-OWLAPI-4.x-v1.6.5.jar + FaCTPlusPlusJNI.dll 需在每台目标机器上提供对应位数的 JNI 动态库，部署/打包/CI 都不友好。JFact 是 FaCT++ 的官方 Java 移植版，内核设计一致但用 Java 重写，无 JNI 依赖，OWL API 5 兼容性更好。本测试已完全迁移到 JFact。

4. 测试场景 (8 组)

5. 关键结论一览

6. 详细测试结果

T1 — 基础一致性 + 分类 (3 个类 A ⊑ B ⊑ C)

✅ 两者结果一致，JFact 创建推理机更快。

T2 — 不一致本体 (Person ⊓ Dog, 同一实例 John)

✅ 两者均正确检测出本体不一致。

T3 — 实例检索 (8 个个体，4 个 Student、4 个 Teacher；Student ⊑ Person, Teacher ⊑ Person)

✅ 两者结果完全一致。

T4 — 复杂 OWL 2 特性 (Animal ≡ Mammal ⊔ Pet，Pet ⊑ ∃hasOwner.Thing，hasOwner / hasPet 互逆)

✅ 两者在嵌套等价类 + 逆属性 + 存在量化下结果完全一致。

T5 — 性能基准 (小型本体，单次)

小本体下两者都 < 1ms，无法体现差距。详见 T5b 与 T6。

T5b — 性能基准 (小型本体，5 次平均)

同样 < 1ms，无法体现差距。

T6 — 大本体 (pizza.owl, 939 axioms) ⭐ 最显著的差异

这是本测试最关键的性能差异：在 939 axioms 的 pizza 本体上，JFact 完成完整分类只需 ~222ms，而 HermiT 需要 ~475ms。一致性检查则相反：HermiT 仅 1ms 而 JFact 用了 83ms (JFact 在 consistency 上内部多做了些工作)，但 222ms 的总分类时间已包含了一致性 + 分类。

T7 — 角色层次 + 传递性 (hasParent ⊑ hasAncestor, Transitive(hasAncestor), Alice hasParent Bob)

✅ 两者都通过传递性 + 角色层次推导出 hasAncestor 关系。

T8 — 真实本体 (families.owl, 9 axioms)

✅ 结果完全一致；本体太小，性能差异无法体现。

7. 差异分析

7.1 性能差异来源

• JFact 是在 FaCT++ 设计基础上的纯 Java 移植：保留了 C++ 版本的高度优化算法，分类阶段直接调用 Java 实现，避开 JVM 解释/GC 压力优势（与原版 C++ JNI 相比差距缩小）。
• HermiT 是纯 Java Hypertableau：策略更复杂、blocking 校验更多，在分类前要构造并维护完整的 hypertableau 数据结构，因此在中大本体上分类开销更明显。
• 小本体上差距消失：当本体公理数 < 50 时，JVM 启动 + JIT 预热的开销会反过来让 JFact 看起来稍慢或相当。
• pizza.owl 场景具体数据：JFact 一致性耗时 83ms 反而比 HermiT 1ms 慢很多 (因为 JFact 内部需要先构建内部数据结构)；但最终分类完成时间 JFact (222ms) 仍快于 HermiT (475ms)。

7.2 与原 FaCT++ JNI 版本对比 (历史数据)

7.3 部署差异 (JFact vs HermiT)

7.4 接口差异

两者都实现了标准的 OWLReasoner 接口，因此调用代码完全相同：

1
2
3
4
5
6

OWLReasoner r = factory.createReasoner(ontology);
boolean consistent = r.isConsistent();
r.getSubClasses(cls, true);  // 直接子类
r.getInstances(cls, false);  // 所有（推理）实例
r.isEntailed(axiom);         // 蕴含检查
r.dispose();                 // 必须释放

唯一区别在于工厂类：

1
2
3
4
5
6
7

// JFact (原 FaCT++ 移植)
import uk.ac.manchester.cs.jfact.JFactFactory;
OWLReasonerFactory factory = new JFactFactory();

// HermiT
import org.semanticweb.HermiT.ReasonerFactory;
OWLReasonerFactory factory = new ReasonerFactory();

8. Maven 迁移经验总结

8.1 原始 lib/ 方式 vs 新 pom.xml 方式

8.2 原始 pom.xml 的修正

8.3 pom.xml 关键配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

<dependencies>
    <dependency>
        <groupId>net.sourceforge.owlapi</groupId>
        <artifactId>owlapi-distribution</artifactId>
        <version>5.1.20</version>
    </dependency>
    <dependency>
        <groupId>net.sourceforge.owlapi</groupId>
        <artifactId>org.semanticweb.hermit</artifactId>
        <version>1.4.3.517</version>
    </dependency>
    <dependency>
        <groupId>net.sourceforge.owlapi</groupId>
        <artifactId>jfact</artifactId>
        <version>5.0.3</version>
    </dependency>
</dependencies>

8.4 历史 lib/ 依赖问题（已通过 Maven 解决）

9. 结论与建议

1. 功能层面可互换：8 组测试中两台推理机的逻辑输出 100% 一致，可放心替换。
2. 性能层面优先 JFact：在 CCKS 任务中若存在 1000+ axioms 的大本体，JFact 优势明显（pizza.owl 上 2.1×）。
3. 部署层面两台均优：Maven 迁移后，JFact 与 HermiT 都是"纯 Java + 单坐标依赖"，部署难度彻底消失，也彻底摆脱了原 FaCT++ JNI 的多平台 / 容器 / 32/64-bit 痛点。
4. 混合策略：可在本地用 JFact 跑离线批量推理；服务化部署时切到 HermiT，通过 OWLReasonerFactory 抽象，业务代码无需改动。
5. 下一步：
   • 把 [Test.java](file:///e:/ccks/reasoner/src/main/java/Test.java) 接入 CCKS 真实语料（contest_data 中的多跳/图谱/表格题本体）；
   • 在 10+ 个真实 OWL 本体上重复 T6 风格的基准，统计 JFact vs HermiT 性能分布；
   • 评估 ELK / Konclude / Openllet 等新一代推理机作为补充方案；
   • 在 CI 中把 mvn package && java -cp ... Test 串成 smoke test 任务。

Maven 项目配置: [pom.xml](file:///e:/ccks/reasoner/pom.xml) 测试代码: [src/main/java/Test.java](file:///e:/ccks/reasoner/src/main/java/Test.java) 原始输出: [test_output.txt](file:///e:/ccks/reasoner/test_output.txt) （ai参与撰写和润色）