Jacoba Cornelia Oosthuizen

1777 – 1870 · Oosthuizen line

Name

Baptismal name: Jacoba Cornelia
Given: Jacoba Cornelia
Surname: Oosthuizen

The formal baptismal name and the name a person was actually called are both kept, and neither is derived from the other. Spelling drift between records is evidence, not noise.

Naaste familie

Father: Jacobus Oosthuizen (b.1722)
Mother: Dina Carolina Britz
Brothers and sisters: 1751Catharina Oosthuizen

1753Johannes Jacobus Oosthuizen (b.1753)

1755Jacobus Nicolaas Oosthuizen

1755Ockert Oosthuizen (b.1755)

1757Jacobus Petrus Oosthuizen

1760Gerrit Johannes Oosthuizen

1762Dina Johanna Oosthuizen

1764Marthinus Oosthuizen

1767Pieter Cornelis Oosthuizen

1769Jacobus Oosthuizen (b.1769)

1771Dina Johanna Magdalena Oosthuizen

1774Adriaan Oosthuizen

'n Lewe in die rekord

1777 gebore Born
1870 oorlede Died

Wat ons nie weet nie

Geen gedateerde rekord bind hierdie mens aan 'n bepaalde stuk grond nie.

A sourced gap beats an unsourced fill. These are the open questions on this person, stated rather than papered over.

Navorsingsnotas

[SRC-074] Child of Jacobus OosthuizenL (PER-000230) and Dina Carolina BritzM, Tulbagh 1749 - sibling of the root ancestor's father.

[31 Jul 2026] MERGED PER-000667 into this row. Duplicate created by the 31 Jul 2026 one-degree tree pull: kin_sweep.py matched on tree id only, so a person already in the model WITHOUT a tree id was added a second time. Same display name AND same full birth date - name plus date, not name alone. Survivor is the pre-existing row; it carries the research. Moved across: sex=F; tree id=. DISAGREEMENTS, kept rather than resolved - the FamilySearch id settles these in one click: death_edtf: kept '1870', PER-000667 said '1805-12-28'.

[6 Aug 2026] FAMILYSEARCH ID CORRECTED, G6ZV-KXX -> G6ZV-KXK, on Frans's reading of the family view for LHLG-SXG. THE MERGE KEPT THE WRONG ONE. When PER-000667 was merged into this row on 31 Jul the tool did what it always does and kept the survivor's id, retiring the loser's to a note - and the loser's was the right one. The default is not wrong in general, but it is a default, and it had never been audited. Two more merges in this model retired an id the survivor does not carry; a check now lists all three - LEAD-0115.

These are working notes, not finished prose: they carry the reasoning, the corrections and the things still marked to verify. They are kept here so the page itself can read as what is known.

Die werksnotas op hierdie werf word in Engels gehou en word nie vertaal nie. Hulle verander met elke navorsingsessie, en 'n vertaling sou uit pas raak met die oorspronklike. Alles anders — die stories, die getranskribeerde dokumente en die koppelvlak — is in Afrikaans.

Oop vrae

Nine people carry a different FamilySearch id here and in the tree prioriteit 2 · LEAD-0036
For nine people the model records one FamilySearch id and the family-tree's _FID records another. Which is the live profile, and are the two ids two profiles for one person that want merging on FamilySearch itself?

Wat dit sou uitmaak Loading each id and seeing whether it redirects.
Two more merges kept the survivor's FamilySearch id. Was it the right one? prioriteit 2 · LEAD-0115
Three merges in this model retired a FamilySearch id the survivor does not carry. One has now been adjudicated and the RETIRED id was correct. Are the other two the same way round? PER-000470 (kept K8RV-S4V, retired GL5W-F4T) and PER-000211 (kept GB6B-ZCM, retired L1GX-62B).

Wat dit sou uitmaak Reading each pair and saying which profile is the person. Where FamilySearch itself holds both, it needs merging there too.

Elders

FamilySearch-profiel G6ZV-KXK