Most people don’t notice because they don’t know what it is. A reasoning engine is a system that derives facts you never explicitly stored. For instance, the sub-classing idea is transitive, it knows that if Mammal is a subclass of Animal, and Dog is a subclass of Mammal, then Dog is also a subclass of Animal. This is revealed without you asserting it. Given a rule that says “a person who authored a paper at institution X was affiliated with X,” it infers the affiliation. You assert the minimum; the engine closes the world (infers the unspecified).

This is what OWL entailment and RDFS semantics gave RDF triple stores in 2004. Formal, auditable, reproducible inference. Load a consistent ontology, run a reasoner like HermiT or Pellet, and your graph knows more than you told it.

Property graphs (Neo4j, Memgraph, Kuzu, TigerGraph…) have none of this. You write Cypher. You get back exactly what you put in. The graph cannot derive a single fact that wasn’t explicitly asserted. The schema is flexible and the tooling is excellent, but the semantics stop at the storage boundary. If necessary people used to create it in the business logic (layer).

Nowadays everyone is wiring LLMs on top of property graphs and calling it “AI-powered knowledge reasoning.”

Well, it isn’t. The LLM is guessing the inference layer inconsistently, expensively, without auditability, and without any guarantee of logical consistency. It depends on the (size of) model, how it fits the data, the language and more. A reasoning engine gives you closed-world guarantees. An LLM gives you a confident guess.

The reasoning gap in labeled graphs is not a footnote. It is the central unsolved problem in production knowledge graph deployments and almost nobody in the LPG ecosystem is talking about it. It’s inconvenient.

Don’t get me wrong, I worked with and for Neo4j, with and for TigerGraph. I like LPGs and advise customers to go for it, if I am convinced it’s the right choice. What I try to emphasize is what you get and what you think you get out of LPGs via LLMs.

OWL Implementations: https://lnkd.in/eVXHkjYn

It’s a Python library for graphRAG on plain Postgres. You point it at a directory of documents, it ingests them (the whole lot: chunks, embeddings, entities, relationships, full-text index) and you get back a query API that combines vector similarity, BM25, and graph traversal. All retrieval happens in one round-trip to Postgres. It is also a full toolkit around that library: a CLI , an optional FastAPI server with a web UI and an MCP server for Claude Desktop/Cursor/Zed.

Most graph RAG tools graph-ify everything up front. This one inverts that: start with vector+BM25 and only pay for graph traversal (local/hybrid modes) when the naive retrieval confidence is low or do a cheap 1-hop re-rank (naive_boost) otherwise. It matches what you’d expect analytically: graph structure helps disproportionately on multi-hop/cross-document reasoning and is close to useless on self-contained prose. Their own benchmarks bear this out.

I love the honest benchmark and the comparison with Apache AGE. Plus a forward look at the SQL/PGQ innovation in Postgres v19. It’s a single dev no-star repo but this does not diminish the innovative way of looking at things.

https://github.com/yonk-labs/pg-raggraph

They now have more graph stuff than almost any vendor and yet almost none of it means or feels “graph”. One thing is certain, it’s not the way RDF/OWL practitioners have used the word for twenty years.

Let me recap, because the vocabulary is getting loose fast.

There is a Graph in MS Fabric, a native LPG-graph engine on OneLake, queried in GQL (great!), with serious infrastructure, not a bolted-on acquisition. Microsoft’s docs are explicit: LPG only, RDF isn’t supported, no IRIs, no ontology language, no formal semantics.

There is NL2GQL, a natural language to GQL traversal. The idea here is that agents execute deterministic queries rather than infer structure probabilistically. That’s grounding, not reasoning even though they call it “Graph-powered AI reasoning” 🫣. It’s the more trustworthy design choice. In comparison, the Databricks Mosaic AI Agent Framework has tool-calling agents that register a Neo4j graph as a retriever tool, so an LLM agent interprets natural language and queries Cypher through that tool. SAP has a somewhat similar HanaSparqlQAAgent.

There is Fabric Ontology (inpublic preview). This is a business-vocabulary and data-binding layer bound to real tables, projected as an instance graph. The docs lists rules and constraints as part of the definition. I could not find a single worked example of a rule actually being evaluated 😱 Others have also noted that without a measures layer, how does the system know what “delayed flight” means when different teams define it differently? It’s currently unanswered.

Finally, Cosmos DB, with an AI-native push here (MCP Toolkit, Agent Memory Toolkit, Semantic Reranking). Gremlin first, not very popular but do contradict me.

The famous GraphRAG of 2024 is now explicitly in maintenance mode and has been followed by LazyGraphRAG with mixed reception.

I will not mention the Office graph since it’s not worth calling it a graph. Or the “ontology editor” (https://github.com/microsoft/Ontology-Playground) they vibe coded.

The missing bit in all of this is reasoning, across all products. If you’re evaluating the MS stack for a client, the honest assessment is that they have excellent infrastructure but zero inference and ontology. Where do you send them for the reasoning layer that Microsoft doesn’t have? Palantir, mid-size solutions (Fluree, Stardog,…) or custom development? Likely simply agree that ontology is costly, inference is next-phase…

• Fabric: https://www.microsoft.com/en-us/microsoft-fabric
• Project GraphRAG: https://www.microsoft.com/en-us/research/project/graphrag/
• Fabric Graph DB: https://learn.microsoft.com/en-us/fabric/graph/graph-database
• CosmosDB: https://azure.microsoft.com/en-us/products/cosmos-db

Bitemporal annotations and degradation are not enough, there is so much we can’t know for sure, intrinsically or practically.

The prototypical example is “person X is an expert in topic Y”. You see this in skills graphs, talent intelligence platforms, research networks, customer success graphs. This type of triple (or edge) when used transitively, with downstream reasoning, graph ML…leads to absolute conclusions while this is in fact a prior in need of a probability distribution. Enter Bayesian networks (belief network, probabilistic graphical models).

There are many reasons why we don’t use Bayesian techniques with KGs. Well, in general really. It’s mathematical, it’s difficult, it adds yet another layer of abstraction on top of ontologies, there is no database (storage) support, the query languages do not propagate uncertainty automatically, RDF at its deepest level should include a factor with every triple (confidence level) and more. Scalability is a big issue. Computing would involve Monte Carlo simulations and require GPU processing to scale.

There used to be a BayesDB database on Github, but it did not get the success it deserved.

There is a market gap because the knowledge graphs being built today are not hand-curated encyclopedias. They are extracted from documents by LLMs, assembled from web scrapes, merged across conflicting sources. The uncertainty is not incidental, it is structural. An LLM-extracted triple and a manually verified one sit side by side in your graph, indistinguishable, treated with identical epistemic weight.

Not really a knowledge graph, more like a confidence laundry machine. What is actually needed is a native probabilistic graph store where confidence is a first-class citizen of the data model, not a property you bolt onto an edge and manage yourself. Where query semantics propagate belief through traversal rather than silently dropping it. Where new evidence updates a distribution, not just a value. Where you get a posterior back alongside your results, not just a ranked list you are expected to trust blindly.

There is a huge amount of research on this, the academic foundations are solid but the business world is not there yet. The database does not exist yet. The query language does not exist yet. The market does not know it needs this yet.

Curious when/if it will happen.

On a philosophical level, how does a brain handle so well uncertainty, what would it take to implement probabilistic neural AI? Claude Fable, now with uncertainty included? GPT answering with “I am not sure, but it’s very likely that…”. It’s how we, humans, answer things.

OpenSPG (Semantic-Powered Graph) is an advanced open-source knowledge graph engine developed by the Ant Group (China). The v2 documentation details a framework explicitly designed to bridge the gap between traditional structured business logic and modern unstructured AI data. Its primary focus is on seamlessly integrating Knowledge Graphs with LLMs to create reliable, interpretable, and scalable enterprise AI applications. It’s knowledge augmented AI.

You get semantic-powered modeling. OpenSPG moves beyond basic property graphs by allowing users to define strict, domain-specific semantics. It supports modeling entities, concepts, and events, enabling the system to understand the meaning behind the data rather than just the connections. The GraphRAG and LLM Synergy is a major focal point and uses LLMs to extract knowledge from unstructured text and build the graph, while simultaneously using the structured graph to ground LLM outputs. This creates a closed-loop system that drastically reduces AI hallucinations. There is also an interesting logic & ML integration. OpenSPG combines symbolic logic (rules and schemas) with statistical machine learning, allowing for high-precision knowledge reasoning and extraction.

The whole things is geared towards risk management and compliance. It’s made for applications that rely on tracing complex relationships, events, and logical rules across massive datasets. A wish I hear in many conversations and meetings.

OpenSPG: https://openspg.github.io/v2/

Google just shipped the Open Knowledge Format (OKF): markdown files with YAML frontmatter, cross-linked, version-controlled, git-native. Genuinely useful. Also, it’s not a knowledge graph, despite the marketing copy calling the link structure exactly that.

A directed graph of markdown files linking to other markdown files is a web of documents. A knowledge graph is a graph of entities and typed relations, not a hyperlink a human (or an LLM) has to interpret by reading prose.

OKF’s only structural guarantee is one required frontmatter field, called ‘type’. Everything else, what relations mean, what a link implies, whether “links to” means “depends on,” “is part of,” or “see also” is left to the producer. That’s not a knowledge graph schema, that’s an undefined edge label pretending to be one. So, once again the concept of what a knowledge graph is, is being abused.

This matters for agents specifically. An LLM reading an OKF still has to infer the semantics of every link from surrounding markdown text, every single time. A real KG with RDF/OWL or a property graph schema lets you skip that inference step entirely. The relation type is already explicit, queryable, and consistent across the whole graph. One does context-stuffing for a model that re-reads and re-interprets. The other does retrieval and reasoning over structured relations that don’t need re-interpreting.

Now, of course, Google wasn’t going to push the whole RDF stack into the hands of SEO people. Markdown was inevitable, especially with the whole OpenClaw spirit hanging around. So, OKF solves a real problem but also a bit a missed opportunity. Calling markdown-links-as-graph a “knowledge graph” is misleading.

Introducing the Open Knowledge Format

The latest being “prompting is dead” or better known as agent loops. In essense, agents that plan, act, observe, and try again. You define the goal but not the path. The implicit promise is that these loops get smarter over time through reinforcement learning (RL).

Thing is that RL needs a reward signal and for most agent tasks (“research this,” “fix this bug,” “summarize these documents”), that signal is mushy. You end up scoring free-text outputs with another LLM as judge, which is shaky ground to build a learning loop on.

Once again, I think that graphs are inevitable.

A graph gives you something checkable: did the agent retrieve the right subgraph, does the extracted relation actually exist, does the path it followed lead somewhere correct. Recent work (like Graph-R1, AgentGL) builds exactly this kind of RL loop: “think → query → retrieve subgraph → rethink” with an explicit, structural reward at each step.

My personal conviction has actually more to do with how nature exhibits intelligence than some marketing for my own graph expertise, but that’s an altogether different topic.

There is a real opportunity here beyond “KGs ground your agent’s answers”: graphs give RL something solid to learn against. For document-to-knowledge-graph extraction specifically, this matters directly. Extraction is a task with checkable correctness, entities and relations either match a schema/gold graph or they don’t. That makes it a much better candidate for an RL-trained agentic loop than a single-shot LLM extraction pass.

The agentic loop hype glosses over this. Loops don’t automatically get better, they need something to push against. Structure is what makes that possible.

AgentGL

Most graph versioning conversations stop at temporal tracking: valid-time, transaction-time, bitemporal models that let you ask ‘what did this graph look like last Tuesday’. This is useful for audits, but less for asking ‘what would this graph look like if I changed it’.

The need for this is more common than you’d expect. In some of my projects it was, in fact, crucial. Clinical trial optimization (what if we do this before that?), logistic optimization (will cost be reduced if we reroute via this path?), water mining network optimization… Using a computational graph with, say, AMPL or Gurobi is a powerful technique.

Now, git-like versioning is a different proposition. Branching, commits, diffs, merges applied to graph state rather than file state. The operational payoff: a knowledge graph branch is a sandbox for simulation, not just a snapshot in history. Branch off production. Remove a supplier node, add a regulation node, reroute a relationship, bulk-reclassify a taxonomy. Run your queries, your centrality measures, your SHACL validation against the branch. See exactly what breaks, what cascades, what gets quarantined before any of it touches the graph people actually depend on.

That’s a fundamentally different workflow than ‘…log the change and hope someone checks the diff later’. It’s closer to how software teams treat infrastructure.

Few graph databases do this properly and most claim versioning and deliver an append-only changelog. The distinction matters, a changelog tells you what happened while a branch lets you find out what would happen, on the actual graph, with actual constraints, before you commit to anything. Note that all of this is not specific to RDF or LPG (or TypeDB, SurrealDB…).

⚛ TuringDB is one of the few actually built around this. Its storage layer is columnar and immutable by design which is what makes git-like branch/commit/merge semantics possible without locking readers out while writers experiment. You create a change, mutate it however you like, query it under snapshot isolation, and only merge to main once it survives scrutiny. Versioning isn’t bolted onto the engine after the fact; it’s the structural reason the engine can do zero-lock concurrent reads and writes at all.

If your pipeline already includes validation, branch-based simulation is where that validation earns its keep. Not gatekeeping single writes, but stress-testing entire hypothetical states.

⚛ TuringDB

There is an interesting graph RAG paper with the provocative title “You Don’t Need Pre-built Graphs for RAG”

TLDR: graph structures should match the reasoning task, not the other way around.

Here’s what it actually ponders.

Before you can retrieve anything, you transform your entire document corpus into a knowledge graph. That process is expensive (token cost, time, infrastructure), static (stale the moment your corpus changes), and one-size-fits-all. The same graph topology whether your user asks a simple factual question or a deep multi-hop reasoning chain.

𝗧𝗵𝗲 paper’s 𝗟𝗼𝗴𝗶𝗰𝗥𝗔𝗚 𝗶𝗱𝗲𝗮 is to skip the pre-built graph entirely. Instead, at query time:

1. Decompose the question into subproblems
2. Build a DAG (directed acyclic graph) of the logical dependencies between them
3. Use topological sort to determine retrieval order
4. Prune redundant nodes and irrelevant context

The graph is volatile, built for the query, discarded after. Structure follows the question, not the corpus. It doesn’t mean persistent knowledge graphs are obsolete. They shine when you need cross-document entity traversal, long-term organizational memory, or auditability back to source nodes. What LogicRAG challenges is the reflex to always build the graph upfront.

On a more contemplative level, it says what we all know but don’t like: the world is a complex place and every challenge requires a balanced plan of attack, taking into account all sorts of criteria. A good solution is seldom brute force or picking up some general (shall I say, popular) framework.

You Don’t Need Pre-built Graphs for RAG

Everyone is talking about the workflow automation angle and the money. Few are talking about what actually makes this hard.

Connecting 1,000+ enterprise integrations with AI agents isn’t a plumbing problem. It’s a semantics problem. Every system speaks a different vocabulary. Finance calls it a “cost center”. HR calls it a “department”. The CRM calls it an “account segment”. These aren’t synonyms and no LLM will reliably reconcile them at runtime across mission-critical processes.

This is exactly why SAP’s value in this deal isn’t just distribution. It’s the semantic layer they’ve spent decades building: ontology-grounded business data, structured process models, governed vocabularies across ERP, HR, supply chain, and finance.

Without shared ontologies, agentic workflows are just very expensive if-statements waiting to fail at the seams. The real bottleneck in enterprise AI orchestration isn’t the model. It isn’t the workflow engine. It’s the absence of a shared conceptual model across systems. Knowledge graphs solve this. Ontologies solve this. They always have.

The plumbing is finally catching up and SAP knows it.

Personally, I totally love n8n and have used it for years for personal automations, data pipelines and whatnot. If you wanna talk about n8n and knowledge graphs, ping me.

• n8n
• Partnership announcement

Obscure W3C RDF-formats are all around us: RIF, GRDDL, POWDER, SAWSDL, XForms, OWL FULL, CURIE and many more. It’s one thing to make a ‘standard’ but whether people adopt it is something else. Same for HDT (Header, Dictionary, Triples), it gets cited constantly in RDF compression papers. It almost never gets cited in enterprise architectures.

HDT is a binary RDF serialization that separates a graph into three parts: - the Header: plain-text metadata, provenance, statistics, VoID-style descriptions - a Dictionary: every IRI, blank node, and literal gets a numeric Id, sorted into Shared/Subjects/Objects/Predicates for locality - Triples: BitmapTriples encode the graph as a forest of trees rooted at each subject and referencing dictionary IDs instead of strings.

The real result is an order-of-magnitude smaller than Turtle or N-Triples, it’s small enough to sit in memory and triple-pattern lookups work directly on the compressed form. Cool. Well, not really.

The business case gets thin in various ways. First off, HDT is read-only. No updates, no deletes, no inserts. For anything that changes more than occasionally that’s not a trade-off, it’s a disqualifier. Most enterprise knowledge graphs I see are not static. Second, the tooling ecosystem is small and mostly academic. A handful of C++/Java libraries, a reference spec still sitting as a W3C Member Submission rather than a full standard. Third, it solves a storage-and-transfer problem, not a reasoning or integration problem. Compressing your graph doesn’t help you map it to an ontology, keep it consistent or connect it to an LLM’s context window. Finally, almost none of the current GraphRAG stack touches RDF or HDT at all. LangChain, LlamaIndex, Microsoft GraphRAG, Graphiti… all property graphs and vector stores, not triples. Pitching HDT into that conversation is usually a mismatch.

None of this means the underlying ideas are wrong. A handful of the standards did stick: Turtle, SPARQL, SHACL, JSON-LD earned adoption because they lowered the cost of doing something people already needed to do. At the same time, the RDF graveyard is bigger than the survivors and sometimes I feel very concerned when I tell customers about possible semantic solutions. A spec, even a W3C spec, is not evidence anyone is or will use it. Ask who has shipped it under load… Is the imbalance a maturity problem the field will grow out of or a structural mismatch between how W3C standards get made and how enterprises adopt tools? Whenever I hint at this the RDF guards are quick to send me more research papers and unconvincing singular business cases. Reminds me of the R statistical language which also grew out of academia and still feels awkward as an enterprise tool. The proverbial wisdom that the road to hell is paved with good intentions comes to mind.

• RDF-HDT: https://www.rdfhdt.org
• GRDDL: https://www.w3.org/TR/grddl
• SAWSDL: https://www.w3.org/TR/sawsdl
• …many more.

A chord progression is a walk on the tonnetz, the toroidal lattice where every triangle is a triad and every edge is a voice-leading move. Counterpoint rules aren’t stylistic preferences; they’re path constraints on a weighted graph. The parallel fifths prohibition? It’s an excluded subgraph. The resolution of a tritone? A shortest-path problem in harmonic space.

The link between molecules and graphs was figured out decades ago. Graph-native reasoning (subgraph isomorphism, centrality, motif detection) transformed how we understand chemical structure and reactivity. Drug repurposing followed.

Nobody has seriously done this for music (as far as I can see). The patterns are there though. The circle of fifths is a Cayley graph of Z12 (the ring of integers modulo 12.). Modulations are graph homomorphisms between tonal regions. Bach’s voice leading follows rules that look exactly like flow constraints in a network. The question isn’t whether the graph structure exists, it does. The question is whether graph-native reasoning can surface compositional patterns that centuries of human analysis missed.

I don’t think I will get any time soon a customer asking me to help out but I love the idea and what it could reveal. I think the right tool isn’t a music theory thing, rather a knowledge graph that encodes harmonic objects as nodes, voice-leading moves as edges, and lets you query across a corpus the way chemists query molecular databases.

There is an interesting angle related to category theory but I’ll leave that for another post.

• Geometry of chords
• Graph approach to voice-leading
• Musical systems with Cayley graphs

How can it be that this thing has only 63 stars on Github.

It’s a fully client-side knowledge graph editor that runs OWL-RL reasoning, handles Turtle/JSON-LD/RDF-XML/N-Triples, connects to SPARQL endpoints, and does it all without a backend. Just open the browser and start authoring.

For anyone working at the intersection of semantic web tooling and LLM pipelines, give the project a star.

https://lnkd.in/eKmCfAAX Live demo: https://lnkd.in/eHUR3i7c

It’s Azure Cosmos DB extended to support graph traversal as a first-class retrieval strategy alongside vector search and direct database queries.

The technical centerpiece is something they call OmniRAG: a retrieval router that selects the right retrieval method based on query intent. Ask “what is Flask?” and you get a database lookup. Ask “what are its dependencies?” and you get graph traversal. If you ask “what other libraries did this author write?” you get graph again. The system decides at inference time, not at design time. This is a structural insight that the RAG community has been circling for a while, but rarely implements cleanly: retrieval strategy should be a function of query semantics, not a fixed architectural choice.

What is interesting is that a knowledge graph is no longer positioned as a standalone analytical asset, sitting in a separate triple store and queried by specialists. It’s being positioned as part of the retrieval substrate for AI alongside vectors and documents, activated dynamically when relational reasoning is required. That’s a meaningful shift in where graphs sit in the AI stack. Not as an alternative to vector search or as a visualization layer. As the layer that handles the questions vectors structurally cannot answer: paths, hierarchies, dependencies, indirect connections.

They identify three query types: complex relationships, hierarchical structures, contextual paths. It’s where flat embeddings usually fail. You cannot embed “what are all the downstream dependencies of this component?” into a similarity score, you need a traversal. The graph is not a preference; it’s the only coherent answer.

Not everything is bliss, of course. What this doesn’t yet resolve: entity resolution, schema stability as corpora evolve, and the question of who curates the graph structure in the first place. Building the graph is not the same as maintaining it under real-world document drift.

CosmosAIGraph

The new Microsoft Fabric IQ semantic layer ships with an ontology of business entities, relationships, rules and actions, a native graph engine for multi-hop reasoning, and an MCP server so AI agents can discover and act on that semantic context. It’s Power BI’s semantic model, grown up and turned into a graph.

The pattern across the industry is now identical: Microsoft (Fabric IQ + GraphRAG), Google (Spanner Graph + Agentspace’s per-customer enterprise knowledge graph), Cosmos DB’s OmniRAG routing between vector, SQL and graph. I mentioned SAP, Palantir and more some days ago. Everyone has converged to the same thesis, AI without a semantic layer hallucinates. The semantic layer is a graph.

This is good news for those of us building in the knowledge-graph space. The category just got validated by the largest software companies in the world.

Whether jumping on an it-makes-it-easy platform or take time to develop your own ontology, well that’s where it’s good to have a little chat with someone 😊

Microsoft Fabric IQ

SAP just told the world that “the knowledge graph won.”

At Sapphire 2026, Christian Klein put the SAP Knowledge Graph at the core of the new Business AI Platform — 452,000 tables, 7.3 million fields, 50 years of ERP engineering made machine-readable.

If you’ve been following me, you can hear my mixture of joy and suspicion.

Joy, because for decades the graph people were the unfashionable ones. Tables were the thing to do. Vectors were the thing to do. Now SAP — the largest enterprise software company on earth — has bet its strategy on the idea that you cannot ground an agent without a structured model of the business.

Suspicion, because what SAP is shipping is not what most people mean by “knowledge graph.” A graph extracted from 50 years of your own product’s schemas is a catalog of SAP. It tells an agent where the purchase orders live. That’s useful (duh), and it’s the easiest possible knowledge graph to build, because the schema was written in 1995 and it’s called the data dictionary.

The hard problem is the graph of your knowledge — and the ontology behind it, in a proper RDF sense. The decisions in PDFs and Slack threads. The link between a contract clause and a delivery risk no ERP table has ever captured. SAP’s graph does not solve this. By design, it cannot. So when the vendor narrative says “knowledge graphs are now foundational infrastructure,” read the fine print. The market is flooded with knowledge graphs that are really just well-labeled schema exports.

Meanwhile, job titles like “ontologist” and “KG expert” are suddenly everywhere. Funny how many experts appear the moment a category goes mainstream. Business as usual in IT, no offense meant.

The interesting work (extracting structure from unstructured knowledge) is still wide open.

Every RDF practitioner has hit this challenge: you have a triple, and you need to say something about that triple (aka metadata). For instance, who asserted it, when, with what confidence. The old solution is called ‘reification’ and it’s been the wrong solution for as good as 25 years. It requires, in a way, denormalization of triples.

RDF* (RDF-star) fixed this. One triple as subject, annotated directly. Oxigraph, Jena, Stardog and GraphDB all support it now. SPARQL-star gives you query access to embedded triples without reconstructing reification joins.

As far as I can tell everybody in the field has embraced RDF* and, maybe even more important, vendors as well. To be fair, property graphs (LPGs) got this right from day one (applause for payloads as key-value freedom). RDF spent two decades reinventing what edge attributes already gave us, just to stay within triple purity.

I think the lesson isn’t “RDF was wrong and LPG was right”. The world ain’t black-and-white. It’s that statement-level provenance (confidence, source, temporal validity and whatnot) isn’t an edge case that should be bolted onto a graph model. It’s a first-class requirement and a model that doesn’t treat it that way will get worked around, badly, by its users. I silently hope that other needs (temporal and bitemporal graphs, virtual graphs, hypergraphs…) will see the light one day. With appropriate query syntax and instrumentation (tooling).

YouTube video on reification in case you wanna know more

When someone says “We beat GraphRAG without a knowledge graph” I’m all ears. CogBase posted last week a benchmark showing their chunk-and-retrieve pipeline nearly matched graph-based RAG systems on GraphRAG-Bench.

Let’s be precise about what they actually show. They do extract entity-relation triples in their best-performing config. They just don’t resolve, deduplicate, or traverse them, the graph structure is discarded after extraction. That’s a build decision, not evidence that graph structure adds no value.

More importantly, look at what the GraphRAG-Bench tests. Fact retrieval, summarization, and bounded multi-hop reasoning over novels and a medical corpus. Clean, scoped, well-behaved corpora. That’s exactly the workload where a capable LLM with good vector retrieval closes the gap on its own.

A knowledge graph earns its cost at a different problem boundary. Among other things, the cross-document entity identity that no single chunk can resolve. Reasoning about relationship chains that never co-occur in context. Tracking what changed, bitemporal reasoning over evolving document corpora. Knowing what’s absent, not just what’s present.

CogBase has not tested any of this and so, the honest reading of this result is that for shallow QA over a single well-scoped corpus, flat retrieval is competitive. That’s common wisdom, it’s not a refutation of graph structure. It’s a benchmark that doesn’t stress the properties graphs are built for.

• Medium article
• CogBase repo

Most people learning graph databases start with Cypher or SPARQL. TinkerPop barely gets a mention in tutorials. And yet it quietly underpins AWS Neptune, CosmosDB, JanusGraph, DataStax, some of the most serious graph infrastructure around. So what is it, and why does it live in the shadows?

It got launched around 2009, was created at a time when there were already a number of OSS and commercially graphDBs, each using their own proprietary APIs. The idea was to unify graph computing behind a vendor-agnostic syntax. The ODBC/JDBC layer for graphs.

TinkerPop is an abstraction layer over different graph databases. At its core sits Gremlin, a functional, data-flow traversal language.It works with OLTP and OLAP oriented graph DBs, supports imperative and declarative querying, host language agnosticism, and hybrid depth- and breadth-first evaluation with Turing completeness. That last part matters more than it sounds. Gremlin isn’t just a query language, it’s a language and a virtual machine, meaning it’s possible to design another traversal language that compiles to the Gremlin traversal machine, analogous to how Scala compiles to the JVM.

It got stuck with good intentions. Cypher with its declarative style is more intuitive, reads like code, devs love it. Yours included. SPARQL has the W3C. Cypher had Neo4j’s massive evangelism machine and community gravity. TinkerPop is an open source project rather than a formal standard, and the Apache brand doesn’t generate the same ecosystem momentum as a well-funded graph vendor.

Roughly 30 graph vendors today support Gremlin, making it arguably the most widely deployed graph query language in production infrastructure. The graph query language landscape is fragmenting. GQL is being standardized. Every major database vendor has a slightly different dialect. In that world, TinkerPop’s original thesis (a single abstraction that runs anywhere) becomes more relevant, not less. If you’re building knowledge graphs, fraud detection pipelines, or identity graphs at scale and want to avoid vendor lock-in at the query layer, TinkerPop is worth understanding. It’s the graph framework that doesn’t market itself. But it’s doing a lot of the heavy lifting.

Gremlin

The data should not dictate the ontology, unless the data exactly reflects your focus. In this sense, most ontology designs start in the wrong place.

You look at your documents, your database schemas, your existing data and you build an ontology that reflects what’s there. It feels empirical and safe, but often it’s also backwards.

An ontology is not a description of your data, rather a statement of what you care about. It defines the concepts, relationships, and distinctions that are meaningful to you not the ones that happen to be easiest to extract.

If you run a pharmaceutical company, your ontology should encode what matters to drug development: targets, mechanisms, adverse events, trial phases, regulatory pathways. Not whatever noun phrases your extraction pipeline surfaced most frequently.

If you run a law firm, your ontology should reflect the structure of legal reasoning (jurisdiction, obligation, precedent, party) not the entity types your extraction model was trained on.

Data follows intent. Ontology precedes data.

I think people go from data to blueprint because it’s easier to let engineering deal with ontologies, letting the data talk via extraction. On the other hand, defining what matters as a company (division) entails meetings, business goals, difficult questions, sometimes difficult people. Ontology design is a knowledge-elicitation exercise, not a data-mining exercise. The right people in the room are domain experts and decision-makers, not data engineers (or at least not only engineers).