Earlier posts in this series have focused on modelling judgement: separating financial things from their records and identifiers, examining what kind of difference a business distinction represents, making context explicit when it matters, and deciding how much meaning a model needs to preserve.
Those habits help us make better decisions. But when we sit down in front of a blank ontology, we still need a practical way to begin.
How do we move from messy business language to a semantic model? And how do we know whether the model preserves the meaning we intended?
This post introduces a simple modelling loop:
Say It → Model It → Challenge It
First, express the business meaning in clear language. Then, propose a semantic structure that captures it. Finally, test that structure against the questions it needs to answer and situations that might expose its weaknesses.
The steps can send us back as well as forward. A difficult example may reveal an ambiguity in our original statement; trying to model a relationship may uncover a distinction we had overlooked.
The loop gives us a practical way to turn modelling judgement into something we can explain, examine and revise—whether we are working through a single relationship or reviewing a larger model.
A model should survive questions.
1. Say It: Make the Business Meaning Explicit
Suppose somebody tells us:
FatCat Bank issued Bond A.
That sentence gives us a concrete business situation. For this example, Bond A means a particular corporate bond issue, rather than an individual investor’s holding.
We are not yet trying to write OWL. We are trying to understand what the business means and what we need to explain.
FatCat Bank is a legal entity. It issued Bond A. Another entity might invest in that bond, arrange its issuance or guarantee the obligations associated with it. Those are different relationships, even when one organisation participates in several of them.
Now ask what the model needs to help us answer:
- Which legal entity issued each security?
- Which securities did a particular legal entity issue?
- Can we distinguish the issuer from an investor, arranger or guarantor?
These questions establish a purpose. Without one, it is easy to model everything we know about issuance and still miss the distinction that matters to the user.
Real financial language often needs more discussion. Someone may say that a bond “belongs to” a bank, that a fund “owns” a security, or that a trade “is settled”. Each statement sounds ordinary, but each hides choices about relationships, ownership or time.
The purpose of Say It is to make those choices visible before we commit to structure. We need an understandable situation, a sufficiently clear interpretation, and some questions worth answering.
2. Model It: Propose Reusable Semantics
Our example contains two particular things: FatCat Bank and Bond A. The reusable model must express the meaning that applies beyond them.
We might begin with classes such as LegalEntity, Security and Bond, and a claim that every Bond is a Security.
We might also introduce an Issuer class:
Issuer SubClassOf LegalEntity
This says that anything classified as an Issuer is also a Legal Entity. It gives us a way to classify FatCat Bank, but it does not yet identify the security it issued.
At this stage, each modelling decision is a semantic hypothesis: a proposal about which distinctions and relationships will express the business meaning adequately.
Thinking this way changes the modeller’s attitude. We can explain why we introduced a class, what a relationship means, and which question a distinction helps us answer. We can also revise those decisions when they prove insufficient.
Throughout this series, Model It focuses on reusable semantics: the kinds of things, relationships and claims that can describe many situations. Concrete examples remain available to test them. Ontologies can also contain assertions about particular individuals; the convention here is about where we focus our attention, rather than excluding instances from ontology work.
3. Challenge It: Find What the Model Leaves Unexplained
Return to our initial model. FatCat Bank is a Legal Entity and an Issuer.
Now introduce a second situation:
FatCat Bank issued Bond A, but invested in Bond B, which another legal entity issued.
Does that make the Issuer subclass wrong?
No. An individual can belong to several OWL classes unless relevant disjointness axioms prevent it. Being an issuer and an investor is not automatically a contradiction. Nor does subclassing, by itself, say that issuer status is permanent or fundamental.
The useful challenge is more specific:
Can our model identify which security makes FatCat Bank an issuer?
With only the classifications described above, it cannot. We know that FatCat Bank is an Issuer, but we have not preserved its issuer relationship with Bond A.
That matters because our original questions require us to distinguish who issued each security. The challenge has exposed a missing relationship, rather than disproved the class hierarchy.
We can revise the model by introducing an issues relationship connecting a Legal Entity to a Security. Its intended meaning must distinguish issuing from investing in, arranging or guaranteeing that security.
Our examples can now test whether the structure preserves the differences:
- FatCat Bank issues Bond A.
- FatCat Bank invests in Bond B.
- Another legal entity issues Bond B.
The reusable model describes these relationships generally; the examples show whether they work in concrete situations. An Issuer classification may still be useful alongside them.
This completes one pass through the loop:
| Stage | What we did |
|---|---|
| Say It | Identified the business situation and the questions about issuers and securities. |
| Model It | Proposed classes, including an Issuer classification. |
| Challenge It | Discovered that classification alone did not preserve which entity issued which security. |
| Model It again | Added an explicit relationship and tested it against both bonds. |
Now suppose we also need to ask when issuance occurred and which parties participated in that event. Those questions may justify representing Issuance explicitly, with its timing and participants.
The richer model becomes useful because the required meaning has expanded. A direct relationship may be enough for the earlier questions.
4. Use Questions to Guide and Test the Model
Ontology engineering commonly uses competency questions: questions that the resulting knowledge base should be able to answer. They help establish scope and later assess whether the model preserves the required meaning.
In our loop, they belong both at the beginning and during challenge.
During Say It, they tell us what matters. During Challenge It, they help us inspect whether our proposed structure supports it.
At the conceptual stage, we do not need to turn every question into an executable query. We should, however, be able to explain what relationships and distinctions would support an answer. Later, answering questions about particular securities will also require the relevant facts.
Questions need scrutiny too. “Which securities can a bank issue?” might concern legal permission, business capability or what our model allows. “Which securities did the bank issue?” asks about actual relationships. The wording changes the modelling problem.
Counterexamples provide another form of challenge. If a trade is Pending yesterday and Settled today, ask whether the model preserves when each status applies. If two vendors report different prices for the same bond, ask whether their observations remain distinguishable by source and time.
Neither example automatically invalidates the original representation. Each tests whether it preserves enough meaning for its purpose.
The same questions can expose unnecessary complexity. If we cannot explain why a distinction matters to the agreed scope, we should reconsider whether it belongs in this model.
5. Challenge the Words as Well as the Structure
Sometimes the challenge takes us back to the sentence we started with.
Consider:
Fund X owns Bond A.
Does “owns” mean legal title, beneficial ownership, economic exposure or a position recorded in an investment book? Is a custodian involved? Which of these distinctions matters to the question we are trying to answer?
A neatly drawn owns relationship cannot resolve an interpretation that nobody has agreed.
We may need to return to the business expert, refine the description and then revise the model. That is why Say It → Model It → Challenge It is a loop.
A challenge can reveal a missing relationship, an unnecessary distinction, or an ambiguity in the business language itself. A good modelling discussion improves our shared understanding as well as the ontology.
6. Formalisation Does Not Settle the Business Interpretation
Suppose we encode the model in valid OWL. Protégé accepts it, and a reasoner reports that the ontology is consistent.
That is useful evidence about the formal statements. It does not establish that we chose the right business interpretation.
OWL reasoners can check logical consistency and derive consequences from the axioms and assertions we provide. They cannot establish, merely from a successful consistency check, that our interpretation of “issuer” or “ownership” meets the business need.
If the business interpretation is wrong, formalisation can make the mistake extremely precise.
Formalisation therefore participates in the loop. It can expose consequences we did not anticipate, prompting further challenge and revision.
Definitions, standards and existing data are valuable inputs. Each may also contain ambiguities or assumptions. The modeller’s task is to turn those inputs into explicit claims that people can inspect and discuss.
7. Know When the Model Is Good Enough
Repeated challenge could continue indefinitely. We need a practical stopping point.
For a stated purpose, a model is ready to use when:
- it supports the agreed competency questions;
- it handles the relevant examples and counterexamples;
- its important assumptions and limitations are explicit;
- its level of detail has a clear justification.
Surviving these tests increases confidence. It does not establish that the model is universally correct or complete.
New questions may require further distinctions. New scenarios may expose limitations. Those are reasons to revisit the model as its purpose develops.
The habit remains simple:
Say the business meaning clearly. Model the reusable semantics. Then try to break the model.
When a challenge reveals a weakness, use it to improve the description or the structure. When the model survives, record what has been tested and what remains outside its scope.
We now have a practical way to move from business language to a challenged semantic model. The next article considers how that model relates to databases, canonical models, industry standards, mappings and applications:
Ontology Is Part of a Larger Semantic Stack.
Model the meaning before you model the data.
