ontology-engineering

Ontology Engineering Workflow

You have access to the Open Ontologies MCP server, which provides 50+ tools for AI-native ontology engineering backed by an in-memory Oxigraph triple store.

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 -- you know OWL, RDF, BORO, 4D modeling natively

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. For repos that mount a folder of .ttl files via [general] ontology_dirs, prefer onto_repo_load so the same compile-cache / TTL-eviction path is exercised. Use onto_repo_list to discover candidate files.
• 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

Cache and Multi-Ontology Loading

The server keeps a single active ontology in memory plus an on-disk N-Triples compile cache for everything it has parsed. Switch between several ontologies without paying re-parse costs:

• onto_repo_list — enumerate .ttl / .owl / .nt / .rdf / .nq / .trig / .jsonld files configured under [general] ontology_dirs. Container-friendly: mount a host folder of TTL files and discover them at runtime without hardcoded paths.
• onto_repo_load — load by bare file stem, relative path, or absolute path inside a configured repo dir. Reuses the same compile-cache / TTL-eviction path as onto_load.
• onto_cache_status / onto_cache_list — inspect what is cached, what is currently active, and the effective [cache] configuration (TTL, auto_refresh, dir).
• onto_cache_remove — drop a cached entry by name (pass delete_file=false to keep the on-disk N-Triples for a later reload).
• onto_unload — drop the active ontology (or a specific cached entry by name) from memory; the on-disk cache is preserved unless delete_cache=true.
• onto_recompile — force a re-parse from source, ignoring the cache. Without name, recompiles the active ontology and reloads it; with name, rebuilds a non-active entry without disturbing the active in-memory store.