Query grounding without a hand-maintained ontology.
An ontology is a shared vocabulary of types and relationships — the kind of thing teams normally write once in a doc and let go stale. Ontology-aware querying gets the same benefit (an agent knows what it can validly ask) from a live schema that reflects the data as it actually is right now, not as it was documented six months ago.
Ontology-aware querying is the practice of grounding an AI agent’s queries in a live, inspectable schema of real labels, properties, and relationship paths, so the agent constructs valid queries from current structure instead of a static, hand-maintained ontology document.
What this guide covers
The practical decision points.
The problem with static ontologies
A written data dictionary or ontology doc drifts from reality the moment the schema changes and nobody updates the doc.
The live-schema alternative
Read the current labels, property types, value ranges, and relationship directions directly from the data, on demand.
What this buys an agent
Fewer hallucinated field names, fewer impossible relationship traversals, and filters that stay inside real value ranges.
Architecture sketch
Schema as the ontology source
Instead of consulting a static doc, the agent calls a schema endpoint at the start of a session and plans its next query from that live snapshot.
Implementation example
Load schema before building a query
The Markdown schema output is designed for LLM context injection — compact enough to load every session without spending much context budget.
from rushdb import RushDB
db = RushDB("RUSHDB_API_KEY")
schema = db.ai.get_schema_markdown({
"labels": ["ORDER", "CUSTOMER", "PRODUCT"],
}).data
# The agent plans its next query using only fields, values, and relationship
# directions that actually appear in this schema output.
print(schema)What a live schema call returns
The Schema API returns exactly what an agent needs to plan a valid query: which labels exist, what properties each carries, sample values or numeric/datetime ranges, which relationships connect labels and in which direction, and whether a vector index is ready for semantic search.
Grounding filters in real ranges
Beyond field names, the schema exposes the actual numeric and datetime ranges and sample values present in the data — so an agent building a filter for "orders over $500" can check that $500 is a realistic threshold for the current dataset before running the query, not after getting an empty result.
Decision table
Static ontology vs live schema
Both approaches try to give an agent a shared vocabulary. They differ in how that vocabulary stays accurate as data changes.
A document someone wrote and must remember to update.
The current project data itself, read on demand.
High — schema changes and doc updates are two separate, easy-to-desync steps.
Low — the schema call reflects whatever fields and relationships exist right now.
Whatever the author thought to document — often missing value ranges or relationship directions.
Labels, property types, sample values or ranges, relationship directions, and vector-index status.
A recurring documentation task with no enforcement mechanism.
None — it is a query against live data, not a document to maintain.
Related RushDB docs
Read the primitives behind the guide.
These docs links are the implementation references for the concepts explained on this page.