GraphNews

Turning domain knowledge into governed, executable, and auditable decision logic

The Market Distraction Recently, major data platforms (e.g.

When you extract a knowledge graph from a document, what you feed the model matters more than which model you use. In fact, small models perform usually better than larger ones. Thinking models, in particular, are slow and they analyze rather than extract. Raw text is dense, co-referential, and context-dependent. Sentences refer to things like "it", "the company", "this approach"... entities that only resolve if you've read the paragraph before. Feed that directly to an extractor and you get ambiguous predicates, dangling references, and relations that fall apart outside their original context. Atomic proposition extraction is a pre-processing step that fixes this. Before any triple is produced, the document is decomposed into minimal, self-contained claims, each expressing exactly one fact, with all pronouns and references resolved to their full entity names. The extractor then operates on units that are already semantically isolated. Something like KGGen, a Stanford pipeline built on top of DSPy, achieves 66% extraction accuracy this way. The improvement comes not from a better extraction prompt, but from the structure of the input. Decontextualization (creating a self-contained chunk) is the step most implementations skip or underestimate. It requires a sliding context window. Each chunk is resolved against prior material before extraction begins. If done well, it enables parallelization and cutting wall-clock time significantly. On the model side, latent reasoning optimization (LaTRO) offers a complementary lever. Rather than relying on chain-of-thought prompting or external reward signals, LaTRO treats reasoning as sampling from a latent distribution and optimizes it variationally hence improving both reasoning quality and self-evaluation in a single training loop. Applied to the extraction step, it can sharpen triple inference from propositions without touching the pipeline structure. For temporal knowledge graphs, Graphiti takes this further by attaching validity intervals to each extracted fact, enabling the graph to represent a world that changes over time rather than a static snapshot. LaTRO: https://lnkd.in/euTRcitm Graphiti: https://lnkd.in/ega9Esbi DSPy: https://dspy.ai/ #KnowledgeGraphs #Ontology

Taxonomy vs Ontology vs Semantic Mapping vs Knowledge Graph. I see these terms getting mixed up a lot in enterprise AI and data architecture discussions. They sound similar, but they are solving different problems. The way I look at it: Taxonomy = organize the information It gives a clean structure. Example: Product Electronics Laptop Ultrabook It helps with classification, navigation, reporting, and standardization. Ontology = define the meaning It explains the concepts, properties, and relationships. Example: Customer places an order Order contains Product Product belongs to Category This is where the business meaning starts to become clear. Semantic Mapping = align different systems Most enterprises have the same concept stored in different ways across systems. Example: CRM says Customer ERP says Client Support system says Account Semantic mapping connects these terms to a common business meaning. Knowledge Graph = activate the connected knowledge This is where entities and relationships come together as a network. Example: Customer → placed → Order Order → contains → Product Product → belongs to → Category Customer → raised → Support Ticket Now AI systems can use the relationships, not just isolated records. That is the important part. A knowledge graph is not just a graph database. Without proper taxonomy, ontology, and semantic mapping, it can easily become another messy data layer. For enterprise AI, especially RAG, agents, semantic search, recommendation, and decision intelligence, this foundation matters a lot. To sum it up in one line each: Taxonomy organizes the structure. Ontology defines the meaning. Semantic mapping aligns across systems. Knowledge graph connects everything into usable context. This is how scattered enterprise data starts becoming usable enterprise knowledge. #EnterpriseAI #KnowledgeGraph #Ontology #Taxonomy #SemanticMapping #DataArchitecture #AIArchitecture | 28 comments on LinkedIn

Six months ago, a senior architect at a bank I work with closed his laptop in a meeting, looked at me, and said the thing nobody on his team would say out

The era of the context-aware agent–business user is here. 🧠🤝 Ontologies and knowledge graphs aren’t handed down from a technical silo anymore. With OntoBricks 0.6.0, they’re created, managed, and consumed by business users and AI agents — in context: on the entity, the mapping, the graph node. Not in a side chat that loses the thread. 💬 Comment where the model lives ✅ Assign tasks to teammates 🤖 Let agents propose, map, and interpret — grounded in your data 🔍 Review every change — human or AI, always traceable Design together. Govern together. Query together. Same workspace. Same context. Same graph ... Everything stays in Databricks !!! OntoBricks 0.6.0 is out now 🚀 → https://lnkd.in/e8je4TGn #KnowledgeGraph #ContextAware #AIAgents #Databricks

Walk into any enterprise AI conversation today and you'll hear "ontology" everywhere. Then ask five people what an ontology actually is, and you'll get five different answers! This isn't a terminology problem.

Why every semantic layer eventually collapses under its own governance mass

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