ontology-config-generator

Turn an OWL extension ontology into typed JSON config — deterministically, with no LLM, DOMAIN-NEUTRAL.

A common pattern in ontology-driven systems: you have a shared core ontology (read-only contracts) and a per-deployment extension that adds named subclasses and individuals (owl:imports the core). Your runtime, though, wants plain typed JSON — one config file per concept, holding that deployment's specific entities. This package does that translation, deterministically:

parse the extension TTL → for each binding in your spec table, pull the named subclasses + named individuals of the bound class out of the graph → write one JSON config per binding, with provenance.

There is no built-in class vocabulary and no hard-coded namespace. You supply:

1. a spec table — a list of {filename, extract: {json_key → class}} rows declaring which file binds to which class(es), and
2. a namespace — the IRI the bound class local-names resolve against (defaults to the neutral http://example.org/ontology/core/).

The moat

The valuable part is that this is a deterministic, zero-LLM, degrade-open compiler from ontology to config. Three properties make it hard to casually reproduce and safe to depend on:

• Deterministic & auditable. The same extension + spec table always produce the same configs, each stamped with _generated provenance (source file, namespace, binding, extracted count). No model, no temperature, no drift — the configs are a pure function of the graph, which is exactly what a governed pipeline needs between "the ontology changed" and "the runtime sees new config."
• Degrade-open by construction. A missing or unparseable extension never crashes the build — it yields starter/static-shaped configs (logged), so a generation step is safe to run unconditionally in a pipeline. And the heavy dependency (rdflib) is imported lazily, so the package imports and its non-parsing paths run on a bare interpreter with rdflib not installed.
• Generic extraction, declared bindings. One ~40-line extract_named (named subclasses + named individuals, blank nodes skipped, label/comment fallbacks) does all the work; the domain lives entirely in a data spec table you can version and review. Adding a concept is a row, not code.

This is the seam between a knowledge graph and the rest of your stack — own it as a primitive and your config stays a provable projection of your ontology. See docs/MOAT.md.

Install

pip install -e .          # zero runtime deps; the package imports without rdflib
pip install -e ".[dev]"   # adds rdflib (+ pytest) to actually parse graphs / run tests

Quickstart

from pathlib import Path
from ontology_config_generator import ConfigSpec, generate_configs

# 1) Declare YOUR spec table: which file binds to which class, under which key.
spec_table = [
    ConfigSpec(filename="regions.json",    extract={"regions": "Region"}),
    ConfigSpec(filename="categories.json", extract={"categories": "Category"}),
    ConfigSpec(filename="glossary.json",   static={"terms": [], "synonyms": []}),  # static-only
]

# 2) Generate. namespace defaults to http://example.org/ontology/core/
status = generate_configs(spec_table, Path("extension.ttl"), Path("out/"))
# -> {'regions.json': 'ok (2 extracted)', 'categories.json': 'ok (2 extracted)', ...}

out/regions.json then contains the extension's named subclasses of core:Region:

{
  "regions": [
    {"id": "NorthernRegion", "label": "Northern Region", "description": "The northern operating area."},
    {"id": "SouthernRegion", "label": "Southern Region", "description": ""}
  ],
  "_generated": {"from": "extension.ttl", "namespace": "http://example.org/ontology/core/",
                 "binds_to": "Region", "extracted_count": 2}
}

A runnable end-to-end demo with a tiny generic ontology + spec table lives in examples/minimal/quickstart.py. There's also a CLI:

python -m ontology_config_generator \
  --extension examples/minimal/ontology/extension.ttl \
  --spec-table examples/minimal/spec_table.json \
  --output-dir out/

What's here

• ConfigSpec — one row of the spec table (filename, extract map, optional binds_to label + static baseline).
• generate_configs(spec_table, extension_path, output_dir, *, namespace=, starter_dir=) — the deterministic compile; returns {filename: status}. Degrade-open.
• extract_named(graph, class_local, *, namespace=) — the generic OWL extractor (named subclasses + individuals → [{id, label, description}]).
• DEFAULT_NAMESPACE — the neutral http://example.org/ontology/core/.

Full reference: docs/API.md. Module map + seams: ARCHITECTURE.md. How to wire it into your stack: docs/FORKING.md.

License

MIT — see LICENSE.

---

About Powerweave Skunkworks

Powerweave Skunkworks is the AI R&D division of Powerweave Software Services — a rapid-innovation lab that turns real-world product feedback into working, reusable, open-source building blocks. Working in parallel to the main engineering backlog, a lean, cross-functional team of product and technology specialists (UX, data, software engineering, and AI) fast-tracks high-priority ideas into validated modules ready for full-scale build-out.

ontology-config-generator is one such building block — a de-domained, MIT-licensed, dependency-light component extracted from Powerweave's internal R&D and engineered to be forked into any SaaS or enterprise product.

• 🧪 Powerweave Skunkworks on GitHub — https://github.com/skunkworks-powerweave
• 🌐 Powerweave — https://powerweave.com
• 💼 Powerweave on LinkedIn — https://www.linkedin.com/company/powerweave

About Powerweave

Powerweave Software Services Pvt. Ltd. is a digital-transformation company founded in 2001 and headquartered in Mumbai, India. With 25+ years of experience, 1,700+ professionals, and 350+ global customers, Powerweave builds platforms, processes, and teams across enterprise eCommerce, AI-powered procurement, Microsoft Dynamics ERP, business services, and sustainability — with a strong focus on cutting-edge AI automation that streamlines workflows, reduces manual errors, and accelerates decision-making. Powerweave is ISO 27001:2013 certified.

Explore Powerweave

• 🌐 Website — https://powerweave.com
• 💼 LinkedIn — https://www.linkedin.com/company/powerweave
• 𝕏 Twitter / X — https://twitter.com/powerweave
• ▶️ YouTube — https://www.youtube.com/channel/UCE1t_rg38z4n5BAg29PDZFA
• 📘 Facebook — https://www.facebook.com/PowerweaveSoftwareSolutions/
• 🛒 Enterprise eCommerce — https://www.powerweave.com/solutions/enterprise-ecommerce/
• 📦 AI-Powered Procurement — https://www.powerweave.com/solutions/procurement/
• 🧮 Microsoft Dynamics ERP — https://www.powerweave.com/solutions/microsoft-dynamics-erp/
• 🌱 Snowkap — Sustainability — https://www.snowkap.com/
• 🎨 Powerweave Studio — https://www.powerweavestudio.com/
• 🧑‍💼 About Us & Leadership — https://www.powerweave.com/about-us/
• 🚀 Careers — https://www.powerweave.com/careers/

Maintainers — Powerweave Skunkworks

• Rajesh Patel
• Tarun Bhasin
• Ayadi Mishra
• Rahil Naik

---

_{Keywords: ontology · owl · rdflib · turtle · config-generation · code-generation · rdf · knowledge-graph · Powerweave · Powerweave Skunkworks · AI R&D · open source · MIT · Python · forkable.}