GraphNews

The world of graph technology is vast and evolving. We're here to help you make sense of the key trends and players.

Wasserstein Embedding for Graph Learning

Contribute to ashdehghan/NEExT development by creating an account on GitHub.

Author: Himanshu Singh

I used the o word last week and it hit a few nerves. Ontologies bring context. But then context engineering is very poorly understood. Agent engineers speak about it, expect everyone is doing it, know but almost everyone is winging it. Here's what context engineering is definitely not - ie. longer prompts. What it actually is - the right information, with the right meaning, at the right time. Not more but the right information with the right meaning. Sounds super abstract. That's why a brief video that actually breaks down how to load context. Okay. Not brief. but context needs context.

Learn more about how the latest release of G.V() now supports RDF triplestores and the SPARQL query language with autocomplete, visualization, and more.

Your LLM based agent can't reason about what it can't traverse.

Most companies think their knowledge graph or ontology will be built by extracting information from their data only to find out that their data doesn’t contain much information. You’re taught the cycle of Data - Information - Knowledge - Wisdom, but they stop before teaching a fundamental concept of information theory. You can measure the information in a dataset. There’s an entire area of study around defining whether a dataset has sufficient information to answer a question and build a model. Run that evaluation on most enterprise data and business questions and you’ll see the extent of the problem. No downstream process (cleaning, transformation, wrangling, etc.) can introduce information that a dataset doesn’t already contain. Said simply, you can’t clean the signal back into the data. If it wasn’t gathered contextually, the information was lost. For almost a decade, I have had to give new clients the same sad story. Roughly 80% of the business’s data doesn’t contain enough information to be used for model training. LLMs don’t change that. Agents need a lot more information to do their jobs reliably. An agent detects intent, then infers the desired outcome and all the steps required to deliver it. RAG over knowledge graphs is intended to provide all the supporting information required to do that reliably. However, if your datasets don’t contain enough information, no amount of AI can fix it. Before building an agent, we must assess whether our data contains enough information to satisfy the range of intents our users will bring to it. That’s an even higher bar than just answering a question or predicting a single variable. Agents create an information problem on both sides of the equation: Do you have enough information to define the intent and outcome based on the user’s prompt? Do you have enough information to define the steps required to deliver the outcome and execute them reliably enough to deliver the outcome? Information and knowledge management are the keys that unlock AI’s value, but businesses must curate datasets in new ways to succeed. The enterprise’s BI datasets and data warehouses rarely contain enough information to get the job done. | 24 comments on LinkedIn

Ontologies transcend their traditional role as static schema documentation and emerge as dynamic, executable metadata that actively controls and defines the capabilities of AI agents. 🔳 They're storing the instructions agents use to operate on that data. Traditional software architectures separate code from data, with logic hardcoded in application layers while data resides in storage layers. The ontology-based approach fundamentally challenges this separation by storing behavioral rules and tool definitions as graph data that agents actively query during execution. Ontologies in these systems operate as runtime-queryable metadata rather than compile-time specifications This is meta-programming at the database level, and the technical implications are profound: Traditional approach: Your agent has hardcoded tools. Each tool is a Python function that knows exactly what query to run, which entity types to expect, and how to navigate relationships. Ontology-as-meta-tool approach: Your agent has THREE generic tools that query the ontology at runtime to figure out how to operate. Here's the technical breakdown: Tool 1 does semantic search and returns mixed entity types (could be Artist nodes, Subject nodes, whatever matches the vector similarity). Tool 2 queries the ontology: "For this entity type, what property serves as the unique identifier?" The ontology responds because properties are marked with "inverseFunctional" annotations. Now the agent knows how to retrieve specific instances. Tool 3 queries the ontology again: "Which relationships from this entity type are marked as contextualizing?" The ontology returns relationship types. The agent then constructs a dynamic Cypher query using those relationship types as parameters. The breakthrough: The same three tools work for ANY domain. Swap the art gallery ontology for a medical ontology, and the agent adapts instantly because it's reading navigation rules from the graph, not from code. This is self-referential architecture. The system queries its own structure to determine its own behavior. The ontology becomes executable metadata - not documentation about the system, but instructions that drive the system. The technical pattern: Store tool definitions as (:Tool) nodes with Cypher implementations as properties Mark relationships with custom annotations (contextualizing: true/false) Mark properties with OWL annotations (inverseFunctional for identifiers) Agent queries these annotations at runtime to construct dynamic queries Result: You move from procedural logic (IF entity_type == "Artist" THEN...) to declarative logic (query the ontology to learn the rules). The system can now analyze its own schema, identify missing capabilities, and propose new tool definitions. It's not just configurable - it's introspective. What technical patterns have you found for making agent capabilities declarative rather than hardcoded? | 37 comments on LinkedIn

The Knowledge Graph Talent Shortage: Why Companies Can't Find the Skills They Desperately Need In my previous posts, I showed how Google's Knowledge Graph gives them a major AI advantage (https://lnkd.in/d5ZpMYut), and how enterprises from IKEA to Siemens to AstraZeneca have been using knowledge graphs and now leverage them for GenAI applications (https://lnkd.in/dPhuUhFJ). But here's the problem: we don't have enough people who know how to build them. 📊 The numbers tell the story. Job boards show thousands of open positions globally for ontology engineers, semantic web developers, and knowledge graph specialists. Yet these positions remain unfilled for months. Salaries for this expertise are rising, and technology vendors report inbound client calls instead of chasing business. 🤔 Why the shortage? The semantic web emerged in the early 2000s with technologies like RDF, OWL, and SPARQL. A small group of pioneers built this expertise. I was part of that early wave. I contributed to the POSC Caesar Association oil and gas ontology, certified as ontology modeller and participated in the W3C workshop hosted by Chevron in Houston in 2008. Later I led the Integrated Operations in the High North (IOHN) program with 23 companies like ABB, Siemens, and Cisco to increase semantic web knowledge within Equinor's vendor ecosystem. After IOHN, I stepped away for over a decade. The Knowledge Graph Alliance (KGA) drew me back. Companies need people who can design ontologies, write SPARQL queries, map enterprise data to semantic standards, and integrate knowledge graphs with LLMs. These aren't skills you pick up in a weekend bootcamp. 🔄 What needs to change? Universities must integrate semantic knowledge graphs into core curriculum alongside AI and machine learning as requirements, not electives. Here's something many don't realize: philosophy matters. Some of the best ontologists have philosophy degrees. Understanding how to represent knowledge requires training in logic and formal reasoning. DAMA International®'s Data Management Body of Knowledge covers 11 knowledge areas, but knowledge graphs remain absent. This would legitimize the discipline. Industry-academia bridges are critical. Organizations like the KGA bring together industry leaders with research organizations and academia. We need more such collaborations. 💡 The opportunity: If you're a data engineer or data scientist looking for a career differentiator, semantic web skills are your ticket. 🎯 The bottom line: Knowledge graphs aren't optional for industrial-scale GenAI. But you need the people who understand them. While reports document tech talent shortages, the semantic web skills gap remains largely undocumented as companies struggle to fill thousands of positions. What's your experience with the shortage? Are you hiring? Upskilling? Teaching this? #KnowledgeGraphs #SemanticWeb #AI #GenAI #TalentShortage #SkillsGap #Ontology #DataScience #Philosophy #DigitalTransformation | 29 comments on LinkedIn

Turn frontend ASTs into a Neo4j graph to see components, handlers, and events as connected behavior instead of scattered files.

Alhamdulillah, ATOM is finally here! A scalable and fast approach that can build and continuously update temporal knowledge graphs, inspired by atomic bonds. Just as matter is formed from atoms, and galaxies are formed from stars, knowledge is likely to be formed from atomic knowledge graphs. Atomic knowledge graphs were born from our intention to solve a common problem in LLM-based KG construction methods: exhaustivity and stability. Often, these methods produce unstable KGs that change when rerunning the construction process, even without changing anything. Moreover, they fail to capture all facts in the input documents and usually overlook the temporal and dynamic aspects of real-world data. What is the solution? Atomic facts that are temporally aware. Instead of constructing knowledge graphs from raw documents, we split them into atomic facts, which are self-contained and concise propositions. Temporal atomic KGs are constructed from each atomic fact. Then, we defined how the temporal atomic KGs would be merged at the atomic level and how the temporal aspects would be handled. We designed a binary merge algorithm that combines two TKGs and a parallel merge process that merges all TKGs simultaneously. The entire architecture operates in parallel. ATOM employs dual-time modeling that distinguishes observation time from validity time and has 3 main modules: - Module 1 (Atomic Fact Decomposition) splits input documents observed at time t into atomic facts using LLM-based prompting, where each temporal atomic fact is a short, self-contained snippet that conveys exactly one piece of information. - Module 2 (Atomic TKGs Construction) extracts 5-tuples in parallel from each atomic fact to construct atomic temporal KGs, while embedding nodes and relations and addressing temporal resolution during extraction. - Module 3 (Parallel Atomic Merge) employs a binary merge algorithm to merge pairs of atomic TKGs through iterative pairwise merging in parallel until convergence, with three resolution phases: (1) entity resolution, (2) relation name resolution, and (3) temporal resolution that merges observation and validity time sets for relations with similar (e_s, r_p, e_o). The resulting TKG snapshot is then merged with the previous DTKG to yield the updated DTKG. Results: Empirical evaluations demonstrate that ATOM achieves ~18% higher exhaustivity, ~17% better stability, and over 90% latency reduction compared to baseline methods (including iText2KG), demonstrating strong scalability potential for dynamic TKG construction. Check our ATOM's architecture and code: Preprint Paper: https://lnkd.in/dsJzDaQc Code: https://lnkd.in/drZUyisV Website: (coming soon) Example use cases: (coming soon) Special thanks to the dream team: Ludovic Moncla, Khalid Benabdeslem, Rémy Cazabet, Pierre Cléau 📚📡 | 14 comments on LinkedIn

𝙏𝙝𝙤𝙪𝙜𝙝𝙩 𝙛𝙤𝙧 𝙩𝙝𝙚 𝘿𝙖𝙮: Why Ontologies Are More Critical Than Ever

After seeing yet another Graph RAG demo using Neo4j with no ontology, I decided to show what real semantic Graph RAG looks like. The Problem with Most Graph RAG Demos: Everyone's building Graph RAG with LPG databases (Neo4j, TigerGraph, Arrango etc.) and calling it "knowledge graphs." But here's the thing: Without formal ontologies, you don't have a knowledge graph—you just have a graph database. The difference? ❌ LPG: Nodes and edges are just strings. No semantics. No reasoning. No standards. ✅ RDF/SPARQL: Formal ontologies (RDFS/OWL) that define domain knowledge. Machine-readable semantics. W3C standards. Built-in reasoning. So I Built a Real Semantic Graph RAG Using: - Microsoft Agent Framework - AI orchestration - Formal ontologies - RDFS/OWL knowledge representation - Ontotext GraphDB - RDF triple store - SPARQL - semantic querying - GPT-5 - ontology-aware extraction It's all on github, a simple template as boilerplate for you project: The "Jaguar problem": What does "Yesterday I was hit by a Jaguar" really mean? It is impossible to know without concept awareness. To demonstrate why ontologies matter, I created a corpus with mixed content: 🐆 Wildlife jaguars (Panthera onca) 🚗 Jaguar cars (E-Type, XK-E) 🎸 Fender Jaguar guitars I fed this to GPT-5 along with a jaguar conservation ontology. The result? The LLM automatically extracted ONLY wildlife-related entities—filtering out cars and guitars—because it understood the semantic domain from the ontology. No post-processing. No manual cleanup. Just intelligent, concept-aware extraction. This is impossible with LPG databases because they lack formal semantic structure. Labels like (:Jaguar) are just strings—the LLM has no way to know if you mean the animal, car, or guitar. Knowledge Graphs = "Data for AI" LLMs don't need more data—they need structured, semantic data they can reason over. That's what formal ontologies provide: ✅ Domain context ✅ Class hierarchies ✅ Property definitions ✅ Relationship semantics ✅ Reasoning rules This transforms Graph RAG from keyword matching into true semantic retrieval. Check Out the Full Implementation, the repo includes: Complete Graph RAG implementation with Microsoft Agent Framework Working jaguar conservation knowledge graph Jupyter notebook: ontology-aware extraction from mixed-content text https://lnkd.in/dmf5HDRm And if you have gotten this far, you realize that most of this post is written by Cursor ... That goes for the code too. 😁 Your Turn: I know this is a contentious topic. Many teams are heavily invested in LPG-based Graph RAG. What are your thoughts on RDF vs. LPG for Graph RAG? Drop a comment below! #GraphRAG #KnowledgeGraphs #SemanticWeb #RDF #SPARQL #AI #MachineLearning #LLM #Ontology #KnowledgeRepresentation #OpenSource #neo4j #graphdb #agentic-framework #ontotext #agenticai | 148 comments on LinkedIn

✅ Some state-of-the-art methods for knowledge graph (KG) construction that implement incrementality build a graph from around 3k atomic facts in 4–7 hours, while ATOM achieves the same in just 20 minutes using only 8 parallel threads and a batch size of 40 for asynchronous LLM API calls. ❓ What’s the secret behind this performance? 👉 The architecture. The parallel design. ❌ Incrementality in KG construction was key, but it significantly limits scalability. This is because the method must first build the KG and compare it with the previous one before moving on to the next chunk. That’s why we eliminated this in iText2KG. ❓ Why is scalability so important? The short answer: real-time analytics. Fast dynamic TKG construction enables LLMs to reason over them and generate responses instantly, in real time. Discover more secrets behind this parallel architecture by reading the full paper (link in the first comment).

How to stay sane about “semantic Graph RAG” when your job is shipping reliable systems, not winning ontology theology wars. You don’t wake up in the morning thinking about OWL profiles or SPARQL entailment regimes.

Knowledge Graphs and GraphRAG have sorta taken over my life the last two months or so, so I thought I would share some very important books for learners and builders. Knowledge Graphs: I’m going to really enjoy this KG book a lot more, now. It’s simple reading, in my opinion. Text as Data: if you work in Data Science and AI, just buy this book right now and then read it. You need to know this. This is my favorite NLP book. Orange Book (Sorry, long title): that is the best builder book I have found so far. It shows how to build with GraphRAG, and you should check it out. I really enjoyed reading this book and use it all the time. Just wanted to make some recommendations as I am looking at a lot of my books for ideas, lately. These are diamonds. Find them where you like to shop for books! #100daysofnetworks | 11 comments on LinkedIn

“Mr. Schwartz, I’ve reviewed your opposition brief,” Federal Judge P. Kevin Castel began, his tone measured but pointed. “You cite six…

Building Precision Through Semantic Discipline

This text is about my impressions from Connected Data London 2024. And about working towards a shared space of present and possible collaborative actions based on connected data and content. Intro: Shiny Happy Data People 20 years after the article in which Sir Tim Berners Lee imagined a paper on which you can click withContinue Weaving

“The idea that chips and ontology is what you want to short is batsh*t crazy.” Whilst I couldn't agree more about how good chips (both the silicon & potato varieties) & ontologies are the context & semantics, as always, are important..... The Context: Michael Burry of Big Short fame is shorting AI as a trend with puts on Nvidia & Palantir being disclosed in the latest regulatory filings for his fund Scion Asset Management - $187 million against Nvidia and $912 million against Palantir as of Sept. 30. The circularity of the latest AI boom and limitations of Large Language Models being amongst many reasons being cited for the apparent AI bubble which Burry believes will burst. Whether you consider it a formal Ontology or not Palantir & Alex Karp are some of the few to use the 'O word' openly in product marketing - something long considered a brave move by many a frontier technology company! https://lnkd.in/eh7SAS8P Ontologies are also a key component of research & development to overcome many of the limitations of contemporary 'AI' systems and the factors contributing to the AI bubble Burry references. Plug: Interested in learning about what industry leaders are doing to overcome these limitations and develop AI systems with true reasoning capabilities? Come to this year's Connected Data London conference and engage in the debate, discussions and learning. This year its at the Leonardo Royal Hotel Tower Bridge on 20th & 21st November and tickets are selling fast! https://lnkd.in/entfkddD CNBC article below with video interview: https://lnkd.in/eHDpnWAW

Pseudo-Knowledge Graphs for Better RAG Retrieval-Augmented Generation (RAG) was supposed to give Large Language Models perfect memory: ask a question, fetch the exact facts, and generate a fluent and …

Using Knowledge Graphs to Accelerate and Standardize AI-Generated Technical Documentation for Avalara Connector Guides A Practical Implementation Guide for Structured, Scalable Documentation …

Unifying Data Structures and Knowledge Graphs Why we get confused about the difference between data and knowledge This article is about a technical issue around the use of Knowledge Graphs to …

Using Knowledge Graphs For Inferential Reasoning Solving semantic paths integrals for causal outcomes This is a short technical note about using the path solving capabilities of knowledge graphs …

Why graph databases aren’t the silver bullet some hoped for, and where the technology is heading next.

gistBFO is an open-source alignment mapping Semantic Arts’ gist to BFO via subclass links—delivering BFO compliance and cross-domain interoperability.

“The idea that chips and ontology is what you want to short is batsh*t crazy.” — Alex Karp, CNBC, November 2025 When Palantir’s CEO, Alex Karp, lashed out at Michael Burry — “Big Short” investor who bet against Palantir and Nvidia — he wasn’t just defending his balance sheet.