For this week's GraphCentric Weekly, I want to report back on my visit to the Knowledge Graph Conference in New York.
A theme of the conference was context. In one of the closing keynotes, Prukalpa Sankar declared that context is king, in reference to the 2000s mantra that content is king. Context graphs have become a hot industry term, with Foundation Capital calling them the next trillion-dollar opportunity.
The context of this discussion is that the hype around AI does not appear to be reflected in actual industry return on investment. Too many organisations report that AI projects are not delivering the improvements they first hoped for. Models still hallucinate to a degree that makes them difficult to build reliable business processes upon. The hope is that better context will improve their output.
What Do We Mean by Context?
There are many interpretations of context: sources of knowledge, traceable inputs to business decisions, metadata, and disambiguation, especially in relation to entity resolution.
The problem is that businesses often do not collect this context information. If they do, it is likely scattered across spreadsheets, Slack conversations, operational databases, and emails. That makes it complicated and time-consuming for both humans and AI agents to access. Wasteful delays matter even more when much of the value of AI agents is the speed at which they operate.
If we can gather this information and connect it in a way AI agents can access easily, those agents become far more effective.
From Context Graph to Semantic Layer
As expected, there is strong support in the Knowledge Graph community for symbolic AI. Lean too hard on AI inference and you reach limits: hallucinations, circular reasoning, or the familiar sense that the model is going round in circles. If you are making pancakes, you cannot get far with just flour or just milk. You need both. A context graph that includes symbolic AI becomes a semantic layer.
Jim Hendler, co-author of the seminal 2001 Semantic Web paper in Scientific American, made a compelling case in his talk with Deborah McGuinness. He argued that a true semantic layer must rest on graph technology and, crucially, a Linked Data Platform. His point was powerful: the highly interconnected nature of business context cannot be adequately captured in tables.
This aligns closely with the core design of GraphCentric: applications write directly to a shared context graph, with resources, links, and update behaviour defined in RDF from the start.
Building Your Semantic Layer
Many vendors are working to gather up the context scattered across organisations. That is one way to approach the problem, but a key part of building a semantic layer is restoring the meaning that evaporates as data flows from place to place.
The problem starts further upstream. As anyone who has worked with a real-world transactional database will affirm, much of the meaning of data can only be found inside application code and never makes it into upstream operational databases in the first place. This is the application centrism that Dave McComb has long argued against, and why a more holistic strategy is needed.
For this reason, it is better for applications to share a context graph and use it to store their data directly. This allows the different parts of context to be stored together, no matter which application generated them. It also provides more up-to-date and reliable context because it does not have to wait downstream behind ETL pipelines and data transformation processes.
Converting legacy systems may be too ambitious as a first step, but we should consider this strategy for new systems. Think big, but start small.
This is the architectural design of GraphCentric, a platform you can build on today. If you want more information, get in touch.