Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/jbarrasa/goingmeta/llms.txt

Use this file to discover all available pages before exploring further.

Season 3, Episode 2 of Going Meta examines how Neo4j Aura-based AI agents can be made significantly smarter by giving them access to an ontology. Out-of-the-box agents match user queries against literal node labels and property values. Once the agent is ontology-aware it can navigate the class hierarchy — understanding that a query about “musicians” should also surface results typed as Composer or Performer — and provide richer, more semantically coherent answers without any change to the underlying data.

Watch the Recording

Season 3, Episode 2 — November 2025

Session Code

PDF presentation slides
The session40 repository contains only the PDF presentation (Going Meta - Supercharging Neo4j Aura Agents with Ontologies.pdf). No code files are published for this session. The Cypher and context-injection examples shown below are illustrative of the patterns discussed in the recording.

​
The Problem with Literal Matching

A standard Neo4j Aura agent answers questions by generating Cypher from the user’s natural language input. When a user asks “Who are the musicians honored by blue plaques in London?” the generated query typically targets a specific label — for example MATCH (p:Musician). If the graph stores individuals as (:Composer) or (:Performer) rather than (:Musician), the query returns nothing even though the relevant data exists. The root cause is that the agent has no knowledge of subclass relationships. It can only match what it literally sees in the schema, not what the schema implies semantically.

​
Ontology-Guided Agents

The session solution loads the domain ontology into the agent’s context so that the agent:
  1. Understands the class hierarchy (Composer rdfs:subClassOf Musician)
  2. Expands queries to include all relevant subclasses automatically
  3. Generates Cypher that traverses the taxonomy rather than targeting a single label

​
Injecting ontology context

The ontology is serialised to a natural-language summary (using a getNLOntology-style utility — covered in depth in Session 41) and injected into the agent’s system prompt. This gives the LLM the vocabulary and hierarchy it needs to reason about query scope before generating Cypher. A simplified example of the enriched system context looks like: 
### CATEGORIES
- Musician
   - Attributes:
        + name: 
        + birthYear: 
- Composer (subcategory of Musician)
- Performer (subcategory of Musician)

### RELATIONSHIPS:
- HONORED_BY: Relationship that connects entities of type Person to entities of type Plaque
- COMPOSED: Relationship that connects entities of type Composer to entities of type MusicalComposition

​
Cypher expansion pattern

With the ontology in context the agent learns to write queries that match across the hierarchy using IN or by following rdfs__subClassOf relationships stored in the graph by n10s: 
// Ontology-aware: match the target class AND all its subclasses
MATCH (sub:owl__Class)-[:rdfs__subClassOf*0..]->(parent:owl__Class {uri: "http://voc.neo4j.com/blueplaques#Musician"})
WITH collect(split(sub.uri, "#")[1]) AS labels
MATCH (p) WHERE any(lbl IN labels WHERE lbl IN labels(p))
RETURN p.name, p.birthYear
Contrast this with the naive version: 
// Literal match — misses Composer, Performer, etc.
MATCH (p:Musician)
RETURN p.name, p.birthYear
For the ontology hierarchy traversal pattern to work, the ontology must be loaded into Neo4j using n10s (neosemantics). Once loaded, class hierarchy relationships are stored as rdfs__subClassOf edges between owl__Class nodes and can be traversed with standard Cypher path queries.

​
Why This Matters for Aura Agents

Neo4j Aura agents are configured through a declarative interface that specifies available tools, the graph schema, and the system prompt. Enriching the system prompt with ontology knowledge requires no changes to the underlying graph data or Cypher queries — it is purely a context injection concern. The key benefits are:
  • Disambiguation: The ontology makes explicit what the graph schema implies implicitly, reducing hallucination caused by incomplete label coverage
  • Recall improvement: Queries retrieve all semantically relevant results, not just those matching the exact label the LLM guessed
  • Maintainability: Domain knowledge lives in the ontology, not scattered across dozens of query templates
The ontology does not need to be imported into the same Neo4j database as the application data. It can be held in a separate namespace or a dedicated database and queried independently to build the context string passed to the agent at runtime.

​
Key Takeaways

Ontology as Agent Context

Serialise your OWL ontology to a structured natural-language summary and inject it into the agent system prompt to give the LLM domain awareness before it generates Cypher.

Hierarchy-Aware Cypher

Use rdfs__subClassOf traversals stored by n10s to generate queries that cover entire class subtrees rather than single node labels.

No Data Changes Required

The approach enriches the agent layer only — the underlying Neo4j data model and indexes remain unchanged.

Complements GraphRAG

Ontology-aware agents pair naturally with vector-based retrieval, providing structured semantic scope to complement embedding similarity.

Build docs developers (and LLMs) love

Get started for freeTalk to us