Skip to content
Direction Draft

Make semantic context explicit

One label, one class, many meanings

Customer is treated as a single, universal thing because the customer domain owns it. Every product that mentions a customer is assumed to mean the same one.

But the same person can be a customer in one context and an employee in another, or both at once. A household, a legal entity, an account holder and a loyalty member can all be called "the customer".

Meaning follows the organisation chart

  • Distinct meanings collapse into one definition because they share a label.
  • A source-aligned product over-claims: its local definition is read as the enterprise definition.
  • A reorganisation silently changes meaning. Move a team to another domain, and its concepts appear to move with it.

Concept + context + relationship

A domain is an ownership boundary, not a sufficiently precise semantic context. Meaning lives in an explicit bounded context and, where it matters, is qualified by role, relationship, scope, time or jurisdiction. Concepts in different contexts are related explicitly, never merged because they share a name.

The picture

Concept plus context plus relationship Above: the formula concept plus domain is crossed out; concept plus context plus relationship replaces it. Below: one Party sits in the middle. In the retail context it holds a customer role; in the workforce context it holds an employee role; it can hold both at once. A note says moving a team does not change the concept. Instead of concept + domain Use concept + context + relationship Retail context Customer buys from the shop Workforce context Employee works in the shop Party one person role of role of Both roles at once: two meanings, related explicitly, never merged by label. Moving a team to another domain changes ownership, not the concept.
One party, two roles, two contexts. The relationship is explicit; the meanings stay distinct.

A customer who also works here

Illustrative example

A retailer's staff can shop with a staff discount. The retail context records them as customers; the workforce context records them as employees. A "customer spend" report built by merging everything labelled person quietly counts staff purchases twice in some views and not at all in others.

With the role made explicit (a party who is a customer in retail and an employee in workforce), the report chooses deliberately: include staff purchases, exclude them, or show them separately. When the workforce team later moves to a different division, nothing about either concept changes.

In detail

What a semantic contribution should say

When a data product contributes meaning, it should be able to state:

  • the governed concept it references or proposes;
  • the bounded context in which the assertion applies;
  • the role or relationship that gives the concept its meaning, where relevant;
  • the scope, time or jurisdiction, where these change interpretation;
  • the product or evidence the assertion comes from;
  • who is responsible for accepting, challenging or superseding it.

Reconcile into a graph, not a single model

Contributions are related through mappings, roles, broader and narrower relationships, rather than forced into one universal model. That graph is where Chapter 8, meaning at scale, picks up.

Not this

  • Not a requirement for a single enterprise ontology.
  • Not a choice of modelling language or technology for representing context.

Unresolved

  • Which context dimensions (role, relationship, scope, time, jurisdiction) are mandatory, and which optional?
  • Who may accept or reject a cross-domain mapping when no single domain owns the relationship?
  • How should contradictory assertions be held while they remain unresolved?

Join the argument

Agree, challenge or add evidence

Architecture improves when its assumptions are challenged. Say which kind of contribution you're making:

  • Challenge I disagree because…
  • Evidence We've seen this too…
  • Question How would this work when…?
  • Alternative Another way to approach this…
  • Extension This also implies…

Please keep clients, employers and colleagues unidentifiable. Strong contributions may be quoted and credited on this site. Read the contribution guidelines and the privacy notice.

Comments are provided by giscus and stored on GitHub. Posting requires a GitHub account.

Next in the argument Source-aligned data as the governed foundation Ownership, meaning, contract and classification are re-decided at every downstream layer, and the definitions drift apart. Meaning and accountability belong at the source

Connected thinking

Principle · draft Meaning and accountability belong at the source Domain owners maintain the meaning of what they publish, and reconciling meaning across contexts is an explicit, recorded decision. Concept · evolving Ontology Concept · evolving Semantic flow Concept · evolving Data contract