Jacoba Cornelia Oosthuizen
1777 – 1870 · Oosthuizen line
Names
- 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.
Immediate family
- 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
A life in the record
- 1777 born Born
- 1870 died Died
What we don't know
- No dated record ties this person to a specific piece of ground.
A sourced gap beats an unsourced fill. These are the open questions on this person, stated rather than papered over.
Research notes
[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.
Open questions
-
Nine people carry a different FamilySearch id here and in the tree
priority 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?
What would settle it Loading each id and seeing whether it redirects.
-
Two more merges kept the survivor's FamilySearch id. Was it the right one?
priority 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).
What would settle it Reading each pair and saying which profile is the person. Where FamilySearch itself holds both, it needs merging there too.
Elders
FamilySearch profile G6ZV-KXK