Jacoba Cornelia Oosthuizen
1777 – before 1805-12-28 · 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.
Three generations around this person
Work out how this person is related to somebody else →
Click any name and the same three generations are drawn around that person instead. There is no first couple here and no top to the tree: it is only ever the family standing closest to whoever you are reading about, and a blank is a gap in the record rather than a statement about anybody.
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 Jacobus 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
- before 1805-12-28 died Died
- 1777 born Born
Stories
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.
[23 Sep 2026, SRC-467] THE 1870 WAS WRONG; SHE WAS DEAD BY 28 DECEMBER 1805. MOOC8/56.13a-b is her estate, taxed at the Weeskamer on that date for her surviving husband JACOB VAN DEN BANK and her children by two marriages: Jacoba Cornelia Emmenes 12 (by the late Jan Emmenes) and Jacobus Marthinus 8, Dina Carolina Johanna Catharina 6, Johanna 4 and Sara Alberta van den Bank 3. Appraised by her brother PIETER CORNELIS OOSTHUIZEN (PER-000242); the estate holds Rd:s 510 still owed by Lambert Meyburgh for the opstal of MISTKRAAL 'van Willem Goozen gelegen aan de Touwsberg', and owes Hendrik Oosthuijsen for planks. The merged tree row (PER-000667, FS G6ZV-KXK) already carried 1805-12-28; the document settles it.
[2026-09-23] The sheets are transcribed in full with a reading in both languages, DOC-0368, INV-0033.
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.
What the record is missing
-
An estate taken on ground we cannot place
second order · B6 loose-doc
DOC-0368 (MOOC8/56.13a and 56.13b, 1805-12-28) lists a household's whole movable estate, which means officials went to where that household lived. It says “not named; the estate holds the price of the opstal of Mistkraal, 'van Willem Goozen gelegen aan de Touwsberg'” and no more. No parcel is attached, so the family it describes sits nowhere on the map.
What would settle it The inventory's own heading usually names the farm and the field-cornetcy; where it does not, the deceased's quitrent or opgaaf entry for that year will. This is the shape that produced the de Bruin/Rondabel find.
Found by breaks.py reading the model against itself, not written by hand,
each one is a shape of missing record, not a fault in the data.
The whole set is on the
questions page.
Elders
FamilySearch profile G6ZV-KXK