GraphNews

Microsoft just announced Fabric IQ. At its core: an "Ontology item.

RDF 1.2 Candidate Recommendation is a real milestone, but not the finish line. W3C advanced RDF 1.2 Concepts and Abstract Data Model and RDF 1.2 Semantics to Candidate Recommendation Snapshot on 7 April 2026, with comments requested by 5 May 2026. For the Labelled Property Graph (LPG) world, the significance is not just timing. It is the continued narrowing of a long-standing modelling gap. RDF 1.2 standardises triple terms, reifying triples via rdf:reifies, annotation syntax, and clearer guidance on interoperability between RDF 1.2 Full and RDF 1.2 Basic. In practical terms, that gives RDF a stronger and more coherent way to attach metadata to statements such as provenance, confidence, validity interval, source system, policy context, or processing state. That matters in enterprise settings because these are exactly the attributes that determine whether graph data can be trusted, governed, exchanged, and audited across organisational boundaries. In that sense, RDF 1.2 improves RDF’s role as a semantic contract and interchange layer. But it still does not make RDF a native property graph. Triple terms denote propositions. They are typically surfaced through reifiers and semantic constructs, not as first-class operational edges with property bags in the LPG sense. That distinction remains important. In most enterprises, LPGs earn their place because they are operationally direct. Teams use them to model application-facing networks, fraud paths, supply chains, identity graphs, recommendations, infrastructure dependencies, and decision flows where developers want explicit nodes, explicit relationships, straightforward mutation semantics, and predictable query patterns. Relationship properties are not an afterthought there. They are part of the working model. This is also where the Applied Knowledge Graph (AKG) perspective matters. AKG is about using graph structures to support operational and analytical outcomes in the enterprise. That means combining semantics, governance, lineage, and domain meaning with execution models that are usable by engineering teams and close to business processes. In that architecture, RDF and LPGs are often complementary rather than mutually exclusive. So the real impact of RDF 1.2 is not that LPGs become obsolete. It is that the boundary between semantic graph standards and operational graph platforms becomes easier to manage. RDF becomes better suited for rich meaning, controlled exchange, and durable interoperability. Labelled Property Graphs remain strong as the execution model for enterprise graph workloads that need speed, flexibility, and close alignment with business applications. That is why I see RDF 1.2 as convergence, not replacement. Enterprises will still need LPGs for operational graph systems. What RDF 1.2 improves is the quality of the bridge: better semantics around statements, better interoperability options, and a stronger foundation for AKGs that need both enterprise control and practical delivery.

Column Operations & Graph Traversals

The term "ontology" has become overloaded. The meaning of ontology has turned into something like "whatever description encoded in Semantic Web languages" (RDFS, OWL, SHACL). Why was this a mistake, not merely a terminology issue? It obfuscates the history of ontology in philosophy and its value as a toolbox for making **ontological commitments explicit**, rather than just a formal encoding of vague terminology. For example, you can create an OWL class Person to represent people involved in a mortgage contract. However, this encoding is just a mnemonic for many implicit assumptions. We're not clarifying anything here. We need more than formal semantics. We need real-world semantics, provided by foundational ontologies and ontological analyses. For example, a Person can be understood as (a) a human being; (b) a cognitively capable person; (c) a legally capable person; (d) a legal person; (e) a living human being, etc. Each of these concepts has a very different nature, and its instances behave differently. The area of Applied Ontology (https://lnkd.in/ed8ZfJZP) is devoted to addressing these issues by developing theories based on which we can build domain ontologies that have explanatory power, in whatever language you decide to pick. Ontology development is consensus creation, not (merely) representation (https://lnkd.in/evgfSpby). A good ontology is the outcome of an ontological analysis and meaning negotiation, making ontological commitments explicit. This cannot be extracted directly from documents because too many assumptions are implicit and reside in people's minds. Moreover, there isn't a unique way to do that. Ontologies are meaning contracts (https://lnkd.in/eyT9znTR). The fundamental problem has never been a matter of representation language. Y.digital, Semantics, Cybersecurity, and Services (SCS), University of Twente | 22 comments on LinkedIn

Integrate postgres and graphRAG in a docker, add AGE and AI agents. - Azure-Samples/postgreSQL-graphRAG-docker

Free, open-source web app for learning about ontologies and Microsoft Fabric IQ. Explore a catalogue of pre-built ontologies, design your own visually, export as RDF/XML, and share interactive diag...

Most AI-assisted builds re-explain the same domain knowledge from scratch every session. Learn why reusable, versioned taxonomies and ontologies are t

Hannah Stulberg built a Claude Code repo at DoorDash that 20 people use daily. Root CLAUDE.md under 500 tokens. Nested indexes in every folder. Each function owns its context. Data scientists pull metrics without asking. Strategy leads grab call summaries. Engineers check analytics without filing tickets. She calls it a Team OS. It is the most production-ready multi-user AI knowledge architecture I have seen documented publicly. Here is the problem she will face within six months. Andrej Karpathy 's LLM Wiki works beautifully for one person. You dump messy notes, the LLM compiles them into a wiki, every query makes the wiki better. The loop compounds because one mind, one vocabulary, one namespace. No ambiguity about what "revenue" means when you are the only person defining it. Four failure modes appeared in every enterprise knowledge graph project since the Semantic Web era. Ungoverned documents that make the graph a liability. Nobody owning the ontology so definitions drift silently. Semantic ambiguity where the same label means different things across functions. Maintenance decay where the system was created once and maintained never. Stulberg's Team OS solves the first two with folder ownership: PM owns /product, data scientist owns /analytics, strategy owns /customer. Each function maintains its domain context. That is governance through file structure. But folder ownership does not solve semantic ambiguity. When the PM writes "conversion" in /product and the data scientist writes "conversion" in /analytics, those reference different metrics. When engineering references a "service" and strategy references a "service," those are different entities. The file system has no way to express that two identical labels point to different concepts. Flat markdown cannot represent typed relationships between entities. The missing layer is a graph ontology. Entities need types. Relationships need labels. Definitions need namespaces. A graph where "conversion" is a node with typed edges to its definition, its owner, its data source, and its measurement methodology prevents the silent drift that kills knowledge systems at team scale. GraphQLite makes this practical. A single SQLite file with Cypher queries, schema-free node creation, and built-in algorithms like PageRank and Louvain community detection. No server. No configuration. Drop it into the Team OS repo alongside the CLAUDE.md files. When the agent needs to disambiguate "conversion," it queries the graph instead of guessing from context. LightRAG takes this further for retrieval. Its dual-level system searches entities by vector similarity AND traverses their relationships in the graph. Legal document retrieval with graph-enhanced search scored 84.8% versus 15.2% for naive vector search. The graph does not replace the wiki. The graph makes the wiki queryable at the relationship level.

In the context of algorithms for problem solving, procedural knowledge -- the know-how of algorithm design and operator composition -- remains implicit in code, lost between runs, and must be...

Common Beginner Mistakes in Ontology Projects (and how to avoid them) I often see enthusiastic starts in ontology engineering, followed by avoidable missteps that limit impact and reuse of ontology. Here are a few patterns worth reflecting on: 1. Starting with tools instead of purpose It’s tempting to jump straight into editors like Protégé or other modeling tools. But ontology work isn’t tool-driven—it’s problem-driven. Before choosing a tool, ask: 1.1 Where will this ontology be used? 1.2 Who are the users? 1.3 What decisions or queries should it support? Tools don’t define good ontologies—clarity of purpose does. ________________________________________ 2. Skipping competency questions Competency questions are not just a formality—they are your design compass. They define: 2.1 the scope of your ontology 2.2 how deep or broad it should go 2.3 which use cases matter 2.4 what problems you’re solving Without them, you risk building something that: a) isn’t reusable b) doesn’t support real queries c) becomes another silo in the semantic ecosystem A simple rule: If your ontology can’t answer its competency questions, it’s not done. ________________________________________ 3. Over-modeling (the silent trap) More detail ≠ more value. Over-modeling often shows up as: 3.1 unnecessary class hierarchies 3.2 excessive axioms “just in case” 3.3 modeling edge cases before core use cases This leads to harder maintenance, lower adoption and confusion for users and developers Instead, aim for: minimal viable ontology → model what is needed now, evolve later. ________________________________________ 4. Ignoring domain experts Ontology engineering is not a solo activity. Domain experts bring: 4.1 real-world context 4.2 implicit knowledge 4.3 validation of concepts and relationships As ontologists, our role is to: a) translate domain knowledge into structured, interoperable representations b) align with FAIR principles (Findable, Accessible, Interoperable, Reusable) Without domain experts, even a “technically perfect” ontology can miss the mark. Final thought Good ontologies are not just well-structured—they are useful, usable, and used. I’m curious to know what mistakes have you seen (or made) in early ontology projects? If you're starting out in ontology engineering or transitioning into it, I’m happy to connect and exchange ideas.

How maplib bridges tabular data, ontologies and open standards Riksantikvaren (Norwegian Directorate for Cultural Heritage) is pushing boundaries in how public institutions manage and share heritage data. Embracing semantic web technologies, open-source tooling, and international standards to future

How two Helsinki tickets, one podcast rabbit hole, and a series on Knowledge Graph Architecture ruined my weekend — in the best way possible.

Название: Hands-On Microsoft Fabric AI Architecture: Ontology Design, Graph Semantics, and Governed Agentic AI (Early Release)Автор: Brian BønkИздательство: O’Reilly Media, Inc.Год: 2026-04-02Язык: английскийФормат: epubРазмер: 10.1 MBMicrosoft Fabric IQ represents a paradigm shift in how

From Word Clouds to Knowledge Graphs: A Practical NLP Path for Developers David Balkcom, Principal Engineer When people first start exploring text analysis, they often land on a familiar visual: the …

Glean enterprise AI platform doubles ARR to $200M, expands agentic engine, model hub, and governance, and faces Microsoft 365 Copilot head-on.

Organizing a large-scale knowledge graph into a typed property graph requires structural decisions -- which entities become nodes, which properties become edges, and what schema governs these choices. Existing approaches embed these decisions in pipeline code or extract relations ad hoc, producing schemas that are tightly coupled to their construction process and difficult to reuse for downstream ontology-level tasks. We present an ontology-oriented approach in which the schema is designed from the outset for ontology analysis, entity disambiguation, domain customization, and LLM-guided extraction -- not merely as a byproduct of graph building. The core mechanism is intrinsic-relational routing, which classifies every property as either intrinsic or relational and routes it to the corresponding schema module. This routing produces a declarative schema that is portable across storage backends and independently reusable. We instantiate the approach on the January 2026 Wikidata dump. A rule-based cleaning stage identifies a 34.6M-entity core set from the full dump, followed by iterative intrinsic-relational routing that assigns each property to one of 94 modules organized into 8 categories. With tool-augmented LLM support and human review, the schema reaches 93.3% category coverage and 98.0% module assignment among classified entities. Exporting this schema yields a property graph with 34.0M nodes and 61.2M edges across 38 relationship types. We validate the ontology-oriented claim through five applications that consume the schema independently of the construction pipeline: ontology structure analysis, benchmark annotation auditing, entity disambiguation, domain customization, and LLM-guided extraction.

Knowledge Drift: The Hidden Failure Mode of the Knowledge Graph If code bloat is the visible artifact of AI-assisted development, knowledge drift is its quieter and more consequential counterpart in …

AI coding assistant skill (Claude Code, Codex, OpenCode, OpenClaw). Turn any folder of code, docs, papers, or images into a queryable knowledge graph - safishamsi/graphify

When video reasoning requires external knowledge, many systems with large multimodal models (LMMs) adopt retrieval augmentation to supply the missing context. Appending textual or multi-clip evidence, however, forces heterogeneous signals into a single attention space. We observe diluted attention and higher cognitive load even on non-long videos. The bottleneck is not only what to retrieve but how to represent and fuse external knowledge with the video backbone.We present Graph-to-Frame RAG (G2F-RAG), a training free and auditable paradigm that delivers knowledge in the visual space. On the offline stage, an agent builds a problem-agnostic video knowledge graph that integrates entities, events, spatial relations, and linked world knowledge. On the online stage, a hierarchical multi-agent controller decides whether external knowledge is needed, retrieves a minimal sufficient subgraph, and renders it as a single reasoning frame appended to the video. LMMs then perform joint reasoning in a unified visual domain. This design reduces cognitive load and leaves an explicit, inspectable evidence trail.G2F-RAG is plug-and-play across backbones and scales. It yields consistent gains on diverse public benchmarks, with larger improvements in knowledge-intensive settings. Ablations further confirm that knowledge representation and delivery matter. G2F-RAG reframes retrieval as visual space knowledge fusion for robust and interpretable video reasoning.