Part 2 — Things
8. Identity is not a primary key
Two patients with the same name and birth year were merged into one chart. The key worked perfectly. It was doing exactly what a key does, which is not what anybody thought it was doing.
Chapter 7 said roles borrow identity from a kind. That leaves an obvious question unanswered.
What is identity?
Two patients arrived at a hospital with the same name and the same birth year. The system matched them and merged their charts. One of them was given a drug the other was allergic to.
Nothing malfunctioned. The matching rule ran correctly. The key did its job.
Two different jobs
A key is a storage device. It has to be unique inside a table, and it has to be stable enough to point at. That is all it promises.
An identity criterion is a truth about the world. It answers: given two descriptions, are these one thing or two?
Most of the time they line up and nobody notices the difference. When they come apart, you get one of two failures.
Two keys, one thing. Maya Chen from chapter 7. Two customer IDs, one human. The system sees two customers because the key said so.
One key, two things. The two patients. One matched identity, two humans. The system sees one because the key said so.
The second one is much more dangerous, and it is the one that hurt somebody.
Identity across a moment, and across time
The field splits the question in two, and the split is useful.
Same at one moment. Two records in front of you right now. One thing or two? This is what entity resolution and record matching try to answer, usually with fuzzy rules about names and addresses.
Same across time. The thing in front of you now, and the thing that was here last year. Same one?
The second question is older and stranger, and it has a famous form.
Freezer FRZ-0041
The door seal is replaced
Routine maintenance. Ten minutes.
Is it still the same freezer?
What the freezer shows
Somewhere in that sequence most people change their answer. Where they change reveals what rule they are actually using. Some people track the function. Some track continuous history. Some track the physical parts.
The database never changed its answer, because the asset tag never changed. It was never tracking parts, or function, or history. It was tracking a label somebody stuck on the front.
That is fine, right up until the last step, when two working freezers exist and only one can hold the tag.
A good identity criterion
Three things to check.
It must actually decide. Given two records, it returns same or different. "Name and address" does not decide, because addresses change and names are spelled differently.
It must be stable. The thing keeps it over its whole life. An email address fails this badly, and it is used as a customer identity constantly.
It must belong to the kind. From chapter 7: identity belongs to the kind, not the role. A customer ID identifies a customer relationship. It does not identify a person.
Check yourself
Your team uses email address as the customer identity. Which failure will you get, and when?
The key is doing identity work, whether you meant it or not
In Fabric IQ, an entity type has a key. Rows that share a key value fold into one entity instance. Rows with different key values become different instances.
That folding is exactly identity. So the key you pick is your identity criterion, whether you chose it for that reason or not.
This is worth stating clearly, because the tool presents it as a technical setting. Pick CustomerID because it is the primary key of the table, and you have decided that a customer relationship is what identifies a person. Every consequence in chapter 7 follows from that one dropdown.
What to do about it
Pick the key for the kind, not for the table. Ask what identifies the thing, then find or build a column that carries it. Sometimes that means adding a stable identifier upstream rather than reusing whatever the source system had.
Resolve identity before you bind, not after. Once instances exist in the graph, a wrong key has already split one thing into two nodes, and every relationship, traversal, and agent answer is built on that split. Fixing it later means rebuilding.
Write the rule down. Somewhere a human can read it: "two rows are the same supplier when the registration number matches, and a rename does not create a new supplier." That sentence is your identity criterion. It is not stored anywhere in Fabric, so if it only exists in someone's head it will be lost.
The one trap
Never let the source system choose your identity. The key in the source table was chosen to make that system's storage work, by somebody who was not thinking about your model, your graph, or your agent.
Ask what makes two records the same thing in the world. Then go and find a column that carries that. If none exists, that is a finding worth reporting, not a detail to work around.
This is the end of Part 2. You can now say what an ontology is, place any model on the ladder, read what a model claims exists, sort things into the biggest boxes, test a category, check a hierarchy, tell a kind from a role, and pick an identity criterion.
Part 3 starts at chapter 9, and it moves from things to the links between them. It opens with a fact that will not fit on an arrow.
Do it yourself
Build this step in the interactive Ontology Lab.
Open the lab →Milestone
Finished this concept? Mark it learned to track your progress.