Sponsored by: Stardog | Implementing Agentic AI on Databricks with an Ontology-Driven Semantic Layer

Summary

Ontologies are structured, shareable representations of business concepts and relationships that give LLM-based agents the enterprise context they need to reason autonomously across domains.
Stardog's zero-copy architecture maps an ontology directly to data wherever it lives in Delta Lake or Unity Catalog, without requiring data movement or restructuring.
This video demonstrates cross-domain use cases—supply chain, drug discovery, and compliance—where natural-language queries return deterministic, explainable answers grounded in business logic.

Chapters

FAQs

What is an ontology and why does it matter for AI agents?

An ontology is a structured, shareable representation of business concepts, relationships, and logic that humans and machines can reason over together. For AI agents, ontologies provide the contextual grounding needed to operate autonomously across complex enterprise domains without being tied to specific tables or storage systems.

How does Stardog's zero-copy architecture work with Delta Lake and Unity Catalog?

Stardog maps an ontology directly to data wherever it lives—in Delta Lake, Unity Catalog, or other sources—without requiring data movement or restructuring. This data-agnostic approach keeps the semantic layer independent of the underlying storage system.

What enterprise use cases does an ontology-driven semantic layer support?

This video demonstrates cross-domain use cases including supply chain optimization, drug discovery, and compliance, all powered by natural-language queries against a unified ontology. The architecture supports any scenario requiring connected knowledge across multiple business domains.

How does Stardog integrate with Databricks tools like Unity Catalog and Genie?

Stardog's knowledge catalog automatically harvests metadata from Unity Catalog, building ontological context from existing data assets. The consumption layer then exposes this semantic layer via MCP servers, APIs, and Genie integration for use by LLM-based agents.

Full transcript

[00:07] All right, my name is Naveen Sharma. I'm the chief product officer here at Stardog. Uh my session today is a topic that's uh certainly near and dear to my heart. Uh but certainly taking front and center stage today u in fact yesterday
[00:20] when Ali opened the his keynote talking about uh the notion of ontologies and the importance of ontologies to power semantics. So we'll get started with that note. What are the one of the most
[00:32] important questions we start to receive when we have conversations at our booth right now is what is an ontology and why should I care and how does it help drive the context that agents need in order to
[00:46] operate autonomously. So I thought we start off with just the baseline understanding of what ontology really means. An ontology is really a structured sharable representation of semantics that encapsulates business
[00:59] concepts, relationships, your business logic constraints relative to a single or many specific domains that are important to your organization. And you
[01:11] think about how why that is important. Ultimately, it's about allowing humans and machines to share, understand, and reason over that knowledge. And that's
[01:23] where ontologies really start to drive value, especially now that we talk about Agentic AI. Ontologies start to really model context and meaning. And why that
[01:36] is important? Because in the in a in the scope of an enterprise, we're not really down to a specific table or a schema or a warehouse or a data product or even a
[01:48] single domain. Ontologies are great at capturing the complexity that sits across domains. Those domains, whether they happen to be in the supply side or they're on the manufacturing side or on
[02:01] the commercial side. How do you bring that connected knowledge, that digital thread, and the ontologies are a way to model that information that represents the business domain? Number two, ontologies abstract that knowledge away
[02:16] from where data is actually located or how the data is actually structured. And that's an important distinction. You'll hear the word ontologies that are specific to a tooling. Whether that tooling happens to be data bricks or
[02:30] whether that happens to be Palunteer or someone else that talks about ontologies. If that ontology is not abstracted away from where the data is stored or structured, then they're just
[02:42] making up the word to make it sound cool for their specific tech. Right? Ontologies need to be abstracted completely away from where the data lives. Number three, why this becomes important is because they provide the
[02:54] ontologies provide the deterministic grounding and accuracy your agents need in order to operate uh without any hallucinations. Right? So that determinism comes from the fact that an
[03:08] agent can ask a question but everything is responded or answered through the lens of the ontology because the onentology encapsulates that domain knowledge and why that becomes important
[03:21] eventually because ultimately the goal is what the goal is to accelerate issue to insight by connecting all aspects and assets of the problem domain. And so
[03:33] what that means is now you can look at each insight through the lens of the individual stakeholder where you want to drive optimization strategies for supply chain, optim optimization strategies for
[03:45] manufacturing efficiencies, optimization strategies from a distribution or logistics standpoint. That becomes an important element. But of course when you drive those optimization strategies, you need to understand the full context
[03:58] that cuts across those domains. And this is where ontologies are really powerful. Now, ontologies in practice are also important to understand, right? It's not just a concept. Ontologies, I have two
[04:13] main ways these get represented and implemented. One's a standardsbased approach. This is all about how you encapsulate W3C standards that have been established for over a decade. They talk
[04:26] about capturing and maintaining and building ontologies as RDF al sparklebased constructs. These are supported by vendors like us. Make it much more interoperable and also allows you to bring in external
[04:40] industry domains that have been built on the inside on the public domain versus proprietary implementations where you're now building ontologies that are specific to that tooling infrastructure
[04:52] which means now you're talking about vendor lock in making it very harder for you to scale this across the enterprise. And where do ontologies really fit in the semantic stack? And that's an
[05:04] important element too. Soontology is basically just the foundation to abstract modeling of complex domains to make it human consumable and machine consumable. But above that semantic
[05:18] stack is how do I map this knowledge to where my data is stored, where my how my data is structured without having to actually physically move or copy all that data, right? So if your data sits
[05:31] in data bricks today or your data set lives in Snowflake or BigQuery, it doesn't matter at the end of the day. You want to be able to map the underlying metadata to the actual physical ontology that you've established and described within the
[05:44] domain itself. Number three, you want to be able to inference and reason over that information. So you can create new semantic insights. So when I talk about uh a semantic concept like orders, we
[05:57] know that's modeled in a table or a schema somewhere. But then I want to be able to ask a question about expensive delayed orders. But what's an expensive or delayed order really mean? Well,
[06:09] that's where you can create logic on top of the ontology model to make that deterministic insight make come come to life for the user where you describe based on business logic. An expensive
[06:22] order is anything that exceeds 400 or a delayed order is anything that came after the actual shipment required date. And that can also be inferred at the time you ask the question and create a
[06:34] new semantic concept called expensive delayed orders. And then the knowledge layer that comes above that is the actual governance and security through which you enable your end users to
[06:47] consume this knowledge. Right? You still want the right set of users for the right set of use cases to be able to ask questions and get the right answers within the scope of what is allowed from a security and governance standpoint.
[07:00] And then the consumption layer, it doesn't matter how you consume it. It's now available everywhere, anywhere, all at once. Whether it's through your MCP server implementations, whether it's through APIs, whether it's through your
[07:13] BI tools or the notebooks themselves or your own custom homegrown apps. So, of course, we talk about ontology in in slides and it's it's a it's conceptually understood. We're all we've
[07:26] established a baseline of what an ontology means, what good looks like. The key understanding of autotology is also how do we bootstrap this knowledge? How do we get going when we're talking about AI ready use cases? So let's get a
[07:39] bit of insight into how we might bootstrap an autotology for our given use case. >> For the purposes of this demonstration, I'm going to pretend to be an actual
[07:51] senior analyst at Acme Manufacturing. As a human intelligent analyst, I kind of know what the issues are, how to describe those issues, what we're trying to accomplish. And then that description
[08:03] is what feeds the bootstrapping of the ontology itself. That's step number one. That's where you collaborate with your business domain users, business domain
[08:15] experts to encapsulate exactly what is the important uh standard operating practices or what is the business trying to achieve uh and describe it in a set of use cases that are familiar for that
[08:27] user so that you can capture that as the baseline for what you're trying to build. Number two is what are the questions I want to answer? What are the questions that I find hard to answer
[08:39] today? So as again as an analyst I might ask a question about I want to be able to find out which widget shipped to distributors in April that contain at least one part instance that was produced with a machine fault window. A
[08:52] complex question requiring many different domains to come together in order to respond. But that's the type of question I want to be able to answer as an analyst. Number three is the metadata knowledge
[09:06] of the underlying systems themselves. This helps automate and seed the mapping to the ontology. So again, in this scenario that I'm going to obviously demonstrate, I'm using uh data bricks
[09:19] and unity, right? We're connected to Unity. We're pulling on the Unity catalog and extracting and harvesting the metadata that sits there into uh what we call the Stardog knowledge catalog. And I'll show you and
[09:31] demonstrate to you why that is important. So let's uh flip that a little bit. I'm going to go into demo mode. So again I'm using the same description as I said I want to be able to answer
[09:43] questions about you know Acme manufacturing specific widgets and I've described this as a user who is familiar with the domain itself. So through this description I can start to generate
[09:56] specific competency questions. So if you don't have questions you you want to bring to this discussion we will generate those competency questions for you. But let's say I have my own set of
[10:08] questions that I want to be able to answer, right? So, okay, great. I I can appreciate random questions being generated. That kind of helps uh bootstrap the anttology, but I have my own set of
[10:21] questions that are important to answering for the business, right? What is the total revenue? How many widgets, ship, distributors, what is the schedule, maintenance, load time per technician at uh for a specific part?
[10:34] And I'm going to use this set of questions. And then the third step is now at this stage I want to be able to search the catalog, the knowledge catalog to say is there any relevant
[10:48] schema, table data, metadata that might be the right information to pull in as I bootstrap the ontology with the mappings against those tables and schemas that are important to answering the question.
[11:00] So through this process now I start to search the catalog and the catalog like I said could be not only data bricks unity could be calibbra could be uh purview uh could be snowflake right so
[11:12] that schema and that information is all pulled in and harvested within the uh the knowledge catalog to try and search the catalog for what's the right set of metadata that I want to be able to extract and as it's going through that
[11:25] process it obviously generates uh the actual description of what we're trying to to address in the with this particular use case and it actually tells me what specific sources it found
[11:39] that is able to then uh recommend as part of the process for mapping back to the ontology. And now I can use this to generate the ontology, the schema, the models, the constraints, the rules
[11:53] and I can use this to also create the mappings back to those systems of record. Right? So what we're not doing is physically moving or copying any of that data into startup. So that is an
[12:05] important element to the semantic stack that you want the data to stay where it is because the idea of this is to be able to create what's called a zero copy architecture. Right? So now as it goes through this process it's doing a few
[12:19] things. It's creating the database. It's describing the metadata. It's describing the mappings. It's actually looking at the questions and seeing based on the
[12:31] underlying metadata and the and the profile of the data do I have can I answer the questions that were originally asked by the user or do I need to refine that uh to actually really answer the questions more accurately. So now I have done is I've
[12:45] created a refined list of questions. I've also generated the actual ontology behind this and each ontology concept and you can kind of look through here. Let's say I have customer. I have the
[12:58] mappings to the specific table schema within the catalog that I was able to pull in as part of the process. So now what I've done is I've gone from a description of the problem space to actually creating the ontology
[13:13] and the mappings that allows the user now to be able to ask and answer questions. Right? So what does that look like? We'll start to take a look at that and you can kind of see the tables that we pulled in for the mapping purposes.
[13:25] Let's go and ask some questions. And this is where we're now talking about how do agents retrieve information in ways that does
[13:37] not hallucinate but uses the ontology to create the grounding and then to the understanding of the mappings to go fetch the data at query time, federate over that information and pull that together for the user. So what could
[13:50] that look like? Let's take an example and I'm just going to pull one. Let's say uh this one right here for widget instance X built at facility Y. Which part instances were
[14:05] assembled into it and which orders and shipment contain that widget? And what is it? What are we doing? We're using what's called again multi-agent orchestration underneath the covers asking the questions based on the schema
[14:18] concepts. So these schema is basically the ontology concepts that were identified in the original question. So the widget instance part assembly order shipments. We also know that there's a a
[14:31] schema that has the information about the facility. And then we're using the query which is what this is representing to actually answer certain questions. Right now I what it also does is it tries to move over the data look at the
[14:45] information reason over the information and say do I actually have the right set of information or do I still need certain details that are missing in order to answer the original question right so X and as it goes through the
[14:57] process you have full observability behind this so you kind of see the decision traces as it goes through this to eventually come back and generate the response for the user right so it's gone
[15:09] through uh a multi-query orchestration looking at queries that have been grounded on the actual ontology and then uses that to generate the right query and structure the right query
[15:22] which is the actual uh uh standardsbased ontology based sparkle language sparkle query language we use the large language model to generate that query for us once that query is generated we use the
[15:35] mappings to then push SQL down using the SQL warehouse endpoint to the data bricks layer and pull all the information at query time and federate over that and present the result back to the user. So that's the roundtrip
[15:48] occurrence that is happening in this whole process. Now, one of the other things we also do is, of course, as you're building through this, you want to be able to augment this with uh certain piece of data that might not be
[16:00] available, right? Let's say I want to go back here and I want to be able to ask a certain question. Now, I'll pull up one of the other demos here.
[16:18] Edit. I want to be able to ask a question about returns. So, I I'll actually go back into here and say, you know what, uh, what customers had returns?
[16:34] And if there's a concept of returns, that's great. We wanted to answer the question, but if it doesn't have information, then we also wanted to make sure that it doesn't answer the question, right? So that's the key here is to look at how we're actually coming to a decision, looking at what specific
[16:48] ontology concepts are being referenced, what information we have and then be able to provide that information back to the user in this whole process. At the same time, we also want to make sure as
[17:00] we go through the process of making changes to the ontology that we are able to evaluate those changes so that any changes in the ontology that we make because this is a living system, a
[17:12] living knowledge layer where the actual agents work with the human collaborator which is the knowledge steward to provide useful insights. Right? We talked about observing new behavior. Well, the observability allows us to
[17:25] understand the specific behavior that's being captured through many questions that are coming in from users. And then the analysis agent allows me to analyze information that might require changes
[17:37] either because there's a data gap or a schema gap. And then the evaluation allows me to actually reprocess based on what good looks like. So I know these questions and these are the answers I
[17:50] expect. So if I make a change, I want to re-evaluate that to make sure that my accuracy levels don't go down. Right? So that's the whole process and life cycle working together as a human and agent
[18:02] collaborator within the notion of what we call the semantic control plane and I we have limited time so I'm going to jump right into it. So what is the future of knowledge
[18:14] management? It's a user journey that includes uh humans and agents collaborating together where we not only bootstrap the ontology based on the problem space. But we observe agent behavior,
[18:26] we analyze and capture human feedback, we analyze the decision traces, we action those semantic improvements and then we're able to evaluate the behavior of the new agents ultimately allowing
[18:38] you to scale knowledge inside the enterprise. Right? So the semantic control plane becomes this infrastructure of trust a living knowledge layer where there's continuous collaboration of the semantic models and then the human and agents collaborating
[18:50] to what we call meaning management of course to scale AI you need the right architecture right so that's an important element to consider when we're talking about semantics and the importance of semantics every data
[19:03] platform vendor out there talks about semantics sometimes they'll talk about ontologies but those are restricted and limited because they're either doing so based on their under understanding of the their metadata of their data data
[19:16] layer or their application layer and that's represented in the ontology but we all know ontologies are not about how the data is structured but what the domain of the business encapsulate in
[19:28] terms of true meaning right so having that semantic layer tied to a specific data application platform gives you very limited scope in what you can achieve within an autotology layer with a
[19:40] analytics or BI layer, it's the same dimension, right? Whether it's a reporting mechanism in Tableau or PowerBI, you're limited to semantics or metrics you're trying to capture for those dashboards, those reports, that
[19:52] doesn't scale across the enterprise. That doesn't scale across the complexity of the domains that you're operating in. That's where the data consumption and data sources operate through what we call the universal semantic layer where it becomes a cognitive backbone for the
[20:06] infrastructure of trust and more importantly abstracts that process complexity away from where the data is structured and stored and supports these standards that I referenced earlier in my presentation
[20:18] and again don't take it from me Gartner talks about this you know those that actually incorporate semantic layer will reduce the amount of technical debt and rework work they would have to do if they go about this approach early and
[20:31] and do it the right right way and the 80% of all agent orchestration in large enterprises will have the dependency on this universal semantic layer that can scale across use cases scale across
[20:43] application platforms or data platforms and that becomes an important element at this point I'm sure your organization is talking about bringing in Juul from SAP or Genie from data bricks or cortex from snowflake or another agent into a tool
[20:57] from uh from another application or data vendor. Uh and this is where you get into the problem where now you have agents running around with disconnected knowledge operating in their own little
[21:10] walled garden not knowing what the other walled garden actually includes and might might provide of value to the to the overall business objectives. And this cuts across not only the foundation
[21:22] that you put for your agentic enterprise but the types of problem spaces and use cases you can address. So when we talk about manufacturing we talk about supply chain visibility. We talk about operational efficiencies in
[21:34] manufacturing. We talk about R&D innovation. We even talk about complex questions around quality and recall management. Right? So this is an element of how we describe the semantic platform enabling these use cases for the
[21:48] specific industry or domain and it doesn't have to be manufacturing. It can be financial services where now we're talking about fraud and AML. We're talking about risk management, what kind of controls we need to establish, what are the policies, how do they adhere to
[22:02] compliance requirements or just basic understanding of customer 360 types of use use cases. Or if you're in the life sciences space, it's all around drug development, right? How do you enable your researchers, your scientists with
[22:15] the utmost and most complete information that be available? Whether it's through clinical trials, whether this is through uh understanding of the the the compound and the molecule at the protein level of a drug uh or chemical or whether it's
[22:30] looking at previous research that you want to pull in and bringing connecting all that knowledge to answer how you accelerate drug discovery and improvement. Thank you for your time.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.