Multiple Document Linking: Building Evidence Graphs

---

Tamil Ancestry Research | Family Tree Guide

---

In this article:

1. What “multiple document linking” actually means
2. Why “one person → one document” thinking is childish
3. Person–document links vs document–document links
4. How to decide two documents point to the same person
5. Modelling links in TamizhConnect: IDs, link types, confidence
6. Handling conflicts across linked documents (names, dates, places)
7. A realistic workflow: linking a life across 6+ document types

---

1. What “multiple document linking” actually means

Most people do this:

• Create a person in the tree.
• Upload a birth cert as an attachment.
• Maybe later add a passport scan.
• End of story.

That’s not linking. That’s stapling.

Multiple document linking means:

Treating each document as a separate evidence source,
linking it to:

• one or more people,
• specific facts (birth, marriage, land, residence),
• and sometimes to other documents in a chain.

You’re building:

• an evidence graph:
  • people ⟷ facts ⟷ documents ⟷ other documents

not:

• “this person has 10 random PDF attachments”.

If you do this properly, you can answer:

• “What evidence do we have for this date?”
• “Which documents tie these two branches together?”
• “Why do we believe these two names are the same person?”

If you don’t, you’re guessing and calling it genealogy.

---

2. Why “one person → one document” thinking is childish

Real life:

• Same person appears in:
  • birth/baptism record
  • school admission register
  • college record
  • electoral rolls
  • passport/visa
  • ID cards
  • pattas / deeds
  • temple/church/mosque records
  • obituaries
  • association membership lists

Each:

• uses a different name format,
• has different errors,
• shows them at different ages / addresses / roles.

If you act like:

• “birth certificate is the only real thing”,
• or “passport name is the truth and everything else is fake”,

you trash 90% of your usable evidence.

Multiple document linking is the only sane way to:

• reconcile inconsistent information,
• see the timeline of how identity changed,
• understand why the same person looks different on paper over time.

---

3. Person–document links vs document–document links

You need both. Don’t mix them in your head.

3.1. Person–document links

This is basic but critical:

• Document D supports facts about Person P.

Example:

• Birth cert → P’s birth date, birthplace, parents.
• E-roll → P’s residence and approximate age in a given year.
• Patta → P’s role as landholder in a specific survey number.

In TamizhConnect:

• each link should say:
  • how the person appears in the document,
  • what role they play,
  • which facts you extracted from it.

3.2. Document–document links

Documents also talk to each other:

• A passport was issued based on a birth certificate + school record.
• A patta mutation refers to a sale deed or court order.
• A temple donor plaque matches names already in a trust register.
• A NIC/ID card is renewed using the old one.

These are dependency links:

• “D2 cites D1”
• “D3 supersedes D2”
• “D4 is a renewal/duplicate of D3”

Without document–document links, you miss:

• chains of evidence,
• why errors got propagated,
• which document is actually independent and which is just a copy with new letterhead.

---

4. How to decide two documents point to the same person

This is where people usually screw up and merge the wrong humans.

4.1. Don’t rely on name alone

Names are the noisiest field:

• spelling shifts,
• initials appear/disappear,
• pet names vs formal names,
• caste titles added/dropped.

If all you check is:

• “Oh look, ‘Muthusamy’ appears here also, must be him”,

you’re begging for false merges.

4.2. Use a match bundle, not a single field

Treat it like this:
Two records refer to the same person if a bundle of fields line up strongly enough:

• name (or plausible variant),
• father/husband/mother name,
• approximate age/year-of-birth,
• village/street / address,
• caste/title (if present),
• school / occupation / deity context (if relevant),
• time window makes sense.

Example match:

• E-roll 1995:
  • R. MUTHUSAMY, father Ramasamy, age 45, house 12A, Village X.
• Passport 2003:
  • Muthusamy R, DOB 1958-06-10, address 12A, Street, Village X.

Bundle says:

• same village,
• same address,
• same father name,
• age matches DOB,
• name variant is trivial.

So yes, link them as same person with high confidence.

4.3. Record match confidence, don’t pretend certainty

Not every link is that clean.

For each person–document link, store:

• linkConfidence: "high" | "medium" | "low"

Example:

• Temple notebook entry: “Muthusamy, gothram X, nakshatram Y, Village X” – looks like your guy but not 100% unique.
• Mark link as "medium" with a note:
  • “Likely same as Person #23 based on village + gothram; name is common; no father’s name given.”

Later evidence can upgrade/downgrade this.

---

5. Modelling links in TamizhConnect: IDs, link types, confidence

You need real structure, not vague “attached files”.

5.1. Source (Document) object

Each document gets a Source object:

• sourceId
• sourceType: "birth-cert", "marriage-cert", "death-cert", "patta", "sale-deed", "e-roll", "temple-record", "school-record", "passport", "visa", "affidavit", etc.
• titleOrLabel: "Birth certificate of X", "SSLC Book for Y", "Patta #123 for Survey 45/2", etc.
• yearApprox
• pages / fileLink
• jurisdiction: Tamil Nadu, Sri Lanka, Gulf, etc.

5.2. Person–Source link object

For each connection between a person and a document, define a PersonSourceLink:

• personId
• sourceId
• role:
  • "subject" (it’s about this person)
  • "parent" / "spouse" / "child" / "witness" / "informant"
  • "landholder" / "tenant" / "trustee" / "donor" / "voter" / "applicant" etc.
• nameAsWritten in that document
• otherPartyNameAsWritten (father/husband/etc. if relevant)
• linkConfidence: "high" | "medium" | "low"
• notes: “Age inconsistent with later records”, “Likely same person; name variant; see X”.

This lets you say:

• “Show me all documents where this person appears as subject,”
• “Show me all documents where this person appears as landholder,”
• “List all witness roles they played.”

5.3. Fact objects linked to both person and source

You shouldn’t let documents directly overwrite person fields. Instead:

• extract facts from each document (birth, land, address, etc.),
• each fact has:
  • factType
  • structured fields (date, place, etc.)
  • personId(s)
  • sourceId
  • factConfidence.

Then your person’s “canonical” DOB / place / etc. is derived from all facts, not blindly from one document.

5.4. Source–Source links

For document–document relationships, create SourceLink objects:

• sourceAId
• sourceBId
• linkType:
  • "cites" – passport cites birth cert, will cites patta, etc.
  • "supersedes" – revised patta replaces older one.
  • "duplicate" – identical copies or renewed cards.
  • "bundle" – pages belonging to same file (e.g., court bundle).
• notes:
  • “Passport requires school record; DOB changed between A and B.”

This builds a chain of how identity paperwork evolved and which doc is just derived from which.

---

6. Handling conflicts across linked documents (names, dates, places)

Multiple document linking doesn’t magically solve conflicts – it just makes them visible. Good.

6.1. Don’t pick a random “winner”; rank and annotate

When documents disagree:

• keep all their statements as separate facts,
• assign:
  • fact-level confidence,
  • explanation in notes:
    • “School DOB differs by 1 year; likely adjusted for exam eligibility.”

Canonical fields on the person:

• store:
  • chosen working value (e.g., 1950),
  • pointer to which facts it’s based on,
  • overallConfidence: "high" | "medium" | "low".

6.2. Exploit time and dependency

If:

• passport was issued using a particular (fake) school DOB,
• but you have a hospital birth record from the actual year,

then:

• birth record gets higher weight,
• passport gets logged as “derived from school record; date likely administrative, not factual.”

Document–document links (“passport cites school cert”) make this explicit.

6.3. Accept that some fields stay fuzzy

Sometimes:

• three documents all disagree,
• oral memory doesn’t help,
• no new evidence is likely.

Then your conclusion is:

• “DOB ~ 1948–1951, exact date unknown.”
• Store that as a range and move on.

Better to admit uncertainty than fake accuracy.

---

7. A realistic workflow: linking a life across 6+ document types

Take one person and do it properly. Example stack:

• Birth certificate
• SSLC / school record
• College record
• Passport
• E-roll entries (1995, 2005, 2015)
• Patta & sale deed

Step 1 – Create the person with minimal assumptions

• Person P with:
  • provisional name,
  • rough birth year,
  • core village.

Don’t overfill fields yet.

Step 2 – Add all documents as Source entries

For each:

• add sourceType, year, fileLink, jurisdiction.
• Don’t link anything else yet.

Step 3 – For each document, create Person–Source links

Per document:

• identify where P appears (subject, parent, voter, landholder, etc.),
• create PersonSourceLink with:
  • nameAsWritten,
  • role,
  • linkConfidence.

If a document also mentions relatives:

• create links for them too, even if they’re placeholder profiles.

Step 4 – Extract facts per document

Example:

• Birth cert → birth fact:
  • date, place, parents.
• School record → education fact + alternative DOB.
• E-roll → residence facts with age estimates.
• Patta → land-holding facts.
• Sale deed → land-transfer event.

Each fact points to:

• personId(s),
• sourceId,
• factConfidence.

Step 5 – Reconcile into canonical person data

Look at all birth-related facts:

• pick a working DOB or year-range,
• set overallConfidence,
• note conflicts.

Likewise for:

• canonical name (with normalized form + variants),
• native village vs birth hospital,
• occupation,
• migration events.

None of this deletes underlying facts; it just chooses a current best summary.

Step 6 – Tie documents to each other

• Passport cites school record → SourceLink: passport cites schoolRecord.
• Patta mutation refers to sale deed → SourceLink: patta supersedes old patta based on saleDeed.

These chains explain:

• where errors came from,
• which doc is independent vs derivative.

Step 7 – Re-use links for relatives

Once P is properly linked:

• siblings/children/spouses who appear in the same documents:
  • inherit some of the linking work.

Example:

• E-roll household entries → multiple people at same address, same year.
• Patta with multiple co-holders.
• Marriage record listing both sides.

You link them all into the same evidence graph instead of re-doing everything from scratch.

---

If you treat each document as an isolated trophy, TamizhConnect becomes a prettier file system and nothing more.

If you actually do multiple document linking:

• every person is backed by a web of sources,
• each fact is traceable and ranked,
• conflicts are visible and explainable,
• and your “family tree” becomes what it should be:

not a neat fantasy diagram, but a documented, honest reconstruction of messy real lives – with birth certs, school lies, passport hacks, pattas, and temple records all tied together in one coherent evidence graph.