Knowledge Graphs, Part II

Three RDF Graph Architectures

Introduction

Part I of this series establishes that a knowledge graph is an architecture, not a product. A product has walls and doors. An architecture is a purposeful arrangement of components assembled in relationship to one another, in service to what the organization needs to represent, reason over, and query. Part I defined those components and surveyed the breadth of the graph landscape. Part II specifies three common RDF-based architecture patterns, explored in depth.

A product is finite. You acquire it or configure it and operate within its boundaries. An architecture is a set of decisions that determines what the system can do and what it cannot. The three patterns examined here make different decisions about which components to assemble, how those components interact and how architectural decisions determine the capabilities of each specific knowledge graph architecture.

Part I established that the vocabulary, the ontology and the knowledge base form the irreducible core — the required components of any knowledge graph. Remove any one of the three, and what remains may be a useful data structure, but it is not a knowledge graph. What distinguishes one knowledge graph architecture from another is how those required components are configured and which optional components are enabled as part of each knowledge graph type. The metadata schemas, reasoner, validation layer, query interfaces, NLP pipelines, vector retrieval, graph analytics and federation infrastructure are all architectural decisions driven by the use case, the domain and the production environment.

The Enterprise Knowledge Graph is built for breadth across organizational systems. The Domain Knowledge Graph is built for depth within a single field of expertise. The Linked Data Knowledge Graph is built for openness across the web. These are architectural commitments that determine the utility of each graph, to satisfy intended output and alignment with use cases.