5. Four questions to ask about any class

In chapter 4 you learned to sort things into the biggest boxes. Now we go one level finer.

Two people are arguing about whether Customer should sit under Person in the hierarchy.

One says yes, a customer is a person. The other says no, a company can be a customer. The first says fine, then put IndividualCustomer under Person. The second says that is backwards, Person should be the child, because the customer table holds the name and address.

Three hours. Both senior. Neither can prove anything. So it gets decided by whoever has more influence, and everyone goes back to work.

This is normal, and it does not have to be.

Question 1: can a thing stop being one and still exist?

This is the important one. Everything else is easier.

Take Person. Can something that is a person stop being a person and still be the same thing? No. If it stops being a person, it is gone, or it has become something else entirely.

Take Customer. Can a customer stop being a customer and still exist? Yes, easily. They stop buying. They are still there.

Those are two different kinds of category, and the field has names for them.

• A category is rigid when nothing can stop being one and survive. Person. Freezer. Shipment. Written +R.
• A category is anti-rigid when every single one could stop being one and survive. Customer. Student. Manager. Written ~R.

There is a third answer for the awkward middle. A category is non-rigid, -R, when some things hold it permanently and others do not. It comes up less often.

The formal version, if you want it

You do not need this to use the method. It is here so that when you see it written down, it is not a wall.

+R(φ)  ≝  ∀x □(φ(x) → □φ(x))

Read the symbols as words. ∀x is "for every thing x". □ is "necessarily". φ(x) is "x is a φ".

So the whole line says: for every thing, if it is necessarily true that being a φ means always being a φ, then φ is rigid. Which is what we said in English: nothing can stop being one and survive.

And anti-rigid:

~R(φ)  ≝  ∀x □(φ(x) → ◇¬φ(x))

◇ is "possibly" and ¬ is "not". For every thing, being a φ means it could possibly not be a φ. Every one of them could stop.

That is all the notation is. Nicola Guarino and Chris Welty wrote the semantics in a system called S5 modal logic, which is simply the branch of logic that handles "necessarily" and "possibly" precisely.

The other three questions

Question 2: does it tell you when two are the same thing? If you have two records, does being in this category tell you how to decide whether they are one thing or two? Written +I when it does. This sounds obvious and is not. Chapter 8 is entirely about it.

Question 3: is each one a whole? Written +U. A statue is a whole; there is a clear answer to where it stops. A lump of clay is not; there is no principled edge. This matters less often but it is what separates a statue from the clay it is made of.

Question 4: does it need something else to exist? Written +D. An employee needs an employer. A person does not need anything. This one is how you tell a role from a kind, which is chapter 7.

What the answers buy you

Once every class has its answers, rules fall out. The famous one uses only question 1:

An anti-rigid category cannot be the parent of a rigid one.

In symbols, where ⊑ means "is under" or "is a kind of":

if  ψ ⊑ φ  and  ~R(φ)  then  ~R(ψ)

Why does this hold? Putting Person under Customer says every person is essentially a customer. Essentially, because that is what being under a category means: it applies to all of them, for as long as they exist. So a person would stop existing the moment they stopped buying.

Nobody believes that. But if you drew that hierarchy, your model says it.

There is nowhere to write these down

A Fabric IQ entity type holds a name, a description, properties with types, a key, and bindings to data. It holds none of these four answers. There is no rigidity field and no validator that will ever tell you a hierarchy is wrong.

That is not special to Fabric. No mainstream enterprise modeling tool carries them. This lives in academic toolchains and Protégé plugins, and it has never crossed over.

So the work happens before you open the tool. On a whiteboard, or in a design note. What you carry into Fabric is the result: a set of entity types that survived the questions.

The one trap

Do not ask "can this change?" That returns anti-rigid for nearly everything and the method becomes useless.

Ask the sharper version: is there even one thing for which this is permanent? If yes, it is not anti-rigid. One example is enough to settle it.

Next, chapter 6. You have the four questions. Chapter 6 turns them into four rules and runs them over a real hierarchy, one that passed three design reviews, and two of its lines turn out to be illegal.