Skip to main content

Overview

Overview

The Knowledge Graph Manager (KGM) is the Witboost service that unifies business knowledge from different systems and exposes it as a single, coherent knowledge graph.

Organizations often maintain business concepts (definitions, taxonomies, glossaries, classifications, reference vocabularies) across a variety of heterogeneous tools. Because each tool uses its own format and structure, it becomes difficult to understand how these concepts relate across systems.

KGM solves this by acting as an integration and access layer, collecting knowledge from multiple sources, standardizing it, and exposing it through a unified graph interface that supports both search and relationship queries.

What is a Knowledge Graph?

A knowledge graph represents information as a network of connected facts.

Instead of storing data in tables, a knowledge graph expresses information as simple statements called triples:

<subject> <predicate> <object>

Examples:

  • Electric Caris a type ofVehicle
  • Customerrelated toContract
  • Orderhas definition"A request for goods or services"

Because knowledge graphs focus on relationships, they make it easy to:

  • navigate concepts
  • discover related ideas
  • understand meaning across systems

The Knowledge Graph Manager (KGM) builds and exposes such a graph for your organization.

How Knowledge is represented: RDF and JSON-LD

KGM uses RDF (Resource Description Framework) as its underlying data model.

RDF stores knowledge as triples and supports many vocabularies, including SKOS, RDFS, OWL, and custom models.

To collect RDF triples from multiple sources, KGM relies on JSON-LD, a lightweight JSON format designed for linked data.

Example JSON-LD describing a concept:

{
"@id": "ex:ElectricCar",
"@type": "ex:Vehicle",
"ex:relatedTo": { "@id": "ex:ChargingInfrastructure" },
"ex:definition": "A vehicle powered exclusively by electricity."
}

Or using the SKOS vocabulary:

{
"@id": "ex:Customer",
"@type": "skos:Concept",
"skos:broader": { "@id": "ex:Person" },
"skos:prefLabel": "Customer",
"skos:definition": "A party purchasing goods or services."
}
info

KGM is vocabulary-agnostic and accepts any RDF expressed as JSON-LD.

Querying the Knowledge Graph: Search and SPARQL

KGM exposes knowledge in two ways:

Search

A keyword-based way to find concepts using their labels and definitions.

Examples:

  • "Find anything mentioning customer onboarding"
  • "Search for concepts containing 'maintenance'"

SPARQL

A graph query language for exploring relationships.

Examples of questions SPARQL can answer:

  • "What concepts fall under Employee Benefits?"
  • "What is related to Electric Vehicles?"
  • "Which concepts belong to which collections?"

Two ways KGM integrates Knowledge

KGM can retrieve knowledge from upstream systems in two complementary modes:

1. Ingestion Mode

Some systems can export their concepts and relationships. For example, Data Catalogs usually provide APIs to query their business glossaries.

A KGM Source Adapter transforms this exported content into JSON-LD (RDF triples), and KGM ingests it into its internal knowledge graph.

This internal graph becomes the foundation for unified search and query operations across all ingested sources.

Examples of ingestible sources:

  • a glossary in a data catalog
  • a CSV taxonomy
  • a wiki export
  • a compliance dictionary

2. Passthrough Mode

Some upstream systems already provide their own SPARQL or text search capabilities.

In these cases, KGM does not ingest or store the data.

Instead, KGM simply forwards queries directly to the source and returns its live results, allowing that system to remain the authoritative source of truth.

Passthrough is ideal when:

  • the source already maintains its own graph
  • data must always be fresh
  • replication is unnecessary

Both modes can coexist, enabling KGM to unify ingested knowledge while still supporting live querying of external systems.

Internal Graph Queries vs. Passthrough Queries

Although the query interfaces exposed by KGM have a consistent shape, their behavior depends on the source configuration:

  • Queries through KGM's main graph interface operate on the internal knowledge graph, which contains only ingested triples.
  • Queries through a passthrough interface are forwarded to the upstream system, and the results come directly from that system.
note

No triples from passthrough sources are stored or merged inside KGM.

This separation ensures that users and downstream services can choose whether they want:

  • a unified view of all ingested knowledge, or
  • a live view of a specific upstream system

Example Scenario

Consider an organization that has:

  • A glossary exporting SKOS concepts → ingested
  • A CSV taxonomy describing product hierarchies → ingested
  • An ontology server modeling domain relationships → passthrough
  • A compliance dictionary defining sensitive data types → ingested

KGM merges all ingested knowledge into a single internal graph.

Queries routed to this graph provide a unified view.

Queries routed to a passthrough interface reach the ontology server and return its live results, without storing any triples inside KGM.

This allows downstream tools to explore business knowledge seamlessly, even though it originates from multiple independent systems.

What KGM Enables

By centralizing access to business knowledge, whether ingested or queried live, KGM enables:

  • unified concept discovery
  • exploration of relationships across systems
  • consistent interpretation of definitions and identifiers
  • visualization features such as the Business Concept Map
  • improved governance and shared business understanding

KGM does not replace or duplicate existing knowledge systems; it connects them and provides a standardized semantic layer for consuming their knowledge.