Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Amazon Music | Android | Youtube Music | RSS
Semantic technologies permit powerful connections across a variety of linked data resources across the web. Until recently, developers had to learn the RDF language to discover and use these resources.
Leveraging the new Model Context Protocol (MCP) and LLM-powered natural-language interfaces, Emeka Okoye has created the RDF Explorer, an MCP service that lets any developer surf the semantic web without having to learn its specialized language.
We talked about:
- his long history in knowledge engineering and AI agents
- his deep involvement in the business and technology communities in Nigeria, including founding the country’s first internet startup
- how he was building knowledge graphs before Google coined the term
- an overview of MCP, the Model Context Protocol, and its benefits
- the RDF Explorer MCP server he has developed
- how the MCP protocol and helps ease some of the challenges that semantic web developers have traditionally faced
- the capabilities of his RDF Explorer:
- facilitating communication between AI applications, language models, and RDF data
- enabling graph exploration and graph data analysis via SPARQL queries
- browsing, accessing, and evaluating linked-open-data RDF resources
- the origins of RDF Explorer in his attempt to improve ontology engineering tooling
- his objections to “vibe ontology” creation
- the ability of RDF Explorer to let non-RDF developers users access knowledge graph data
- how accessing knowledge graph data addresses the problem of the static nature of the data in language models
- the natural connections he sees between neural network AI and symbolic AI like knowledge graphs, and the tech tribalism he sees in the broader AI world that prevents others from seeing them
- how the ability of LLMs to predict likely language isn’t true intelligence or actual knowledge
- some of the lessons he learned by building the RDF Explorer, e.g., how the MCP protocol removes a lot of the complexity in building hybrid AI solutions
- how MCP helps him validate the ontologies he creates
Emeka’s bio
Emeka is a Knowledge Engineer, Semantic Architect, and Generative AI Engineer who leverages his over two decades of expertise in ontology and knowledge engineering and software development to architect, develop, and deploy innovative, data-centric AI products and intelligent cognitive systems to enable organizations in their Digital Transformation journey to enhance their data infrastructure, harness their data assets for high-level cognitive tasks and decision-making processes, and drive innovation and efficiency enroute to achieving their organizational goals.
Emeka’s experience has embraced a breadth of technologies his primary focus being solution design, engineering and product development while working with a cross section of professionals across various cultures in Africa and Europe in solving problems at a complex level. Emeka can understand and explain technologies from deep diving under the hood to the value proposition level.
Connect with Emeka online
- Making Knowledge Graphs Accessible: My Journey with MCP and RDF Explorer
- RDF Explorer (GitHub)
Video
Here’s the video version of our conversation:
Podcast intro transcript
This is the Knowledge Graph Insights podcast, episode number 36. The widespread adoption of semantic technologies has created a variety of linked data resources on the web. Until recently, you had to learn semantic tools to access that data. The arrival of LLMs, with their conversational interfaces and ability to translate natural language into knowledge graph queries, combined with the new Model Context Protocol, has empowered semantic web experts like Emeka Okoye to build tools that let any developer surf the semantic web.
Interview transcript
Larry:
Hi, everyone. Welcome to episode number 36 of the Knowledge Graph Insights podcast. I am really delighted today to welcome to the show my good friend, Emeka Okoye. Emeka is a really interesting ontology practitioner and knowledge engineer, and he’s operating now at the intersection of knowledge engineering and generative AI, which I think is a really interesting intersection and that’s what we’re going to talk about today. So welcome, Emeka. Tell the folks a little bit more about what you’re up to these days.
Emeka:
Oh, well, thank you bringing me to this awesome podcast. I’m proud to be here. I have been involved in knowledge engineering or more like AI. We need to understand that knowledge engineering is important for AI because it creates the knowledge layer. So that’s where we have knowledge graphs. There’s been a lot of tribalism in AI, the neural nets on one side and the symbolic AI on the other side. So I am in for the convergence. I’ve always believed in the convergence.
Emeka:
Funny enough, I’ve been teaching and mentoring young ones on both sides of the divide since 2016 in the Nigerian data science space. So no surprises that generative AI boomed, and I needed to find reasons to see how we can integrate both sides, because that’s what AI is all about, the best of both worlds, best of neural nets, and then best of symbolic AI. That’s the future. I mean, there’s no doubt about it. So that foundation, I needed to be there and that’s why I’ve been working on both sides. So from knowledge graphs to AI agents.
Larry:
That’s so funny, we didn’t talk about this before I hit record, but right before we started this interview, I posted a thing to LinkedIn about exactly that. It was specifically about the need for executive education around hybrid AI architectures ’cause all they have is Silicon Valley hype. That’s all the information they have. But more to the point, you’re a hybrid practice. Well, first of all, I’ve known you for years now, and it just occurred to me, I don’t really know your academic background, but it sounds like you’re equally grounded in machine learning and knowledge representation stuff. Have you always pursued both?
Emeka:
I’m a geologist. That’s the only qualification I do have. Immediately I found love with personal computers. So once the PC era boomed, I just went in programming. Nigeria was once one of the biggest software countries in the world at a point in time. Our software houses were building financial and banking systems the whole of North America were using, and some part of Europe. So we are that big. So when the internet came, we embraced it that early. I was already building internet protocols using Visual Basic, and not long after I co-founded the first startup in Nigeria. And then after that I worked with probably one of the earliest Semantic Web brands in the world, which is OpenLink Software. I became the Chief Technical Officer in the whole of Africa.
Emeka:
So I was with OpenLink Software when Tim Berners-Lee came up with the Semantic Web thing and Ora and co coming up with agents. So I started early on, thanks to my mentor, my boss then, Kingsley Idehen, who mentored me throughout and made me understand that the future was Semantic Web. So I dove right into it. And can you believe this, we were already creating knowledge graph before Google called it knowledge graph. I had created one for a client, which is Music In Africa by 2011, 2012.
Larry:
That’s right before they introduced the term knowledge graph with their… That’s so interesting because… And the RDF and the OWL and all the Semantic Web tech goes back 10 years before that. So that gap between the dawn of the Semantic Web and the coining of the term knowledge graph, you were just in there doing it.
Emeka:
Yes. Yeah, we were already doing it. And remember I came from a company that is on top of this technology. You who Kingsley Idehen is. He’s my former boss, and mentor today, even after. I left OpenLink Software, he was there to guide me in. So most of what I know in semantic technology comes from Kingsley. So we were already doing this. So my understanding of the technology is very sound. Academia-wise, I didn’t do anything much in that regards on the technology, but I’m hoping I’ll do research in the future, because as I’m trying to come into Europe, I noticed that there are a lot of research-based jobs and AI is something I would love to devote research time.
Larry:
Yeah, and I know a lot of those people, and there’s not a specific track yet around the hybrid AI stuff. I hope you get a chance to do that. But hey, that’s what I want to really focus on today. So your background, your RDF Explorer project makes even more sense to me now. I just want to say real quickly about that. Emeka and I meet once or twice a week, and our Dataworthy Collective, which we co-organize with some other folks, and I was just embarrassed that I had totally missed this awesome piece you wrote for LinkedIn about RDF Explorer, and then you just happened to mention it in one of our meetings, and I went and read it and I was like, “Whoa, that’s amazing. We got to talk about this.”
Larry:
So here we are. Finally, I get to share the RDF Explorer with folks. So tell me, I think one thing I’ve been a little bit surprised by is that not everybody in the knowledge graph and semantic tech space is familiar with MCP. They maybe know the acronym and what it stands for, but can you talk just a little bit about the Model Context Protocol?
Emeka:
All right, so the Model Context Protocol, which was created by Anthropic sometimes in November 2024, is a standardized protocol which allows AI agents to connect and interact with external tools and different data sources in a simplified manner. It’s that simplicity that is the attraction. So it removes a lot of stress that comes to connecting different data source to it. Now, just to give you an idea what we are talking about. Before MCP, we had all these agentic RAG solutions. It means that you hand-code every individual sources to pull that data to the language models. Okay? So just imagine that you have something like 10,000 external tools or 10,000 external sources. So that means you will hand-code each one of them and that comes to 10 million implementations. But with MCP, you only do it once, so it becomes 10,000 implementations, rather than 10 million. Okay? So that’s what it does. It automatically takes away the reality of us hand-coded integration. That’s one.
Emeka:
Second thing is that it communicates with our tools. The communication between the language models and our tools happen with natural language and in structured formats, like for instance, our APIs. Our APIs understand structured formats. So what happens is that MCP now turns natural language into the stronger structure format using language models so that the communication between these external tools become so easy. Remember, the transaction starts with the natural language prompt, which is not the new UI and the new UX. So that ease of communication between the language models and the external tools and the external data, is what MCP does, simply. Very efficient. So it removes the need for custom integration. It removes the complexity and it accelerates deployment quickly and easily.
Larry:
Yeah, and a perfect example of that accelerated deployment is you learn about this and you go like, “Well, there should be an RDF service out there. Let’s build RDF Explorer.” So I guess I probably oversimplified that, but from your insight about how MCP… Well, first of the fact that it’s a protocol, like TCP/IP or HTTP or something, and you talked about how that simplifies the communication and connection process. So you take that insight and you go like, “Okay, here’s an RDF service for folks.” Can you talk a little bit about what RDF Explorer is and how it helps people?
Emeka:
All right, so before I go into that, let me just explain briefly one of the motivations about this. Before I started working with OpenLink Software, I was a developer. So, as a developer, coming in to semantic technology was very hard. We came from a relational database. We see the world differently. You understand? But semantic technology is about the real world. It’s about our worldview, it’s about the philosophy, the culture, the norms. It’s a whole lot. That’s not what you see in regular software development. So it was hard for a lot. So that challenge is still there. Learning curve is very steep. It was for me before I finally got into it. So it’s been a problem in the semantic world. Tooling was a big problem. So once I embraced MCP, I now saw an opportunity to lessen the stress coming into and embracing semantic technology, and that was the motivation for me to create the Explorer.
Emeka:
Basically the RDF Explorer is a Model Context Protocol server that provides conventional interface for the exploration and analysis of RDF Turtle-based knowledge graph in two modes, local file mode or SPARQL endpoint mode. So this server facilitates communication between AI applications and language models and RDF data. So making graph exploration and analyzing graph data through SPARQL queries. So this is a perfect tool for all sorts around knowledge graph research, data preparation, data understanding, and so on. This project didn’t start by me creating Explorer. It started by me creating a tool to create ontologies and creating knowledge graph.
Emeka:
And yes, because this, like I said, the learning curve was steep. Tooling is a problem in the semantic word community. So when I started on that, it became so easy. Oh yeah, it was so easy. I mean, it is just like God brought us the MCP specifically for semantic technology. So it was easy for me to pass a prompt with sample data and sample instruction. “I need to create ontologies.” Now, I am not saying, and I’m not promoting vibe ontology. I think that discussion has started in the community. We can’t vibe ontology creation. So I need to emphasize on this. You have to be an experienced ontologist for you to create something meaningful. But it is just to say that the tools that will make our work easier is now available and we can take advantage of that. So I started building ontologies and it was easier and I now realized that the work needed to create something that I could share publicly would take time.
Emeka:
So I pivoted to Explorer first what I could quickly showcase the opportunity in using MCP. So that’s why the RDF Explorer came up. So you have to have a ready-made data or any public link open data instance. You can use it to browse through it and it does a lot of things. But I restricted the function so that I could focus on the beauty of that synergy between MCP and knowledge graph. So you can run queries, execute at any end point, get statistics about graphs, count the triples, do text search, do a head check, and basic… So for the release version now it’s just this basic function so that I can take my time to build other functions to it.
Larry:
That sounds like an awesome start though, I have to say, because one of the first things that when you get interested in linked open data, the first thing you do, you just end up at some SPARQL query generator and then you’re like, “Oh, crap, I gotta learn SPARQL.” But you have a conversational interface, so you can just immediately show the benefits of the semantic tech stack, linked open data and all the stuff that comes with that. How many people have experimented with it yet? Or how much have you done with it and how much have other people done with it?
Emeka:
A lot. I think I counted close to 60 people who are using it, because I installed it in a whole lot of places and people downloaded. Because it’s an MCP server, the most interesting is that when you’re writing AI agents with MCP clients, it becomes a server inside the agent. So all you are saying is, “Pull this data from this knowledge graph instance.” You don’t need SPARQL. So in your agent code, you don’t need to write SPARQL, you just need to write your query in natural language. You see that? They just know that data is a knowledge graph. They know anything about RDF, they don’t know anything about SPARQL. So all they’re saying is, “Since this data is the knowledge graph, please, I want…” I don’t want to say in abstract, but let me say something like this.
Emeka:
Okay, so you could say, “What’s the best treatment, maybe, in that agent’s interaction?” You could ask for, “Please get me the best treatment of the patient’s diabetes from maybe a known link open data instance.” And then what the server does is it’ll not pull all the nodes. So remember that the question is in English language, but it’ll now be converted to a SPARQL statement that will pull all the nodes, maybe say the insulin therapies, similar patient profiles, research going on in that area because it’s all about graph of context. You understand? This is the beauty thing. So you see, the reason why I’m emphasizing this is that it solves a problem that RAG introduced, the bringing of static data from vector database. Static data from vector database cannot be an answer for knowledge.
Emeka:
So what MCP does is that in this conversational natural language prompt, it now pulls down the graph with all the context. So now imagine that you’re talking about diabetes and we can pull information on the latest research on diabetes, so that will form the basis on how the model would respond. It enriches the answers that will come out, but the developer that wrote the application does not know SPARQL, does not know RDF. So that’s what the RDF Explorer does.
Larry:
This is so awesome. We talk all the time in this community about how hard it is to onboard people and everybody complains about it, but nobody’s doing anything until Emeka came along and fixed it with his MCP server. I love this.
Emeka:
We have to thank people like you, Ora, Pete, Kingsley, Neal, everyone, because we all talk about it. In our community, we’ve been talking about this for years. We’re all part of the puzzles of the solution. Everybody. Everybody is. So I do my own-
Larry:
What I was just saying, I’m kind of half-joking about that, but truly, so much of that has been architectural and really internal nerding out about how to craft. I think of my conversations like Jans Aasman and Tony Seale and people like that about how to craft these neuro-symbolic architectures, and this is one of the benefits you’ve talked about a couple of times is the simplicity that this client-server arrangement affords. You just create a server that does this specific thing that like, “Hey, you want access to this knowledge graph? Let me give you a natural language interface to that. Here. Here’s some data.”
Emeka:
Yeah. The developer that is solving the problem does not understand how a knowledge graph looks like. He just knows that it’s a kind of database of answers. If you post in a question, it’ll come out with an answer.
Larry:
Yeah. You know what’s interesting about that, as I think about that, I’ve done a lot of content modeling and data modeling stuff over the years, and I’ve always been the designer getting from the conceptual models and then sitting down with an engineer to work out the implementation model. And often, almost always, it’s been a relational database, but who cares? Ultimately, you don’t care. If you can execute on that, the needs articulated in that conceptual model. If it’s NoSQL or a relational database or it’s triple store, who cares, quite literally. And so you’ve taken out that, “Who cares?” part. You’re just like, “Really? I don’t care. Here, you want this data? It just happens to be in a knowledge graph. Come to my MCP server and you can get it.” That’s the idea, right? Yeah.
Emeka:
Yeah. So that’s how powerful it is. It’s really, for me, it’s very powerful. I haven’t started talking about a whole lot of benefits, but yeah.
Larry:
Well, yeah, and you really are just getting started because the obvious thing about LLMs is their conversational interface, like, “Great, let’s do that. Okay, that’ll be the interface for this thing.” But there’s so many other benefits. There’s been this talk for years of the ostensible failure of the Semantic Web. We know that it’s pretty well entrenched in a number of places, but this seems like a way to just avoid that whole conversation. You don’t have to care about the Semantic Web. I can just get you this nicely structured data that’s going to help your AI system work better because of all the things that we know about the benefits of an ontologically driven, structured knowledge product. That wasn’t really a question, but I’m curious.
Emeka:
No, no, no. It’s just funny that people are trying to separate knowledge graph from AI. I mean, it is the brain. Unfortunately, a lot of people who don’t understand what knowledge is to intelligence. People should be worried because we don’t think in numbers. People need to embrace the knowledge graph because it’s brain-like. It maps like the brain, it connects data, it connects the meaning, it connects the context, and it’s very important. Context is what they all try to do in similarity set with vectors. I mean, it is called similarity search for a reason. Similar.
Larry:
Exactly. Yeah. What’s interesting about that to me, is that the neural network side, it’s so powerful and it’s based on if you just look at a picture of how neurons work with your brain. That’s the foundation of that famous 1945 paper where you’re trying to mimic human neural activity with a computer. There’s sort of that, and I think unless you dive a little deeper into it’s hard to see the conceptual difference between using that kind of structure to learn stuff versus using another kind of graph structure to ensconce knowledge. It’s not like it’s even subtle. It’s a huge difference. But I think a lot of people have trouble teasing out. I love that you’re at the forefront of integrating neural tech and symbolic tech. Do you have to explain it to people or do you just show them the benefits of having done it?
Emeka:
I have to explain it and I have to show it, like I said, which you can confirm. I’ve been talking about this AI tribalism for a long time, and I said, “It’s going to have some implication.” We’ve been talking about this for four or five years. You open a website in the next few years, AI, the … I mean, that can’t be true, something is very wrong. So a lot of people came into AI thinking that AI is all machine learning, all deep learning. You understand? And that’s the foundation of disaster. So you can’t separate knowledge. You can’t say, “Oh, let’s bring knowledge to AI.” No, AI is based on knowledge. You’re not doing any favors. It’s not like you have a choice. AI is from knowledge. So they need to understand that intelligence is at the center of symbolic AI.
Larry:
As you talk about that, I’m reminded of a number of people have used the analogy of Kanehman’s Thinking Tast and Slow. Like the neural stuff being the fast side, the systems one and the knowledge stuff being the systems two. But a human brain rarely does any either of those separately. They’re always working with each other. And to this point though, to what you were just saying, everybody’s like, “Oh, LLMs can fix everything, and that’s all we need.” And it’s like, “Actually this knowledge stuff is important too.”
Emeka:
LLM is all about human writing and human thinking. So when we write, we think well, and that’s what you see in the writing. That’s what LLM has taken in. But because they can predict on our human thinking, again, human thinking, because it comes from writing, it looks as if they’re intelligent, but they’re not. They are actually smart. Actually smart, yes. They get into problem when intelligence is needed and they don’t have the skills of zero cognition. That is, they cannot make anything out of nothing.
Larry:
Yeah. And that’s their problem right now is they just need bigger and bigger learning sets to do anything. But hey, Emeka, I could talk about this stuff all day with you and we will continue it soon, but we’re coming up on time today. Is there anything last though that you would like to revisit from the conversation or share with people before we wrap up?
Emeka:
Yeah, I could talk about some of the learning points from… One of my biggest takeaway from this is the lean protocol of MCP made everything look minimal. It removed all the complexity and also showed the power of our words is conversation. You understand? The language. So we need to understand that language models are good servers for language tasks. MCP breaks it down easily for it. So that was the first thing for us. So MCP removed a lot of complexity in integrating language models and knowledge graph. Something again is the tooling, the tooling gap. So the tools to create semantic technology solutions is now available easily. Language models can do that because they understand semantic technology. They have been trained on W3C thing, so they have that understanding of the specs. We need MCP to be that interface to make it easy to create things that is Semantic Web related. So that’s the beauty of the MCP and all that.
Emeka:
One other thing I haven’t mentioned, let me quickly mention, which was in the parts where I was creating the MCP server for creating ontologies, is that when you now create a data, and that one actually blew me. I can actually check the data that I created. I have an employee ontology, so I want to be sure that the data is all right. I can easily query MCP to find out if employee is an organization because I want to be sure that the ontology was created right. You understand? And if it wasn’t created right, I would get an error message that no MCP. Now this is the beauty. Employee cannot be an ontology. So I actually created an RDF file where I made employer an organization and I put it to MCP and I said, “MCP, please tell me what’s wrong with this.” “There’s no way an employee can be an organization.” That easy. Yes, and I just issued the word, “Okay, fix it. Employee is the person that works for an organization. Please help me fix it.” And that was it. He fixed the RDF. Yeah, this is – It’s just to tell you what MCP does for us with Semantic Web technology.
Larry:
Well, I don’t know if we’ve talked about this specifically, but it comes up. I mean, my whole intent in doing these podcasts is to democratize practice and at the highest level possible. And if you can make the benefits of semantic tech accessible to any old engineer or architect anywhere in the world, just by giving them a conversational interface to it with RDF Explorer, awesome. That’s like democratization on steroids. So thank you.
Larry:
Hey, one very last thing, Emeka. If folks want to follow you or connect online, what’s the best place to find you online?
Emeka:
LinkedIn. LinkedIn. LinkedIn, where I’m comfortable with the community and I share my knowledge.
Larry:
Yeah, kind of the last social network standing, I think, for people like us anyway. Well, yeah. Thank you so much, Emeka. I mean, it is always great and we talk all the time. It was really awesome.
Emeka:
I’m honored being here. Thank God I’ve made it. I hope to come back. I talk more on MCP and other things as well.
Larry:
Yeah, we’ll have to check in a year or two, see what else you’ve done with it. So, yeah, absolutely. Cool. Well, thanks so much.
Emeka:
Yes.
