开放本体

用于知识图谱的 Terraforming MCP
验证、分类并治理 AI 生成的本体。使用 Rust 编写。以单个二进制文件形式发布。

快速入门 · Studio · 基准测试 · IES · 工具 · 架构 · 文档

Open Ontologies 是一个用于 AI 原生本体工程的 Rust MCP 服务器 和 桌面 Studio。它暴露了 70+ 工具，使 Claude 能够使用内存中的 Oxigraph 三元组存储来构建、验证、查询、差异比较、检查、版本控制、推理、对齐、规划、认证和治理 RDF/OWL 本体——具备完整的三层 Dynamics → Causal → Planner 架构、包含 33 个标准本体的市场、临床交叉映射、语义嵌入以及完整的谱系审计跟踪。

Studio 将引擎封装在一个可视化的桌面环境中：带有层级线的虚拟化本体树、面包屑导航和连接浏览器；带有 /build（IES 级深度）和 /sketch（快速原型）命令的 AI 聊天面板；Protégé 风格的属性检查器；以及谱系查看器。

无 JVM。无 Protégé。

新增内容（三层架构 + 13 个新原语）

完整的 Dynamics → Causal → Planner 技术栈以及 13 个新原语。每个组件都遵循 MCP-native 约定：服务器提供验证和脚手架，连接的 LLM（通过 MCP 连接的 Claude）负责智能处理。没有内部 LLM 客户端，没有 API 密钥，没有提供商抽象。

三层架构

13 个新原语

• onto_owl_shacl_coevolve_check + onto_owl_shacl_coevolve_incremental — 针对 OWL-RL 闭包的 SHACL 验证，采用依赖图路由，仅重新验证触及已更改 IRI 的形状。
• onto_segment_retrieve — 用于基于本体的 RAG 的 TBox 切片检索。
• onto_extract_scaffold + onto_extract_validate — 模式引导的结构化提取，包含类型化数据类型验证 + 一致性评分。
• onto_cq_run + onto_verify_cq + onto_cq_verdicts_list — 能力问题运行器，包含陷阱提示 + LLM 判断循环。
• onto_classify_el — OWL-EL 分类（传递包含表，排除平凡对）。
• onto_eval_alignment — 基于参考 + 计算对齐集的 P/R/F1。
• onto_shape_combinatorics + onto_shape_induce — 属性组合格 + 数据驱动的 SHACL 形状归纳，采用支持度 × 置信度排名。
• borderline_partition + borderline_record_verdict — 适用于任何候选集的广义双阈值审查循环。
• onto_align_fuzzy — 无嵌入的模糊逻辑裁决，采用 10 规则 Mamdani 推理；HNSW 降级为候选生成器。
• onto_align_flora — 将信号提取器与模糊裁决器配对的端到端对齐管道。
• onto_policy_register + onto_policy_list + onto_policy_check — 与 onto_certify_action 组合的授权门（因果 = 风险；策略 = 授权）。
• eval_rag + eval_rag_mmrag — 用于检索器管道的 Hit@k / MRR / 忠实度 / token-Jaccard / ROUGE-1 评分，包含数据集适配器。
• graph_projection_lossy_check — 与 onto_segment_retrieve 配对的审计器。

端到端验证

cargo run --example three_layer_pipeline

Walks Dynamics 注册 → PDDL 编译 → Fast-Downward 形状的 sas_plan 解析 → 编排器侧 IRI 绑定 → 沙箱验证 → CIVeX 认证 → 应用 OWL-RL 推论 → 最终状态检查。每一层均通过其公共 API 实现，无需外部依赖（Python、DoWhy、Fast Downward）。

零新增外部 Rust 依赖；所有可选功能均通过 Cargo 特性进行门控。完整测试套件（160+ 测试）在默认构建下全部通过；cargo clippy --lib --tests --examples -- -D warnings 在默认和 causal-pywhy 配置下均保持干净。

快速入门（MCP / CLI）

安装

预构建二进制文件：

# macOS (Apple Silicon)
curl -LO https://github.com/fabio-rovai/open-ontologies/releases/latest/download/open-ontologies-aarch64-apple-darwin
chmod +x open-ontologies-aarch64-apple-darwin && mv open-ontologies-aarch64-apple-darwin /usr/local/bin/open-ontologies

# macOS (Intel)
curl -LO https://github.com/fabio-rovai/open-ontologies/releases/latest/download/open-ontologies-x86_64-apple-darwin
chmod +x open-ontologies-x86_64-apple-darwin && mv open-ontologies-x86_64-apple-darwin /usr/local/bin/open-ontologies

# Linux (x86_64)
curl -LO https://github.com/fabio-rovai/open-ontologies/releases/latest/download/open-ontologies-x86_64-unknown-linux-gnu
chmod +x open-ontologies-x86_64-unknown-linux-gnu && mv open-ontologies-x86_64-unknown-linux-gnu /usr/local/bin/open-ontologies

Docker:

docker pull ghcr.io/fabio-rovai/open-ontologies:latest
docker run -i ghcr.io/fabio-rovai/open-ontologies serve

serve 启动一个通过 stdin/stdout 使用 JSON-RPC 通信的 MCP 服务器 — 它不是交互式 CLI，因此启动后在等待 MCP 客户端连接时看起来会“挂起”。这是预期行为。若要直接在终端中试用这些工具，请使用 CLI 子命令（例如 open-ontologies validate <file.ttl>）；若要将其与 LLM 配合使用，请按照 Connect to your MCP client 中的说明将其接入 MCP 客户端。

从源码构建（Rust 1.85+）：

git clone https://github.com/fabio-rovai/open-ontologies.git
cd open-ontologies && cargo build --release
./target/release/open-ontologies init

有关原生 Windows 构建，请参阅 docs/windows.md。

连接到你的 MCP 客户端

{
  "mcpServers": {
    "open-ontologies": {
      "command": "/path/to/open-ontologies/target/release/open-ontologies",
      "args": ["serve"]
    }
  }
}

{
  "mcpServers": {
    "open-ontologies": {
      "command": "/path/to/open-ontologies/target/release/open-ontologies",
      "args": ["serve"]
    }
  }
}

{
  "mcpServers": {
    "open-ontologies": {
      "command": "/path/to/open-ontologies/target/release/open-ontologies",
      "args": ["serve"]
    }
  }
}

{
  "mcpServers": {
    "open-ontologies": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "ghcr.io/fabio-rovai/open-ontologies", "serve"]
    }
  }
}

构建你的第一个本体

Build me a Pizza ontology following the Manchester University tutorial.
Include all 49 toppings, 24 named pizzas, spiciness value partition,
and defined classes (VegetarianPizza, MeatyPizza, SpicyPizza).
Validate it, load it, and show me the stats.

Claude 生成 Turtle，然后自动运行完整的流水线：

onto_validate → onto_load → onto_stats → onto_reason → onto_stats → onto_lint → onto_enforce → onto_query → onto_save → onto_version

每次构建均包含 OWL 推理（物化推断三元组）、设计模式强制以及自动版本控制。

Studio（桌面应用）

Studio 是一款原生桌面应用程序，在可视化环境中封装了相同的引擎——无需浏览器，也无需管理服务器。它完全在你的机器上运行：引擎边车（sidecar）处理 RDF/OWL 操作，而 UI 则实时渲染图谱。

可以将其视为 Protege 与 AI 副驾驶的结合。输入“构建关于猫的 ontology”，即可在树中看到一个包含 1,400 个类的 ontology 出现——类、属性、个体和公理通过 13 个流水线步骤自动构建。点击任意节点以检查其三元组，通过可点击的标签追踪连接，并通过谱系面板跟踪每一次变更。

为什么使用虚拟化树（而非 3D 图谱）

在 v0.1.12 之前，Studio 使用 D3.js 水平树和 3D 力导向图（Three.js / WebGL）。两者对于小型 ontology（约 100 个类）都能正常工作，但在 IES 级别的深度下变得不可用：D3 树无法处理 500 个以上的节点而不出现布局抖动，且 3D 图谱在超过 1,000 个节点时会使 WebKit webview 冻结。

v2 深度构建器改变了这一局面——单个 /build 命令现在可以生成 1,400 个以上的类。我们用虚拟化 DOM 树替换了这两种视图：只有可见的行存在于 DOM 中（无论 ontology 大小如何，内存占用恒定），并配有层级连接线、类型过滤图例、搜索、面包屑导航和连接面板。这可以无延迟地处理完整的 IES Common（511 个类）和深度构建的 ontology（1,400 个以上的类）。

工作原理

The Studio 启动三个在本地通信的进程：

1. Tauri 2 shell — native window (macOS/Linux/Windows) with a WebKit webview
2. Engine sidecar — the same Rust binary, running as an HTTP MCP server on localhost:8080
3. Agent sidecar — Node.js process running Claude via the Agent SDK, connected to the engine over MCP

当您在聊天面板中输入时，您的消息会发送到 Agent sidecar，然后由它发送给 Claude。Claude 决定调用哪些 onto_* 工具，引擎执行这些工具，UI 刷新图形。整个循环——从提示到视觉更新——只需几秒钟。

安装和运行

前提条件： Rust + Cargo · Node.js 18+

# 1. Build the engine binary (from repo root)
cargo build --release

# 2. Install JS dependencies
cd studio && npm install

# 3. Run
PATH=/opt/homebrew/bin:~/.cargo/bin:$PATH npm run tauri dev

首次启动会编译 Tauri 外壳（约 2 分钟）。后续启动仅需数秒。

功能

键盘快捷键

研究问题

以下基准测试并非功能巡礼。每一项的存在都是为了回答一个具体问题，而答案中包括那些令人不快的部分。

RQ2 和 RQ4 是你在决定是否信任此仓库时值得阅读的部分。两者都是关于在此处所做工作的负面结果。

基准测试

如何解读这些数字。 除非另有说明，LLM 结果为单次运行（未对种子取平均），并使用 Claude Opus 4.8。多个基准本体（Pizza、FOAF、Schema.org、OWL-Time）已广泛发布，可能出现在 LLM 的预训练数据中，因此裸 LLM 分数是一个包含污染的基线，而非推理能力的干净度量——贡献在于 MCP 工具在该基线之上增加的增量，以及该增量是否能在不同模型间复现。为了精确检查这一点，该仓库附带了一个跨模型消融实验，使用本地 Qwen3-Coder-30B 以及 Claude 来驱动相同的任务——参见 benchmark/ontoaxiom/。如果工具增强带来的增益在第二个开源模型上依然成立，那么该增益是工具本身的属性，而非某一家供应商模型的属性。

OntoAxiom — LLM 公理识别

OntoAxiom 在 9 个本体和 3,042 个真实公理上测试公理识别。

以下所有条件均由单一评估器（benchmark/ontoaxiom/score_all_conditions.py）使用一个共享的归一化器进行评分，并报告两种平均值，因为原始脚本在这些方面存在分歧。macro = 每个（本体，公理）F1 的均值；micro = 基于汇总 TP/FP/FN 的 F1。

该论文中“原始 OWL 有害”的结论是一个评分伪影。 OntoAxiom 报告称，给定完整 OWL 文件的 LLM（F1 = 0.323）表现差于仅给定类/属性名称列表的 LLM（0.431）。这两个数字来自在三个维度上不一致的脚本：名称列表评分器拆分 camelCase，而原始 OWL 评分器仅转换为小写；前者报告宏平均值，后者报告微 F1；并且它们在不同公理类型上翻转了配对顺序。这些差异中的每一个都惩罚了原始 OWL 条件，因为在该条件下，模型读取真实的 Turtle，因此以 QName（foaf:Person）和 rdfs:label 文本（"personal mailbox" 对应 mbox）作答，而不是裸局部名称。0.431 和 0.323 从来不是同一个统计量。

在单一评估器下对相同的存储预测重新评分，两个模型在两种平均值下均出现符号翻转：Claude 0.451 → 0.768 宏平均（0.397 → 0.686 微平均），Qwen 0.246 → 0.673 宏平均，分别赢得 33/43 和 33/38 个单元格。score_condition_d.py --legacy 精确复现了错误的 0.323，因此该缺陷是被证明而非断言的。修正移动了 0 个 5,083 个名称列表对，因此它不能美化基线，并且它仍然低估了原始 OWL：Claude 的 51.8% 的配对是此处任何规范化器都无法匹配的标签文本。完整分析和复现：benchmark/ontoaxiom/ONTOAXIOM_SHOWDOWN.md.

修正后，阅读本体和通过 SPARQL 提取它在持平——原始 OWL 在宏平均上获胜（0.768 对 0.713），提取在微平均上获胜（0.717 对 0.686）。因此，工具的优势是可审计性，而非 F1：每个 MCP 配对都可追溯到针对真实三元组的查询，而 LLM 阅读文件仍可能幻觉出一个合理的配对，且没有 F1 分数会指出哪一个。

披萨本体 — 曼彻斯特教程

单句输入："按照曼彻斯特教程规范构建一个披萨本体。"

/sketch 对 /build — 两种构建模式

Studio 提供了两种针对不同使用场景的构建命令。两者接受相同的输入——"构建关于猫的 ontology"——但产生的结果截然不同：

/sketch 执行 3 个步骤：在一个 Turtle 块中处理类 + 属性，公理 + 个体，然后保存。适用于快速领域探索或演示原型设计。它生成一个包含层级、属性和个体的完整 ontology——但深度仅为前者的一小部分。

/build 在单个持久化 Claude 会话中运行一个 13 步的流水线：基础类 → 按分支深化 (4 遍) → 填补空白 → 对象属性 (2 批) → 数据类型属性 → 不相交 → 个体 → 推理 → 保存。每个步骤专注于 ontology 的一个方面，在保持输出 token 限制的同时，基于前一步的上下文进行构建。结果在所有指标上均超过 IES Common。

/sketch 与 Pizza 基准 (95 个类, 8 个属性) 相当。/build 生成 IES 级别的 ontology——深度足以用于生产环境。

蘑菇分类 — OWL 推理 vs 专家标签

数据集： UCI 蘑菇数据集 — 8,124 个由真菌学专家分类的样本。

本体市场 — 33 个标准本体

29 个通用市场本体（四个 IES 条目在 IES 支持) 下单独覆盖）已获取、owl:imports 解析、加载，并使用 RDFS 和 OWL-RL 配置文件进行推理。使用 python3 benchmark/marketplace_benchmark.py 重新生成：

29/29 个本体已加载，导入已解析，并完成推理。RDFS 增加了 18% 的三元组。OWL-RL 增加了 43% —— 传递/对称/逆属性以及 equivalentClass 扩展发现了大量隐式知识。Schema.org 的推断三元组从 +4,082（RDFS）跃升至 +14,236（OWL-RL），耗时 136ms。

类和属性的计数是结构性的，而非仅基于声明：如果一个术语被类型化（owl:Class, rdfs:Class, owl:ObjectProperty, owl:DatatypeProperty, rdf:Property）或被用作类型（rdfs:subClassOf/subPropertyOf/domain/range 位置），则计入该术语。因此，从不发出 OWL 类型声明的词汇表（如 Schema.org）会被计数，而不是报告为空。rdf:、rdfs: 和 owl: 命名空间中的术语被排除，以免将词汇表所编写的元词汇表归功于该词汇表。正是由于这种排除，OWL 2、RDF Schema 和 RDF Concepts 报告 0 个属性：它们定义的每个属性，根据定义，都位于被排除的命名空间中。FIBO 的市场条目仅包含元数据模块（48 个三元组），该模块未声明任何自身的术语。

编译声明验证 — 实测与 HermiT

claimcheck 模块将本体一次性编译（推断层级 + 不相交性，包括通过可靠传播规则推导出的对）为每类的令牌位集，然后验证候选声明——即“这组三元组是否与本体一致？”的问题——在查询时不进行推理：每对类执行两次 64 位 AND 操作，并提取见证公理用于解释。

同一本体（规范 pizza.owl）、同一任务、同一机器，判定结果已与 HermiT 1.4.3.456 交叉核对：

正确性优先于速度：

• 在 78,884 个经全面审计的类对（13 个本体）和 793 个结构性对抗性声明中，与 HermiT 零分歧。
• 构造上可靠：每个 Rejected 判定均由可推导的矛盾支撑，并指明见证公理。在两个完全审计的本体上，矛盾召回率为 100%。
• 显式的不完备性包络：编译表面无法判定的任何内容均返回 Undetermined 并路由至推理器支持的剩余层——绝不进行猜测。
• 封闭世界词汇检查可捕获开放世界 OWL 语义在结构上无法标记的幻觉类/属性。

离线编译：通过任意完整 OWL 推理器执行一次分类遍历（Pizza 约 120 ms）；发布的热点路径为纯 Rust，无 JVM 依赖。 复现脚本：benchmark/layer3-prototype/.

设计、测量与包络：docs/layer3-compiled-reasoning.md. 完整基准测试方法论：docs/benchmarks.md

OAEI 本体对齐 — 解剖赛道

OAEI](https://oaei.ontologymatching.org/) 是本体对齐系统的标准基准。Anatomy 赛道将小鼠解剖本体（2,744 个类）与 NCI Thesaurus 的人类解剖片段（3,304 个类）进行对齐，并对照 1,516 个参考映射。

下表是 完整 的 OAEI 2025 Anatomy 领域数据，摘自官方结果论文（Vol-4144, om2025-oaei-paper0）的表 9，包含两个基线。Open Ontologies 按其测量排名插入。未进行任何过滤。

请诚实地阅读此内容。 Open Ontologies 在 F1 指标上位列 13 个系统中的第 9 名。其精确率（0.960）在领域内排名第三，但其召回率（0.730）在非基线系统中倒数第二，由此产生的 F1 值与刻意轻量化的词汇匹配器 LogMapLt 持平，且比领先者低 0.112。StringEquiv 基线仅通过归一化字符串相等性即可达到 0.766，因此该系统相对于纯字符串匹配所获得的边际优势为 +0.063 F1。这是需要超越的数值，而目前这仍不是一个具有竞争力的结果。

差距在于召回率，且其原因可识别：该系统不包含任何领域背景知识。解剖学是一个 UMLS 和 BioPortal 查询将 0.88+ 区间与其他系统区分开来的赛道，表格中排在 Open Ontologies 之上的每个系统要么使用生物医学背景知识，要么使用 LLM 预言机，要么两者兼用。此处的对齐使用了 7 个加权信号（标签相似度、属性/父级/实例/限制/邻域重叠、嵌入相似度）、稳定的 1 对 1 匹配，以及在无结构证据可用时的标签惩罚。

因此，从该赛道得出的可辩护结论并非头条 F1 值。而是消融实验：稳定的 1 对 1 匹配才是产生差异的关键，且一旦应用了它，信号权重几乎无关紧要。

移除稳定匹配后，针对 1,516 映射的参考集，产生了 12,557 个候选项。参见问题 #8, #9, #10；背景知识集成是未完成的工作。

OAEI 本体对齐 — 会议赛道

21 个会议赛道配对中的 15 个，微平均：

不可直接对比，且表现比看起来更差。 OAEI 行来自 2025 年结果论文的表 10，针对所有 21 个配对，在每个系统 F1 最优阈值下，依据 rar2 参考集进行评估。Open Ontologies 行覆盖 15 个配对，采用固定置信度阈值。在说明该前提的情况下，结果明确无误：低于所有参与系统，且低于两个基线。最佳配对为 ekaw-iasted (0.588) 和 ekaw-sigkdd (0.533)；最差为 edas-sigkdd (0.211)。会议赛道中，导致 Anatomy 排名下降的相同召回率失败代价更大，因为此处没有词汇冗余可供回退。

IES 支持

IES（信息交换标准） 是英国国家数字孪生计划的核心本体框架。它采用 4D 外延主义（BORO）方法对实体、事件、状态和关系进行建模。Open Ontologies 支持完整的 IES 技术栈——包括所有三个层级、SHACL 形状以及来自 IES-Org GitHub 仓库的示例数据集。

IES 层级

市场包含 IES 框架的所有三个层级：

onto_marketplace install ies-top     # ToLO — BORO foundations (~22 classes)
onto_marketplace install ies-core    # Core — persons, states, events (~131 classes)
onto_marketplace install ies         # Common — full ontology (511 classes, 206 properties)

基准测试

IES 是按类数量计的市场中第二大本体（仅次于 Schema.org）。RDFS 推理在所有非通用本体中产生了最丰富的推理增益——State、ClassOfEntity 和 Event 的子类均生成了深层传递链。

示例数据

直接从官方仓库加载 IES 示例数据集：

onto_pull https://raw.githubusercontent.com/IES-Org/ont-ies/main/docs/examples/sample-data/event-participation.ttl
onto_pull https://raw.githubusercontent.com/IES-Org/ont-ies/main/docs/examples/sample-data/hospital.ttl
onto_pull https://raw.githubusercontent.com/telicent-oss/ies-examples/main/additional_examples/ship_movement.ttl

SHACL 验证

onto_pull https://raw.githubusercontent.com/IES-Org/ont-ies/main/docs/specification/ies-common.shacl
onto_shacl

数据映射：EPC → IES

该仓库包含一份真实的英国能源性能证书样本（benchmark/epc/epc-sample.csv），并附带一个映射配置，用于将表格形式的 EPC 数据转换为 IES 形状的 RDF：

onto_load benchmark/generated/ies-building-extension.ttl
onto_ingest benchmark/epc/epc-sample.csv --mapping benchmark/epc/epc-ies-mapping.json
onto_reason --profile rdfs

这反映了 NDTP 的实际流水线：CSV → IES RDF → 验证 → 推理 → 查询。

IES 建筑扩展 — 与 NDTP/IRIS 的对比

该仓库包含一个基于英国 EPC 数据模式和建筑科学基础构建的 IES 建筑扩展，使用了 IES 4D 模式。它是独立构建的——未参考任何现有实现——然后与用于政府数据流水线的 NDTP/IRIS 生产级建筑本体进行了对比。

基于 105 列的 EPC 模式、SAP 方法论和 BORO 4D 外延性盲构建——零参考 IRIS 实现。这两个本体做出了不同的权衡：IRIS 经过更严格的策划，具有更高的平均层级深度（2.89 对 2.02），反映了领域专家的刻意分组。Open Ontologies 覆盖了更多的 EPC 数据模式，并在整个领域中更系统地应用了 BORO 4D 模式。

层级结构如何从建筑科学中涌现

本体论的深度（最多 10 层）并非人工调整——它遵循建筑科学家所使用的自然分类。EPC 数据模式将供暖系统描述为扁平的文本字段（"Condensing gas boiler with radiators"），但底层领域具有分层结构：

graph TD
    HS[Heating System] --> CH[Central Heating]
    HS --> NC[Non-Central / Room Heating]

    CH --> WET[Wet Central Heating<br/><i>hydronic distribution</i>]
    CH --> WA[Warm Air Central Heating<br/><i>ducted air</i>]
    CH --> EC[Electric Central Heating<br/><i>storage / underfloor</i>]

    WET --> BB[Boiler-Based]
    WET --> HP[Heat Pump]
    WET --> DH[Community / District]

    BB --> CB[Combustion Boiler]
    BB --> CHP[Micro-CHP]

    CB --> GAS["Gas boiler"]
    CB --> OIL["Oil boiler"]
    CB --> LPG["LPG boiler"]
    CB --> COND["Condensing boiler"]
    CB --> COMBI["Combi boiler"]
    CB --> BACK["Back boiler"]

    HP --> ASHP["Air source"]
    HP --> GSHP["Ground source"]
    HP --> WSHP["Water source"]

    EC --> STOR["Storage heaters"]
    EC --> PNL["Panel heaters"]
    EC --> UF["Underfloor electric"]

    NC --> FIX[Fixed Room Heater]
    NC --> PORT[Portable Heater]

    FIX --> GROOM["Gas room heater"]
    FIX --> EROOM["Electric room heater"]
    FIX --> SFROOM["Solid fuel room heater"]

    style HS fill:#1a1a2e,color:#fff
    style CH fill:#16213e,color:#fff
    style NC fill:#16213e,color:#fff
    style WET fill:#0f3460,color:#fff
    style WA fill:#0f3460,color:#fff
    style EC fill:#0f3460,color:#fff
    style BB fill:#533483,color:#fff
    style HP fill:#533483,color:#fff
    style DH fill:#533483,color:#fff
    style CB fill:#e94560,color:#fff
    style CHP fill:#e94560,color:#fff

同样的模式也适用于建筑围护结构——传热物理决定了分组方式：

graph TD
    TE[Building Thermal Envelope] --> OP[Opaque Elements<br/><i>conduction-dominated</i>]
    TE --> TR[Transparent Elements<br/><i>radiation + conduction</i>]

    OP --> WALL[Walls]
    OP --> ROOF[Roofs]
    OP --> FLOOR[Floors]

    TR --> WIN[Windows]
    TR --> DOOR[Doors]

    WALL --> MAS[Masonry Walls<br/><i>thermal mass</i>]
    WALL --> FRM[Framed Walls<br/><i>stud bridges</i>]

    MAS --> CAV["Cavity wall"]
    MAS --> SOL["Solid brick"]
    MAS --> SND["Sandstone"]
    MAS --> GRN["Granite"]
    MAS --> COB["Cob"]

    FRM --> TF["Timber frame"]
    FRM --> SYS["System-built"]
    FRM --> PH["Park home"]

    ROOF --> PIT[Pitched Roof]
    ROOF --> FLT[Flat Roof]

    PIT --> COLD["Cold roof<br/><i>insulation at ceiling</i>"]
    PIT --> WARM["Warm roof<br/><i>insulation at rafter</i>"]
    PIT --> THATCH["Thatched"]

    WIN --> SGL["Single glazed"]
    WIN --> DBL["Double glazed"]
    WIN --> TPL["Triple glazed"]
    WIN --> SEC["Secondary glazing"]

    style TE fill:#1a1a2e,color:#fff
    style OP fill:#16213e,color:#fff
    style TR fill:#16213e,color:#fff
    style WALL fill:#0f3460,color:#fff
    style ROOF fill:#0f3460,color:#fff
    style FLOOR fill:#0f3460,color:#fff
    style WIN fill:#0f3460,color:#fff
    style DOOR fill:#0f3460,color:#fff
    style MAS fill:#533483,color:#fff
    style FRM fill:#533483,color:#fff
    style PIT fill:#533483,color:#fff
    style FLT fill:#533483,color:#fff

树中的每一层都是真实的建筑科学区分——中央供暖与房间供暖、水暖与暖风、燃烧与电加热、砌体与框架、空腔与实心。一位独立的建筑科学家，在给定相同的 EPC 数据值的情况下，会得出这些相同的中间分组（已通过洁净室复现验证）。RDFS 推理以传递方式遍历这些链，这就是为什么一个 10 级层次结构会从 3,229 个原始三元组中生成 662 个推断三元组。

EPC 列覆盖基准测试

两种本体均针对 36 个关键 EPC 数据列进行了测试——每种本体能否接收并表示该列的数据？

查询源自已发布的 DESNZ/ONS EPC 统计报告——而非源自任一本体的类结构。完整基准测试：benchmark/epc/

使用 onto_align 将其映射到其他领域本体：

onto_load benchmark/generated/ies-building-extension.ttl
onto_align <other-ontology.ttl>

层级强制 — 自动化推理改进

hierarchy enforce 包可检测任何本体中的扁平区域，并建议中间分组类。这与用于深化建筑扩展的过程相同——现已固化为可重复使用的工具：

onto_load my-ontology.ttl
onto_enforce --pack hierarchy
# → flags classes with >5 direct children
# → reports max depth, avg depth, hierarchy density

在 IES Common（511 个类）上测试，该工具发现了 24 个平坦点。一个洁净室智能体——没有任何先验上下文——仅基于被标记子类的领域含义，提出了 38 个中间分组类：

graph LR
    subgraph Before["IES Common — before"]
        EP1[EventParticipant] --> P1["Prosecutor"]
        EP1 --> P2["Observer"]
        EP1 --> P3["Driver"]
        EP1 --> P4["Supplier"]
        EP1 --> P5["WeaponLocation"]
        EP1 --> P6["...52 direct children"]
    end

    subgraph After["IES Common — after hierarchy enforce"]
        EP2[EventParticipant] --> R[RoleInEvent]
        EP2 --> L[LocationInEvent]
        EP2 --> A[AssetInEvent]
        R --> LR2[LegalRole]
        R --> IR[InvestigativeRole]
        R --> CR[CommercialRole]
        LR2 --> Q1["Prosecutor"]
        LR2 --> Q2["Signatory"]
        IR --> Q3["Observer"]
        IR --> Q4["Investigator"]
        CR --> Q5["Supplier"]
        CR --> Q6["Negotiator"]
        L --> Q7["WeaponLocation"]
        L --> Q8["TargetLocation"]
        A --> Q9["VehicleUsed"]
    end

    style EP1 fill:#e94560,color:#fff
    style EP2 fill:#1a1a2e,color:#fff
    style R fill:#16213e,color:#fff
    style L fill:#16213e,color:#fff
    style A fill:#16213e,color:#fff
    style LR2 fill:#0f3460,color:#fff
    style IR fill:#0f3460,color:#fff
    style CR fill:#0f3460,color:#fff

同一工具，应用于任何本体，都会产生相同类型的改进。中间类源自领域知识——而非参考任何其他实现。

延伸阅读

工具

按功能组织的 70+ 工具 — 可作为 MCP 工具（前缀为 onto_）和 CLI 子命令使用：

架构

引擎

flowchart TD
    subgraph Clients["Clients"]
        Claude["Claude / LLM\nMCP stdio"]
        CLI["CLI\nonto_* subcommands"]
        Studio["Studio\nHTTP REST"]
    end

    subgraph Server["Open Ontologies Server"]
        direction TB

        subgraph Transport["Transport Layer"]
            MCP_HTTP["MCP Streamable HTTP\n/mcp"]
            REST["REST API\n/api/query · /api/update\n/api/save · /api/load · /api/lineage"]
        end

        subgraph ToolGroups["70+ Tools"]
            direction LR
            Core["Core\nvalidate · load · save · clear\nstats · query · diff · lint\nconvert · status"]
            DataPipe["Data Pipeline\nmap · ingest · shacl\nreason · extend · import-schema"]
            Lifecycle["Lifecycle\nplan · apply · lock · drift\nenforce · monitor · lineage"]
            Advanced["Alignment + Clinical\nalign · crosswalk · enrich\nenrich · embed · search · similarity\ndl_explain · dl_check"]
            Version["Versioning\nversion · history · rollback"]
        end

        subgraph Core2["Core Engine"]
            GraphStore["Oxigraph Triple Store\nRDF/OWL in-memory\nSPARQL 1.1"]
            SQLite["SQLite\nlineage events\nversion snapshots\nlint/enforce feedback\nembedding vectors"]
            Reasoner["OWL2-DL Reasoner\nSHOIQ tableaux\nRDFS · OWL-RL"]
            Embedder["Embedding Engine\ntract-onnx (ONNX)\ntext + Poincaré structural"]
        end
    end

    subgraph External["External Sources"]
        PG["PostgreSQL\nschema import"]
        SPARQL["Remote SPARQL\nendpoints"]
        OWL["OWL URLs\nowl:imports chains"]
        Parquet["Parquet / Arrow\nclinical crosswalks\nICD-10 · SNOMED · MeSH"]
        Files["Files\nCSV · JSON · XML\nYAML · XLSX · Parquet"]
    end

    Claude -->|"MCP stdio"| MCP_HTTP
    CLI -->|"subcommands"| MCP_HTTP
    Studio -->|"sessionless"| REST

    MCP_HTTP --> ToolGroups
    REST --> ToolGroups

    ToolGroups --> GraphStore
    ToolGroups --> SQLite
    ToolGroups --> Reasoner
    ToolGroups --> Embedder

    Reasoner --> GraphStore
    Embedder --> SQLite

    DataPipe --> Files
    Advanced --> Parquet
    Core --> OWL
    Core --> SPARQL
    DataPipe --> PG

工作室

flowchart TD
    subgraph UI["React UI (Vite + Tailwind CSS)"]
        Graph["Virtualized Tree\nDOM + virtual scroll"]
        Chat["AI Chat Panel\nZustand store"]
        Inspector["Property Inspector\nInline SPARQL edit"]
        Lineage["Lineage Panel\nAudit trail"]
        Save["Named Save\n⌘S → ~/.open-ontologies/"]
    end

    subgraph Tauri["Tauri 2 Shell (Rust)"]
        IPC["Tauri IPC\ninvoke / event"]
        ChatState["ChatState\nstdin/stdout pipe"]
    end

    subgraph Engine["Engine Sidecar (Rust / Axum)"]
        MCP["/mcp — MCP Streamable HTTP\nonto_* tools"]
        REST2["/api/query · /api/update\n/api/save · /api/load-turtle\n/api/stats · /api/lineage"]
        Store["Arc<GraphStore>\nOxigraph"]
        DB["SQLite"]
    end

    subgraph Agent["Agent Sidecar (Node.js)"]
        SDK["Claude Opus 4.8\nAgent SDK"]
        Proto["stdin/stdout JSON protocol"]
    end

    Graph -->|"SPARQL SELECT/UPDATE · REST"| REST2
    Inspector -->|"SPARQL UPDATE · REST"| REST2
    Lineage -->|"GET /api/lineage"| REST2
    Save -->|"POST /api/save"| REST2
    Chat -->|"invoke send_chat_message"| IPC
    IPC --> ChatState
    ChatState -->|"stdin { type: chat }"| Proto
    Proto --> SDK
    SDK -->|"MCP tools/call"| MCP
    SDK -->|"stdout { type: text/tool_call/done }"| Proto
    Proto -->|"Tauri emit agent-message"| Chat
    MCP --> Store
    REST2 --> Store
    Store --> DB

###设计决策

技术栈

文档

引用

Open Ontologies 在一篇预印本中有所描述。对齐引擎实现了其中介绍的稳定匹配方法；因果层则基于 CIVeX 的干预验证框架构建。

• Open Ontologies: Tool-Augmented Ontology Engineering with Stable Matching Alignment. Fabio Rovai, 2026. arXiv:2605.09184
• CIVeX: Causal Intervention Verification for Language Agents. Fabio Rovai, 2026. arXiv:2605.09168

@article{rovai2026openontologies,
  title   = {Open Ontologies: Tool-Augmented Ontology Engineering with Stable Matching Alignment},
  author  = {Rovai, Fabio},
  journal = {arXiv preprint arXiv:2605.09184},
  year    = {2026},
  doi     = {10.48550/arXiv.2605.09184},
  url     = {https://arxiv.org/abs/2605.09184}
}

参见 CITATION.cff 获取机器可读的元数据。它驱动了 GitHub 的“引用此仓库”按钮。

维护者

由 The Tesseract Academy (Kampakis and Co Ltd) 维护，这是一家英国的研究与数据科学机构。使用本工具包构建的应用案例研究发表于 Tesseract Foundational Research 计划中。

许可证

MIT