GraphNews

If you could hire the smartest engineers and drop them in your code base would you expect miracles overnight? No, of course not! Because even if they are the best of coders, they don’t have context on your project, engineering processes and culture, security and compliance rules, user personas, business priorities, etc. The same is true of the very best agents.. they may know how to write (mostly) technically correct code, and have the context of your source code, but they’re still missing tons of context. Building agents that can deliver high quality outcomes, faster, is going to require much more than your source code, rules and a few prompts. Agents need the same full lifecyle context your engineers gain after being months and years on the job. LLMs will never have access to your company’s engineering systems to train on, so something has to bridge the knowledge gap and it shouldn’t be you, one prompt at a time. This is why we're building what we call our Knowledge Graph at GitLab. It's not just indexing files and code; it's mapping the relationships across your entire development environment. When an agent understands that a particular code block contains three security vulnerabilities, impacts two downstream services, and connects to a broader epic about performance improvements, it can make smarter recommendations and changes than just technically correct code. This kind of contextual reasoning is what separates valuable AI agents from expensive, slow, LLM driven search tools. We're moving toward a world where institutional knowledge becomes portable and queryable. The context of a veteran engineer who knows "why we built it this way" or "what happened last time we tried this approach" can now be captured, connected, and made available to both human teammates and AI agents. See the awesome demos below and I look forward to sharing more later this month in our 18.4 beta update!

GraphRAG doesn’t lack ideas, it struggles to scale up. It’s easy to be impressed by a demo that runs on a few documents and carefully curated questions. In that controlled environment, the answers appear seamless, latency is low and everything seems reliable. But the reality of enterprise is very different. Production workloads involve gigabytes of content, thousands of questions and tens of thousands of documents that are constantly changing. In such an environment, manual review is no longer an option. You can’t hire teams to check every answer against every evolving dataset. For GraphRAG to succeed in enterprise production, it must therefore rely on automated control mechanisms that continuously validate efficiency. Validation cannot be based on subjective impressions of 'good answers'. What is needed is a synthetic index of accuracy: a measurable framework that automatically tests and reflects performance at each stage of the workflow. This means validating ingestion (are we capturing the correct data?), embeddings (are entities represented consistently?), retrieval (are relevant entities retrieved reliably?) and reasoning (is the output aligned with the validated context?). Each step must be monitored and tested continuously as data and queries evolve. Another critical requirement is repeatability. In chatbot use cases, a degree of LLM creativity might be tolerated. In enterprise environments, however, it undermines trust. If the same query over the same dataset yields different answers each time, the system cannot be relied upon. Reducing the LLM's freedom to enforce repeatable, auditable answers is essential for GraphRAG to transition from prototype to production. The real differentiator will not be which graph model is 'purest', or which demo looks smoothest, but rather which implementation can demonstrate efficiency within enterprise constraints. This requires automation, accuracy, repeatability, and resilience at scale. Without these features, GraphRAG will remain an experimental solution rather than a practical one. #GraphRAG #RAG #AITrust #AutomatedValidation #AIBechmark

It is here: the second edition of An Introduction to Ontology Engineering, also published with the non-profit College Publications and making its way through the distribution channels (e.g., on ama…

Meet Infinigraph, a scalable, distributed graph architecture that allows you to run 100TB+ operational and analytical graph workloads in a single system.

Atomic Facts, Validation, Entity Resolution, KG and more

Labeled property graphs often contain rich textual attributes that can enhance analytical tasks when properly leveraged. This work explores the use of pretrained text embedding models to enable...

💡 Graph of Ideas -- LLMs paired with knowledge graphs can be great partners for ideation, exploration, and research. We've all seen the classic detective corkboard, with pinned notes and pictures, all strung together with red twine. 🕵️  The digital version could be a mind-map, but you still have to draw everything by hand. What if you could just build one from a giant pile of documents? Enter GoAI - a fascinating approach that just dropped on arXiv combining knowledge graphs with LLMs for AI research idea generation. While the paper focuses on a graph of research papers, the approach is generalizable. Here's what caught my attention: 🔗 It builds knowledge graphs from AI papers where nodes are papers/concepts and edges capture semantic citation relationships - basically mapping how ideas actually connect and build on each other 🎯 The "Idea Studio" feature gives you feedback on innovation, clarity, and feasibility of your research ideas - like having a research mentor in your pocket 📈 Experiments show it helps produce clearer, more novel, and more impactful research ideas compared to traditional LLM approaches The key insight? Current LLMs miss the semantic structure and prerequisite relationships in academic knowledge. This framework bridges that gap by making the connections explicit. As AI research accelerates, this approach can be be used for any situation where you're looking for what's missing, rather than answering a question about what exists. Read all the details in the paper... https://lnkd.in/ekGtCx9T

Our RDF Sketch extension (https://lnkd.in/d_T4SUGX) for VS Code now works directly in the browser. You can use it in:  - https://vscode.dev - https://github.dev - GitLab Web IDE We’d love your feedback if you try it out. #RDF #LinkedData #KnowledgeGraphs #VSCode #DevTools #SemanticWeb

There are people who seem to reject Knowledge Graphs while claiming that they do not allow AI Agents to make decisions under uncertainty. This article aims at refuting this claim and showing that, apart from supporting decisions based on reasoning grounded in logic, they are also capable of supporti

Seven knowledge graph quality problems that undermine GraphRAG performance and how to detect them

What they mean, what they don’t, and how to use them

Citation metrics are widely used to assess academic impact but suffer from social biases, including institutional prestige and journal visibility. Here we introduce rXiv Semantic Impact (XSI), a...

In an era where software systems are increasingly complex and interconnected, effectively managing the relationships between packages, maintainers, dependencies, and vulnerabilities is both a challenge and a necessity. This paper explores the integration of knowledge graphs into the Debian ecosystem as a powerful means to bring structure, semantics, and coherence to diverse sources of package-related data. By unifying information such as package metadata, security advisories, and reproducibility reports into a single graph-based representation, we enable richer visibility into the ecosystem's structure and behavior. Beyond constructing the DebKG graph, we demonstrate how it supports practical, high-impact applications — such as tracing vulnerability propagation and identifying gaps between community needs and development activity — thereby offering a foundation for smarter, data-informed decision-making within Debian.

Wikidata Knowledge Graph to Enable Equitable and Validated Generative AI - Jonathan Fraine & Lydia Pintscher, Wikimedia DeutschlandGenerative AI has changed ...

AbstractMotivation. Ecological systems are complex. Representing heterogeneous knowledge about ecological systems is a pervasive challenge because data are

Earlier this week I came across a post by Miklós Molnár that sparked something I think the ontology community has needed to articulate for a long time. The post described a shift in how we might think about ontology mapping and alignment in the age of AI.

The ultimate RAG for your monorepo. Query, understand, and edit multi-language codebases with the power of AI and knowledge graphs - vitali87/code-graph-rag

What is your role? I am a product manager in the Office of the CTO at Bloomberg, where I am responsible for developing products that help to deploy semantic solutions that facilitate our data integration and delivery. Bloomberg is a global provider of financial news and information, including real-t

OpenAI’s recent paper, Why Language Models Hallucinate, takes direct aim at one of the most persistent criticisms of AI: hallucination. The research makes a clear point: hallucinations are not random glitches.

Calling all data scientists, developers, and managers! 📢 Looking to level up your team's knowledge of graph technology? We're excited to share the recorded 2-part training series, "Graph Tech Demystified" with the amazing Paco Nathan. This is your chance to get up to speed on graph fundamentals: In Part 1: Intro to Graph Technologies, you'll learn: - Core concepts in graph tech. - Common pitfalls and what graph technology won't solve. - Focus of graph analytics and measuring quality. 🎥 Recording https://lnkd.in/gCtCCZH5 📖 Slides https://lnkd.in/gbCnUjQN In Part 2: Advanced Topics in Graph Technologies, we explore: - Sophisticated graph patterns like motifs and probabilistic subgraphs. - Intersection of Graph Neural Networks (GNNs) and Reinforcement Learning. - Multi-agent systems and Graph RAG. 🎥 Recording https://lnkd.in/g_5B8nNC 📖 Slides https://lnkd.in/g6iMbJ_Z Insider tip: The resources alone are enough to keep you busy far longer the time it takes to watch the training!

AI data processing-related companies have seen continuous growth in financing in recent years, representing essential AI subdivision…

Unlock true AI potential with neuro-symbolic AI. Learn how combining LLMs with knowledge graphs solves unreliable and inaccurate outputs for enterprise success.

What is an ontology? Well it depends on who’s talking. Ontology talk has sprung up a lot in data circles the last couple of years. You may have read in the news that the Department of Defense adopted an ontology, Juan will tell you enterprise AI needs an ontology, Jessica will tell you how to build an ontology pipeline, and Palantir will gladly sell you one (🤦‍♂️). Few people actually spell out what they mean when talking about “ontology” and unsurprisingly they’re not all talking about the same thing. Ontology is a borrow word for information scientists who took it from philosophy where ontology is an account of the fundamental things around us. Some of you no doubt read Plato’s Republic with the allegory of the cave, which introduces the theory of forms. Aristotle’s had two ontologies, one in the Categories and another in the Metaphysics. (My friend Jessica would call the former a Taxonomy). When I talk about ontology as a philosopher I’m interested in the fundamental nature or reality. Is it made up of medium sized dry goods or subatomic wave functions. Information scientists aren’t interested in the fundamental nature of reality, but they are interested in how we organize our data about reality. So when they talk about ontologies they actually mean one of several different technologies. When Juan talks about ontologies I know in my head he means knowledge graphs. This introduces a regression because knowledge graphs can be implemented in number of different ways, though the Resource Description Framework (RDF) is probably the most popular. If you’ve ever built a website, RDF will look familiar because it’s simply URIs that represent subject predicate object triples. (Juan-works at-ServiceNow) Because we’re technologists there are a number of different ways to represent, store, and query a knowledge graph. (See XKCD 927) Knowledge graphs are cool and all, but they’re not the only approach to ontologies. When the DoD went shopping for an ontology, they started with an upper formal ontology, specifically the Basic Formal Ontology. I think BFO is cool if only because it’s highly influenced by philosophy through the work of philosopher Barry Smith (Buffalo). Formal ontologies can organize the concepts, relations, axioms, across large domains like healthcare, but they’re best fit for slowly evolving industries. While BFO might be the most popular upper ontology it’s certainly not the only one on the market. My own view is that in data we’re all engaged in ontological work in a broad sense. If you’re building a data model, you need a good account of “what there is” for the business domain. At what grain do we count inventory? Bottles, cases, pallets, etc? The more specific we get around doing ontological work, the harder the deliverables become. eg knowledge graphs are harder to build than data models, formal ontologies are harder to build than knowledge graphs. Most organizations need good data models over formal ontologies. | 109 comments on LinkedIn

A database tells you what is connected. A knowledge graph tells you why. → SQL hides semantics in schema logic. Foreign keys don’t explain relationships, they just enforce them. → Knowledge graphs make relationships explicit. Edges have meaning, context, synonyms, hierarchies. → Traversal in SQL = JOIN gymnastics. Traversal in a KG = natural multi-hop reasoning. Benchmarks show LLMs answered enterprise questions correctly 16.7% of the time over SQL … vs. 54.2% over the same data in a KG. Same data, different representation. Sure, you can bolt ontologies, synonyms, and metadata onto SQL. But at that point, you’ve basically reinvented a knowledge graph. So the real question is: Do you want storage, or do you want reasoning? #KnowledgeGraphs #AI #LLM #Agents #DataEngineering | 51 comments on LinkedIn

This post captures the desire for a short cut to #KnowledgeGraphs, the inability of #LLMs to reliably generate #StructuredKnowledge, and the lengths folks will go to realize even basic #semantic queries (the author manually encoded 1,000 #RDF triples, but didn’t use #OWL). https://lnkd.in/eJE_27gS #Ontologists by nature are generally rigorous, if not a tad bit pedantic, as they seek to structure #domain knowledge. 25 years of #SemanticWeb and this is still primarily a manual, tedious, time-consuming and error-prone process. In part, #DeepLearning is a reaction to #structured, #labelled, manually #curated #data (#SymbolicAI). When #GenAI exploded on the scene a couple of years ago, #Ontologist were quick to note the limitations of LLMs. Now some #Ontologists are having a "Road to Damascus" moment - they are aspirationally looking to Language Models as an interface for #Ontologies to lower barrier to ontology creation and use, which are then used for #GraphRAG, but this is a circular firing squad given the LLM weaknesses they have decried. This isn't a solution, it's a Hail Mary. They are lowering the standards on quality and setting up the even more tedious task of identifying non-obvious, low-level LLM errors in an #Ontology (same issue Developers have run into with LLM CodeGen - good for prototypes, not for production code). The answer is not to resign ourselves and subordinate ontologies to LLMs, but to take the high-road using #UpperOntologies to ease and speed the design, use and maintenance of #KGs. An upper ontology is a graph of high-level concepts, types and policies independent of a specific #domain implementation. It provides an abstraction layer with re-usable primitives, building blocks and services that streamline and automate domain modeling tasks (i.e., a #DSL for DSLs). Importantly, an upper ontology drives well-formed and consistent objects and relationships and provides for governance (e.g., security/identity, change management). This is what we do EnterpriseWeb. #Deterministic, reliable, trusted ontologies should be the center of #BusinessArchitecture, not a side-car to an LLM.

Apache TinkerPop™ is a graph computing framework for graph systems and the home of the Gremlin graph traversal language. Contributorcasts allow contributors ...

A canonical problem in computer science is to find the shortest route to every point in a network. A new approach beats the classic algorithm taught in textbooks.

NLWeb turns Schema Markup into AI-ready data—unlocking smarter search, improved content discoverability, and faster AI integration.

Every knowledge system has to wrestle with a deceptively simple question: what do we assert, and what do we derive? That line between assertion and derivation is where Object-Role Modeling (ORM) and the Resource Description Framework (RDF) with the Web Ontology Language (OWL) go in radically differe