Open Ontologies

Open Ontologies

A Terraforming MCP for Knowledge Graphs

Validate, classify, and govern AI-generated ontologies. Written in Rust. Ships as a single binary.

Quick Start · Studio · Benchmarks · IES · Tools · Architecture · Docs

______________________________________________________________________

开放本体论是 Rust MCP服务器 和 桌面工作室 用于AI原生本体工程。它揭示了 43工具 这让Claude能够使用内存中的Oxigraph三重存储构建、验证、查询、区分、lint、版本、推理、对齐和持久化RDF/OWL本体——具有Terraform风格的生命周期管理、32个标准本体的市场、临床人行横道、语义嵌入和完整的沿袭审计跟踪。

这 工作室 将引擎封装在可视化桌面环境中：具有层次线、面包屑导航和连接资源管理器的虚拟化本体树；AI聊天面板 /build （IES深度）和 /sketch （快速原型）命令；普罗泰格式财产检查员；以及血统观察者。

没有JVM。没有Protégé。

______________________________________________________________________

快速入门（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

来源（Rust 1.85+）：

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

连接到您的MCP客户端

Claude Code

添加 ~/.claude/settings.json:

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

重新启动克劳德代码。这 onto_* 工具现在可用。

Claude Desktop

添加 ~/Library/Application Support/Claude/claude_desktop_config.json:

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

Cursor / Windsurf / any MCP-compatible IDE

添加 .cursor/mcp.json 或同等产品：

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

Docker

{
  "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是一个原生桌面应用程序，它将相同的引擎封装在一个可视化环境中——没有浏览器，也没有服务器需要管理。它完全在您的机器上运行：引擎sidecar处理RDF/OWL操作，而UI实时呈现图形。

把它看作是 Protege与AI副驾驶会面键入“构建关于猫的本体论”，并观察树中出现的1400个类本体论——类、属性、个体和公理，这些本体是在13个流水线步骤中自动构建的。单击任何节点以检查其三元组，通过可点击的药丸跟踪连接，并通过沿袭面板跟踪每一个更改。

为什么是虚拟树（而不是3D图）

在v0.1.12之前，Studio使用D3.js水平树和3D力导向图（Three.js/WebGL）。两者都适用于小型本体（约100个类），但在IES级别的深度上变得不可用：D3树在不进行布局抖动的情况下无法处理500多个节点，3D图将WebKit网络视图冻结在1000个节点以上。

v2深度构建器改变了方程式—— /build 命令现在生成1400多个类。我们用虚拟DOM树替换了这两个视图：DOM中只存在可见的行（无论本体大小如何，都是恒定的内存），具有层次结构连接线、类型过滤图例、搜索、面包屑导航和连接面板。这可以无延迟地处理完整的IES Common（511个类）和深度构建的本体（1400多个类）。

运作原理

工作室启动三个本地通信进程：

1. 金牛座2壳 --带有WebKit网络视图的本机窗口（macOS/Linux/Windows）
2. 发动机侧车 --相同的Rust二进制文件，在上作为HTTP MCP服务器运行 localhost:8080
3. 代理sidecar --通过代理SDK运行Claude的Node.js进程，通过MCP连接到引擎

当你在聊天面板中键入时，你的消息会发送到代理sidecar，后者会将其发送给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分钟）。后续发射将在几秒钟后开始。

特性

键盘快捷键

______________________________________________________________________

基准测试

OntoAxiom——LLM公理识别

OntoAxiom 测试9个本体和3042个基本真理公理的公理识别。

披萨本体论——曼彻斯特教程

一句话输入： *“按照曼彻斯特教程规范构建披萨本体。”*

/sketch vs /build --两种构建模式

Studio为不同的用例提供了两个构建命令。两者都接受相同的输入-- *“构建猫的本体论”* --但产生非常不同的结果：

/sketch 运行3个步骤：类+属性在一个Turtle块中，公理+个体，然后保存。适用于快速领域探索或演示原型。生成一个包含层次结构、属性和个体的完整本体，但深度很小。

/build 在一个持久的Claude会话中运行一个13步的管道：基础类→ 每个分支深化（4遍）→ 填空→ 对象属性（2批）→ 类型属性→ 分离→ 个体→ 原因→ save.每一步都专注于本体的一个方面，在构建前一步的上下文的同时，保持在输出令牌的限制范围内。结果在每个指标上都超过了IES Common。

/sketch 与披萨基准（95个等级，8个属性）相当。 /build 生成IES级别的本体，其深度足以用于生产环境。

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

数据集： UCI蘑菇数据集——由真菌学专家分类的8124个标本。

本体论市场——32种标准本体论

获取了所有32个市场本体， owl:imports 使用RDFS和OWL-RL配置文件进行解析、加载和推理：

加载32/32个本体，解析导入并推理。RDFS增加了18%的三元组。OWL-RL补充道 41% --传递/对称/逆性质和等价类扩展发现了更多的隐式知识。Schema.org在117毫秒内从+4031（RDFS）跳到+13670（OWL-RL）推断的三元组。

推理性能——与HermiT

LUBM缩放（负载+原因循环）

完整的基准测试报告： docs/benchmarks.md

OAEI本体对齐——解剖轨迹

OAEI 是本体对齐系统的标准基准。解剖学轨道将2737个小鼠解剖学类与3304个人体解剖学类与1516个参考映射对齐。

______________________________________________________________________

IES支持

IES（信息交换标准） 是英国国家数字孪生计划的核心本体框架。它使用4D外延主义（BORO）方法对实体、事件、状态和关系进行建模。开放本体论支持 完整的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推理在所有非通用本体中产生了最丰富的推理增益——状态、类实体和事件子类都生成了深度传递链。

示例数据

直接从官方存储库加载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的比较

回购包括 IES大楼扩建 基于英国EPC数据模式和建筑科学基础，使用IES 4D模式构建。它是独立构建的，没有参考任何现有的实现，然后与政府数据管道中使用的NDTP/IRIS生产构建本体进行比较。

从105列EPC模式、SAP方法和BORO 4D扩展主义中盲目构建——对IRIS实现没有任何参考。这两种本体论做出了不同的权衡：IRIS的策划更为严密，平均层次深度更高（2.89比2.02），反映了领域专家的刻意分组。开放本体论涵盖了更多的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
hydronic distribution]
    CH --> WA[Warm Air Central Heating
ducted air]
    CH --> EC[Electric Central Heating
storage / underfloor]

    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
conduction-dominated]
    TE --> TR[Transparent Elements
radiation + conduction]

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

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

    WALL --> MAS[Masonry Walls
thermal mass]
    WALL --> FRM[Framed Walls
stud bridges]

    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
insulation at ceiling"]
    PIT --> WARM["Warm roof
insulation at rafter"]
    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级层次结构从3229个原始数据中生成662个推断出的三元组。

EPC立柱覆盖率基准

这两个本体都针对36个关键的EPC数据列进行了测试——每个本体都能接收和表示来自该列的数据吗？

查询来自已发布的DESNZ/ONS EPC统计报告，而不是来自任何一个本体的类结构。完整基准： 基准/epc/

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

onto_load benchmark/generated/ies-building-extension.ttl
onto_align 

层次强制——自动推理改进

这 hierarchy enforce-pack检测任何本体中的平面点，并建议中间分组类。这与用于深化建筑扩展的过程相同，现在已被编码为可重复的工具：

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

同样的工具，应用于任何本体，都会产生同样的改进。中间类来自领域知识，而不是来自对任何其他实现的引用。

延伸阅读

______________________________________________________________________

工具

43个按功能组织的工具——可用作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["43 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\n43 onto_* 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.6\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

设计决策

______________________________________________________________________

堆栈

______________________________________________________________________

文档

______________________________________________________________________

许可证

麻省理工学院