OntoBricks turns Databricks tables into a queryable knowledge graph. You design an ontology in OWL, map it to Unity Catalog tables through R2RML, materialise the triples into a triple store, reason over the result with OWL 2 RL inference, SWRL rules, and SHACL validation, and query it through an auto-generated GraphQL API or an interactive graph viewer. The whole pipeline — import metadata, generate an ontology, auto-map, synchronise — can be driven in four steps, with a model proposing the entities, relationships, attributes, and SQL mappings.
It runs as a FastAPI web application, locally or deployed as a Databricks App with a service principal, a SQL warehouse, a Unity Catalog volume, and a Lakebase Postgres database for the domain registry and graph store.
The graph backend is pluggable and chosen per domain. Lakebase Postgres is the default and keeps three objects per domain version — a bulk-data sync table, a companion table for reasoning and cohort writes, and a union view for reads — with bulk ingest either streamed by the application in batches or delegated to a Databricks Lakeflow snapshot pipeline. A Lakehouse backend uses governed Unity Catalog Delta triple tables instead, and a Neo4j backend talks Bolt to Aura or a self-hosted instance. Switching backends after a build requires rebuilding the graph.
Ontology work is versioned and governed. Every domain version carries a DRAFT, IN-REVIEW, or PUBLISHED status, only DRAFT versions are editable, and the external API, GraphQL, and MCP surfaces serve the numeric-latest PUBLISHED version. A DRAFT is edited by one user at a time under a renew-only lease that auto-releases when a session is abandoned, and admins get a registry-wide lock panel with force-unlock. A review layer adds a cross-domain worklist, reviewer sign-off with a per-domain quorum, and an append-only audit trail of every transition.
Agents reach the graph through a companion MCP application, which exposes graph reads plus the Unity Catalog functions bound to an ontology class as getentitycontext and invokeentityaction.
Features
- Ontology design: a visual canvas plus OWL and RDFS import, including FIBO, CDISC, IOF, and HL7 FHIR R4, R4B, and R5
- R2RML mapping: ontology entities mapped to Unity Catalog tables with column-level precision, generated automatically or by hand
- Pluggable graph backends: Lakebase Postgres, Unity Catalog Delta lakehouse tables, or Neo4j over Bolt, selected per domain
- Reasoning: OWL 2 RL inference, SWRL rules, SHACL validation, and constraint checks with per-rule progress
- GraphQL API: an auto-generated schema and playground over the materialised graph
- Graph viewer: two-phase search, configurable traversal depth, right-click neighbour expansion, and cross-domain bridge navigation
- Cluster detection: Louvain, Label Propagation, and Greedy Modularity, client-side for the visible subgraph and server-side for the whole graph
- Cohort discovery: rule-based linkage and compatibility constraints with why and why-not explainers, materialised as triples or Delta tables
- Class actions: Unity Catalog functions bound to an ontology class and invoked on a node from the viewer or over MCP
- Pitfalls detector: 19 structural, logical, and semantic checks (P1.1–P4.7) over the ontology
- Versioning and review: DRAFT, IN-REVIEW, and PUBLISHED lifecycle, single-editor leases, sign-off quorum, and an append-only audit trail
- Registry transfer: portable .obx export and import from the UI, or a scripted registry transfer for promotion pipelines
