Ontology Building Blocks

In the last unit you separated the conceptual, logical, and physical views and saw why an initiative stalls when conceptual disagreement is left unsettled. This unit goes inside that conceptual layer. When a business narrative arrives as plain prose ("customers hold accounts, and households sometimes share one"), your job is to pull it apart into its working parts before anyone argues about structure.

In this lesson, you will learn to:

• Identify classes, instances, properties, relationships, constraints, and definitions in a business narrative
• Distinguish a class from a property or role when definitions compete
• Explain why a disputed role such as payer should be modeled as a relationship rather than a kind of person
• Place a semantic artifact on the maturity spectrum, from glossary to ontology

An ontology is assembled from six ontology building blocks, and you can find all six in ordinary business language. Classes are kinds of things: Customer, Account, Household, Subscription. Instances are specific things of that kind, such as customer R-4471. Properties are characteristics that describe a thing, like enrollment date or payer status. Relationships are connections between concepts, such as a customer holds an account, or an individual belongs to a household. Constraints are limits on what counts as a valid interpretation: can one household hold more than one account, or must every subscription have exactly one billing party? Definitions carry the intended meaning of each term, including what it deliberately excludes.

The most common beginner error is promoting a property or a relationship to a class. "Payer" sounds like a kind of thing, but it is usually a role a person plays in a relationship to an account. Treating it as a class multiplies entities that never needed to exist.

Keep one memorable test in reach: if a thing can stop being X without ceasing to exist, then X is a role or status, not a kind; and if X only makes sense relative to something else ("payer of what?"), then X is a relationship rather than a class.

It also helps to know how far up the ladder you are. The semantic maturity spectrum runs glossary (terms plus agreed definitions), then controlled vocabulary (approved terms used consistently), then taxonomy (terms arranged in a hierarchy), then thesaurus (broader, narrower, and related links), and finally ontology (formal classes, relationships, and rules that support inference). Most disagreements you meet in your first two years are resolvable one or two rungs up. Reaching for an ontology when a glossary would do is its own kind of failure.

Competing definitions are rarely wrong. They are usually correct for different purposes, which is why they survive. Billing may define a customer as the party who pays, support as any named individual with a service relationship, marketing as a household addressed as one target. Each is defensible. What matters architecturally is that each definition changes the denominator, and the denominator changes the story: churn rate, revenue per customer, and retention all move without a single underlying fact changing.

• Priya: Procurement calls every approved seller a supplier, but operations calls only a contracted seller a supplier. One of those has to be wrong.
• Emre: Neither is wrong for its purpose. A supplier is a company we buy from; "approved" is a status that company can have.
• Priya: So approved supplier is not a separate kind of company?
• Emre: Right. It is a supplier with an approval relationship or property. We should ask which purpose needs that status before we publish a count.

Notice what Emre does not do: he does not pick a winner. He separates a kind of thing from a status, then asks which purpose makes the distinction material. That is the move.

Product, analytics, and governance audiences will not engage with the words "class" and "relationship limits," and they do not need to. Explain the distinction using their own examples, then name the business consequence. Rather than "payer is a role, not an entity type," say "the person paying and the person using the service are not always the same person, so counting payers gives you a revenue number, not a reach number." Rather than "we have an unresolved constraint," say "we have not decided whether one household can hold two accounts, and until we do, our household count is a guess."

The takeaway to carry: most definition fights are not disagreements about facts. They are disagreements about which kinds of things exist, which characteristics are being mistaken for kinds, and which constraints were never stated. Two quick pattern-spotting checks come first: a four-item multiple-choice quiz that asks you to recognize the building blocks in business language, followed by a matching practice that places artifacts on the maturity spectrum. Then you'll take this into a live conversation with a domain lead who is certain his definition is the only real one.