GraphNews

Why Bloomberg uses the Knowledge Graph and how it manages Enterprise Ontology versioning, 3/3

Thank you for reading this long article. If you are a financial engineer who is interested in the three posts, including this one, we have a virtual coffee chat scheduled for early June with Enterprise Data Architect, who presented this session.

If you are interested in ontology as part of guardrail or Finance data quality control, you may want to participate in the discussion. Please DM.

--

As we have seen earlier, the starting point of dependency-aware ontology versioning is to distinguish between version-agnostic objects and version-aware objects. However, this is not enough.

In a real production environment, you need to be able to track which semantic artifact a particular resource is associated with, and which ontology version that artifact depends on.

To do this, the semantic artifact must have a core metadata for versioning. Typical examples are Ontology IRI, Ontology Version IRI, Version Info, and Imports. The Ontology IRI is a persistent identifier for ontology, providing a base identity that does not change over time.

Ontology Version IRI refers to a specific version, which changes every time the ontology changes. Version Info is metadata that describes what changes have been made in that version. Imports specify which other ontology this ontology depends on, and should refer to the versioned ontology if possible. This way, you can reproduce what semantics a particular version of ontology operated on.

With this structure in place, it is possible to create a dependency graph based on the relationship between Resource, Semantic Artifact, and Ontology Version. A Dependency graph is not just a diagram that shows the relationships between ontology elements.

This is an operational tool for analyzing which artifacts a particular change affects. For example, if the definition of a class changes, the SHACL shape, taxonomy node, rule, dataset, API, and query template that use that class can be affected as well.

A change in the range of a property can result in a validation result, and a change in the Entity Classification result can change in a taxonomy hierarchy.

Here, the role of the Competency Question naturally expands. In the existing ontology engineering, CQ was a representative question that ontology had to answer. However, in a dependency-aware versioning environment, CQ goes beyond a simple design question and acts like a regression test.

It is a criterion for checking whether the questions that could be answered in a particular ontology version are still valid in the new version, whether the classes and properties required for answering have not been changed, and whether the query pattern needs to be modified.

This structure is particularly important in the financial data landscape. Financial data is both accurate and timely, and new policies, regulations, disclosures, and market events continue to flow in. When this information is indexed and incorporated into the knowledge base, it is not enough to simply add new data.

It is necessary to analyze which resources the new information is associated with in the existing ontology, which semantic artifacts it affects, and which rules or validation constraints need to be changed.

Therefore, dependency-aware ontology versioning can be the basis for notification systems. If new policy or regulatory data comes in and you need to change a specific ontology element, the system can tell you which datasets, APIs, queries, rules, and user workflows the changes will affect.

This allows users to understand not just the fact that "the data has changed" but "what semantics have changed and how those changes may affect my decision-making."

After all, versioning is not about managing release, but about managing the lineage of meaning. You need to be able to trace which source a particular information came from, what ontology version it was interpreted through, and what downstream decisions it influenced.

This is where Bloomberg's "Change Without Chaos" comes in. Change is inevitable, but the meaning and scope of change must be traceable. In this case, the dependency graph becomes a key device that turns ontology evolution into an object of governance rather than chaos.

Why Bloomberg uses the Knowledge Graph and how it manages Enterprise Ontology versioning, 2/3

The core of the "Change Without Chaos" in the Bloomberg session is not to prevent change in ontology. Rather, it is to make it controllable how the change occurs and to what extent it affects on the premise that change is inevitable. The first thing we need to do is to clearly divide the criteria for versioning.

In order to perform Ontology versioning, it is necessary to distinguish between two types of version objects. One is a version-agnostic object, and the other is a version-aware object. This distinction is necessary because all properties in ontology do not change in the same way.

Some attributes are stable attributes that rarely change over time, while others are variable attributes that vary depending on a specific point in time, policy, regulation, and data environment.

The Version-agnostic object represents the continuous identity of the resource. For example, if a particular financial product, organization, person, event, or policy concept remains the same over time, this object serves as a stable identifier for that resource.

On the other hand, version-aware objects express definitions, attributes, relationships, constraints, rules, and import relationships at a specific point in time. Even if it is the same resource, it belongs to a specific class in some ontology versions, and the taxonomy position and validation rules may be different in other versions.

Therefore, we need to separate identity and state to determine what actually changed and what remained the same when ontology changed.

After distinguishing between stable and variable attributes, a versioning protocol is required to operate them. The protocol consists of three main principles: clear ownership, defined identifiers, and explicit tracking.

Clear ownership is to clarify who is responsible for each semantic resource.

Defined identifiers are to create a consistent identification system that can distinguish between ontology, version, artifact, and resource.

Explicit tracking systematically records the history and dependency of changes in ontology, making it possible to track which downstream artifacts a particular change has affected.

The purpose of this versioning protocol is, after all, clarity and traceability. Clarity is about making it clear what a particular resource means, which ontology is defined, and which version it is used in. Traceability allows you to trace where a particular semantic definition came from, by which artifacts it was used, and by what history of changes it went through to reach its current state.

An important rule for defining a resource is that each resource must be associated with at least one semantic artifact. A resource can be linked to multiple semantic artifacts in a 1:N relationship.

For example, a financial entity can be used by multiple artifacts, such as ontology class, taxonomy node, SHACL shape, business rule, dataset schema, API contract, query pattern, etc.

However, this connection must be managed based on the authoritative definition. This way, you can trace where the meaning of that resource is defined and what version of semantics it is based on.

After all, the starting point of versioning is not just about assigning version numbers to ontology. It clearly defines what to see as a stable identity, what to see as a changing state, and what semantic artifacts that change is associated with.

From here, ontology is not a static schema, but a semantic governance object that manages the history, responsibility, and scope of change together.

Why Bloomberg uses the Knowledge Graph and how it manages Enterprise Ontology versioning, 1/3

One of the most interesting presentations of KGC2026 sessions was Bloomberg's "Change Without Chaos: Dependency-Aware Evolution of Knowledge Graphs and Services" session. This session was not just about how to build a knowledge graph, but about how to maintain semantic consistency in a hyper-large financial data environment.

Why is this important?

The financial industry is essentially an information-based industry. Depending on who interprets the information faster, more accurately, and more meaningfully, there will be real financial gains and losses.

In the past, information asymmetry itself was a competitive advantage, but now the semantic layer, which judges "what is actually meaningful information" in the flood of information, has become a core competitiveness.

Bloomberg, which collects, refines, and delivers financial data from around the world in the form of a Bloomberg Terminal, is one of the companies that is dealing with this problem on the most extreme scale.

As of the AI Engineer session in December last year, Bloomberg is processing about 96,000 companies, more than 2M entities, more than 3.3M executive/government biographies, more than 1.5M news articles per day, and more than 600B market ticks per day.

The problem is not simply the amount of data. Even if the data is the same, the purpose of the user and the system that consumes it is different.

Some users look at data from a risk perspective, some users interpret the same data from a trading perspective, and some systems interpret the same data from a compliance or AI reasoning perspective. In the end, "semantic interpretation" becomes more important than the data itself.

To solve this problem, Bloomberg explains that it uses two main directions. The first is an approach based on data acquisition, training data building, and prompt optimization. In other words, it is a direction to collect better data and refine it so that AI can make good use of it.

The second is a Knowledge Graph-based approach. Bloomberg specifically describes the core value of the Knowledge Graph as "integratable" here.

The meaning of this statement is not just about connecting data. This means making data generated by different teams, different systems, and different domains reusable within a single semantic context.

For example, entities that were represented as "Customer" in some systems, "Counterparty" in others, and "Organization" in others can be connected through semantic alignment.

Bloomberg especially describes "reuse" as a very important philosophy. A well-designed semantic component should not be limited to a single use case, but should be repeatedly reusable across various workflows and AI systems. This requires semantic standardization based on ontology and taxonomy, not just at the schema level.

What criteria are used to construct this knowledge graph? It is Ontology.

Instead of a single giant ontology, Bloomberg chose a layered ontology strategy that combines role-specific ontology in layers.

Technical ontology manages system implementation layers such as RDF and Neo4j, and Contingent ontology manages the operational context for each company, department, country, and policy. Domain ontology is responsible for financial domain concepts, and upper-level ontology is responsible for common concepts such as Person and Event. Each ontology also consists of Taxonomy, SHACL Shapes, Rules, Dataset, and API.

This structure has a clear separation of roles, but in fields like finance, where up-to-date and accuracy are important, governance costs are high. This is because the structure and consistency of real-time incoming data must be continuously verified.

For this purpose, we use SHACL-based validation. If Ontology defines meaning, SHACL validates constraints such as datatype, cardinality, relation, and range. Data that does not pass is passed through reject, remediation, fallback pipeline, etc.

However, since SHACL is more like structure validation, business reasoning is handled by Rules. Rules is a semantic inference layer that classifies entities or determines workflows based on specific conditions.

Taxonomy is a hierarchical classification system for entities and concepts, and APIs are interfaces that provide these ontology-driven assets to users and applications.

In the end, what Bloomberg is building is not just a knowledge graph, but an enterprise-scale semantic governance architecture with ontology, validation, reasoning, classification, storage, and APIs connected.