name: open-ontologies version: "0.5.1" description: > AI-native ontology engineering using 50+ MCP tools backed by an in-memory Oxigraph triple store. Build, validate, query, and govern RDF/OWL ontologies with a generate-validate-iterate loop. Use when building ontologies, knowledge graphs, RDF data, SPARQL queries, BORO/4D modeling, SHACL validation, clinical terminology mapping, ingesting from CSV/JSON/Parquet/XLSX or SQL backbones (PostgreSQL, DuckDB), or Terraform-style ontology lifecycle management. tags:

• ontology
• rdf
• owl
• sparql
• knowledge-graph
• semantic-web
• mcp
• oxigraph
• shacl
• boro metadata: openclaw: requires: mcp: - name: open-ontologies description: > Oxigraph-backed MCP server providing all onto_* tools. Install: cargo install open-ontologies OR download binary from https://github.com/fabio-rovai/open-ontologies/releases config: command: open-ontologies args: ["serve"] bins: - open-ontologies network:
  • description: "onto_pull fetches ontologies from remote URLs or SPARQL endpoints (user-provided URLs only)" direction: outbound optional: true
  • description: "onto_push sends triples to a user-specified SPARQL endpoint" direction: outbound optional: true notes: > All processing is local by default. The in-memory Oxigraph triple store runs inside the MCP server process -- no database, no JVM, no external services required. Network access is only used by onto_pull and onto_push when the user explicitly provides a remote URL or SPARQL endpoint. onto_monitor alerts are logged locally to stdout; no external notification services are contacted. No credentials or API keys are needed for core functionality.

Open Ontologies

AI-native ontology engineering. Generate OWL/RDF directly, validate with MCP tools, iterate until clean, govern with a Terraform-style lifecycle.

Prerequisites

This skill requires the Open Ontologies MCP server to provide the onto_* tools.

Install: cargo install open-ontologies or download from GitHub releases

MCP config (add to .mcp.json or Claude settings):

{
  "mcpServers": {
    "open-ontologies": {
      "command": "open-ontologies",
      "args": ["serve"]
    }
  }
}

No credentials needed. All processing runs locally in an in-memory Oxigraph triple store. Network access is only used when you explicitly call onto_pull (fetch remote ontology) or onto_push (send to SPARQL endpoint) with a URL you provide. Monitor alerts (onto_monitor) are logged to stdout only.

Core Workflow

When building or modifying ontologies, follow this workflow. Decide which tools to call and in what order based on results -- this is not a fixed pipeline.

1. Generate

• Understand the domain requirements (natural language, competency questions, methodology constraints)
• Generate Turtle/OWL directly -- Claude knows OWL, RDF, BORO, 4D modeling natively
• For complex methodologies, ask for background documents or constraints

2. Validate and Load

• Call onto_validate on the generated Turtle -- if it fails, fix syntax errors and re-validate
• Call onto_load to load into the Oxigraph triple store
• Call onto_stats to verify class count, property count, triple count match expectations

3. Verify

• Call onto_lint to check for missing labels, comments, domains, ranges -- fix any issues found
• Call onto_query with SPARQL to verify structure (expected classes, subclass hierarchies, competency questions)
• If a reference ontology exists, call onto_diff to compare

4. Iterate

• If any step reveals problems, fix the Turtle and restart from step 2
• Continue until validation passes, stats match, lint is clean, and SPARQL queries return expected results

5. Persist

• Call onto_save to write the final ontology to a .ttl file
• Call onto_version to save a named snapshot for rollback

Ontology Lifecycle (Terraform-style)

For evolving ontologies in production:

1. Plan -- onto_plan shows added/removed classes, blast radius, risk score. Check onto_lock for protected IRIs.
2. Enforce -- onto_enforce with a rule pack (generic, boro, value_partition) checks design pattern compliance.
3. Apply -- onto_apply with mode safe (clear + reload) or migrate (add owl:equivalentClass bridges).
4. Monitor -- onto_monitor runs SPARQL watchers with threshold alerts. Use onto_monitor_clear if blocked.
5. Drift -- onto_drift compares versions with rename detection and self-calibrating confidence.

Data Extension Workflow

When applying an ontology to external data:

1. onto_map -- generate mapping config from data schema + loaded ontology
2. onto_ingest -- parse structured data (CSV, JSON, NDJSON, XML, YAML, XLSX, Parquet) into RDF
3. onto_shacl -- validate against SHACL shapes (cardinality, datatypes, classes)
4. onto_reason -- run RDFS or OWL-RL inference, materializing inferred triples
5. Or use onto_extend to run the full pipeline: ingest, SHACL validate, reason in one call

Clinical Terminology Support

For healthcare ontologies:

• onto_crosswalk -- look up mappings between ICD-10, SNOMED CT, and MeSH
• onto_enrich -- add skos:exactMatch triples linking classes to clinical codes
• onto_validate_clinical -- check class labels against clinical crosswalk terminology

Ontology Alignment

For aligning two ontologies:

• onto_align -- detect alignment candidates (equivalentClass, exactMatch, subClassOf) using 6 weighted signals
• onto_align_feedback -- accept/reject candidates to self-calibrate confidence weights

Tool Reference

Usage Examples

Build a pizza ontology from scratch

Build me a pizza ontology with classes for Pizza, PizzaBase (ThinAndCrispy, DeepPan),
PizzaTopping (Mozzarella, Tomato, Pepperoni, Mushroom), and properties hasBase, hasTopping.
Include rdfs:labels and rdfs:comments on everything. Validate and run competency queries
to check I can ask "what toppings does a Margherita have?"

Load and query an existing ontology

Load the ontology from https://www.w3.org/TR/owl-guide/wine.rdf, show me stats,
lint it, and run a SPARQL query to find all subclasses of Wine.

Evolve an ontology safely

I need to add a new class "GlutenFreePizza" as a subclass of Pizza with a restriction
that hasBase only GlutenFreeBase. Plan the change, enforce against generic rules,
and apply in safe mode.

Ingest CSV data into a knowledge graph

I have a CSV of employees with columns: name, department, role, start_date.
Map it to the loaded HR ontology and ingest it. Then validate with SHACL shapes
and run inference to materialize department hierarchies.

Align two ontologies

Load schema.org and my company ontology. Run onto_align to find equivalentClass
and exactMatch candidates. I'll review and give feedback to calibrate the weights.

Key Principle

Dynamically decide the next tool call based on what the previous tool returned. If onto_validate fails, fix and retry. If onto_stats shows wrong counts, regenerate. If onto_lint finds missing labels, add them. The MCP tools are individual operations -- Claude is the orchestrator.

Open Ontologies is a Rust MCP server and desktop Studio for AI-native ontology engineering. It exposes 70+ tools that let Claude build, validate, query, diff, lint, version, reason over, align, plan, certify, and govern RDF/OWL ontologies using an in-memory Oxigraph triple store — with a full three-layer Dynamics → Causal → Planner architecture, a marketplace of 32 standard ontologies, clinical crosswalks, semantic embeddings, and a full lineage audit trail.

The Studio wraps the engine in a visual desktop environment: virtualized ontology tree with hierarchy lines, breadcrumb navigation, and connection explorer; AI chat panel with /build (IES-level deep) and /sketch (quick prototype) commands; Protégé-style property inspector; and lineage viewer.

No JVM. No Protégé.

What's New (three-layer architecture + 13 new primitives)

The full Dynamics → Causal → Planner stack plus 13 new primitives. Every piece holds the MCP-native convention: the server provides validation and scaffolding, the connected LLM (Claude over MCP) does the intelligence. No internal LLM clients, no API keys, no provider abstractions.

Three-layer architecture

13 new primitives

• onto_owl_shacl_coevolve_check + onto_owl_shacl_coevolve_incremental — SHACL validation against the OWL-RL closure, with dependency-graph routing so only shapes touching changed IRIs revalidate.
• onto_segment_retrieve — TBox-slice retrieval for ontology-grounded RAG.
• onto_extract_scaffold + onto_extract_validate — schema-guided structured extraction with typed datatype validation + conformance scoring.
• onto_cq_run + onto_verify_cq + onto_cq_verdicts_list — competency-question runner with pitfall hints + LLM-judgement loop.
• onto_classify_el — OWL-EL classification (transitive subsumption table, trivial pairs excluded).
• onto_eval_alignment — P/R/F1 over reference + computed alignment sets.
• onto_shape_combinatorics + onto_shape_induce — property-combination lattice + data-driven SHACL shape induction with support × confidence ranking.
• borderline_partition + borderline_record_verdict — generalised two-threshold review loop for any candidate set.
• onto_align_fuzzy — embedding-free fuzzy-logic adjudication with 10-rule Mamdani inference; HNSW is demoted to a candidate generator.
• onto_align_flora — end-to-end alignment pipeline pairing the signal extractor to the fuzzy adjudicator.
• onto_policy_register + onto_policy_list + onto_policy_check — authorisation gate that composes with onto_certify_action (Causal = risk; policy = authorisation).
• eval_rag + eval_rag_mmrag — Hit@k / MRR / faithfulness / token-Jaccard / ROUGE-1 scoring for retriever pipelines, with a dataset adapter.
• graph_projection_lossy_check — the auditor that pairs with onto_segment_retrieve.

Validating end-to-end

cargo run --example three_layer_pipeline

Walks Dynamics register → PDDL compile → Fast-Downward-shaped sas_plan parse → orchestrator-side IRI bind → sandbox validate → CIVeX certify → apply with OWL-RL ramification → final state inspection. Every layer through its public API, no external dependencies (Python, DoWhy, Fast Downward) required.

Zero new external Rust dependencies; everything optional gates behind Cargo features. Full test suite (160+ tests) green on default build; cargo clippy --lib --tests --examples -- -D warnings clean across both default and causal-pywhy configurations.

Quick Start (MCP / CLI)

Install

Pre-built binaries:

# 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

From source (Rust 1.85+):

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

For native Windows builds, see docs/windows.md.

Connect to your MCP client

Add to ~/.claude/settings.json:

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

Restart Claude Code. The onto_* tools are now available.

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

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

Add to .cursor/mcp.json or equivalent:

{
  "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 your first ontology

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 generates Turtle, then runs the full pipeline automatically:

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

Every build includes OWL reasoning (materializes inferred triples), design pattern enforcement, and automatic versioning.

Studio (Desktop App)

The Studio is a native desktop application that wraps the same engine in a visual environment — no browser, no server to manage. It runs entirely on your machine: the engine sidecar handles RDF/OWL operations while the UI renders the graph in real time.

Think of it as Protege meets an AI copilot. Type "build ontology about cats" and watch a 1,400-class ontology appear in the tree — classes, properties, individuals, and axioms built automatically across 13 pipeline steps. Click any node to inspect its triples, trace connections via clickable pills, and follow every change through the lineage panel.

Why virtualized tree (not 3D graph)

Prior to v0.1.12, the Studio used a D3.js horizontal tree and a 3D force-directed graph (Three.js / WebGL). Both worked for small ontologies (~100 classes) but became unusable at IES-level depth: the D3 tree couldn't handle 500+ nodes without layout thrashing, and the 3D graph froze the WebKit webview above 1,000 n