In the previous article, we learned to pause before turning every business difference into an ontology construct.
A difference might concern what kind of thing something is, how it is related to something else, how it changes, how somebody classifies it, or what a particular context makes relevant.
Once we start noticing those distinctions, however, a new problem appears.
There are usually far more of them than we can sensibly model.
Take a bond.
We may begin with the security itself, its issuer, currency, maturity and economic terms. Then we notice that the issuer is a legal entity, the legal entity belongs to a corporate group, the group structure changes through time, and the entity operates within particular jurisdictions.
The bond was created through an issuance. The issuance involved parties, documents and contractual terms. Its market price depends on source and time. Its valuation depends on market inputs and assumptions. Its risk depends on scenarios and risk factors. Its settlement depends on accounts, instructions and infrastructure.
Everything connects to something else.
So perhaps the ontology should model all of it.
It can (arguably).
That does not mean it should.
One of the hardest skills in ontology modelling is not learning how to add more meaning. It is learning where to stop.
1. More Meaning Is Not Automatically a Better Model
Imagine we are building an ontology to support questions about corporate bonds.
A modest starting point might include securities, bonds, legal entities, issuer relationships, identifiers, currencies and maturity.
Then somebody points out that incorporation jurisdiction matters.
Someone else needs the corporate ownership hierarchy.
Another team wants regulatory licences, ratings, settlement infrastructure, legal documentation, tax treatment, collateral eligibility and accounting classification.
Every one of those distinctions may matter somewhere in financial services. That is not enough reason to put all of them into this ontology.
An ontology with more concepts is not necessarily a better ontology. It may simply be a larger one.
This is easy to forget because semantic modelling creates a particular temptation. Once we discover that a distinction is meaningful, leaving it out can feel intellectually incomplete.
But an ontology is not an attempt to describe everything that can possibly be said about finance. It is a semantic model built to support some purpose.
The useful question is therefore not simply whether a distinction can be modelled. Almost everything can.
A better question is:
What becomes possible if we preserve this distinction, and what goes wrong if we do not?
That moves the discussion from completeness to usefulness.
2. Let Important Questions Pull Meaning into the Model
Suppose our initial requirement is:
Which securities were issued by legal entities belonging to the FatCat banking group?
That question already tells us something about the meaning the ontology needs to preserve. We need to distinguish securities, legal entities, issuer relationships and group membership.
If the model cannot distinguish those things, it cannot answer the question reliably.
Now suppose the requirement becomes:
Which entity belonged to the FatCat group when the security was issued?
The question has changed. Time now matters. A model that treated group membership as timeless may no longer be sufficient.
Then another requirement appears:
Which of those securities were investment grade according to Agency A at the end of last year?
Now the source and timing of the rating become relevant.
The ontology grows because the questions demand new semantic distinctions.
That is very different from beginning with a catalogue of everything we might possibly model.
A useful principle is:
Let important questions pull meaning into the model.
In ontology engineering, such questions are often called competency questions.
The term is useful, but the habit matters more than the terminology.
Before adding another concept or relationship, ask what question requires it.
If nobody can explain what difference the distinction makes, it may not yet have earned its place.
3. The Right Level of Detail Depends on the Problem
Consider the statement:
FatCat Bank issued Bond A.
For some purposes, a simple model may be enough:
FatCat Bank │ issues ▼ Bond A
Perhaps all we need to know is which securities are associated with which issuers.
Now imagine that the business needs to distinguish the legal entity involved in the issuance from an arranger, guarantor, programme sponsor and ultimate parent.
The simple relationship may no longer preserve enough meaning.
Or perhaps we need issuance dates, programmes, tranches, participant changes and supporting documentation.
The model may need to become richer again.
Neither the simple model nor the richer model is universally correct.
The simple model is not wrong merely because it omits detail. The richer model is not better merely because it contains more structure.
They support different questions.
This is a fundamental modelling principle:
The appropriate level of semantic detail depends on what the model needs to explain.
That does not make financial meaning arbitrary.
The business distinctions still exist whether or not we choose to represent them.
It simply means that not every true distinction must appear in every ontology.
4. Abstraction Is Not Vagueness
This creates another important distinction.
A model can be simple because it operates at a useful level of abstraction.
Or it can be simple because it has thrown away the meaning.
Those are not the same thing.
Suppose we model:
Party ── relatedTo ──> Security
and explain that relatedTo might mean issuer, guarantor, investor, custodian or whatever the source system happens to contain.
That is not especially useful abstraction.
We have removed precisely the distinction that gives the relationship its financial meaning.
Now consider:
Party ── issues ──> Security
Perhaps we have deliberately chosen not to model the full issuance process, legal documentation and all possible participants yet.
That may be entirely reasonable.
The model is simpler, but the important business distinction has survived.
Good abstraction removes detail while preserving the meaning that matters. Vagueness removes the meaning itself.
So when simplifying a model, ask:
Which distinctions must survive the simplification?
That is more useful than trying to minimise the number of classes or properties.
5. Model Boundaries Should Be Deliberate
Financial meaning forms long chains.
Suppose we are modelling the issuer of a bond:
Bond │issued by ▼Legal Entity │member of ▼Corporate Group │controlled by ▼Parent Entity
We can keep following the relationships.
The parent entity may be incorporated in a jurisdiction. The jurisdiction belongs to a legal and regulatory environment. The entity may hold licences. Those licences may be issued by regulators. The regulators may have mandates defined by legislation.
Nothing forces the chain to stop.
But the ontology needs a boundary.
Choosing a boundary does not mean declaring everything outside it unimportant.
It means saying that, for this model, some distinctions will be made explicit while others remain outside the current scope.
That boundary should be deliberate.
A weak ontology often inherits its boundary accidentally from whatever data happened to be available:
"If it is in these tables,it belongs in the model."
That is a data boundary, not necessarily a semantic boundary.
A stronger approach asks which parts of the financial world the ontology actually needs to make explicit.
The modeller should be able to explain not only why something is included, but sometimes why something has been left out.
6. Do Not Import Complexity Just Because Another Model Has It
Existing standards and canonical models make this boundary question particularly important.
Suppose FINOS CDM contains a rich structure around a financial product or lifecycle process.
It may be tempting to reproduce that entire structure in the ontology.
After all, the model already exists and contains valuable domain knowledge.
But the CDM has its own purpose.
Likewise, FpML, ISO 20022, FIX and internal canonical models have structures shaped by the problems they are designed to solve: interoperability, processing, message exchange, lifecycle representation, reporting or integration.
The ontology may need some of those distinctions.
It may not need all of them.
So the question is not:
CDM has this type. Should we create the same ontology class?
Nor is it:
FpML has this element. Should it become a property?
The better question is:
What business distinction is this structure expressing, and does our ontology need to preserve that distinction?
Sometimes the answer will be yes.
Sometimes several structures in an industry model may correspond to one broader semantic idea.
Sometimes a convenient canonical structure may combine several business meanings that the ontology should distinguish.
The source model informs the decision.
It does not make the decision for us.
7. Semantic Precision Has a Cost
Making meaning explicit can improve consistency, querying, integration, validation, explanation, reuse and AI interpretation.
But every additional semantic distinction also creates work.
Someone needs to understand it. Someone needs to agree on its meaning. Somebody may need to map data to it. Data sources must be capable of supporting it. Documentation and governance may need to preserve it as systems and business practices change.
Semantic precision therefore has a cost. That does not mean we should favour crude models. It just means precision should earn its place.
Imagine an ontology that distinguishes six subtly different forms of ownership.
If the organisation has business questions that depend on those differences and has data capable of supporting them, that precision may be essential.
If nobody can tell the six forms apart operationally and no use case depends on the distinction, the ontology may simply have become more difficult to understand.
The value of semantic precision depends partly on the consequences of losing it.
Confusing legal ownership with beneficial interest may matter enormously.
Failing to distinguish two obscure categories that no system or decision process uses may not.
The modeller has to make that judgement.
8. Model for Today Without Trapping Tomorrow
There is an obvious danger in modelling only what current questions require.
The ontology can become too narrowly tied to one use case.
The solution, however, is not to model the entire future in advance.
It is to make today’s model semantically honest and extensible.
Suppose our current requirement only needs:
Legal Entity ── issues ──> Security
We do not need to invent every possible participant in an issuance simply because they might matter one day.
But we should avoid making stronger claims than our current understanding supports.
For example, if the business meaning of Issuer depends on a relationship, modelling Issuer as though it were simply a permanent fundamental kind of legal entity may make the current model appear simpler while embedding an assumption that later becomes painful to unwind.
There is a useful balance here:
Make the model as simple as the current problem allows, but no simpler than the meaning permits.
The goal is not to predict every future requirement. It is to avoid closing semantic doors unnecessarily.
9. Knowing What Not to Model Is Part of Modelling
Ontology diagrams show what we decided to include. They rarely show everything we deliberately left out.
Those omissions can be important modelling decisions too.
For a particular ontology, we might choose to:
- model the security, but not every document describing it;
- model direct issuer relationships, but not the complete history of corporate control;
- model rating assessments, but not the internal methodology of every rating agency;
- model valuations, but not every internal step of the valuation engine;
- model business events, but not every technical event emitted by operational systems.
Those choices are not necessarily gaps caused by ignorance.
They may represent a conscious semantic boundary.
A mature ontology therefore has both semantic content and semantic scope.
The modeller should understand both.
10. Ask What Difference the Difference Makes
So how much meaning should we model?
There is no universal level of detail at which an ontology becomes complete.
Instead, ask what question needs the distinction, what goes wrong if the distinction is collapsed, whether the business and available information can support it, and whether preserving it changes interpretation, querying, validation, reasoning or decision-making in a useful way.
Then ask one final question:
Does this distinction clarify the model, or merely make it larger?
These questions do not produce a mechanical algorithm. They provide something more useful: a discipline for making semantic trade-offs.
The shift is:
Old ambition:"Model as much of the financial worldas we possibly can." ↓Better ambition:"Make explicit the distinctionsthat the problem needs us to preserve."
A useful ontology is not the one that says the most.
It is the one that says enough — clearly, deliberately and without hiding distinctions that matter.
By this point we have developed several habits: look past the representation, understand what kind of difference we have found, make context explicit when it changes the meaning, and choose a deliberate semantic boundary.
