Episode 9 — What Are Ontologies? Their Role in Knowledge Graphs and AI Domain Super Intelligence

This week's topic: domain superintelligence

Sunil Baliga: It's Friday, so it's Token Drop time. This week I want to talk about domain superintelligence, and within that, knowledge graphs and ontologies. Sajjad, even after working with you on these for so long, I honestly didn't know what a knowledge graph — or an ontology — even was until you first mentioned them back when we worked together at WIPRO, years ago. I think I've mostly got it now, but I'm still a little fuzzy. Let me tell you what I understand an ontology to be, and we can go from there.

To me, an ontology is kind of a combination of an org chart, a dictionary, and a thesaurus. In a company, you have an org chart across departments — marketing, sales, HR, engineering — and a description of how those roles work together. Then you have a dictionary of terms with specific definitions — in sales, for example, the word "spiff," which is a sales incentive given to the field sales team. So there's a term, "spiff," and a definition, like a dictionary entry. And then there's a thesaurus layer — synonyms for "spiff" that might be used within that specific company. That's my business-level mental model of an ontology. Am I on the right track, or completely off?

Sajjad Khazipura: You're actually on the right path. More formally, an ontology is a schema for modeling knowledge within a given domain — not general-purpose, applying to everything in the universe (that's a much harder problem), but modeling domain knowledge within a well-defined domain, in a way that lets you use that schema, vocabulary, and taxonomy to actually transact business. Everyone ends up sharing the same understanding of what each term means, how terms relate to each other, and what their properties are. It's a good organizing framework for knowledge.

That connects directly to the term "domain superintelligence," which we're hearing more and more often. Unlike a general-purpose LLM, domain superintelligence means that within a narrow enough domain, you have enough knowledge and expertise to genuinely call yourself the best in that specific, narrow slice. That's achievable — pragmatic and practical — especially for automating specific business functions, which tend to be well-defined and narrow enough to scope out reasonably well. That's exactly where ontologies become valuable: combine them with general-purpose LLMs plus specialized domain knowledge, domain rules, and business taxonomy, and you have a real toolkit for attempting to automate that domain.

Industry ontology standards: from the early web to FIBO and OSDU

Sunil: These seem to be growing more important across industries — there are now industry associations building shared ontologies. Oil and gas has OSDU, finance has FIBO. Is that a trend that's picked up steam, or an older idea that's fading?

Sajjad: It's very much alive. I think it emerged just after the dot-com era, right as the World Wide Web had been invented and people were starting to appreciate its value. Tim Berners-Lee and others believed that organizing that worldwide knowledge would be achievable if you had ontologies and taxonomies to structure it. That's where standards like those from the W3C originated, and they've kept evolving since — Wikipedia's own knowledge organization draws on those same standards.

Certain industries — healthcare and medicine especially — adopted rigorous term definitions early on, because precision matters enormously there. If, as a doctor, I tell you I'm going to administer a painkiller, I need to be precise, you need to understand exactly what I mean, and any other clinician needs to interpret that the same way. That need for standardized semantics — a shared, precise understanding of a concept — was critical, so the medical domain embraced it first, and the financial domain followed for similar reasons: precision and accuracy around concepts and meaning matter enormously there too.

What we're increasingly realizing today is that ontologies are also a good organizing principle for building guardrails around LLMs. LLMs are only as useful as the depth and breadth of their knowledge, and their generative behavior can sometimes go uncontrolled — ontologies are a great tool for constraining and managing that.

Sunil: I remember, a few years back, talking with a customer about building an ontology — they estimated it would take a sizable team of engineers six to nine months. It seems like these industry groups doing this work are providing real value to their members.

Sajjad: Absolutely — look at Wikipedia. It's a massive, genuinely global effort organizing knowledge according to real ontological standards, using things like RDF and SPARQL, trying to stay as standards-compliant as possible. And you're seeing dedicated industry bodies emerge too — OSDU in oil and gas, FIBO in banking, and similar efforts in healthcare, life sciences, and insurance. Industries with fairly rigid compliance and regulatory oversight tend to adopt ontologies fastest, because it's directly in their interest: associating unambiguous, well-understood meaning with a given term, with all of its properties and relationships to other terms clearly defined. These standards provide enormous benefit as a shared service to the broader community of users, who can then build their own solutions on top of them.

Is an ontology tied to a specific type of knowledge graph?

Sunil: Are these ontologies specific to a particular type of knowledge graph, or are they generic, meant to be applied to whatever graph you're building?

Sajjad: That's an interesting distinction. First, there's the ontology itself — how you organize your knowledge — which is independent of your implementation choice, much like a database schema. You can take a given schema and use it in MySQL or in Oracle; it's the same underlying schema regardless of the database engine. Similarly, an ontology is a technology-agnostic abstraction, and how you actually render it depends on the graph storage platform you choose.

Historically, most graph databases tried to comply with W3C standards like RDF, OWL, and SPARQL. More recently, we're seeing the emergence of "labeled property graphs," which are far less rigid about strictly adhering to RDF/OWL/SPARQL — you can still represent an ontology and organize knowledge, but it's more freeform and less constrained, which makes it easier to program against and lets you build solutions faster. So there's a spectrum: rigid, standards-oriented designs on one end, and entirely free-flowing architectures on the other, with a hybrid in between.

If you look at the graph database industry, an emerging query standard called GQL is roughly 70–80% Cypher (Neo4j's query language) — noticeably different from SPARQL, which is far more rigorously standards-driven. So across the industry, there's a gradual loosening of these standards to make systems easier and faster to build and operate. I'd call that a good drift — you still get the core benefit of organized knowledge, while also benefiting from newer, more scalable graph data stores.

Are ontologies coming to Silicon Valley's own industries?

Sunil: One question for Sam — we're here in Silicon Valley, which started with silicon, moved into systems, and is now a bunch of other things. Most of the ontologies I'm personally familiar with come from domains outside silicon and networking. Having sat on standards committees in silicon and networking myself, I'm curious — is there a real push to build ontologies specifically for semiconductors, EDA, or networking? Do you see that happening, Sam?

Sam Pooni: I do see real movement in that direction, especially in the semiconductor industry. For context, domain modeling itself has existed forever — Sajjad knows I was involved early on in storage standards work, things like the Bluefin specification and the SMI-S (Storage Management Initiative Specification) standard.

The real challenge people point to today is that knowledge graphs and ontologies have historically been very difficult to maintain.

Sunil: That's the part I don't fully understand — an industry's language doesn't change dramatically year over year; maybe a handful of new terms show up. Why is it so hard to maintain?

Sam: The real problem traces back to how people originally built these ontologies. First, they were largely handcrafted. Second, people often approached it as a giant, top-down, "boil the ocean" effort driven by committee — trying to define everything before delivering any real value. The problem with that approach is that people keep refining the definition indefinitely, and by the time anything's realized, a decade can pass. That was a real bottleneck in systems that tried to model everything to the nth degree.

Here's the subtle but important shift: if you apply a concept like domain-driven design, you only model the portion of the domain you actually care about right now. You go deep on that slice and don't worry much about the rest — which dramatically reduces the surface area of the ontology you need to build. Defining something that specific and scoped is genuinely doable, versus the old boil-the-ocean approach.

The second major shift is LLMs themselves. The hardest part of building an ontology used to be processing raw information — reading documents, extracting entities and relationships, normalizing terminology. LLMs now handle most of that heavy lifting directly.

Sunil: Isn't an ontology, at its core, just a representation of language — and language is exactly what language models are built to work with? Why wouldn't you just use an LLM to build it?

Sajjad: Exactly right. You craft the ontology once, then use an LLM to extract knowledge from your documents against that structure — with a human in the loop if the stakes are high enough. Once that knowledge is organized in the graph, you can apply it across any number of use cases, so the investment of time and effort is justified by the return you get from reusing it. LLMs are what's accelerating that whole process now.

Historically, this really was laborious — you needed domain specialists and ontology specialists, plus specialized tools. I remember Protégé, an open-source ontology tool out of Stanford that's been around for 15–20 years. We'd use tools like that, bring in ontology specialists and domain specialists, get everyone in a room, and work toward agreement — and even then, some other department or division often wouldn't fully agree, so you'd have to loop them in too. It was genuinely hard. LLMs help accelerate a lot of that — though you still can't shortcut the human process of actually reaching consensus across stakeholders. What you can shortcut is the raw automation and extraction work.

Sunil: That's part of what these standards committees have already effectively solved — they know how to build agreement across multiple companies.

Sajjad: True, though even standard, off-the-shelf ontologies usually need adaptation for a given organization — each company may interpret certain terms slightly differently, and there's always some work in mapping their specific products and services into a shared taxonomy. But by and large, yes — the open-source ontologies contributed by industry bodies and associations are genuinely helpful starting points.

Renewed momentum for knowledge graphs

Sunil: I've also noticed more academic papers and research on ontologies lately.

Sajjad: No question — it's a clearly growing trend. If you look at Google Trends, this is an actively trending topic right now, whereas just two years ago, people paid it far less attention. I remember at the Knowledge Graph Conference in New York — an annual event — a couple of years back, people were actively having to justify why graphs were even still necessary, because there was real pressure from the rise of LLMs suggesting graphs might become unnecessary altogether. That pressure has clearly eased. At the most recent KGC, there was significantly more enthusiasm — people are doubling down on graphs rather than abandoning them, because it's becoming clear how much this capability supplements what an LLM alone can do.

Why ontologies matter for AI: the case against "just use an LLM"

Sam: Building on what Sajjad said about scope — the scope of an ontology is really the single biggest lever on cost, and it's entirely within your control; keeping it tightly scoped makes everything more manageable. The second piece is the automation pipeline itself, which can now propose the graph structure — which entities to extract, what relationships exist, candidate terms — with humans still involved, but in a review-and-correct role rather than an author-from-scratch role. That author-from-scratch burden is essentially gone now; it's a review-and-correct process instead.

That brings us to the real question: why does any of this matter for AI in the first place? Because ontologies give AI an explicit, shared model of meaning — and that shared model is what makes real reasoning possible. It constrains generation and curbs hallucination, as Sajjad mentioned earlier. It also enables interoperability across silos and standards, and makes AI systems explainable and auditable.

So consider the alternative: what if you skip ontologies entirely and leave everything to the LLM? That means every time your domain shifts, you're re-prompting, re-fine-tuning, and re-evaluating the model — with no real traceability into what it actually "believes," and no way to surgically correct a single wrong fact. None of that is really under your control. With a domain graph, by contrast, when a fact changes, you update one node, and that change propagates cleanly through downstream inference. With a pure LLM-based approach, when a fact changes, you genuinely don't know where that fact "lives" inside the model, or whether retraining actually fixed it — or whether it silently broke three other things in the process. You're essentially left hoping it worked. That's the real problem with skipping the knowledge graph and leaving everything to the LLM: you don't know where facts live, you don't know how they're maintained, and if you retrain to fix one issue, you have no visibility into whether you introduced new problems or broke existing relationships elsewhere.

Sajjad: It also acts as a bridge. LLMs are trained largely on internet data, and they may or may not understand a specific company's internal terminology, associations, and concepts — that's proprietary, "dark data" that belongs to the company. If a company can define an ontology for its own business processes or product set, and combine that with an LLM, that combination becomes the last-mile bridge — the graph bridges what the company actually needs against what the underlying LLM is capable of on its own. That's a clear, direct pathway toward domain superintelligence.

Domain superintelligence vs. AGI

Sunil: That's an interesting term — I recently learned "domain superintelligence" is an actual technical term, not just marketing language. I see it plastered on billboards up and down Highway 101 and always assumed it was pure marketing spin.

Sajjad: It's genuinely technical, because you're constraining your field of operation to a very narrow domain — accounts receivable, accounts payable, or something like CRM (customer relationship management). Once you define a domain that narrowly, you can afford to go very deep within it — build detailed ontologies, customize and adapt them to your specific business terminology, and then constrain the LLM's generative and verification processes to operate strictly within that narrowly scoped domain, using the ontology and graph as guardrails. That's a genuinely viable pathway to domain superintelligence.

Sunil: So domain superintelligence sits one level down from AGI — is that the right way to think about it?

Sajjad: Right — AGI is typically discussed as the more general, "shoot for the stars" goal that everyone in the field is ultimately aiming at, and nobody really knows when we'll get there. The current generation of LLMs and transformer-based architectures is falling short of that promise on its own — real AGI likely needs something more, and we don't yet know what post-transformer architectures will look like, so there's a lot of genuine uncertainty there. But for businesses that need to automate real processes today and want to benefit from AI now rather than waiting, the pathway we've just described — narrow domain, ontology-constrained, graph-guarded — is a pragmatic way to actually automate something and capture real value from the technology that exists today.

The economics of reuse: domain cartridges and accuracy

Sam: There's another interesting angle here — Sajjad's talked before about domain cartridges, which brings in the economics of reuse. Once you build an ontology, the cost gets amortized over time. Sajjad, you can speak to that.

Sajjad: Exactly — once you define an ontology, whether for accounts receivable, accounts payable, or any specific business process, companies tend to stick with that process and run it repeatedly, often millions of times. You define the process and the ontology once, then run it through that structure at massive scale — that's really the amortization Sam's describing. And because you've constrained the domain and layered in guardrails and verification, you end up with meaningfully better accuracy than you'd get from an unconstrained LLM.

That accuracy bar matters because businesses genuinely want it — nobody wants anything less than 100% accuracy in a real business process. But classical data science almost never talks in those terms; every leaderboard talks about 70%, 80%, 90% accuracy. Nobody's out there claiming 100%.

Wrap-up

Sunil: I think we're out of time — thank you both, have a great weekend, and we'll talk soon.

Sam: Thank you — that was a great discussion, guys.

Sajjad: Anything less than that just isn't good enough for a real business process.