Entity and Relationship Meaning

The last lesson gave you the vocabulary: nodes, edges, labels, properties, paths, neighborhoods, and the discipline of stating every relationship as a triple. That vocabulary only holds up if everyone agrees what each node is and what each edge actually claims. This lesson is about that second layer of meaning, where most connected work quietly goes wrong.

In this lesson, you will learn to:

• Explain why entity resolution is a different activity from deduplication.
• Separate the four identity concepts — identity, type, attribute, and relationship — and avoid mistaking a shared attribute for proof of sameness.
• Interrogate a relationship for direction, cardinality, time, provenance, confidence, and appropriate use, and write an assessment that separates what the evidence observed from what you inferred.

Four distinct concepts get collapsed into one another constantly, and separating them is the whole discipline. Entity identity asks whether two records refer to the same real-world thing, while entity type asks what kind of thing a record represents: a person, an account, a household, a service point.

An attribute is a characteristic of a thing, such as a shared address or an enrollment date. A relationship is a connection between two things, such as a meter assigned to a service point. Those two are easily confused with the first two, and the confusion is expensive.

The failure mode is treating a shared attribute as proof of identity. Two customer records sharing a service address tells you they have an attribute in common. It does not tell you they are the same person, and it does not tell you the address is a node in its own right rather than a property hanging off each record. Similarly, a shared device is a relationship, not evidence of sameness. Two people can plausibly be connected to one meter.

That distinction also forces the entity-type question into the open. If two individuals share a meter, the thing the meter actually serves may not be a customer at all: it may be a household, which is a candidate entity type nobody has agreed to introduce yet. Notice how much of this echoes the class-versus-instance work you did on ontologies. Identity questions are semantic questions wearing connected clothes.

A terminology note before the distinction itself: in everyday use, "deduplication" often serves as a loose synonym for entity resolution or record linkage — a team says "let's dedupe the customer table" and means the whole identity question, evidence and all. This lesson draws a narrower, deliberate convention instead, because the two postures below are the ones that cause damage when confused, whatever a given team happens to call them.

Deduplication, in that narrower sense, starts from a conclusion: one record is redundant, remove it. Entity resolution starts from a question: what real-world thing does each record refer to? Those are not the same activity, and the second can legitimately end with "these are two different people."

This matters because the merge decision propagates through every connection attached to the merged node. Merge two records and you have also merged their usage histories, their consents, their case histories, and their eligibility for whatever campaign triggered the request. Get it wrong and you have not created a duplicate row; you have created a person who does not exist, with a behavior profile nobody has.

The exchange below is between Ryan, an analyst handed a rushed merge request, and Natalie, the senior data steward he checks his reasoning with.

• Ryan: Retention wants these two records merged before Friday. Same address, same registered meter. It looks obvious.
• Natalie: Obvious in which direction? Same person twice, two occupants of one household, or one occupant who replaced another?
• Ryan: The third one hadn't occurred to me. Does it change anything if it's a succession?
• Natalie: It changes the business conclusion entirely. One offer, two offers, or a tenancy-change investigation. Same evidence, three readings.
• Ryan: So the merge isn't a data cleanup task. It's a claim about who lives there.

Notice that Natalie didn't argue against the merge. She refused to let one reading of the evidence pass as the only reading.

Whether two records refer to the same real-world thing does not change with context — that fact is either true or it isn't, whether or not you currently have enough evidence to know which. What does change by context is what you do with an uncertain answer: the confidence threshold you require before acting, whether you group the records for one purpose while keeping them separate for another, and what use is appropriate given the cost of being wrong. Billing might reasonably act on a merged view at a lower confidence threshold than a safety visit ever should, because the cost of a wrong grouping differs sharply between a misapplied invoice and a technician sent to the wrong household. State the threshold and the stakes out loud for the specific decision in front of you, rather than picking one global answer and applying it everywhere.

Once identity settles, the edge itself needs interrogating. Six questions do that work:

1. Direction — is the meter assigned to the customer, or is the customer associated with a service point that holds the meter?
2. Cardinality — one-to-one, or one-to-many, whether simultaneously or in succession?
3. Time-boundedness — is this link current or historical?
4. Provenance — what source supports the claim?
5. Confidence — how confident is that evidence?
6. Appropriate use — is the proposed use appropriate for a claim of that strength?

The first three describe the shape of the edge; the last three — provenance, confidence, and appropriate use — are the connected-claim trust test.

That last question is the one people skip. A relationship reliable enough to route an engineer may be nowhere near reliable enough to send a regulated communication or suppress a customer from a campaign.

The takeaway to carry forward: a connection is a claim, and every claim has a direction, a lifespan, a source, and a limit on what it may be used for. Two quick checks come first, on resolution versus deduplication and on the four identity concepts. Then you'll write an assessment for a data governance lead who will read it for one thing above all: whether you separated what the evidence observed from what you inferred.