GraphNews

The scientific method is easy to admire and easy to skip, most of us apply it selectively, somewhat at work, loosely everywhere else. We like to drop any of the scientific principles to fast forward an opinion or a project. Most knowledge graphs are built like press releases, not data science. An LLM reads a document, extracts stuff, writes it to the graph, done. No hypothesis, no test, no error bar, no way to be wrong later. That's not knowledge engineering, it's more like stenography. The scientific method has four habits that KG pipelines routinely skip. Hypothesis. A claim is a hypothesis, not a fact. Every extracted triple should carry a credence instead of a checkmark. "Confident" and "true" are different properties. Provenance. If you can't trace a triple back to the observation that produced it, you can't replicate it, audit it, or revise it. A graph without provenance isn't a knowledge base, it's a rumor with good formatting. Falsifiability, not permanence. Science doesn't delete superseded results, it supersedes them with a timestamp and a reason. Most graphs still treat every assertion as eternally true the moment it's ingested. Reproducibility. Replication is the real validation step. If two independent passes over the same source produce different triples with no accounting for why, you don't have an extraction pipeline, you have a random generator with a schema. None of this is exotic really. It's just what every first-year STEM student is trained to do (to understand, to acknowledge). Why do we silently forget when we move into business? Knowledge graph benchmarking: https://lnkd.in/evRACr6W #KnowledgeGraphs #RDF #Semantics #Ontology

What Kind of Knowledge Graph does an AI need to plan its World Domination?

A Survey of Task-Oriented Knowledge Graph Reasoning: Status, Applications, and Prospects - ngl567/KGR-Survey

Urban event management faces critical challenges in processing unstructured citizen complaints because of the limitations of traditional extraction models in handling colloquial text, static nature of conventional knowledge graphs that overlook spatiotemporal risk propagation, and brittleness of handcrafted symbolic rules that fail to generalize to novel scenarios. To address these issues, this study presents ST-CKG, a generalized spatiotemporal causal knowledge graph framework with Large Language Model (LLM)-enhanced reasoning. The framework integrates three tightly coupled components: a hybrid information extraction module that combines fine-tuned models with an LLM-based verifier to produce confidence-calibrated structured knowledge; a spatiotemporal causal hypergraph construction module that encodes spatial proximity and temporal causal hyperedges to model cascading urban risks; and a neuro-symbolic reasoning engine that distills expert-defined risk causal chain rules into a graph attention network, enabling interpretable and generalizable inference over incomplete or unseen event configurations. Extensive experiments conducted on over 2,000 real-world citizen complaints demonstrated that the hybrid extraction module outperformed standalone baselines by 3–5 percentage points in the F1-score, achieving 91% urgency assessment accuracy, significantly surpassing pure rule-based and pure graph neural network variants in rule-uncovered scenarios. Ablation studies have confirmed the indispensability of each component. The ST-CKG framework offers a replicable paradigm for bridging unstructured civic narratives with structured actionable governance decisions in smart cities.

Retrieval-Augmented Generation (RAG) enhances the response quality and domain-specific performance of large language models (LLMs) by incorporating external knowledge to combat hallucinations. In...

Replacing static YAML schema files with a Neo4j knowledge graph cuts token usage by 20–30% on average while improving accuracy

Last month, my morning briefing flagged a blocker I’d completely forgotten about.

Let's talk about deleting knowledge. Not as glorious as acquiring it but just as important. We are obsessed with knowledge graph extraction pipelines, entity resolution, ontology alignment, ETL, CDC and I admit, I help companies doing precisely that. But knowledge has a shelf life: contracts expire, regulations get superseded, business is dynamic, not to mention the geopolitical shifts. That authoritative product hierarchy from last year is now three reorgs stale, but the KG/ontology is still serving it with full confidence, right next to yesterday's facts. RDF has no native notion of decay, LPGs let you slap a timestamp on an edge and then ignore it forever. Neither community has a good answer to the question: when does a fact stop being true, and who tells the graph? The who matters here: do companies have business flows to forget things? The same is obviously true for SQL data but cascading deletes are a lot easier there, the foreign keys mechanics is a blessing we do not have in KGs. The result is a familiar failure mode: the graph doesn't become wrong all at once. It accumulates errors quietly. A knowledge graph that's 90% accurate but you don't know which 90% is maybe worse than no graph at all. Downstream reporting and bots use the stale info into confident answers. To be precise, forgetting is not data loss. Forgetting is an inference problem: provenance, temporal validity, confidence that degrades unless evidence renews it. A fact extracted from a 2019 PDF should not carry the same weight as one from last quarter's filings yet in most triple stores, it does. We engineer elaborate machinery for adding knowledge, we hardly ever create the machinery for letting it go. Yes, I know, the many AI memory systems out there (Mem0, Graphiti...). These tools are per-agent, per-user, conversation-scoped. Enterprise knowledge is cross-team, cross-document, governed, versioned, and contested. Nobody's compliance department is going to sign off on "the graph is whatever the agent remembered." The moment you need provenance, temporal validity, access control, or two agents sharing a consistent world model, you've left the design envelope of a memory layer entirely. Memory is what was said. Knowledge is what survives scrutiny. Conversation versus science, they are related but not the same. #KnowledgeGraphs #Ontology When Facts Expire: https://lnkd.in/eskw-Num Efficient Knowledge Graph Unlearning with Zeroth-order Information: https://lnkd.in/emM_qAEv

There is a massive amount of noise around "ontologies" and "semantic layers" right now. As vendors rush to label every database schema or graph as an ontology for the sake of AI marketing, we are losing our shared definitions. If we can’t agree on what constitutes a rigorous semantic foundation, we cannot build systems that truly understand each other. To cut through the confusion, I have drafted these 9 Foundational Principles, a baseline prerequisite to ensure we are speaking the same language when engineering knowledge. I would love to get the community's brutal feedback on these. Are we aligned? 👇 The Semantic Prerequisites: Principle 1 (Conceptualization): An ontology is a formal, explicit specification of a shared conceptualization of a real-world domain. Principle 2 (Abstraction and Modularity): The level of detail in an ontology is guided by its initial use case, but its semantic structure must be designed to be reusable and extensible by design. Principle 3 (Foundational Alignment & Real-World Fidelity): The domain ontology aligns explicitly with a realist Upper Ontology. Principle 4 (Semantic Consistency): The concepts, axioms, and relationships defined in the ontology must not contradict verified domain knowledge of the real world. Principle 5 (Multi-Level Stratification and Consistency): The ontology must explicitly distinguish between real-world physical instances, their immediate categories (Types), and higher-level categories of those categories (Types of Types). Properties and logical rules specific to one level must not be conflated or mixed with those of another level. Principle 6 (Determinism of Laws to govern the reality): The invariant laws governing reality (e.g., physical laws, strict business rules) act as absolute validity constraints on ontology properties and instances. Principle 7 (Formalization and Computability): The ontology is expressed in a formal logic language with computational semantics (e.g., OWL / Description Logic), enabling automated consistency checks by software agents (reasoners). Principle 8 (Separation of Concerns): The data model addresses only constraints related to data structuring, performance, storage, and computing, which are completely independent of the ontology's pure semantic logic. Principle 9 (Operational Embodiment): The data model is a technical translation and instantiation of the ontology, allowing a computer system to process data without altering or losing its original meaning. An ontology is not just a glorified data schema; it is a contract of meaning meant for machine reasoning. Which of these principles do you find the hardest to enforce in production today? Did I miss a foundational pillar? Let’s discuss in the comments. 👇 #SemanticWeb #OntologyEngineering #DataArchitecture #KnowledgeGraphs #AI #DataStandards | 14 comments on LinkedIn

Semantic satiation and enabling architectures don't shy away from natural "loss of meaning" but become defensible against it.

Once you've captured a retiring operator's expertise, how does AI make it usable for a new hire? A plain-language look at the mechanism, and what it can't do.

Why concept management and knowledge representation decides whether your AI gives the right answers

I was at the 2026 Databricks Data+AI Summit, attended the keynotes and a few talks, met with a lot of customers, and had many hallway conversations.

The ontology engineering process is complex, time-consuming, and error-prone, even for experienced ontology engineers. In this work, we investigate the potential of Large Language Models (LLMs) to...

The term fractured into three meanings in a single year. The fracture is not a vocabulary squabble, it's a map of where the value is moving.

The New Dimension Of Knowledge Work 📏 A coding agent knows when it's done because the compiler tells it. That one fact is the whole engine. Write the code, run the tests, read the verdict, correct, repeat. The loop closes because something outside the model returns ground truth that is not an opinion. The tools built to extend Codex into the rest of knowledge work are software-brained: they assume the final artifact is what matters, because in code it mostly is, and because code is the rare domain that ships its own verifier. Most knowledge work ships two things code keeps fused. The deliverable, and the inquiry that produced it: the research, the abandoned branches, the failed attempts, the reasoning path. In code that inquiry is scaffolding you discard at merge. In analysis and management it is the value. A memo is worth the grapple behind it, not the headings on top. So the new dimension is an inversion. The line of the week is "code is disposable, the spec is the asset." For knowledge work it flips: the artifact is disposable, the process is the asset, and nothing on the market captures it. This is also why harness-as-moat machinery stalls outside code. HarnessX gates its edits on verifier scores. S-Agent distilled a Qwen3-VL-8B to GPT-5.4 and Gemini 3 level by filtering trajectories on task correctness. Every loop presumes a ground-truth oracle. Remove the oracle and the loop optimizes the only signal left: it stops being checked against what is true and starts being checked against what sounds true. A wrong coding agent fails the test. A wrong knowledge-work agent just sounds right. What has to be invented sits below the model: a non-plausibility quality signal for non-code work, and the inquiry process treated as a first-class, retained, inspectable asset. Where a latent verifier exists, it can be surfaced. Forecasts have outcomes. Decisions have consequences. Where none does, the process is the only ground truth there is. The open question is whether judgment work can be given a verifier at all, or whether some of it is verifier-free by nature.

AI did not simplify the graph technology market.

From automated semantic artifacts to the problem of shared understanding Every few weeks, new announcements claim that AI can now generate ontologies, semantic models, or knowledge graphs automatically. Documents become taxonomies.

Exploring a Few Ontology Variations

Knowledge graphs store facts, but the world is full of uncertainty. 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. #KnowledgeGraphs #BayesianInference #GraphDatabases #Semantics

Inspired by Francois Vanderseypen s reflections on the automation of ontology creation. Recent months have confirmed what many of us suspected: ontology creation is becoming increasingly automated.

Every year, thousands of engineering teams make the same expensive mistake: they confuse the tool with the outcome. There's a question that gets asked in data architecture meetings every week, in boardrooms, in Slack threads, in conference rooms filled with sticky notes and whiteboard diagrams: "Sho

AI agents can't remember anything. So we fixed it. Today, we're introducing cognee V1: a major breakthrough in agentic intelligence. Cognee is 145% better than Opus 4.8 and GPT 5.5 at long context memory recall. Cognee allows for a 100 BILLION token context window. That’s 100,000x more than Claude. Cognee is 6.9x cheaper than GPT 5.5 and Opus 4.8. Cognee isn’t a new place to build agents. Cognee works as a memory layer on top of the agents you’ve already deployed, across any platform, and makes them significantly cheaper, faster, and more accurate. Right now, AI agents like Claude Code and Codex waste up to 90% of their tokens rebuilding context they should know. They forget critical information between prompting sessions, compress & forget context, burn compute searching for relevant context, and ultimately guess when they can't find the right answer. Cognee gives agents persistent, dynamic memory. Here's how it works: - You connect your agent to Cognee. - Cognee then builds a dynamic memory graph of everything your agent sees: conversations, documents, code, tools, and automatically builds relationships between them. - When you prompt your agent to do a task, Cognee activates that memory graph to retrieve the most relevant context, while continuously updating how knowledge is connected, prioritized, and understood over time. Instead of forcing the model to reread everything, Cognee surfaces what is critical every session: giving your agents higher-quality context with dramatically fewer tokens. The result: up to 1,000x more context than frontier models, 40% higher accuracy, and up to 10x lower cost. Everything in my life has led to this moment. I moved to Germany with no coding background, taught myself everything from scratch, and worked my way into data engineering and product roles on large-scale systems. Along the way, I went back to study cognitive science in my 30s, started building again with no money or network, and eventually turned an idea about AI memory into a company. So far, I’ve built systems used by thousands of users and raised backing from strong technical investors... but I still have something to prove. We spent 3 years and nearly went bankrupt building Cognee with neuroscience researchers from Ivy League universities. Cognee is our Magnum Opus. To celebrate our launch, we're giving away the secrets to boost Claude’s output by 400%. Reply to this post & we’ll send you the link. | 418 comments on LinkedIn

Cheeky investors and aggressive inquiries sometimes reveal more than they ask. The race to automate ontology creation is clearly on and it's moving faster than people realize. The demand for taxonomists and ontologist might come to an halt. It simply takes too long for companies in need of tens, hundreds or sometimes thousands of ontologies. I see three flavors of automation emerging, but do let me know if you have some other magic. The LLM-native builders like Perseus (Lettria) generates ontologies directly from text exported in RDF. Fine-tuning LLMs with heaps of data. It won't replace a seasoned ontologist, but it lowers the entry cost dramatically. The research community is moving fast here too: frameworks like Ontogenia show that LLMs can produce logical axioms at consistency levels comparable to junior human modelers. There is the enterprise graph platform like Stardog's Voicebox. It ships basic ontology generation via a GenAI multi-agent system. Their thesis is blunt: coverage beats perfection. A system-generated ontology that's 80% right and deployed is worth more than a perfect one still in a workshop. You also have the SQL-native pragmatists. Timbr.ai is probably the most aggressive automation play right now. They auto-generate an ontology draft from your existing schema (Snowflake, Salesforce, Databricks, whatnot) and let you refine from there. Mind, it ain't OWL. It's SQL-native and virtual. Not for RDF believers but it's winning on adoption. And then... the platform giants decided they wanted in. Snowflake shipped Semantic View Autopilot. Databricks took Unity Catalog Business Semantics to GA. Microsoft unveiled Fabric IQ Ontology with MCP endpoints. Google's Looker BI Agents are grounded in an auto-generated Knowledge Catalog semantic graph. Collibra launched Semantic Agents that read your existing business glossaries and generate semantic models from them. Spoke about these before. The interesting open question is: will the pragmatic SQL-native approaches pull formal ontology down-market and make it mainstream? Or will the OWL/RDF community watch the world absorb the term "ontology" and use it to mean something quite different? Neither, of course. The world is complex and we create ever more diverse solutions. The second law of thermodynamics comes to mind. #KnowledgeGraphs #Ontology #Semantics #GraphDatabases | 23 comments on LinkedIn