OntologyRAG is TrustGraph's ontology-guided knowledge extraction approach paired with graph retrieval. It uses domain-defined types and relationships to structure information from documents, then retrieves connected knowledge to answer questions.

How does TrustGraph use an ontology during ingestion?

TrustGraph selects the relevant portion of an imported ontology for each document chunk, then uses its classes and properties to guide extraction of entities and relationships into a knowledge graph.

How does OntologyRAG answer a natural-language question?

TrustGraph identifies key concepts in the question, uses semantic similarity to find graph entry points, traverses related knowledge, reranks relevant relationships, and supplies a focused subgraph to the LLM for answer generation.

Does OntologyRAG require me to write Cypher queries?

No. TrustGraph provides a native natural-language Graph RAG query path for ontology-extracted knowledge. In a graph application built around Cypher, teams typically write query patterns or build and maintain a natural-language-to-query retrieval layer themselves.

Is OntologyRAG the same as importing an ontology into a graph database?

No. Importing definitions gives a graph a vocabulary. OntologyRAG also uses relevant definitions during document extraction and provides a retrieval path from a question to connected, source-linked facts.

Can OntologyRAG guarantee a correct answer?

No. An ontology can improve consistency, but source documents and extracted facts can be wrong or incomplete, and an LLM can still make mistakes. TrustGraph's explainability helps you inspect retrieved relationships and trace them to documents.

When should I use OntologyRAG instead of simpler RAG?

Use it when domain types and relationships matter, answers span multiple documents, or specialist knowledge requires consistent extraction. For a small collection where matching text is enough, Document RAG may be simpler.

What is OntologyRAG?

A graph database can answer a precise question when someone knows which nodes and relationships to match. But people do not usually ask in graph patterns. They ask things like, “Which intelligence resources were used during this operation?” To answer, a system must locate the right entities, follow the relevant relationships, select evidence, and explain where it came from. Requiring an engineer to handcraft a retrieval pattern for every variation of that question does not scale.

OntologyRAG is TrustGraph's way to connect those steps. It uses an ontology to guide what gets extracted from documents, then uses graph retrieval to find and assemble relevant knowledge for a natural-language question. The ontology shapes the knowledge that enters the graph; the retrieval system finds useful paths through that knowledge when the question arrives.

Ontology-guided ingestion

An ontology defines the types and relationships that matter to a domain. In the SOSA/SSN example, those include sensors, observations, features of interest, and results. A reading is not merely a sentence containing a temperature; it can be represented as an observation linked to what was measured, the sensor involved, and the result.

TrustGraph's OntologyRAG flow works through a document in stages:

It splits the document into chunks.
It selects the relevant portion of the loaded ontology for each chunk, rather than putting the entire ontology into every extraction prompt.
It uses those definitions to guide extraction of entities and relationships.
It embeds entities for semantic discovery and stores their relationships in a knowledge graph.

That per-chunk ontology retrieval matters when the domain model grows. A document about a sensor reading does not need every class in a broad technical ontology in the model's context. The relevant terms give extraction a narrower target while preserving the wider ontology for other documents.

You can import a standard OWL ontology through the TrustGraph Workbench Ontology Editor or create and refine one there. The editor converts imported OWL into TrustGraph's internal JSON ontology representation; the configuration CLI uses that native JSON format, not a raw OWL/Turtle file. Clear labels on ontology terms help the extraction process use them effectively.

Retrieval without a hand-built path

At question time, TrustGraph's graph retrieval identifies concepts in the question, finds candidate entities by semantic similarity, explores their graph relationships, and reranks discovered relationships. It then uses a focused subgraph to generate an answer. TrustGraph describes its explainability events as grounding, exploration, focus, and synthesis; the focus stage can be inspected to trace selected graph edges back to source documents.

This is different from embedding a document, retrieving a nearby chunk, and asking an LLM to work out the relationships unaided. The ontology has already helped define the entity and relationship types in the graph. Retrieval can then follow connections among extracted facts, including connections that bring together information from separate documents.

It is also different from writing a fixed query for each possible request. A fixed pattern is excellent when the question and graph structure are known. A natural-language retrieval system must additionally decide which entities to start from and which relationships are relevant for this particular question. TrustGraph provides that discovery-and-traversal workflow natively for ontology-extracted knowledge.

The manual-retrieval alternative

Consider an application built on a graph system where the team writes its own retrieval layer. The team must decide how to model documents as graph entities, extract and reconcile instances, identify a user's intent, map that intent to graph labels and edge types, choose traversal depth and filters, limit irrelevant paths, pass selected evidence to an LLM, and retain a source trail. A graph query language can execute the resulting pattern efficiently, but it does not by itself perform all those application-level decisions.

Retrieval task	Manually assembled graph application	TrustGraph OntologyRAG
Define domain meaning	Model labels, relationships, and extraction rules for the application.	Import or build an ontology whose types and properties guide extraction.
Process documents	Build or integrate a document-to-graph extraction pipeline.	Use the ontology flow to chunk documents and extract ontology-guided entities and relationships.
Choose starting points	Write query templates, entity linking, or natural-language-to-query logic.	Find graph entry points from question concepts using semantic similarity.
Select useful paths	Maintain traversal patterns, filters, and relevance logic.	Traverse related knowledge and rerank relationships to build a focused subgraph.
Explain the answer	Implement links between retrieved graph facts and source material.	Inspect retrieval events and trace focused graph edges to source documents.

This is a comparison of integrated workflows, not a claim that other graph databases cannot hold ontologies or support natural-language applications. They can, with suitable extensions and engineering. Nor does OntologyRAG eliminate the need to design a useful ontology, test extraction quality, or evaluate the answers your users receive.

Where it earns its keep

OntologyRAG is especially useful when answers depend on relationships across documents, domain terminology has specific meanings, and consistent extraction matters more than the quickest setup. Think of a maritime intelligence report connecting a vessel, an operation, an observation, and a resource used to investigate it. A question about that resource may require following several relationships rather than finding one sentence with matching words. TrustGraph's guide uses a maritime report to demonstrate exactly this kind of query and shows how to inspect the retrieval path.

There are costs. Defining the ontology takes effort, and ontology-guided extraction consumes LLM time and tokens during ingestion; large collections may take substantial time to process. If simple text retrieval answers the question, TrustGraph's Document RAG may be a better starting point. If you need graph relationships but do not yet have a useful ontology, its schema-free Graph RAG may be more appropriate.

The practical test is not whether the graph looks richly connected. Ask whether it retrieves the right evidence for real questions, whether the extracted relationships are correct, and whether a person can trace a consequential answer to its sources. OntologyRAG makes that workflow native to TrustGraph instead of leaving every retrieval pattern and evidence trail to be built by hand.

What is OntologyRAG?

Ontology-guided ingestion

Retrieval without a hand-built path

The manual-retrieval alternative

Where it earns its keep

Related Guides

Resources