A graph is one tool, not the destination

VivekYou've been at one organization a long time, and you've watched customers adopt technology over decades. What is it about knowledge graphs and the semantic web that people still don't get right — the thing that's most misunderstood, that's limited their adoption?

MelliGo back to the mid-2000s. The technology was powerful but hard to understand — there's a real learning curve. I've had countless customer conversations that start with a developer team who get into it, learn it, love it. Then it moves toward production, senior management looks at it and says: rather than train my teams on all these strange acronyms — RDF, OWL, SPARQL — I can solve this another way. SQL has amazing staying power; asking people to also learn SPARQL, and to bring a whole new toolset with it, is a hard sell. It became its own ecosystem — wonderful in academia, very hard to carry into production. I used to think the world was divided into RDF aficionados, who'd go to great lengths to make it work, and people who decided they couldn't be bothered.

MelliAnd the problem it set out to solve was real and old — integrating data from many sources, linking it accurately, actually understanding it. It used to be called master data management. Enterprises would tell me: we have all this data in silos and we're not using it. But going from that wish to a working implementation took time. The customers who succeeded invested a year and a half to two years before they saw the benefits — and that upfront cost is exactly what senior management balked at.

MelliWhat's changed is AI. Knowledge graphs are now seen as a tool for more trusted AI, and enterprises don't want to lose the value AI can bring — so maybe they're finally willing to invest in building the graph. The incentive is stronger than it was for plain data integration. I won't claim to know whether this is a flash in the pan or something more substantive, but I see far more enterprise investment in this area now than I used to.

VivekSimply adopting a knowledge graph doesn't mean your agents will work the way you expect — it's one tool. So how could it still fail now, despite all the momentum, with the Knowledge Graph Conference at peak attendance this year?

MelliFirst — I hope it doesn't fail; we're investing a lot and we love the technology. But the lines aren't clearly drawn yet between what an LLM can do, what a statistical search like vector search can do, and what graphs do. You can solve some of these problems with pure vector search — less precise, statistical by nature — but teams going to production need to move fast, and if the LLM or a vector-search combination is good enough, that's what they'll use. I've seen plenty of cases where statistical search isn't good enough and you need precise, relationship- and concept-based retrieval. What I haven't seen is the airtight case that says: this is why a graph will always be needed, even as LLMs keep improving.

MelliWhere I do see durable value: an ontology can encode relationships and entities specific to your business that an LLM simply doesn't know. Take an artificial example — an LLM knows revenue relates to profit. But if, in your business, "revenue" also means how many happy workers you have, the model has no way to know that; it's trained on facts it already has. A knowledge graph gives you a succinct, precise way to represent knowledge that's specific to your enterprise. You could try to say it all in paragraphs of text, but models do seem to do better when the representation is precise. So there'll always be value in graphs — I just think it lands somewhere in between: not the key to all your problems, but an essential piece.

VivekYou used a word very casually — ontology. Like "knowledge graph," it's getting used loosely, even stretched into things like "context graph" that aren't in the semantic-web glossary at all. How do you explain ontology to an enterprise customer just starting to explore this?

MelliI define an ontology as a schema for your data — a precise way to describe the meaning embedded in it. I know an ontology is more than a schema; it's not just the T-box, there's the A-box, the instance data, and the RDF world deliberately left a lot of flexibility, so there are blurry lines. But enterprises don't like blurry lines; they like precise terms. So I choose to frame it as a knowledge schema for your data — where you can say things like "this is my primary key," or "this entity is a subclass of that one."

JoshuaThis could relate back to SQL — when you define a schema, you define tables. You could even reuse SQL itself as the storage layer for it. Fair, or am I off?

MelliNo, that's fair. Those of us who grew up in the SQL database world can't help but be shaped by it. To work with data well you have to define its structure — in SQL, that's tables, schemas, primary and foreign keys. An ontology helps define the meaning of your data. That thinking absolutely influences how we look at it.

JoshuaOntologies also carry a lot of natural language — descriptions, metadata, annotations, originally meant for humans. Do you see the machine using those annotations? How does that fit alongside schema?

MelliI think of natural language as a query language now — increasingly it's how people want to interact with their data, the way SQL was. And an ontology-as-schema helps translate a natural-language question into something that matches how your data is actually stored, so you get better, more trusted answers. On annotations: Oracle now lets you add comments to describe your tables — "this is my customer table, here's what it holds." Those comments are genuinely useful context for an LLM or an agent. Ontologies are the more precise, standards-based, shareable layer; annotations are looser text. Both are useful — we're all still working out how they fit together.

VivekThe vocabulary is a bit broken today. Enterprises come to us at CogniSwitch and ask, "can you build us an ontology?" — a pharma or manufacturing company, driven by FOMO, everyone saying own your ontology, own your context — and they have very little clue what that means. How do you break that request down: the prerequisites, where you maintain it, whether it's once-and-done or ongoing?

MelliSome customers come with an ontologist on staff, which makes it much easier. And unlike the past — when an ontology was a static thing you generated once and rarely changed — it's now more dynamic; it gets updated. Without that expertise it's still not easy. A couple of things we've worked on: one, generating an ontology from your database tables — there's the R2RML standard for mapping relational tables to an ontology, and tooling to automate it, so "here's my data, here's the ontology" becomes a starting point. Two, for unstructured data, using AI to draft an ontology from the documents themselves. The tricky part is that the next batch of documents uses a term slightly differently — Oracle USA versus Oracle Corporation — and you need enough knowledge to decide those are the same thing and map them. That isn't fully automatable; you need a human in the loop. What we focus on is giving that human the tools to succeed quickly — I want people getting value in far less time than the year and a half it used to take.

VivekAt the Knowledge Graph Conference you talked about agents operationalized in the database. Most people picture layers — data silos, a transformation pipeline, the database, a knowledge graph on top, then an agent layer reaching in. You said you can collapse some of those layers into one. Explain that.

MelliBy collapse, I mean doing all of it in one database, one instance, rather than several systems that have to talk to each other. That's our converged-database approach. Your business data — airline reservations, bank transactions — is already in the database. To do something interesting with it, you shouldn't have to move it to a different system or layer. Keep the data where it is and bring the analytics to it. One of our customers said at KGC that he liked this precisely because he didn't have to go to his chief security officer and ask to move data or get new permissions — it was all already there, with a SQL layer that plugged into the tools he already used. So rather than take the data to the technology, we bring the technology to the data: property graph, knowledge graph, vector search, JSON — all in the database, all with a SQL API. Security and auditing then apply automatically, at the source, whether you treat the data as JSON, as a graph, or in a vector search.

JoshuaSo instead of a separate graph database like Neo4j, you have all those modalities — a multimodal database — in one place. And how do you define an agent here?

MelliExactly right on multimodal. For agents, we have a PL/SQL package — PL/SQL is our procedural language for SQL. You create a tool for a particular function, a task that uses those tools, an agent, and teams of agents that work together — all as PL/SQL APIs. In a recent session we had one agent working with property graphs and another with knowledge graphs, and set them to find financial fraud: one reasoned over a money-transfer pattern on the property-graph side, the other checked an ontology of high-risk jurisdictions, and they brought the two together. There's also a no-code interface for wiring these modules together.

VivekYou've seen both successes and failed implementations. What does failure typically look like — is it the modeling, the loading, query performance, a lack of semantic understanding? What are the early signs teams should watch for?

MelliSeveral things. One is over-engineering — putting more knowledge graph in the mix than you need. If you have relational tables, the road to success is a graph that works with them, not converting all that relational data into a graph. The volumes can be high, you've tuned that relational system, and once you convert you inherit a whole new set of tuning problems — plus a constant sync headache, because your applications keep updating the relational data. Use graphs where they belong; relational databases are very good at certain things, and there's no need to change that. It's the new questions of your data where graphs come in. Two is performance — you have to think differently about tuning and design. Three is tooling — the landscape isn't as mature as it is for SQL, so people do great work and then can't reach it from the tool they need. And finally, I've seen customers build everything on a competitor's product only for the chief security officer to shut it down — an unknown vendor they won't bring in — and it's back to the drawing board. New technology has to fit the enterprise: IT, developers, security. That's exactly why we collapse the layers into the database — we think it's the best bet for success.

VivekOne last question, the one we ask every guest: if there were a single thing you could change about how enterprises do this, and it happened tomorrow — what would it be?

MelliI'd go back to ontology development. If there were a magical way to create an ontology for an enterprise — so a company that's ready could easily build a knowledge graph and integrate it with their other technologies — you'd take away the initial pain of getting started, which is where the real friction is. We see success when customers arrive already having invested: they come with an ontology, or with their entities, documents, and data, ready to operationalize. Increasingly they do. The pain is getting to that starting line. I'd love every customer to be able to create this quickly, so we can get on with the actual problems.