GraphNews

6121 bookmarks
Custom sorting
Semantic layer from an LPG practitioner's point of view: what are we all confused about?
Semantic layer from an LPG practitioner's point of view: what are we all confused about?
Semantic layer from an LPG practitioner's point of view: what are we all confused about? We talk about semantic layers as if everyone means the same thing. We do not. For some, it is a SQL facade. For others, it is a metrics layer, ontology, catalogue, governance wrapper, data product contract, knowledge graph, or AI grounding layer. For LPG teams, the confusion is sharper. We already model meaning in the graph. Labels, relationship types, properties, paths, and patterns express how the business sees the domain. So when someone says "semantic layer", the question is: layer over what? Tables, to hide joins? Metrics, to standardise definitions? Data products, to support discovery? A graph, to expose a shared domain model? AI, to ground prompts? All are valid. None is the whole story. To be clear: a semantic layer is not an RDF layer. RDF, OWL, and SPARQL are useful for semantics, reasoning, and interoperability. But semantics do not only exist in triples. In LPG practice, meaning can live in topology, naming, constraints, identifiers, provenance, time, confidence, lineage, and exceptions. The mistake is treating "semantic" as a technology label instead of an organisational agreement. A useful semantic layer handles three concerns: meaning, access, and control. Meaning is what things are called and how they relate. Access is how people query data without knowing every physical detail. Control is how definitions, ownership, quality rules, and policies are managed. If it only gives access, it is a nicer query interface. If it only captures meaning, it is documentation. If it only controls, it is governance theatre. For LPG practitioners, the opportunity is a bridge between business language and analytics, applications, AI agents, and decision makers. That means being honest about the boundary. The graph, ontology, BI model, metrics store, and RDF layer are not automatically the semantic layer. The semantic layer is where agreed meaning becomes usable. Maybe the real confusion is this: we are trying to buy a semantic layer before agreeing on what semantics means in our organisation. Start there. Name the core concepts. Define the relationships. Decide which definitions are governed and which are local. Make the model queryable and explainable. Then choose the tooling. The best semantic layer is not the one with the most impressive architecture slide. It is the one people trust enough to reuse.
Semantic layer from an LPG practitioner's point of view: what are we all confused about?
·linkedin.com·
Semantic layer from an LPG practitioner's point of view: what are we all confused about?
Giulia. A persistent, local-first AI development daemon built in Elixir/OTP. AST-level code intelligence, Property Graph, runtime BEAM introspection, and semantic search — all via a 80+ endpoint REST API
Giulia. A persistent, local-first AI development daemon built in Elixir/OTP. AST-level code intelligence, Property Graph, runtime BEAM introspection, and semantic search — all via a 80+ endpoint REST API
·linkedin.com·
Giulia. A persistent, local-first AI development daemon built in Elixir/OTP. AST-level code intelligence, Property Graph, runtime BEAM introspection, and semantic search — all via a 80+ endpoint REST API
Most agent memory failures are not solved by more memory
Most agent memory failures are not solved by more memory
Most agent memory failures are not solved by more memory. 🕋 The dominant pattern is memory-pull. Embed everything. Store it in a vector database. At conversation time, retrieve the top-k chunks by semantic similarity, inject them into context. Mem0 ships this. Letta ships this. Most production agents have some version of it. The pattern works for breadth. It fails for organizational coherence. A vector store with a million embeddings can answer "what did the user say about X six months ago." It cannot reliably answer "what is the parent project this conversation belongs to," because the parent is not always lexically similar to the question. An alternative has been observed twice this month from different angles. One critique of a parallel-vector-graph RAG library: the graph disappears after the answer is generated, so the persistent knowledge structure never accumulates. One personal-agent experiment: nested topic trees with parent descriptions injected into child system prompts at conversation start. No retrieval. No embeddings. Hierarchical text concatenation. Context = parent topic + parent of parent + parent of parent's parent, concatenated into the system prompt. The tradeoffs are concrete. Memory-pull scales with knowledge breadth. Topic-tree scales with organizational depth. Memory-pull retrieves by semantic similarity, which can miss the load-bearing parent. Topic-tree retrieves by structural position, which always loads the parent because the parent is structurally above. Memory-pull surprises you when it forgets. Topic-tree forgets predictably. A production agent needs both. The architectural choice of which layer to invest in determines what kind of forgetting you get. When an Obsidian vault becomes an agent's memory, the file structure is the topic tree. When a Claude Code project has a CLAUDE.md, that file is the parent topic. When a customer-support agent confuses product lines, parent-topic injection is the missing piece. Memory-store size does not help. The memory problem gets discussed because vector-store memory is sold as a category. Hierarchical context injection is so old nobody pitches it. IDEs have done it for thirty years: project, file, function. The function inherits the file's imports inherits the project's config. Agents need the same shape. Practical implication: before adopting a memory framework, design the topic hierarchy. If the parent context is missing, no memory framework recovers it. If the parent context is present, much of what people call memory becomes unnecessary. The architectural primitive for agent context is hierarchy. Memory frameworks operate downstream of it.
Most agent memory failures are not solved by more memory
·linkedin.com·
Most agent memory failures are not solved by more memory
An Empirical Study of Knowledge Graph-Enhanced RAG for Information Security Compliance
An Empirical Study of Knowledge Graph-Enhanced RAG for Information Security Compliance

GraphRAG Meets Regulatory Compliance: KG-Enhanced RAG for ISO/IEC 27000 A study published in Information (MDPI, 20 April 2026) demonstrates the practical limits of conventional RAG when applied to the ISO/IEC 27000 family of information security standards — 97 cross-referencing documents whose dense interdependencies defeat chunk-based retrieval — and proposes a privacy-preserving alternative using LightRAG, a knowledge graph-based retrieval system paired with locally hosted open-source language models.

The core finding is architectural rather than merely empirical: traditional RAG, which treats document segments as independent retrieval units, systematically fragments the contextual relationships that give regulatory standards their meaning. Cross-references, conditional requirements, and scope qualifiers — precisely the structures that compliance analysts must navigate — are severed at the chunk boundary. The knowledge graph substrate preserves these connections, allowing the system to follow multi-hop reasoning paths that mirror actual compliance interpretation.

The team released the ISO27K-QnA-Benchmark dataset publicly on Hugging Face to support reproducible evaluation, a useful contribution to what remains a sparse landscape of domain-specific regulatory benchmarks.

A companion paper published in Neural Computing and Applications (13 April 2026) — GRAGLLM — takes a similar hybrid approach to multi-aspect sentiment analysis, constructing a Neo4j knowledge graph where nodes represent reviews and aspect categories, with edges capturing semantic relationships, and layering dense retrieval on top via hybrid Cypher-plus-embedding querying.

👉 Both papers reinforce the same thesis: structured semantic representation is not optional when reasoning must traverse interconnected, formally defined knowledge — it is a prerequisite.

·mdpi.com·
An Empirical Study of Knowledge Graph-Enhanced RAG for Information Security Compliance
Welcome to Google Cloud Next26 | Google Cloud Blog
Welcome to Google Cloud Next26 | Google Cloud Blog

Google Cloud Next '26: Enterprise Knowledge Graph Takes Centre Stage At Google Cloud Next '26 (22 April 2026), Google announced a cluster of interconnected initiatives that collectively signal a strategic bet on knowledge graph infrastructure as the semantic backbone of agentic enterprise AI.

The centrepiece is Smart Storage — a new storage tier that applies semantic meaning to unstructured data, serving as the foundation for what Google is now calling its Enterprise Knowledge Graph. Alongside this, Google announced Knowledge Catalog, described as a way to "ground agents in trusted business context across your entire data estate," and Workspace Intelligence, which reframes Google Workspace as a continuously updated knowledge graph over email, documents, and chat — a system designed not merely to store but to reason over organisational context.

The framing is significant. Google is no longer positioning knowledge graphs as a specialist data engineering concern; they are being presented as fundamental infrastructure for reliable agentic AI. The Knowledge Catalog announcement in particular echoes vocabulary that has long been native to the ontology community — curated vocabularies, semantic interoperability, governed retrieval — now arriving at hyperscaler scale.

Harness, announced as Google Cloud's 2026 Technology Partner of the Year for Application Development, also made news at the conference by integrating Google Cloud's Developer Connect into its Software Delivery Knowledge Graph, giving engineering teams a continuously updated semantic view of their entire delivery pipeline, with AI agents able to traverse that graph to accelerate diagnosis and remediation.

👉 The semantics community has built this architecture in standards-based form for two decades. It is now being implemented at infrastructure scale by the largest cloud provider in the world.

·cloud.google.com·
Welcome to Google Cloud Next26 | Google Cloud Blog
W3C Invites Implementations of RDF 1.2 Concepts and Abstract Data Model and RDF 1.2 Semantics
W3C Invites Implementations of RDF 1.2 Concepts and Abstract Data Model and RDF 1.2 Semantics

W3C Publishes RDF 1.2 Candidate Recommendation Snapshots The W3C RDF & SPARQL Working Group published Candidate Recommendation Snapshots of both RDF 1.2 Concepts and Abstract Data Model and RDF 1.2 Semantics on 7 April 2026, formally inviting implementation experience. The comment period closes 5 May 2026, with the Working Group signalling that advancement to full Recommendation cannot occur before that date.

The headline addition in RDF 1.2 is triple terms — the ability to embed an RDF triple as the object of another triple, providing a first-class reification mechanism that resolves one of the longest-standing pain points in the stack. Alongside this, the specification introduces directional language-tagged strings, allowing a base text-direction component to be attached to string literals, a long-requested internationalisation feature.

To exit the CR phase, the Working Group requires at minimum two independent implementations passing each test in the dedicated test suite, and at least one concrete syntax specification (such as N-Triples or Turtle 1.2) must also satisfy its own exit criteria. Implementation teams working with Jena 6.0, RDFLib, or other major triple stores should review the test suite in the rdf-tests repository and begin documenting conformance.

For ontologists and knowledge graph practitioners, triple terms are the change that matters most: they allow provenance, certainty, and temporal metadata to be expressed as native graph structure rather than as cumbersome reification workarounds. The formal semantics document — itself a revision of the 2014 RDF 1.1 model-theoretic semantics — defines precise entailment regimes for these new structures, grounding the extension in the same rigorous framework the community has relied on for a decade.

👉 This is the last significant checkpoint before RDF 1.2 becomes a full W3C Recommendation. If you are building against the stack, now is the time to test.

·w3.org·
W3C Invites Implementations of RDF 1.2 Concepts and Abstract Data Model and RDF 1.2 Semantics
Why a Knowledge Engineering Framework Is Essential (Even When Modellers Disagree)
Why a Knowledge Engineering Framework Is Essential (Even When Modellers Disagree)
Why a Knowledge Engineering Framework Is Essential (Even When Modellers Disagree) Ontology and knowledge engineering are never neutral. Modelling is an act of interpretation — translating human viewpoints into machine-readable form. Every modeller brings different assumptions, goals, and philosophies. These differences are inevitable, not mistakes. The real challenge is managing them productively. A knowledge engineering framework provides the structure to coordinate diverse perspectives while maintaining interoperability, quality, and trust. The Problem Modelling as Philosophy Modelling choices are rarely objective. When defining a class or property, each modeller makes conceptual decisions about meaning, boundaries, and scope. This leads to different but internally consistent ontologies that do not easily align. Integration suffers not because anyone is wrong, but because assumptions differ. What a Knowledge Engineering Framework Does A framework is a collection of governance practices, patterns, and validation tools that turn disagreement into productive diversity. Core Components Modelling principles – shared guidelines for scope, ontology alignment, and provenance. Design patterns – reusable structures that prevent arbitrary local design. Naming and IRI conventions – consistent syntax that improves searchability and alignment. Governance process – defined workflows for proposing and resolving differences. Validation suite – competency questions converted into SPARQL queries to test model adequacy. Handling Discrepancies 1 Accept variation as normal Do not pursue one perfect model. Enable multiple viewpoints that can still answer common queries through alignment. 2 Use alignment not unification Link equivalent or related classes through mappings. The goal is a network of connected models rather than a single hierarchy. 3 Capture design rationale Record why modelling decisions were made. This supports transparency and future learning. 4 Let competency questions decide If different models can answer the same test queries, both are valid. This makes utility the main success metric. 5 Manage versioning explicitly Define clear version tags, deprecation timelines, and changelogs linked to the questions or requirements impacted. 6 Automate repetitive checks Use SHACL and SPARQL to enforce data constraints and detect inconsistencies via automated validation pipelines. 7 Teach modelling pluralism Encourage analysts to document assumptions and respect alternative perspectives while maintaining functional coherence. 👉 Follow me for Knowledge Management nuggets 👉 Join my group for more insights and community discussions Join the Group #KnowledgeGraphs #OntologyEngineering #KnowledgeManagement #SemanticAI #DataGovernance #ExplainableAI #CompetencyQuestions #SPARQL #OntologyDesign #NeuroSymbolicAI #DigitalTransformation #KnowledgeFrameworks
Why a Knowledge Engineering Framework Is Essential (Even When Modellers Disagree)
·linkedin.com·
Why a Knowledge Engineering Framework Is Essential (Even When Modellers Disagree)
Breaking: Ultipa GQLDB is officially here
Breaking: Ultipa GQLDB is officially here
🚀 Breaking: Ultipa GQLDB is officially here. After years of engineering, we're launching GQLDB — v6 of Ultipa's real-time graph database, and the world's first native graph database to fully speak ISO GQL (ISO/IEC 39075). What makes GQLDB different: ✅ 100% ISO GQL — portable, future-proof queries, no vendor lock-in ✅ AI-native by design — natural language to GQL (AI.GQL()), vector embeddings (AI.EMBED()), similarity search, and built-in RAG ✅ One engine, no stitching — graph + vector + full-text + RDF/ontology, all native ✅ Real-time graph-native storage — index-free adjacency, full ACID ✅ Deploy anywhere — embedded, gRPC/REST service, or distributed cluster And the best part? The Community Edition is completely free and installs in seconds as a single binary. No license friction, no cloud lock-in — just download and go. Whether you're building knowledge graphs for LLMs, modernizing AML and fraud detection, powering real-time recommendations, or tokenizing real-world assets — GQLDB is production-ready today. 👉 Learn more: https://lnkd.in/dVKwTdxS 👉 Try the playground instantly: https://gql.ultipa.com 👉 Download Community Edition: https://lnkd.in/dnNPzUST Huge thanks to the Ultipa team across Bay Area, EU, APAC, and beyond for making this milestone happen. The graph era just leveled up — and this time, it's standards-based. #GraphDatabase #ISOGQL #AINative #KnowledgeGraphs #VectorSearch #RAG #Ultipa #GQLDB
Breaking: Ultipa GQLDB is officially here
·linkedin.com·
Breaking: Ultipa GQLDB is officially here
A knowledge graph of the EU AI Act and its regulatory environment
A knowledge graph of the EU AI Act and its regulatory environment
𝐍𝐞𝐫𝐝 𝐩𝐨𝐬𝐭 𝐰𝐚𝐫𝐧𝐢𝐧𝐠: 𝐎𝐯𝐞𝐫 𝐭𝐡𝐞 𝐰𝐞𝐞𝐤𝐞𝐧𝐝 𝐈 𝐬𝐩𝐞𝐧𝐭 2.5 𝐦𝐢𝐥𝐥𝐢𝐨𝐧 𝐭𝐨𝐤𝐞𝐧𝐬 𝐚𝐧𝐝 ~€60 𝐛𝐮𝐢𝐥𝐝𝐢𝐧𝐠 𝐚 𝐬𝐞𝐜𝐨𝐧𝐝 𝐛𝐫𝐚𝐢𝐧 𝐟𝐨𝐫 𝐭𝐡𝐞 𝐄𝐔 𝐀𝐈 𝐀𝐜𝐭 𝐚𝐬 𝐚 𝐩𝐞𝐫𝐬𝐨𝐧𝐚𝐥 𝐩𝐫𝐨𝐣𝐞𝐜𝐭 - 𝐨𝐧𝐞 𝐭𝐡𝐚𝐭 𝐤𝐧𝐨𝐰𝐬 𝐞𝐯𝐞𝐫𝐲 𝐬𝐨𝐮𝐫𝐜𝐞, 𝐫𝐚𝐧𝐤𝐬 𝐭𝐡𝐞𝐦 𝐛𝐲 𝐥𝐞𝐠𝐚𝐥 𝐪𝐮𝐚𝐥𝐢𝐭𝐲, 𝐚𝐧𝐝 𝐧𝐞𝐯𝐞𝐫 𝐜𝐨𝐧𝐟𝐮𝐬𝐞𝐬 𝐚 𝐅𝐀𝐐 𝐰𝐢𝐭𝐡 𝐛𝐢𝐧𝐝𝐢𝐧𝐠 𝐥𝐚𝐰. 𝐍𝐨 𝐫𝐞𝐠𝐫𝐞𝐭𝐬. 😄 The concept comes from Andrej Karpathy: feed raw documents into a structured markdown folder, let an LLM compile them into a linked knowledge base. No vector database, no RAG pipeline. In practice: Claude Code reads and maintains the wiki, Obsidian is where it lives. Obsidian's Graph View shows the whole thing visually. Every source, every concept page, every connection between them. That is what you see in the video below. 𝐌𝐲 𝐬𝐮𝐛𝐣𝐞𝐜𝐭 𝐦𝐚𝐭𝐭𝐞𝐫: the EU AI Act and its regulatory environment. 𝐕𝐞𝐫𝐝𝐢𝐜𝐭 𝐚𝐠𝐚𝐢𝐧𝐬𝐭 𝐑𝐀𝐆: clear quality improvement. Structured pre-compiled knowledge beats shotgun context retrieval in RAG... especially for questions that cut across multiple sources and legal levels. But: building takes time, maintenance takes discipline, and you only get better answers if you curate carefully. 😐 I made several dozen refinements to Karpathy's original concept to make it work for legal. A few that matter most: 📌 𝐒𝐨𝐮𝐫𝐜𝐞 𝐡𝐢𝐞𝐫𝐚𝐫𝐜𝐡𝐲 𝐢𝐧𝐬𝐭𝐞𝐚𝐝 𝐨𝐟 𝐟𝐥𝐚𝐭 𝐬𝐭𝐨𝐫𝐚𝐠𝐞: ten categories ranked by legal quality, because a Delegated Act and a LinkedIn comment do not sit on the same level. 📌 𝐂𝐨𝐥𝐥𝐢𝐬𝐢𝐨𝐧 𝐥𝐨𝐠𝐢𝐜: when sources of different legal standing conflict, the tension is marked, not resolved. Legal uncertainty belongs in the answer, not swept under it. 📌 𝐒𝐭𝐚𝐭𝐮𝐭𝐨𝐫𝐲 𝐠𝐫𝐨𝐮𝐧𝐝𝐢𝐧𝐠 𝐫𝐞𝐪𝐮𝐢𝐫𝐞𝐦𝐞𝐧𝐭: concrete legal questions must be anchored in the actual text of the law, not just in wiki pages. Wiki = navigation. Statutory text = foundation. 📌 𝐀𝐧𝐭𝐢-𝐚𝐧𝐜𝐡𝐨𝐫𝐢𝐧𝐠 𝐫𝐮𝐥𝐞: my own prior publications are ingested last and treated as historical data points, not as the starting position for new analysis. Avoids the trap of an LLM confirming your old conclusions instead of testing them. 📌 𝐒𝐞𝐦𝐚𝐧𝐭𝐢𝐜 𝐝𝐫𝐢𝐟𝐭 𝐜𝐨𝐧𝐭𝐫𝐨𝐥: as the wiki grows through incremental edits, pages can quietly drift from their source material. A periodic audit pass checks whether wiki pages still accurately reflect the raw documents they are built on (more than Karpathy's lint command). Thanks to Oliver Schmidt-Prietz, whose post finally pushed me from planning to building. 👍 | 42 comments on LinkedIn
the EU AI Act and its regulatory environment
·linkedin.com·
A knowledge graph of the EU AI Act and its regulatory environment