Untangling Graph Technology: A Q&A with GraphGeeks Founder Amy Hodler

Many AI leaders argue that graph technology is the next trillion-dollar opportunity. However, there are many types of graphs on the market – RDFs, knowledge graphs, property graphs, or context graphs. These are used almost interchangeably and most people don’t know how they relate to each other. 

Today we answer those questions and more. We sat down with GraphGeeks’ founder Amy Hodler for a deep dive into all things Graphs. For those who don’t know her, she is a pioneering graph analytics expert who built a global community dedicated entirely to the power of connected data.

We started from the beginning, using simple vocabulary to explain how graphs are currently reshaping AI. You will learn why the most important work in this field is also the least glamorous and where the technology is headed next.

Understanding the basics of graphs

Q: What Is Graph Technology?

Graph technology is a modern way to organize data that focuses on how to connect different pieces of information together. At its core it “connects the dots” rather than just store information. Graph technology utilizes “nodes” (for things like products and people) and “edges” (for the relationships between them) instead of traditional rows and columns. Because those relationships are stored directly in the data, retrieving the information is fast, without the multiple lookups that a traditional database requires.

Knowledge graphs, RDF, property graphs, and context graphs are all types of graph technology, each modeling those connections a little differently.

Q: What’s the actual difference between a knowledge graph and a knowledge base?

Let’s start with defining what is the main idea and philosophy behind knowledge graphs.

A knowledge graph, at its core, is just interconnected facts, structured with the intent of helping a human understand a domain of information. That definition is independent of any backend technology. You can technically have a knowledge graph that isn’t stored in a graph database at all, as long as the front-end experience preserves how things relate to one another. In a knowledge graph, relationships matter just as much as the entities themselves.

The differences lie in how they search and serve information. Ask a knowledge base to define the Eiffel Tower, and you’ll get facts: height, location, weight. 

A knowledge graph answer, on the other hand, will respond with its cultural significance, who built it, where it sits in a broader hierarchy of concepts. That’s because a knowledge graph isn’t trying to define a term but answer specifically using the context of your question.

Q: Here is a controversial question: Do you actually need a formal ontology to have a knowledge graph?

No, you don’t need one to have a functioning knowledge graph. But this is exactly where things get really fuzzy. Here’s where knowledge management professionals and librarians tend to push back, since an ontology is usually what defines the context for all the relationships in the graph in the first place. 

That approach is called bottom up, and it skips using any formal ontology or schema so we can get something of a “flexible” knowledge graph that allows for different creative solutions to very ambiguous problems.

A good example is the use of an anonymous node. This is a node you know exists but haven’t defined yet. In real life you often know something is there before you know what it is – the unknown unknown. Placing it in a graph, even undefined, can actually help you figure out what it is. That said, the best property graphs for enterprises still tend to have ontologies behind them and work better with them.

Q: Where would a fuzzy and flexible knowledge graph be the best approach?

A strong example is crime or fraud investigation, where you often don’t know in advance what you are looking for. The evidence may be incomplete or disconnected, so the graph needs to evolve as clues emerge.

You might not have every node, but you know that if a particular piece existed, everything else would click into place. A flexible knowledge graph lets investigators add these possibilities, as “what if” scenarios, and test whether they can clue you want to investigate next.

For example, a missing person, company, account, or transaction might explain several otherwise unrelated connections. If adding that hypothetical element makes the rest of the graph fit together, it gives investigators a concrete lead to verify in the real world.

Inferred relationships don’t carry the same confidence as verified facts, but they can still carry utility. As long as inferred nodes are clearly marked, they allow teams to explore hypothetical patterns of the “unknown unknowns” that a rigid model might miss.

Q: What is a context graph, and how does it differ from a standard knowledge graph?

Context graphs are used to analyze how AIs have made a decision, now. You can also call them decision graphs. Their purpose is simply to capture what AI just did and what decision got made in the moment. A regular knowledge graph, conversely, acts as the single source of truth instead of watching over AI’s decisions.

We are in the early stages of using this type of graph. But in the future, context graphs can become a dossier of an AI agent’s behavior. It will not only remember the steps it took, but the policy it was following, or what it was told last week that’s still shaping its decisions today, and how that’s shifted over time. 

Push that even further, and a context graph can evolve into something bigger we call an environmental graph. It can show not just what one agent is doing, but what all of them are doing together. Picture a decision log that tracks why an analyst — or a system of AI agents — chose to sanction a certain company. Suddenly you have a full view of those decisions, and you can check whether, say, a $1 million fine was justified. That’s what brings real transparency and accountability to those types of systems.

RDF vs. Property Graphs

Q: When we go one level down to the backend, how do RDFs and Property Graphs compare?

They’re about how that data gets modeled on the backend. RDFs tend to be used when the priority of the company is managing knowledge and information itself. However, property graphs lean more toward computer science and analytics to understand trends and patterns. 

Q: How should a team decide which one to use to begin with?

Eventually, more people will end up using both RDFs and property graphs because they’re built for different strengths you will be interested in.

Property graphs store properties directly on nodes and relationships, which makes for a compact representation of nested detail. That matters because it enables fast, computer-friendly traversal — which is exactly what you want for app development.

Use property graphs as a starting point if the priority is analytics, algorithms, whole-graph analysis, and flexibility for app development teams.

RDF, by contrast, structures everything explicitly as triples. Meaning capturing all the attributes of the Eiffel Tower might take hundreds of nodes. That makes RDF sprawl, but the same rigidity makes logic far easier to enforce, which is exactly why it’s a great transport layer (a shared, structured format you can move between systems).

Use RDFs as a starting point if you have to enforce guardrails. It’s the standard in industries like biotech, and why it underpins financial standards like FIBO (the Financial Industry Business Ontology). Anywhere there’s heavy business logic, serious knowledge management, or strict compliance guardrails to enforce, RDF is the natural starting point

Q: You mentioned most people end up using both RDF and property graphs. How would that actually work?

Yes. App developers usually benefit from this approach. 

Say you’re building a customer-facing app your team can use a property graph to move fast, testing out ideas and “what-if” scenarios as they build. But once that data needs to go somewhere stricter like, proving to a regulator that you followed the rules it should move into RDF. RDF is what enforces the rules and structure you need. In this setup, RDF becomes your official, trusted source of truth, while the property graph stays the fast, flexible tool your developers work with each day.

Q: What are the best practices for moving that knowledge between different teams and systems? 

A good starting point is to treat RDF triples as facts and store them in a format that’s portable across systems for example, vectors. That doesn’t replace a classic knowledge graph sitting in a graph database but solves a different problem. 

Most organizations have multiple teams working across different systems that all need access to the same facts, and a vector representation is simply easier to move around. This is where RDF earns its reputation as a transport layer, and where hypervectors in particular shine. They’re efficient at capturing large amounts of information while staying flexible to work with.

A useful way to think about it: RDF and property graphs are the endpoint. They are the format your subject matter experts actually work in. But that knowledge should be able to be extracted and transformed so different teams can collaborate using large vector representations instead.

Graphs, AI, and the reality of implementation 

Q: Everyone is talking about AI integration right now. Can you just hand an AI a knowledge graph, or do you need GraphRAG in between?

Knowledge graphs help AI agents make better, more auditable decisions – that’s a fact. However GraphRAG is only the most visible piece of a much larger picture. You can connect the two through MCP servers, through APIs, or through several other integration points. Most importantly, integration should happen at multiple stages of an agentic workflow, not just one.

Most companies stop at GraphRAG and assume there’s no more value left to extract. But knowledge graphs can also help form better questions for an LLM in the first place, so that its response actually matches your schema or ontology and reflects how your product or customer data is really structured. Context graphs can add another layer on top of that to monitor the questions, answers, and queries flowing through your agentic operations, and turning that history into a template for future interactions.

Q: What is the biggest mistake or challenge businesses run into when trying to implement this?

Businesses don’t focus on the fundamentals like data cleansing and documenting data lineage. Instead they focus on trying to maximize the prediction accuracy even by little margins. They focus on using newer AI models, having more downstream training or spending more tokens. But that focus can miss the larger, less glamorous work that has to happen upstream: improving the quality, structure, and meaning of the data in the first place.

Companies need clear ontologies and shared definitions, and almost nobody wants to have that conversation. What does “customer” actually mean? If different teams define it differently, it doesn’t matter how good the model is because the answers will still be wrong, just produced faster. That’s the highest-impact work, and it’s also the least exciting: aligning business logic, cleaning up data, and getting teams to agree on what terms like customer, revenue, and region actually mean. Without that foundation, engineers and models are stuck working with inconsistent assumptions, capping the value of any AI or analytics effort built on top. 

This is actually somewhere AI can help. It can dig through the messy, siloed data that’s hard for a human to make sense of, and propose a clearer, shared definition for a term based on how your own company already uses it. From there, you bring in your SME to review and refine it. 

Q: What skills do teams need to build effective graphs for better AI results?

You need people with a knowledge management background who understand ontologies and can hold that flexibility while working alongside computer scientists. Add people who understand how LLMs work and how information gets structured, data engineers who can bridge across teams, someone who understands agentic workflows end-to-end, and graph specialists who know the underlying technology. That’s a lot to assemble and it’s not realistic for every company to build from scratch.

That’s where working with a specialized vendor like Graphwise makes sense. It’s often easier to bring in outside expertise to augment what you already have, while your own team remains the actual subject matter expert. The more you build out externally with the right partners, the easier it becomes to eventually bring knowledge management expertise in-house.

Industry adoption curve and the future

Q: Looking across the market, which industries are leading the pack with graph technology, and which are lagging?

For Knowledge Management

Media companies are ahead. They have massive content libraries to distribute and naturally lean into that library sciences thinking. Biotech is also ahead because of the rigorous structure needed to evaluate genes and genomes.

For Computer Science

Banking is adopting it fast and it splits two ways. First, in fraud detection, there’s a lot of money and incentives. This couples with cybersecurity since both rely on pattern recognition and analytical thinking, which graph tech supports well. The second split is regulatory: governance, compliance, loan approvals – they need stricter ontology for those applications.

In Supply Chain

Some companies are making amazing advancements, others aren’t. This will likely change because the supply chain is literally a knowledge graph connection on a global scale.

Emerging Adopters

Manufacturing is a lagger that’s about to commit. Semantic digital twins are making a comeback. Legal is interesting too because there are massive amounts of documents and videos to review, and even big teams miss details or broader patterns. Graphs and AI together are solving that pattern recognition problem.

Q: So where is all of this headed?

Toward what we call a hyper-hybrid future.

Multimodal graphs are already emerging. These graphs go beyond text. They map images, including the spatial relationships within a photo. They also map sound, linking a tone or pitch to something concrete, like a specific bird’s call. Expect more combinations like these: graph plus audio, graph plus image, graph plus vector. Many of these combinations haven’t been mapped out yet.

I think the current instinct to keep RDF and property graphs strictly separate is backwards. People are going to start combining RDF, property graphs, and structures that don’t cleanly resemble either one — and the real challenge will be figuring out how to organize all of that together. Which, in a way, brings this full circle: that organizing structure is itself just another graph. The endpoint is a multi-layered graph infrastructure, where individual graphs are organized inside an overarching graph that ties them all together.

Conclusion

Graph technology is complicated. You have many different definitions and technologies surrounding it. However the main takeaway from our conversation is pretty simple. Different graphs solve different problems, and none of them matter if you don’t have clean data and shared definitions behind them. As AI becomes more embedded in business, graphs will likely play a bigger role in making systems more useful, connected, and accountable. 

A huge thank you to Amy Hodler for so generously sharing her time, clarity, and hard-won expertise with us.

Curious how this plays out in practice?