GraphNews

Leveraging the power of graphs to play with probabilities

Continual graph learning (CGL) is about graph machine learning (GML) over dynamic graph data. Real graphs don't hold still and retraining from scratch is often not an option. It leads to catastrophic forgetting: the model gets sharper on new patterns and quietly worse at everything it used to know. Dealing with this is hard. GML is already quite challenging, making the training data variable adds another layer of complexity. People have invented a various sophisticated approaches, my favorite being the geometric-topological one. Ollivier–Ricci curvature is a discrete analogue of curvature for graphs: for an edge between two nodes, it measures how much their neighborhoods overlap. Densely interconnected, cluster-like regions have high curvature. The two endpoints' neighbors overlap heavily, so the edge is somewhat redundant, since information can flow around it via other paths. Bridge-like edges connecting otherwise separate regions have low or negative curvature, they carry structural information that no alternate path replicates. In a nutshell. The application I find most compelling of all this is the lifelong embedding learning for growing knowledge graphs. Instead of re-materializing and re-embedding an entire KG every time your ontology or instance data shifts, you update incrementally. The graph representation of your domain stays the durable asset, and the embedding layer adapts around it. Like a dynamic vector space. I wished someone would invent a merge of neural networks and CGL. Something like continuous neural network learning. #GraphML #KnowledgeGraphs #GNN #ContinualLearning - Survey of CGL: https://lnkd.in/eTCQSbs8 - BEGIN (foolproof python framework): https://lnkd.in/entd5xXw - Online CGL: https://lnkd.in/eearNNV7

Build a Concept Graph, Generate RDF, Validate and Export

Quine 2.1.0 brings the biggest leap yet for the visual Quine experience: a live flow diagram of your running instance, a new Streams page, floating query result cards, and live standing-query inspections.

When I explain graph machine learning to people I always give graphcast, alphafold and pinsage as big success stories. LinkedIn does not allow me to write lengthy posts, so I'll highlight Graphcast here. Around 2023, DeepMind created GraphCast. A deterministic GNN that represents the atmosphere as a multi-scale icosahedral mesh with learned edges. Two 6-hour-apart states in, autoregressive rollout to 10 days out. It matched or beat the physics-based HRES model. It was pretty much the first time in history that an ML model was better than a simulation. In 2024 GenCast was invented, same graph substrate, but the deterministic decoder was swapped for a conditional diffusion process, producing 50+ ensemble scenarios instead of a single forecast. Uncertainty from a graph neural network. Somewhere in 2026 Google released WeatherNext 2. Still a graph mesh but with a GNN encoder/decoder mapping the lat-lon grid onto a icosahedral latent mesh, with a graph transformer operating on the mesh nodes . Noise gets injected directly into the model's normalization layers rather than through a diffusion process. It's now live in Google Search, Maps, Gemini, and Pixel Weather. The physical mesh remained the same but the generative mechanism evolved:from deterministic to diffusion to function-space noise injection. The mesh topology turned out to be the durable part of the design while the uncertainty model was the part that got iterated. Before you ask me to create a GNN for you: I tried to estimate the cost of training graphcast and came up with something ~$400K. Very few companies have the data and the cash to experiment with this kinda technology. ☀️ WeatherNext2: https://lnkd.in/e4hYAN7X ⛈️ Graphcast: https://lnkd.in/ed5RQphu #KnowledgeGraphs #GraphML #GraphNeuralNetworks #MachineLearning

AI engineers are rediscovering ontologies as a way to keep probabilistic agents inside deterministic boundaries.

Two Anthropic seniors just made Karpathy's loop 1000x better with "Graph Engineering" - dropped 11-page PDF the shift: the agentic systems got 1000x better the moment you wired agents into a graph here's the playbook in 6 steps: step 1 → build one loop: generate, critique, revise - one self-review cycle beats a smarter model with none step 2 → add tools: search, code execution, database - thinking without tools is hallucinating step 3 → go parallel: spin up agents in separate worktrees - same repo, different branches, no conflicts step 4 → add a graph: agents write findings as typed nodes and edges - not transcripts - every claim keeps its source step 5 → ground your evaluator: it checks claims against graph edges, not vibes - "Triple not found" beats "seems off" step 6 → the graph survives every session - your agents stop rebuilding context from scratch the result: Karpathy ran 1 agent in 1 direction - this system runs 1,000 with shared memory - same model, it's the architecture read this 11-page PDF and paste it into your Claude - you won't regret it bookmark - then read the article on building graphs from scratch ↓ | 43 comments on LinkedIn

Sign in or join now to see posts like this one and more.

The first (official) Monterey Bay Ontology Meetup ⛵️ Great talks and opportunity to think. Better yet, we went analog. Thank you Joshua Shinavier for a great dry erase board and thoughtful planning, that made for a most excellent meetup. And only 8 minute drive from my house | 44 comments on LinkedIn

From Spreadsheet to Substitution Engine: Building an Agricultural Knowledge Graph in Neo4j, Layer by Layer Build an agricultural knowledge graph one public data source at a time, and watch the …

Every few years our industry discovers a new silver bullet. Today, it's context. Knowledge graphs. Ontologies. Semantic layers. Context engineering. They're all valuable, and necessary. But context alone doesn't solve the fundamental problem of how do we ensure data required by downstream consumers, including AI, is trustworthy? AI doesn't replace the need for trustworthy enterprise data. It amplifies it. In many ways, AI needs exactly what BI, analytics, and operational systems have always needed: • Trusted data • Consistent business meaning • Shared definitions • Authoritative master data • Governance The difference is that AI also needs something more. It needs knowledge. For years we've treated data management and knowledge management as separate disciplines with separate architectures, separate teams, and separate technologies. It's abundantly obvious to me that having data and knowledge in separate organizational silos has reached the end of its useful life. AI demands a more holistic approach that integrates these critical disciplines, and the architectures which support them. 20+ years ago some of us were so myopically focused on BI, that allowed the worlds of enterprise search, document management, and knowledge management to completely split away from data. It's now the time to reunite these disciplines with a more cohesive approach focused on both structured and unstructured data across a cohesive enterprise architecture. There are three key layers to this architecture (see diagram below): 1️⃣ The Semantic Foundation - consolidates all of our repositories of terms and definitions into a single business glossary and enterprise taxonomy. This is the world of data catalogs, and its where basic governance policies are documented. 2️⃣ The Truth Layer (MDM) - establishes trusted representations of customers, products, suppliers, locations, and other core business entities regardless of whether the evidence originates in databases, documents, emails, contracts, PDFs, images, conversations, or other unstructured content. 3️⃣ The Context Layer then connects those trusted entities into a coherent enterprise knowledge model that AI can reason over. The context layer consumes trusted data from the truth layer. The result is shared enterprise semantics built on both truth and context. The future isn't data management. The future isn't knowledge management. The future is an integrated enterprise architecture that finally brings them together. #datamanagement #enterprisearchitecture #informationarchitecture | 28 comments on LinkedIn

PostgreSQL 19 adds SQL/PGQ graph queries. See how its graph features compare with Memgraph on exact hop traversal performance.

It took a while but Postgres finally learned to speak graph. Like MS SQL (in 2017!) and Oracle, that doesn't make our beloved elephant a graph database. PostgreSQL 19 ships SQL/PGQ, the ISO standard for property graph queries. You define a CREATE PROPERTY GRAPH over your existing tables and suddenly your relational schema is queryable with pattern-matching syntax (Cypher-ish) instead of chained JOINs. The graph is a read-only view over the same tables SQL has always queried. It's a solution I suggested to various customers in the past (atop MSSQL) and it safes money and deployments. But the architecture underneath hasn't changed. A property graph in Postgres v19 is still a view over relational storage, executed by a planner built for joins and joins compose differently than traversal. Memgraph benchmarked exactly this: exact N-hop reachability over the Pokec dataset (100K vertices, 1.77M edges), 1 to 5 hops, same data on both engines. Postgres moves from milliseconds into seconds while Memgraph stays under 100ms. At higher hops Postgres hits a 30-second timeout, Memgraph finishes in ~259ms. The gap isn't a tuning problem, it's what happens when you bolt a graph query surface onto a storage engine that was never designed to keep the graph as its primary structure. Each hop re-expands the search through join machinery. SQL/PGQ is still a milestone worth taking seriously though, it legitimizes property graphs as a first-class relational concept and will pull a huge SQL-native audience toward graph thinking. Just don't confuse "my database can express graphs" with "my database was built to traverse." #KnowledgeGraphs #GraphRAG #Postgres #KnowledgeAugmentedAI #GraphDatabases ❧ Postgres LPG: https://lnkd.in/emvFXSFQ ❧ Memgraph's benchmark: https://lnkd.in/ezGGGvYP

Most "LLM wikis" use agents, embeddings, and repeated model calls to organize local notes. I built a deterministic alternative: a pure Python compiler that turns messy markdown into a linked, linted wiki using only the standard library. Along the way, I fixed two real bugs, benchmarked the pipeline on two operating systems, and showed why a compiler is often a better fit than an agent for mechanical text organization.