Distributed EKG Architecture¶

Traditional Knowledge Graphs vs EKG¶

Most knowledge graph projects to date follow a monolithic pattern: a single (often giant) knowledge graph where only one copy of any given ontology is loaded. While the OWL specification technically supports loading multiple versions of an ontology (via the version IRI mechanism), this is rarely done in practice—especially when reasoners or inference engines are involved.

An Enterprise Knowledge Graph (EKG) takes a fundamentally different approach.

The EKG Difference¶

Distributed by Design ¶

An EKG is not a single monolithic graph. It can consist of many knowledge graphs, each of which can have their own versions of ontologies loaded. This distributed architecture reflects the reality of large enterprises where:

Different business units have different data needs
Systems evolve at different rates
Legacy and modern systems must coexist
Regional or regulatory requirements vary

Heterogeneous Components¶

Not all components of an EKG need to be semantic knowledge graphs. The EKG can integrate:

Semantic Knowledge Graphs — RDF/OWL-based triple stores
Labeled Property Graphs (LPGs) — Graph databases using the property graph model
Hybrid Graph Databases — Systems that support both semantic (RDF) and property graph models
Relational Databases — SQL databases with structured data
Document Stores — NoSQL databases storing JSON or similar formats
Data Lakes — Large-scale storage systems
APIs and Services — External data sources

The EKG provides a semantic layer that enables these diverse components to be understood and queried as if they were part of a unified knowledge graph.

Context-Specific Ontology Linking¶

When we link Use Cases to Ontology axioms, we do so in a way that is always context-specific. The context is primarily defined by the given Use Case.

The Linking Chain¶

The Use Case Tree Method establishes a clear chain from business requirements to formal ontology axioms:

Use Case
    └── Story
        └── Concept
            └── Technical Term
                └── Ontology Axiom

Each level in this chain serves a purpose:

Use Case — Defines the business context and requirements
Story — Captures specific scenarios and user needs
Concept — The linking pin between business language and technical implementation
Technical Term — The manifestation in code, data, and metadata
Ontology Axiom — The formal semantic definition in OWL or SHACL

Why Context Matters¶

Different use cases may map to the same ontology in completely different ways. A "Customer" concept in a sales use case may have different attributes, constraints, and relationships than "Customer" in a compliance use case—even if both ultimately link to the same OWL class.

This flexibility ensures that:

Ontology mappings serve the use case, not the other way around
Business language is preserved throughout the lifecycle
Technical implementation details remain local to the use case

Use Cases at Various Maturity Levels¶

The Use Case Tree does not necessarily consist only of production-ready use cases with perfect mappings to OWL ontologies. The tree may contain:

Exploratory use cases — Early ideas being validated
Partially defined use cases — Requirements still being gathered
Well-defined use cases — Clear requirements, not yet mapped
Mapped use cases — Linked to ontologies but not implemented
Production use cases — Fully implemented and operational

This is one of the key reasons why the Use Case Tree Method introduces the idea of Concepts of the Use Case.

Concepts as the Linking Pin¶

Concepts form the linking pin—in the context of the given use case—between the Stories and the OWL ontology axioms.

Why Concepts, Not Direct Ontology Mapping?¶

If use cases mapped directly to ontology axioms, we would face several problems:

Premature commitment — Use cases would need ontology mappings before requirements are fully understood
Brittleness — Changes to ontologies would ripple through all use cases
Loss of business language — Ontological terminology tends to be philosophical and academic, which has its place, but not in conversations with the business when reaching agreements on use case definitions
Integration complexity — Traditional approaches try to force everyone to commit to a new "canonical model," but legacy systems tend to hang around for decades. The EKG needs to understand all vocabularies from all silos—old and new. Even if a legacy system does things "the wrong way," if you're still using it and transferring data to and from it, you need to know exactly what's what.

By introducing Concepts as an intermediate layer:

Business language is preserved — Stakeholders recognize their terminology
Mapping can be deferred — Ontology integration happens when appropriate
Context is maintained — Each use case has its own semantic context
Evolution is supported — Concepts can be refined as understanding grows

Context-Specific Operations¶

Concepts provide the information needed to perform various context-specific operations for each use case:

Inbound mapping — Transform data from source systems into EKG representations
Outbound mapping — Transform EKG data into formats required by consuming systems
Semantic alignment — Ensure that different representations of the same concept are understood as equivalent
Validation — Apply context-appropriate validation rules that may differ from use case to use case
KPI measurement — Track performance metrics relevant to each use case's specific outcomes
Security rules — Enforce access controls and data protection policies appropriate to each context

All these operations are context-specific, defined by the use case that needs them. A concept like "Customer" may have different validation rules, different KPIs, and different security constraints depending on whether it appears in a sales, compliance, or marketing use case.

Context-Specific Testing¶

Stories and their Concepts also drive context-specific test scenarios. Even when multiple use cases map their concepts to the same generic ontology, each use case maintains its own test scenarios that validate the ontology from its particular angle.

This approach provides significant benefits:

Massively increased robustness — The same ontology is continuously tested from many different perspectives
Impact analysis — When an ontology changes, test scenarios from all affected use cases immediately reveal the impact
Early warning — Problems surface quickly because tests run from multiple angles simultaneously
Confidence in change — Teams can evolve ontologies knowing that comprehensive testing will catch regressions

Rather than relying on a single test suite for a shared ontology, the distributed approach means that every use case contributes its own validation—creating a much more thorough and resilient testing regime.

Implications for Architecture¶

No Single Source of Truth¶

Unlike traditional data architectures that seek a "single source of truth," the EKG embraces the reality that:

Truth is context-dependent
Multiple valid representations exist
Reconciliation happens at query time, not load time

Federated Reasoning¶

Reasoning in a distributed EKG is different from reasoning in a monolithic graph:

Reasoners may operate on subsets of the overall graph
Different use cases may apply different reasoning profiles
Context determines which axioms and rules apply

Evolutionary Architecture¶

The distributed, context-specific approach enables:

Incremental adoption — Start with one use case, expand over time
Parallel development — Different teams can work on different use cases
Graceful evolution — Ontologies can evolve without breaking existing use cases