GraphNews

An AI won't build a better ontology than you — but it can out-discipline you. Competency questions, SHACL validation, and a worked example, end to end.

Which AI Code Knowledge Graph Should Developers Choose in 2026?

Sovereign AI starts with semantics, not with infrastructure. Sovereignty is not only about where the model runs.

When meaning lives inside one application, every integration, acquisition, and replacement has to reconstruct it.

Data Engineering 1.0 moved data. Data Engineering 2.0 created Trusted Data Products. Data Engineering 3.0 creates the Context Layer that…

Stop choosing between structured knowledge and semantic search. Learn when to use Knowledge Graphs for explicit facts and Vector Databases…

Retrieval-Augmented Generation (RAG) improves large language models (LLMs) by retrieving relevant information from external sources and has been widely adopted for text-based tasks. For structured...

Graph Retrieval Augmented Generation (GraphRAG) has garnered increasing recognition for its potential to enhance large language models (LLMs) by structurally organizing domain-specific corpora and...

There is a lot of confusion around knowledge graphs and semantics. Much use and abuse of words, marketing claims, fluff and fake statements. Sometimes subtle, sometimes explicit. AI generated websites, AI generated articles, dashboards and stats. For some reason we went from 'data science' to 'AI' and completely dropped 'science'. Claims and analysis don't need evidence anymore. It ain't my style to shoot at anyone, but a widely-shared graph RAG production write-up does something rare: it contradicts itself in public, inside a single article 😣 In the opening we go from "accuracy jumped from 43% to 91%", halfway we read "...real production numbers 95% GraphRAG vs. 40–60% plain RAG..." and we end the report with "91% vs. 58%". Pick a baseline, any baseline, no dataset is named, no task or methodology, no metric. The piece also reports indexing cost at $7.13, and cost-per-document at $0.0048. Decimal-point precision on numbers that come from nowhere reproducible. It's precision theater, circus progress. Knowledge graphs and AI context architecture has a citation problem that hides behind good sounding details. Of course, none of this means that (graph) RAG doesn't work. If you do need solid references, have a look at the following: - When to use graphs in RAG: https://lnkd.in/eXXbVcec - GraphRAG bench: https://lnkd.in/e2sAs5f6 - RAG vs GraphRAG: https://lnkd.in/ep_VGt-v #GraphRAG #KnowledgeGraphs #KnowledgeAugmentedAI

Graph retrieval-augmented generation (GraphRAG) has emerged as a powerful paradigm for enhancing large language models (LLMs) with external knowledge. It leverages graphs to model the hierarchical...

Competency questions and invariants turn “the graph looks right” into something you can verify — shown on a 10-K filing graph anyone can…

Turning Millions of Documents Into an Agentic Knowledge Graph Why vector search breaks at scale — and how agentic graphs connect scattered facts so AI agents can actually reason across millions of …

We take a look back at the past season of Going Meta, this time with ontologies as the thread running through nearly every episode. This is…

|𝐁𝐅𝐎 "𝐯𝐬" 𝐃𝐎𝐋𝐂𝐄| Strange enough if we agree that those two are rivals, some of the strongest arguments are not really about classes, axioms or philosophical choices. They are much more practical: Who is actually using the ontology? Is it maintained? Is there documentation? A community around it? Are there organizations depending on it in real projects? And I think this opens a slightly uncomfortable question for ontology engineering: Can an ontology be technically excellent and still be, in practice, a failed ontology? Maybe at some point we should also judge them more like infrastructure. Not only “is this ontology good?” but also “is anyone actually able to build on it and keep building on it?” | 18 comments on LinkedIn

I regularly get the question whether using LLMs is acceptable for ontology creation. Usually it's not a question, but asking for confirmation or to determine whether I am 'one of those'. Here is the honest answer: I approve evidence-based decisions and pragmatic approaches. If it works for a particular use-case (including the budget, team expertise, timeline, technology), I will suggest a customer to go for it. I have no particular 'faith' in RDF, LPGs, LLMs, platform or company. I see business and innovation, not ideology. That said, there are interesting efforts to generate ontologies. The 'open-ontologies' project is an AI-native ontology engine, a Rust MCP server with tools for building, validating, querying, and reasoning over RDF/OWL ontologies. I love the "Single binary, no JVM" punch. The most interesting bit is not so much the project itself as the fact that from this you can see (in benchmarks) that: - open-world SHACL checks well-formedness, not completeness - zero focus nodes checks nothing, but it reports success - closed-world vocabulary checking is the missing primitive most knowledge augmented validation stacks don't have. Rephrased differently, open-world semantics can't catch fabrication. If your graph RAG pipeline validates LLM-extracted triples with plain SHACL and calls that governance, it isn't. #KnowledgeGraphs #SHACL #GraphRAG #KnowledgeAugmentedAI Open Ontologies: https://lnkd.in/eMrJvNFZ

This post was first published at metaphact’s blog in 2024 under the title How to approach semantic modeling: Perspectives from a metaphacts friend. I thought I would re-post it here for new readers, and also provide with some reflections at the end. Have my way of approaching semantic modeling changed in the past two years?

Truth value: how to represent it to achieve your goals Want a context graph that your business and its agents can trust? The first step is getting clear about what, exactly, you mean by ‘truth value.’ This is not a theoretical exercise: this is key to how you structure your graphs and the practices

Do We Really Need a Graph Database for GraphRAG? The biggest misconception in GraphRAG: “Graph = GraphDB” I don’t think that’s necessarily true. A graph is a data model — not a database product. A graph can be represented as: (Subject, Predicate, Object) For example: Model X → owned_by → Team Y Team Y → reports_to → Division Z Division Z → governed_by → Policy P These relationships can live in a traditional relational database just as they can in a specialized graph database. So the real question is: Do we need a GraphDB, or do we simply need graph data and graph traversal? A pragmatic GraphRAG architecture Instead of: Documents → GraphDB → Vector DB → Reranker → LLM consider: Documents → Embeddings → Vector Search and independently: Entities + Relationships → Triples → Relational DB → Relationship Search Then combine: Vector Retrieval + Relationship Retrieval ↓ RRF / Rank Fusion ↓ Reranking ↓ Context Assembly ↓ LLM / Agent This separates responsibilities: 🔹 Vector retrieval: “What is semantically relevant?” 🔹 Relationship retrieval: “What is connected to what?” 🔹 RRF: “How do I combine different retrieval rankings?” 🔹 Reranker: “Which candidates are actually most relevant?” 🔹 LLM: “How do I reason over the evidence?” What about multi-hop reasoning? Consider: Which regulations affect applications using Model X? The relationship layer can traverse: Model X ↓ owned_by Team Y ↓ reports_to Division Z ↓ governed_by Regulation R The vector layer retrieves the underlying documents supporting those relationships. The LLM receives both semantic evidence and structural evidence. So when does a GraphDB become worthwhile? Not simply because we have nodes and edges. A specialized graph engine becomes compelling when we have: • Deep, variable multi-hop traversal • Highly connected graphs • Complex path queries • Graph-native algorithms • Large-scale graph analytics • Graph workloads becoming a primary system capability For simpler relationships, particularly predictable 1–3 hop traversals, relational triples may be sufficient. The architectural principle Don’t introduce a GraphDB because you have a graph. Introduce one when graph traversal and graph algorithms become a dominant workload. The question isn’t: Vector DB vs GraphDB? It is:How should semantic retrieval and structural retrieval work together? A pragmatic architecture: Vector Search ＋ Triple / Relationship Search ↓ RRF / Rank Fusion ↓ Reranking ↓ LLM / Agentic Reasoning This can potentially deliver much of the value of GraphRAG without prematurely adding another specialized database to the enterprise stack. #GraphRAG #RAG #EnterpriseAI #AIArchitecture #GenerativeAI #AgenticAI #KnowledgeGraph #SemanticSearch #LLM #AIEngineering

Large companies leverage the innovations of smaller companies to scale technology, expand market share, and minimize early-stage risks. Sometimes with big cash, sometimes without giving much in return (think Postgres). I am patiently waiting for the big three to acquire something knowledge graph in the same way that SAP acquired Dremio, Neo4j took GraphAware over, Altair bought Cambridge Semantics, Ontotext merge into GraphWise and so on. Microsoft, Google and AWS are still figuring it out. There is a large amount of open source and good intentions (ontocast, ontop, TrustGraph...) but the RDF/LPG mix is a challenge. If you are Ontotext you go for something RDF, if you are Neo4j you approach LPG solutions, but if you try to embrace everything where do you go? Although Microsoft clearly prefers property graphs it might be a strategic mistake to explicitly put aside semantics. AWS has Neptune with some Cypher but it's not a knowledge augmented AI solution. This is really the challenge: a bolted on solution on top of a graph database or multiple databases with a platform or something completely multi-modal? Microsoft with its Fabric Graph, GQL over OneLake, no persistent graph engine. Google with Spanner Graph, native GQL storage inside Spanner. AWS with Neptune, dual-model Gremlin/openCypher + full SPARQL, actively maintained for years. Three different architectures, three different levels of investment, zero acquisitions. That's unusual. When these companies decide something is strategic, they don't out-build it, they out-buy it. That's how Azure got its AI story, how AWS got serverless-adjacent tooling, how Google got half of its ML stack. Graph is the rare category where all three are still doing it the slow way. Which makes we wonder if the acquisition is still coming. There is no shortage of targets (Stardog, TigerGraph, Franz, Graphwise...) They are all still independent, all still building the semantic-reasoning and agent-grounding layer that none of the hyperscalers have organically matched. The ontology-for-agents pitch that Microsoft is making with Fabric IQ is exactly the pitch Stardog has been making for years, with a decade more of RDF-based reasoning behind it. Maybe the hyperscalers have decided graph is infrastructure, not IP, and don't need to buy their way in. Or maybe we're one earnings cycle away from finding out which of Stardog, TigerGraph, or Graphwise becomes the semantic layer inside a trillion-dollar cloud platform. #RDF #KnowledgeGraphs #GraphRAG #Microsoft