Tables with an RDF dress

VivekHi everyone, welcome back to ContextOps. Today I have with me Stéphane Fellah. Hey Stéphane, how are you?

StephaneHi Vivek, good to meet you, and thank you for inviting me to your podcast to discuss a very fascinating topic.

VivekYeah, I'm glad we're finally able to do this — it took us a while to get the timing of this episode right. But I'm excited about this conversation today. For the audience: Stéphane is the founder of Geoknoesis, a semantic-AI and knowledge-graph consultancy. He spent twelve years as Chief Knowledge Scientist at Image Matters, running projects for DARPA, NGA, SOCOM, and other defense and intelligence agencies. He's a lead editor of the HSML specification under the IEEE Spatial Web standard, and has spent decades authoring OGC and W3C geospatial standards. He's probably one of the few people alive who can trace a direct line from the earliest days of the semantic web to the current LLM-powered knowledge graph resurgence. Stéphane, excited to have you here.

StephaneWell, thank you so much.

VivekNow Stéphane, let's get into this. I know you encountered RDF in the previous millennium — 1999, 27 years back — and you've been working in this field for a considerable time. Obviously the semantic web is way cooler now; everybody wants to build a semantic layer, a context layer, and so on. What do you think remains a misunderstood concept about the semantic web — something people still haven't fully grasped, and end up committing mistakes because of it?

StephaneIt's been a long journey to evangelize the semantic web. As you say, I started in 1999, and my first exposure to RDF was through the Open Geospatial Consortium — I was involved in defining geospatial standards to enable interoperability. At the time, people were starting to talk about web services and interoperability for APIs, and XML was a big thing. That's how I came across a standard called GML, Geography Markup Language — version 1.0 was actually in RDF. I was working in photogrammetry, imagery, and GIS, dealing with different formats where every piece of software communicated differently and you had to do constant conversion. The idea of an interoperable format was very appealing, and a lot of people were working on it, all riding the XML bandwagon. They thought XML would solve everything, the way HTML solved document sharing. But there was a company called Galdos, a Canadian company, that proposed GML, and version 1.0 was RDF. I started looking at that and got introduced to ontology — I'd heard about it a little in school, five or six years earlier, but this was where it got real. And that's where I saw what people were missing: interoperability isn't about syntax and structure, it's about sharing meaning.

That was the hardest thing to get people to understand, because most people in the industry, even today, come from a relational-database background. They see things in tables, columns, and schemas. First it was XML, then it was JSON, and everyone thought they could solve interoperability just by defining a new API. What happened with GML is telling: version 1.0 was RDF, but under pressure from big players like Microsoft and Oracle pushing XML so hard, people decided that must be the right way, so it moved from RDF to XML and XML Schema. At the time I saw that as a big mistake, because by creating new schemas you just create new silos of standards, and interoperability was never actually achieved. It was very easy to produce a new schema, very easy to exchange data in XML, but on the consuming side, the machine receiving it couldn't make sense of the information, because the meaning was missing. So I spent years of my career trying to explain what XML is, what RDF is, and why RDF isn't XML. RDF/XML didn't help much at the time either, because people found it hard to parse. They missed that RDF is a data model, a triple model, with multiple serializations — you can serialize it in Turtle, in JSON-LD, in N-Quads, and so on. For about ten years I was preaching in the desert. I felt really lonely — in an organization of four hundred people, maybe five or six really understood the significance of RDF. And the standards weren't ready either — the ontology language wasn't fully baked at the time. RDF Schema was a starting point, but it was limited in the constraints it could express. I came from academia, so it made sense to me, but people found it very complex, it required a lot of expertise.

Then SHACL came out in 2017, and that started to fill a gap. It didn't replace RDF, but it filled a real gap around validation and constraint assumptions — I still use SHACL for that today. And then came the emergence of generative AI with large language models, and everyone jumped on that bandwagon and said, well, this is great, we don't need ontology and semantics anymore, we can solve everything with an LLM. But in regulated industries like insurance and banking, there's no room for hallucination. One of the biggest problems with an LLM is: you ask it something, get an answer, ask again, get a different one — how can you trust that? People started asking, how do you explain your reasoning based on facts that are actually in the data? That's where semantics and knowledge graphs started showing value again — semantic technology provides a framework to integrate data silos sitting in SQL databases, behind APIs, in document stores, or graph stores, giving you one common framework to query them, through SPARQL.

You talk a lot about context graph — to me that's obvious. When I joined Image Matters, they were already talking about context-sensitive applications, so it's not something new. You need a graph, and the graph is the context — when an agent needs to ground its reasoning, it pulls the graph as context. People call it context now, but it's just a graph, specifically a semantic graph, as opposed to a labeled property graph like Neo4j, which isn't semantic. Neo4j has a layer that's more of an afterthought; most people use it for graph analytics. It's not really designed to integrate data silos across an enterprise, you get stuck with a single vendor and a single solution. If you're trying to integrate three hundred systems, like I've seen in some insurance companies, Neo4j just isn't going to work. You need a common representation, and that's where ontology becomes important. Now we're in a phase where the LLM has provided, the way I see it, kind of a yin and yang. The LLM adds an interface that makes building the knowledge graph and the ontology much easier, more approachable, and lowers the bar of expertise. That's why it's picking up — I was at the Knowledge Graph Conference last May, and it had the highest attendance ever, real interest across every industry. It took about twenty years to get there. But I never gave up, I really believe in this. So yes, I've spent my career working on this.

VivekGot it. So help me understand — why is interoperability so important, especially in today's context, when things move so fast and you can use models to generate tons of code? What specifically makes interoperability so critical, for the long term, for the enterprise?

StephaneIntegration is probably the biggest application — I call it the killer app of the knowledge graph. It solves the integration problem. What's happening today is that a lot of work is done independently, in a decentralized way, and everyone comes with their own schema. Someone says, I have a new JSON schema, let's do interoperability with that, and you try to force everyone to adopt it as the standard, until it doesn't fit someone's case, so they create another one, or extend it. Syntactic structure doesn't solve the problem, because what you're really trying to interpret is at the level of meaning. The semantic web provides that framework — everyone can talk the same language in terms of describing meaning, not just describing a concept or a property. It gives you the constructs to do that in an interoperable way, and a machine can reason automatically over it, using OWL and SHACL.

VivekGot it. Okay, going back to the yin-yang concept you mentioned: there's the neural part, which is the LLM, and there's the symbolic part, which is knowledge graphs and their variants. I want to understand how you think about allocating work between these two systems, especially in a production pipeline. Take insurance as an example — a very sensitive, regulated industry where you can't make things up, you have to explain every piece of reasoning, and the stakes are high. Could you walk us through an example of how these components are balanced, what role each should play, and how that surfaces as an outcome? That would be really helpful for the audience.

StephaneI'll tell you how I do it, and also how not to do it, because I've seen both. Let's start with what doesn't work. Take insurance, I won't name anyone — most insurers grow through acquisition. They acquire a new system, and that system has its own application model and data model, and then they try to match it up with everything else. It's a kind of software wasteland, as Dave McComb calls it, everything built around the application. To build an enterprise AI layer, you need an ontology that defines your first-class business entities. You usually start with the decision questions you're asking — for example, how many claims has this policyholder filed in the last five years. Looking at a question like that, the entities you need start to emerge, and you model your business the way you actually run it.

I've seen two approaches, and I think both are wrong. The first is picking an upper ontology like BFO, and each of these upper ontologies carries a specific philosophy. BFO, for example, has a philosophy of reality — it's very philosophical, and modeling your business against a philosophy doesn't really work, because once you commit to it you spend a lot of time on philosophical questions: what's a quality, what's an endurant, people stop following once you bring in something that abstract. Don't get me wrong, BFO is used out there, there are valid applications in biomedical contexts, and it's a standard adopted at the DoD; CCO, Common Core Ontologies, is an extension of BFO. So it's not that I never use it, I use it as guidance, like a map legend. It's not something you have to tie yourself to, it's a legend that helps you navigate, but you don't have to commit to it.

The other approach that doesn't work, and is probably the bigger problem, is starting bottom-up: you start from all the systems you already have and try to let the semantics emerge. The trouble is you bring in a lot of technical debt and assumptions that are baked into those systems and very application-oriented, and when you build the ontology bottom-up, you carry all of that debt into it, it's not pure. So the way to start is neither bottom-up nor from a philosophical upper ontology, start by modeling your business, how you want it to operate. Once you identify that, I build the ontology in two layers, because some concepts are cross-domain, location, people, organization, those apply across the board. That's a foundational layer, and you use existing standards wherever possible: W3C ORG for organizations, SSN for sensor observations, DCAT for describing datasets. I usually choose ontologies that are small, with few classes, because they're easier to extend and reuse. Then there's a business layer — for insurance, that's policies, claims, coverage, concepts that apply across the business. Then the last layer is the vertical, property and casualty, health insurance, and so on. Each layer builds on the one below it, and you end up with something well organized, modular, and easy to extend.

That's typically how I do it, modular, driven by business decisions, built around competency questions. The competency question is very important, because it's what scopes your module. If you skip that and try to work bottom-up, you're not really asking anything, you should start with: what am I trying to build, what question do I need to answer. A competency question also gives you a way to do unit testing, you can associate a SPARQL query with it and validate whether your ontology actually answers the question against sample data. That's the way I build it, I could go into more detail, but that's the high level.

VivekSo you're saying you build an ontology incrementally — start small, start with the business, model a very small scope, and then expand. Expansion is much easier than trimming down a much bigger ontology and reducing its scope. Am I hearing that right?

StephaneYes, but one thing I'd add: don't try to do everything at once. Pick a domain, like claims or policy modeling, and get it end to end, build your API, build your agent, and get an early win. Because once you show early success, you can move to the next part. You want to prove success as soon as possible, because ontologists have a reputation, people say they get in a room and it takes five years to decide whether something is a datatype or an object property. You want quick success: start with the pain point the company most wants solved, show success with it, and then move on.

VivekGot it. Now, because you also consult for large enterprises in these hard-to-navigate industries, how were you approaching this work of building semantic infrastructure before LLMs? What's specifically changed since then?

StephaneA lot has changed. Take coding, for example, I don't really look at code anymore. It's mostly done with prompts and the right tooling. With ontology, I don't let AI build the ontology for me, but I use it inside guardrails — I explain what I'm trying to do and say, generate the competency questions, and LLMs are great at that. They can suggest the right term or the right hierarchy, but you always have to stay in the loop. It's sped up about eighty percent of the tedious work an ontologist used to do, if you have the right guardrails, know how to use the tools, and know the standards. A competency question needs to be backed by a SPARQL query, terms need to be encoded in OWL or RDF Schema, and validation needs to go through SHACL, for reference vocabularies I use SKOS. I used to use Protégé or TopBraid to build ontologies by hand, I don't need that anymore. I generate the TTL and validate it with code, and do the reasoning that way. So eighty percent of the time I used to spend is now handled with AI, and the remaining twenty percent is where I focus, the modeling, the proper patterns, the right modularization. AI can't do that part well, which is why human judgment still plays a very important role.

VivekVery important role, got it. Now, what's changed on the expectation side, from the large enterprise or the CFO engaging with consultants and companies like yours? Do they now expect this to happen automatically, without investing in a semantic web effort? In a world where everyone thinks they can build a knowledge graph with one prompt, and everyone suddenly has a point of view on building knowledge graphs, how do you explain the time and effort involved, and the fact that validation is still critical? LLMs can do a lot, but you still need a human to validate, curate, and establish meaning, make sure everything has the right interpretation. People expect a magic wand, wave it, and get a semantic layer, and you're telling them, no, that's not how it works. How do you explain that to a CFO who's sitting on a real budget and hearing this is going to take more time?

StephaneI've had clients who started a project deciding to build their enterprise ontology purely with an LLM, generate the whole thing bottom-up. Give it a database schema and it figures out the ontology automatically. I came in, looked at the result, and said, this isn't an ontology, this is just tables with an RDF dress, disguised in RDF, but still just tables and columns. For example, they had a table with every kind of identifier, industry classification codes, social security numbers, whatever, a column for each one. If you actually think it through, they're all identifiers, and you could create a single identifier class with values coming from different code lists. Instead they defined a hundred separate properties, exactly mirroring the table, because the ontology had been built by a large language model directed by a database modeler who doesn't actually understand what an ontology is. You end up with something that looks like a relational model dressed in OWL, achieving zero interoperability. I've seen ontologies with fifteen thousand classes and properties total, which is insane. How is anyone supposed to interpret an ontology with fifteen thousand terms? A human can't hold more than three or four hundred concepts about a business in their head. Nobody's going to use that.

So I always start with the decision question, what does your business actually need to answer. Then you model the business, without thinking yet about implementation. Just think conceptually about your business, describe the entities, but also describe the process, the data in motion, how things move through the process. That matters, because you have data at rest and data in motion, the data at rest gets modified by these processes, some event happens, it acts on an entity, it moves through a pipeline, and you want all of that to be explainable. A lot of people miss both of these aspects.

VivekOkay, that makes sense. Now, in that specific case, the client already understood they needed an ontology and should invest in these systems, and they'd learned that lesson the hard way. What about clients who come in without a deep understanding of semantic systems and ontologies at all? A lot of people today have hit a glass ceiling with vector RAG, they can't break through it, and they end up putting a human in the loop to solve the remaining twenty percent, which is actually very hard, because the more complex the system, the more complex that verification work gets. Half the time there's fabrication, half the time it just gets things wrong on important stuff, and it creates expectation gaps, then everyone blames the model. When teams with systems like that already in place come to you, and your answer is you need to step back and model your business first, how do you walk them through that?

StephaneFirst, you have to relate to the pain they have, and the pain is always the same, across every industry. They can't interoperate; they have application-centric data silos and they desperately need to exchange and connect that data. Everyone with knowledge graphs has this problem. The second step is explaining that structure and syntax aren't the problem, you have to go to the root cause and articulate it clearly. The root problem is that everything is syntactic, everything is structural, and a machine given a table with a column name has no idea what it means. Say you have a column called XY, it's a lat-long. There's a lot of missing information to make that usable: what's the projection, what's the unit of measure, is it decimal degrees or degrees and milliseconds. All of that is implicit in the data, and what you need to do is make the semantics explicit.

The other thing is you want to reassure them: you don't need to migrate all your data from one system to another. What you need is to lay a layer on top of your existing systems, keep what you have, but add an adapter that surfaces the semantics that are missing. Say you have an API that returns some JSON, you lift that JSON by making everything implicit explicit, and turn it into a knowledge-graph representation. It's not actually that hard to implement, but a lot of people don't understand the architecture. That implicit, unexpressed information is the real root of the interoperability problem, there are a lot of assumptions baked in that you'd have to read documentation to understand. You hand someone a schema, they have to go find the spec and read what a column means, and most of the time that information doesn't exist, so people guess. And then a probe crashes on Mars because of a kilometers-versus-miles mismatch, an international team working on that had exactly this interoperability problem. It can get very costly.

VivekGot it, okay, perfect. Now I want to go back to the latest framing — to your point, you start by modeling your business: your policies, procedures, documents, and you build that model, maybe pulling in a domain ontology or parts of one. But people are also now advocating for a third layer — coming in from your Microsoft Teams, your Slack, your emails — where a lot of distributed, tacit knowledge also lives, and could potentially be folded into your ontology with some curation. What's your read on that? You've actually built and productionized some of these systems, is that really a thing? Does it make a real difference?

StephaneYou mean integration with services like Slack, ServiceNow, email? More than the integration itself, would it be valuable from an outcome perspective? If an agent is processing claims, deciding whether a claim is good or bad, would it do better having that kind of information accessible too, in the right structure? That's the real question. And the answer is yes, of course, reasoning needs to be grounded in facts, so you need access to the enterprise data, and there's already a mechanism to access it, through APIs, through database queries. But what you want is one framework to represent all of that data, you don't need multiple APIs. That's why you want a semantic layer to unify it: the agent sees one graph, one semantic graph, instead of thousands of APIs, systems, and tables. The real work happens at the bridge, the adapter connecting the data source to your semantic representation. After that, the agent has one consistent way to access context, to get the context graph. Now you have MCP, they use the term context, which is probably where the name comes from, but MCP still returns JSON, not RDF, so it's still not interoperable, you still have to deal with structure and syntax. That's why it's important to ground things semantically, where meaning is expressed explicitly so the machine can actually reason. Otherwise it's an unsolved problem end to end.

VivekInteresting, thanks, that's very helpful. For people who don't understand the world of the semantic web at all, they don't understand ontologies, taxonomies, or knowledge graphs in any depth, where would you recommend they start? What milestones would you set for them, if they wanted to go down this path and build on this framework?

StephaneFirst, they need to understand that any data can be represented as a graph, a table, a JSON object, a tree, an XML tree, everything can be represented as a graph. That's the starting assumption: if you want a semantic layer that unifies everything, it has to look like a graph, everything connects. Second, understand that among graph technologies out there, there are two main categories: the semantic graph or knowledge graph, and the labeled property graph. The property graph is the world of Neo4j, I'm not saying anything bad about them, they're great for graph analytics, the question is how you use it, and whether you can do reasoning with it. So understand the difference between a labeled property graph and RDF, and you'll understand what meaning actually means here. Then start looking at semantic web standards. If you're a web developer, start with JSON-LD, because you already know JSON, JSON-LD just adds the notion of a context, which bridges your fields to URIs. You'll see that a value has a language, a datatype, and you'll discover RDF that way. But then you need to understand the RDF model itself, what a property is, a datatype, a literal, a class. That's RDF: a simple model, the building block for a graph, with serializations like Turtle and JSON-LD.

The next layer is: how do you define a schema for a graph? Look at RDF Schema, domains, ranges, subproperties, subclasses. Once you want more expressiveness, look at OWL, the Web Ontology Language, that's where you get axioms like transitive and functional properties, intersections and unions of classes. Then: how do you validate the data coming into your graph? That's where SHACL comes in. And there's another piece, how do you represent your glossary, your code lists, your taxonomies, the values that sit on your entities and classes? How do you govern that, and map between two taxonomies that overlap but aren't quite the same? For that, look at SKOS, the standard for representing that kind of vocabulary. And then look at systems that already use these standards, schema.org, DBpedia, Wikidata, to see how it works in practice. Go to a Wikipedia page, then go to dbpedia.org/resource with the same name, and you'll find the RDF representation of that page, and you can navigate the semantic web from there. That's open linked data, you'll see how it works in public, and you can apply the same mechanism inside the enterprise. And of course, SPARQL is the query language, the SQL equivalent for RDF. Read what's used in the industry, play with the APIs, try modeling a small part of your enterprise to see how it works. Try an open-source graph database like RDF4J or Jena, or look at commercial ones like Stardog or GraphDB from Ontotext. That's the path I'd advise following. But the first thing is understanding the graph, why a graph, and once you start with that question, everything else follows logically, one step leading naturally to the next. If you keep asking does this answer my problem, you'll find that it does. That's my advice.

VivekPerfect, thank you. One last question, which we ask every guest: if there was one thing you could change about how enterprises are approaching agents and AI applications today, and it actually happened tomorrow, what would it be?

StephaneFor me, agentic AI will only succeed if agents can describe themselves semantically, and you build a layer of trust across this web of agents. What I mean is: any agent that wants to interact with another has to be able to present credentials and be authorized to perform some activity within a company. That's actually the idea behind the Spatial Web, it's built from the ground up on a layer of trust, using standards like DID, decentralized identifiers, and Verifiable Credentials, so agents can communicate that way. HSML, the specification I've been building for the Spatial Web Foundation, describes what we call a domain — a holonic entity that contains agents performing activity on things, according to a contract. When an agent tries to enter a domain, it has to present credentials and satisfy the policy in that contract to perform the action. If you build that foundation, which is missing today, it matters a lot. Say you send an agent shopping with your credit card: you need to tell it what it can and can't do, which sites it can visit, how much it can spend. That trust layer on the web today is an afterthought, when the web was designed, nobody thought about security, it got bolted on afterward, which is why we have so many cybersecurity problems today. It was never designed for this, so we have to build it in from scratch, and that's what the IEEE standard for the Spatial Web is trying to address.

I think it's a great vision, it'll take a couple of years to get there, but that's the dream: a world where agents can interact with digital twins, because I do a lot of geospatial work, performing activities in a virtual world, all automated. You send a drone to a city, and it has to follow certain regulations, you have a contract within the drone, which is itself an agent, and it has to present that contract to get clearance from the FAA, saying you're authorized to fly from here to there. That has to be built in. It'll take years, but this is how I see blockchain, agentic AI, and semantics converging, it's rebuilding the HTTP and HTML stack: HSTP, the Hyperspace Transaction Protocol, and HSML, the Hyperspace Modeling Language. Everything in HSML is described semantically, it can describe agents, things, and activities, all semantically. That's the idea.

VivekAwesome, thank you so much for this, Stéphane. I really appreciate you going into this level of detail, and your experience and passion for the subject really comes through. I'm very glad we were finally able to record this episode, thank you so much for taking the time.

StephaneThank you so much for inviting me, I appreciate it.