Skip to main content

​
Knowledge Graph

Beta The Knowledge Graph is everything in OpenMetadata — every table, column, dashboard, pipeline, ML model, glossary term, tag, owner, test case, data product, and lineage edge — represented as one connected RDF graph, addressable by stable IRIs and queryable with SPARQL. The ontology is the schema. The knowledge graph is the schema plus every instance.

​
Why a Graph, on Top of Everything Else

OpenMetadata already has a relational database (source of truth), a search index (discovery), and a lineage store. The graph is not a replacement for any of them. It exists because a specific class of question is awkward or impossible in the others: A graph answers all of those with the same query language and no per-question schema work.

​
What Is in the Graph

​
Named Graphs

The dataset is partitioned so schema, shapes, instances, and inferences never contaminate one another: Because inferred triples live in their own graphs, “what did a rule derive?” and “what did a human assert?” are always separable — and you can drop and rebuild inferences without touching asserted data.

​
Identity

Every entity gets a stable IRI:
With RDF_DEREFERENCEABLE_IRIS=true, those IRIs resolve: GET /api/v1/lod/entity/{entityType}/{id} performs authenticated, content-negotiated redirection so a linked-data client can follow them. That turns your catalog into a proper Linked Open Data endpoint — inside your perimeter, behind your auth.

​
Vocabulary

The om: ontology (https://open-metadata.org/ontology/) declares roughly 80 classes and 200 properties covering services, databases, schemas, tables, columns, stored procedures, queries, dashboards, charts, reports, metrics, pipelines, tasks, topics, ML models, containers, search indexes, API collections and endpoints, directories, files, spreadsheets, worksheets, LLM models, AI applications, MCP servers, agent executions, prompt templates, glossaries and terms, classifications and tags, data contracts, data products, domains, teams, users, bots, roles, policies, test definitions and cases, threads and posts. It is not a private vocabulary. It aligns with DCAT (om:DataAsset owl:equivalentClass dcat:Dataset), PROV-O for derivation, SKOS for concept schemes, Dublin Core Terms, DQV for quality, FOAF, ODRL, and CSVW — so a DCAT-aware or PROV-aware consumer can read your catalog without a custom adapter. Key relationships include om:belongsToSchema, om:belongsToDatabase, om:belongsToService, om:hasColumn, om:hasTag, om:hasGlossaryTerm, om:hasOwner, om:upstream / om:downstream, prov:wasDerivedFrom, om:testedBy, om:appliedTo, and the full set of typed glossary relations.

​
How It Stays Current

  • Incremental: entity create, update, and delete write through to the triple store, the same way they write through to the search index.
  • Bulk: the RDF Knowledge Graph Indexing application (RdfIndexApp) performs the initial and any full rebuild, with distributed partitioning across servers.
  • Inference: the RDF inference application materializes rule-derived triples into their own named graphs on a schedule.
GET /api/v1/rdf/status reports projectionState as DISABLED, READY, REBUILDING, or DEGRADED — the honest answer to “can I trust what this graph tells me right now.”
The knowledge graph is a derived index, not a source of truth. It can always be rebuilt from the relational database. Never treat a SPARQL UPDATE against it as a way to change your catalog — the next reindex will discard it. Write through the entity APIs.

​
What You Can Do with It

Explore in 3D

The Knowledge Graph tab on a table — asset, product, and domain levels, technical and ontology lenses.

Query with SPARQL

Named graphs, the vocabulary, limits, and a cookbook of real queries.

Reason & validate

Inference levels, materialized rules, and SHACL validation.

Graph insights

PageRank importance, Louvain communities, shortest paths, recommendations.

Give it to an agent

Five MCP tools that let an assistant traverse the graph directly.

API reference

Every endpoint under /api/v1/rdf.

​
Why This Matters for AI Agents

An LLM agent working against a Context Platform has three ways to find things, and they are not equally good:
  1. Keyword search — fast, brittle. revenue returns fourteen tables and no way to choose.
  2. Semantic search — better recall on vague questions, but similarity is not authority. The most semantically similar table is not necessarily the governed one.
  3. Graph traversal — exact. “Follow om:hasGlossaryTerm to Recognized Revenue, then om:appliedTo back to assets, filtered to Tier 1” returns a set, not a guess.
The third only exists if the graph exists. OpenMetadata exposes it to agents through MCP tools — sparql_query, entity_neighborhood, find_by_tag, shacl_validate, and ontology_describe — with ontology_describe acting as the schema-discovery call so an agent can learn the vocabulary before querying it, rather than hallucinating predicate names. A second, subtler benefit: a graph answer is verifiable. When an agent says “these six dashboards depend on this column,” it can hand you the query and the triples. When it says it from memory, you have no way to check. Grounding agents in a graph converts a trust problem into an auditing problem. See Ontology & Knowledge Graph for AI Agents.

​
Getting It Running

1

Deploy a triple store

Apache Jena Fuseki, reachable from the OpenMetadata server and the migrations container.
2

Enable RDF

Set RDF_ENABLED=true and the endpoint/credential variables on both containers.
3

Run the initial index

Trigger RDF Knowledge Graph Indexing from Settings → Applications, during a low-traffic window.
4

Verify

GET /api/v1/rdf/status should report enabled: true and projectionState: READY.
Full instructions: Enabling Ontology & Knowledge Graph and Enable RDF (Deployment).