GraphNews

"You will be in the top 1% of Enterprise Architects" if you truly understand this one idea: EA is not separate business, application, data, and technology architectures. It is one connected enterprise traceability system. Strategy → Value → Capability → Process → Application → Technology → Transformation Once you see how every layer connects and influences the next, architecture stops being static documentation and becomes a real enterprise decision-making system. Most Enterprise Architecture diagrams explain only a slice of the enterprise. This poster attempts to connect the entire EA in one view: WHY → WHAT → HOW → WITH WHAT → WHEN From: • Stakeholders, drivers, assessments, goals, outcomes, value To: • Capabilities, value streams, resources, courses of action Then: • Business services, processes, actors, objects Into: • Applications, services, components, interfaces Down to: • Technology services, nodes, devices, system software, networks And finally: • Work packages, deliverables, plateaus, and transformation states The most important realization while building this: EA is not multiple disconnected architectures. It is one continuous traceability system: Strategy → Operating Model → Solution Architecture → Technology → Transformation A few deep observations: • Value Streams explain how value progresses. • Capabilities explain what the enterprise must be good at. • Business Processes explain how work executes. • Applications operationalize capabilities. • Technology enables execution. • Implementation & Migration explain how the enterprise changes over time. The real power of EA starts when every layer is traceable to the layer above and below it. This is where architecture stops being documentation and becomes an enterprise decision system. #EnterpriseArchitecture #ArchiMate #BusinessArchitecture #SolutionArchitecture #TOGAF #DigitalTransformation #OperatingModel #CapabilityMapping #ValueStreams #Architecture #EA #BusinessTransformation #ITStrategy | 66 comments on LinkedIn

The Living Graph, Part I: A Genealogy of Intent

Federated Time-Series Queries with maplib's chrontext magic

Learn how graph-on-relational engines work in 2026: PuppyGraph, SQL:2023, ISO GQL, hyperscalers, and Prometheux. A deep dive into the category.

If you have been following the enterprise AI debate, you will have encountered a growing consensus: AI only works when anchored in structured context. Ontology, semantic layers, knowledge graphs — the terminology varies, but the argument is consistent.

I presented my paper “Giving AI a Shared Language: Unified Knowledge Graphs for Multimodal Data” at ICMLT 2026 in Berlin. In previous posts, I explained the method behind it: different data types can be represented in a shared space, and relationships can act as the structure that connects them. I applied this idea to country-level data: country background text from the CIA World Factbook, and time-series indicators from the World Bank. Country borders became the relational backbone. The interesting part was the outliers. Some neighboring countries were economically very different. Some border neighbors had surprisingly different Factbook narratives. Some regions showed uneven neighborhood patterns. And this connects to the bigger question from my last slide: as multimodal AI becomes more powerful, the relationship-aware layer becomes more important — not less. AI can process the pieces. Relationships turn them into connected knowledge. #AI #GraphAI #KnowledgeGraphs #MultimodalAI #RelationshipAwareAI #EnterpriseAI #DataStrategy

Twelve useful questions that all ontologists should ask

AI solutions need to be grounded in an organization’s context. Taxonomies and ontologies can do this heavy-lifting.

When to Use a Labeled Property Graph and When to Use an RDF Ontology-Based Knowledge Graph and when might you need both?

We've talked about Glean's Enterprise Knowledge Graph since 2019. People kept asking to see it, so we built a demo. Ask Glean something like: "show me my manager's projects and the team behind them" and watch it traverse the graph in real time, mapping work and people across your org. Because these entities are pre-indexed in the graph, Glean retrieves the answer instantly. This is what enables multi-hop reasoning and saves the LLM from burning tokens re-reading dozens of documents to piece together the answer on every run. This is just a tiny slice of the data the Enterprise Graph contains. Props to David Huynh for putting this beautiful demo together! | 30 comments on LinkedIn

Less than a month ago I released Ontosphere — a browser-based OWL ontology editor with MCP support, built so that AI agents can build and query knowledge graphs entirely client-side, without a server or a plugin. This post is about what has happened since.

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.