GraphNews

One of my favourite images, courtesy of Tudor Girba It shows the self generated architecture of 7 different systems. Each of those graphs contain objects, function calls and data structures. What might not be obvious is those seven systems do the same thing. They were built with the same specification, same testing suites, same tools, same environment but by seven different teams. Why such huge differences? Well, first the code is the real architecture and not some diagram in a specification document (which is little more than a statement of belief). Second, the real architecture represents all the hundreds or thousands of small decisions made by the person building the code. The choices they make depends upon many factors from experience to the values they have. As Norman Foster said, "Architecture is an expression of values" and that's true no matter what type of architecture we are talking about. Whenever you build a system with a co-pilot or an agentic swarm, thousands of small decisions are being embedded into your architecture based upon the values those LLMs have been trained with. The LLM is culturally a non kinetic form of warfare. It's no different from how we've used art such as Hollywood, video games or books to change other cultures. Except this time it's on steroids and there are few players in the game. So, I'm glad to see that the Mayor of London, Sadiq Khan has strolled into the Met Police Palantir contract debate and blocked it. I know it's from a procurement angle but as his spokesperson said "The Mayor believes that Londoners would want public funding to go only to companies that share the city's values". It's about time people started talking about value in this world of AI where everything is sacrificed to expediency. | 10 comments on LinkedIn

Did you start building your ontology as a set of rows in a custom database table? The instinct is completely understandable. As software engineers we have spent our careers putting things into databases: customers, orders, events. So when the organisation says it needs an ontology, the database is the tool to hand. But please let me suggest a different way of looking at the problem. Because an ontology really is not that kind of artefact. ⚡ Ontology IS Code ⚡ It is where your organisation declares what kinds of things exist, how they relate, and what cannot both be true. It is logic. It is expressive. It is a graph of interrelated concepts that build on one another. Formal logic, expressed as a set of rigorous axioms. So treat it that way. 🔵 It should compile. Not just parse. Compile. The syntax should be valid. The classes should be satisfiable. The entailments should be the ones you expected. An absent entailment is a test failure, not a curiosity you discover six months later in production. If the model says two things that cannot both be true, the build should break. If a new term silently duplicates an existing concept, the build should break. You would not ship application code that crashes on import. Do not ship an ontology that contradicts itself. 🔵 It should live in plain text. You would not write your application code in a database table. The reasons are obvious. You want files. You want diffs. You want branches. You want blame, line by line. You want pull requests and review in context. All of this is just as true for the classes in your ontology. It is especially true now that we have large language models in the loop. You do not only want the LLM reaching for your ontology through an API or an MCP server. You want it to read, navigate and edit the source directly, exactly the way it works with a codebase. 🔵 It should be governed like code. Branches. Pull requests. Reviews. Automated checks. Releases. Builds. None of this needs inventing. Your engineering organisation already does all of it, often for code that carries far less conceptual weight. The artefact that decides what your organisation means by a customer, an order, a risk, a product should not be governed less rigorously than the CSS on your marketing site. Compile it. Branch it. Review it. Ship it. Because it is not a table. Not a schema. Your ontology is source code for your meaning. ⭕ McOntology: https://lnkd.in/e_5YqTPe ⭕ The Knowledge Graph Guys: https://lnkd.in/eMQwyBpj | 100 comments on LinkedIn

An LPG practitioner’s view of how Applied Knowledge Graphs give agents state, memory, evidence, tool routing, policy, and decision trace

Enterprise Agentic AI is going nowhere without serious Enterprise Context Engineering. And currently, there are two dominant schools of thought on how to go about it: top-down and bottom-up. Let me explain. The top-down school: Humans document how the enterprise works across domains like finance, legal, HR, and procurement. They encode this knowledge into ontologies, knowledge graphs, and RDF, and LLMs maybe act as helpers. Agents then operate over a curated semantic layer that dictates the rules before they act. The bottom-up school: Context already exists within your systems. If your SAP instance is talking to Workday, a well-grounded LLM can infer meaning directly from transactions and schemas—without requiring anyone to build a single ontology. But do we really need to choose one or the other? I don’t think so. Here's why: Transaction data tells you what did happen, not what should happen. The unwritten rules, the exception logic, the institutional judgment calls—none of that lives in your integration layer. While bottom-up methods capture historical behavior, top-down approaches provide the prescriptive, normative grounding agents need before they act. In other words, we need top-down to tell agents what to do and bottom-up to see what they did and refine what they do. It can’t be either/or. In both large enterprises and startups today, there are more takers for bottom-up since people don't have to document things manually. Top-down requires people from different departments to sit and manually write down things, which seems like a huge exercise (it isn't) in large enterprises and unattractive to startups. But again: it c.a.n.n.o.t. be either/or. -- Thank you Jessica Talisman, Ora Lassila, Navin Sharma, and Daniel Davis for the insightful discussions.

There is a reason we call them language models. It is the kind of sentence that sounds obvious until you sit with it and look around your digital environments. Large Language Models. Not large knowledge models or large reasoning models or large world models. Language is the substrate and the bridge, the surface with which we interact with systems and interfaces. Strip the language away and what remains is a tensor of weights with no bearing on the real world.

In "Everyone Has an Ontology Now. Almost Nobody Has an Ontology," I pointed out a current trend: almost anything related to semantics or formal consistency is now being labeled an ontology.

Main topics: foundations, context, vendor strategy, governance is also king and queen, methodologies and awesome data community

In an era when unstructured data is seen as the most critical fuel for the artificial era ahead, it’s time knowledge management had a seat at the table.

We're all deeply integrated in the AI-world now and have most definitely felt the need for some new special skills. This one's all about that.

Of course, Oracle has ontology support and 'trusted answer search'. It's more substantial than you think. Oracle has had native RDF, OWL inference, and SPARQL support in its database since 2007, predating most dedicated triplestores that are household names today. With Oracle 23ai they added SQL/PGQ (ISO standard property graph queries in plain SQL), integrated vector search, and LLM-based triple extraction from unstructured documents. Basically, full scale multi-modal. At the same time, they have no story around intelligent document ingestion, ontology-guided extraction pipelines, or structured LLM output with validation. Their LLM integration is demonstrator-level. The interesting divide in this space is not RDF vs LPG anymore. It's between systems that store knowledge and systems that build it. Oracle owns the first category at enterprise scale. The second is (I mentioned it many times) wide open. https://lnkd.in/eEA72bXH #KnowledgeGraphs #Semantics #Ontology #EnterpriseAI #GraphDatabase #Oracle

Building Agentic Memory on Graphs — Reality Check “Agentic memory on graphs” is quickly becoming a buzzword. But in practice, we are still very early. After winning the NVIDIA Hackathon with our VoiceApp solution (https://lnkd.in/dRuiyDKu) — where we used graphs as agentic memory — I hit a wall. The uncomfortable realization: 👉 Triples are not enough. 👉 Named entities are not enough. 👉Just tracking the flow is also not enough, you have Langgraph state for it! These graphs structure data… but they do not necessarily capture meaning. Even when pushing knowledge graphs further, I kept running into the same limitations: Complex, multi-dimensional relationships (especially in causal systems), Context that evolves across time, actors, and layers, dependencies between relationships, edges depending on edges and nodes having subnodes? In real-world client scenarios, this complexity is the norm—not the exception. And traditional graph models struggle to reflect it. 💡 Accenture slogan is Reinvent. The shift in perspective. Everything started to click when I came across the work of Volodymyr Pavlyshyn on metagraphs. Traditional graphs (and even hypergraphs) still fall short when modeling: relationships between relationships, multi-entity interactions, hierarchical and temporal context. You need metagraphs to make it work. Metagraphs break the rigid structure of classical graphs: Edges can connect sets of nodes to sets of nodes. Edges themselves can be treated as first-class entities. Relationships can have other relationships. Everything is a graph, there is distinction any more between nodes and egdes, only the context matters! Mind blowing death of the rigid Ontology! This is exactly what agentic systems need for real memory. If we want agents to: reason across contexts, handle causality, build long-term, structured memory …then we must go beyond: - triples - entity extraction - static schemas Because real-world knowledge is: - non-linear - nested - multi-layered And our data structures need to reflect that. ⚠️ The current gap There is still no mature, out-of-the-box technology that fully supports this paradigm. But what is exciting: 👉 Practical workarounds are offered in Volodymyr's book: from extending graph DBs (e.g., Neo4j-style abstractions) to modeling metagraph concepts directly in SQL or hybrid systems 📚 Final thought We are at the same point with agentic memory as we were with knowledge graphs for AI a few years ago: 👉 The idea is ahead of the tooling. Metagraphs might be one of the missing pieces to move from structured data → machine-understandable meaning. Highly recommend digging into this space. 🔖 Hashtags #AgenticAI #KnowledgeGraphs #ArtificialIntelligence #GraphData #CausalAI #Metagraph #AIEngineering #LLM #DataModeling #neo4j #nvidia

Background For full disclosure: I have spent the last twenty years inside knowledge graphs and their predecessors. Around 2005 I read Sir Tim Berners-Lee's 2001 Scientific American paper on the Semantic Web — the idea that the web should link not just documents but the things documents describe, so

Sovereign Artificial Intelligence, semantic infrastructure, and the map beneath the model

SHACL 1.2’s First-Class Support for RDF Linked Lists

Why Building a Semantic Layer Without a Validated Use Case Is Dangerous  Many organizations build a semantic layer such as an ontology or knowledge graph simply because it feels strategic or forward thinking. Yet without validating real customer questions first, it becomes one of the most expensive anti patterns in data management.  The Core Danger Solution in Search of a Problem  A semantic layer is an abstraction. It defines entities, relationships, and rules. Without a validated use case you cannot decide which entities matter, at what granularity, or which rules must be enforced.  The outcome is predictable   - Over engineering model everything and slow down progress.   - Under engineering miss essential relationships and fail to answer business questions.   Both create structures that look impressive but fail to deliver business value.  The Myth Hidden Insights Will Appear Automatically  Connecting data alone does not create insight. Without business context, knowledge graphs often surface irrelevant or misleading results.  | Risk | Description | |------|--------------| | False signals | Apparent correlations without causal meaning. | | Insight overload | Thousands of trivial findings with no priority. | | Fragmentation paradox | Poor alignment produces inconsistent subgraphs and new silos. | A Healthy Customer Driven Process  Customer Decision Need → Competency Question → Minimal Ontology → Query → Validation → Iterate  The knowledge graph is never the starting point. The real customer need always comes first.  The Bottom Line  - Do not build semantic layers without validated use cases.   - Validation comes from real customer questions that represent decisions.   - A knowledge graph cannot validate itself; it is a reasoning tool, not a measure of value.   - Start small, deliver proof, then expand. Trust is earned through useful answers, not elegant models.  👉 Follow me for Knowledge Management and Neuro Symbolic AI daily nuggets   👉 Join my group for more insights and community discussions [Join the Group](https://lnkd.in/d9Z8-RQd)  #KnowledgeGraphs #OntologyEngineering #SemanticAI #KnowledgeManagement #NeuroSymbolicAI #AIEngineering #ExplainableAI #DataGovernance

A companion to "The Semantic Medallion", building out some of what the original walkthrough deliberately scoped out.