What kind of thing are you resolving?

Open a spreadsheet and it is easy to forget what you are looking at.

There are rows. Names. IDs. A few fields that look certain because they have been given a type. Then another file arrives and something has to decide whether two rows mean the same thing.

The thing being decided is not in either file.

That is where entity resolution starts. It is also one of the questions I keep coming back to as I think about entity intelligence. Not with a cleverer match. With remembering that the world came first.

The rule underneath all of it

From John Talburt, in Entity Resolution and Information Quality:

Entities do not exist in the information system. They exist in the real world. Information systems store references to entities, never the entities themselves.

A row is not a person. A row is a claim somebody made about a person, using the fields their system happened to have, for their own purposes.

The same is true of a country. Or a shop. Or a company. The entity can outlast the application that named it, the database that assigned it an ID, and the person who typed it in.

Real does not only mean physical. A company is real in the legal and social world. An account is real within the relationship that created it. Neither is identical to the row that happens to describe it.

Two rows about one person can disagree because the people or systems that wrote them wanted different things.

I find that distinction clarifying rather than pedantic. A system that believes it stores people will eventually tell you it is certain about one.

A system is more than the tool

When I say system here, I do not only mean an application, a database, an agent or an AI model.

A system is a set of parts working together, through a process, to produce an outcome.

Those parts can be people, agents, tools, records, rules, and the steps connecting them. In this work, the outcome is often a decision or an action. A person using a spreadsheet to make a decision is a system. So is a case worker checking a report, a team reading a map in a meeting, or an agent passing a recommendation to a human for approval. While the tool is important. It is not the whole thing.

The system also includes the feedback after that action. Did the delivery arrive? Was the match wrong? Did somebody appeal it? Without that part, it cannot learn where its picture of the world failed.

A report or a visualisation is not automatically a system on its own. It is a view. But once someone uses that view to decide whom to contact, which supplier to pause, or where to send help, it is part of the system that acted.

I think it’s important we understand this, because no part of that system contains the person, country, or company itself. It contains references, evidence, and decisions about them. The more automatic the decision becomes, the easier it is to forget the difference.

The vocabulary, and why each word earns its place

Talburt is careful with terms in a way that pays off later. Four of them do most of the work.

An entity is the thing in the world. Your neighbour. The clinic on the corner. Côte d’Ivoire. It has no fields, because it is not data.

An entity reference is a record that mentions it. A row in a spreadsheet, a name in a PDF, a line in a registry. References are what you actually have.

Identity attributes are the fields of a reference that could distinguish one entity from another. A national ID number. A surname. A registered company number.

Descriptive attributes are everything else. Eye colour, opening hours, staff count. Useful information, no help at all in telling two things apart.

Two references that point at the same entity are said to co-refer. Resolution is the act of deciding whether they do, and that word is doing something specific. You are not measuring similarity. You are deciding co-reference.

Talburt has a longer vocabulary for what happens after that, and it is worth knowing the shape of it even if you never build one. Keeping identity stable over time is entity identity information management, and the store it lives in is an identity knowledge base: a record, per entity, of what has been decided about it, so that next month’s data can be matched against last month’s conclusions rather than starting again.

That is a stateful system with its own governance obligations. Deciding co-reference is not.

Groups, categories, and the things inside them

A product family or category is not automatically an entity reference. It can be a managed concept or entity. A row that names it is an entity reference to that concept.

This matters because a product family is not the product inside it.

Retailer reference: "Coke Can 330ML"
  → resolves to → Coca-Cola Classic 330ml can
                    ├─ GTIN: identifies this sellable variant
                    ├─ size: 330ml
                    ├─ container: can
                    └─ belongs to → Coca-Cola Classic product family

The size and container are attributes on the retailer reference. When the question is which sellable variant this is, they may be identity-bearing, just as the GTIN is. When the question is which product family this belongs to, they merely describe variants inside that family. The product family is a separate managed concept. The belongs to line is a typed relationship between the resolved product entity and that concept.

Categories work the same way. Attraction ticket can be a managed category concept. A Museum Day Pass can be a managed product family. The museum itself is a place entity. A supplier row may mention all three, but it does not make them one thing.

Similarity helps make the candidate group. Coca-Cola Classic can bring a 330ml can and a 500ml bottle into the same search results. It cannot say that they are interchangeable, or that they refer to one sellable product.

Entity resolution then asks the narrower question: does this retailer row refer to the 330ml can, the 500ml bottle, or something else? Only after that decision can the product be safely connected to a product family, category, batch, place, or supplier.

This maps directly onto Talburt’s five activities. Reference preparation and resolution work on the row and its possible entity. Identity management keeps the resolved entity steady over time. Relationship analysis works on the links between resolved entities, such as product-to-family, film-to-franchise, or person-to-household.

Once those links are stored, they form a graph and graph analysis can ask useful questions across them. It can find product families, franchise connections, or communities. It cannot make a wrong identity link right. Every relationship built on a bad resolution decision carries that error forward.

For the everyday version of this distinction, similarity is not transitive follows the same problem through products, families, search, and addresses.

One country, four references

This is easier to see with a country than with a made-up person.

Imagine a spreadsheet has Cote d’Ivoire, with a curly apostrophe, ’ (U+2019). A Google Ads export has Cote d'Ivoire, with a straight apostrophe, ' (U+0027). A colleague calls it Ivory Coast. The country itself uses Côte d’Ivoire, including the accent on the o.

Those are not four countries. They are four references that may all point to one country.

The first two values are different strings. A literal join will treat them as different. That is a real technical problem, and normalising punctuation may help find the pair.

But punctuation normalisation does not tell you what the pair means. Ivory Coast will survive that normalisation unchanged. The evidence comes from the field’s context, the country code CI, a maintained list of names, and the fact that the values are meant to be countries in the first place.

The pronunciation belongs in the picture too. An English speaker can start with something close to coat dee-vwahr. Better still, listen to someone who uses the name. The point is not to turn a country into a phonetics exercise. It is to notice that a reference is also something people read, say, translate, and carry between systems.

If you have never seen the name before, Ivory Coast can be useful evidence. It is not a replacement for the entity, and neither is the display string your system happens to prefer.

The five activities

Talburt decomposes the whole field into five. Naming them is useful mostly because it shows how much of “entity resolution” is not the matching step everybody talks about.

Most tooling sells you number three.

What counts as an entity in context of ER

Anything you can point at twice and mean the same thing. That is a low bar and it is meant to be.

People. Places, including clinics, addresses and settlements. Products, at whichever level you decide counts. Organisations. Also vessels, accounts, creative works, events, and any number of things nobody has written up properly.

The test is not whether something feels important. It is whether two references to it can disagree while still meaning the same thing.

Where each one breaks

People is where the philosophy stops being optional, because a database is a committed bundle theorist with no substance underneath to hold the attributes together. Three tiers of identity data, why most of your record is borrowed rather than yours, and the uncomfortable fact that Customer 360 is the same technical operation as a patient record with a different beneficiary.

Places is where space is the trap. Coordinates for one clinic routinely sit kilometres apart between surveys, so geometry proposes candidates and is never allowed to decide one. Also the address-as-identity argument, and the billions of people who live somewhere named rather than addressed.

Products is where the question is malformed until you fix a granularity. Two tins of tomatoes are the same product and two different things, both correctly, and you cannot answer until somebody says which they meant.

Organisations has no note yet. The hard case is a site and the company operating it sharing a name and a coordinate, so every string signal and every spatial signal points the wrong way at once, and only a declared class refutes it.

Relationships, and the graph everyone wants to build

The fifth activity is the one people jump to, because it is where the interesting questions live. Who is connected to whom. Which accounts share a household. Which suppliers sit behind one parent company.

There is an ordering constraint and it is structural rather than a preference.

Relationships connect entities. Before resolution you do not have entities, you have references. Build the network first and one person appears in it three times, under three spellings, with their connections split between the copies.

You have not modelled a network. You have modelled your data-entry history.

This is the argument for what gets called an entity-resolved knowledge graph: resolve first, then let the resolved things be the nodes.

A graph over unresolved mentions does not fail loudly. It gives you plausible answers about a world that is subtly wrong, and centrality scores computed over duplicated nodes look exactly like centrality scores computed over real ones.

One thing I would add to the standard telling. A relationship claim is itself personal data. Who lives with whom, who transacts with whom, is often more sensitive than either party’s name, and a graph that resolves people carefully and then treats the edges as neutral infrastructure has protected the wrong half.

What this does not make entity resolution

Not every data problem is co-reference.

Two hundred farms’ cocoa can go into one container. The question is not are these the same? It is did this become that? That is a flow, directed and non-symmetric. Under commingling, the individual identity can genuinely disappear into a mass balance.

An identity document is different again. It has an issuer, a subject, and a self-declared origin. Deciding whether to trust it is a provenance problem as much as a resolution problem.

Entity intelligence will need to hold both kinds of claim. It should not pretend they are the same relation because they happen to be stored beside each other.

Where I run out

The vocabulary is good. It is the best I have found for keeping the question straight, and most confusion I meet in this work is someone collapsing entity into reference without noticing.

What it does not give you is the sorting. Talburt tells you identity attributes are the ones that distinguish entities. He does not tell you that a postcode distinguishes clinics and barely distinguishes people, because that is not a fact about entity resolution.

It is a fact about postcodes, and clinics, and where the data came from. Somebody has to know it, write it down, and keep it current, and that part has no theory at all.

Related

• What entity resolution actually is, on the decision itself.
• Talburt, Entity Resolution and Information Quality (2011), for the vocabulary above.
• Google Ads codes and formats, where Cote d'Ivoire appears as the country name beside CI.
• Côte d’Ivoire’s official country presentation, which uses the official French name.