Adriana Cecilia Oosthuizen

1848 – 1913 · Oosthuizen line

Descends from the root couple, 2 generations up

Name

Given: Adriana Cecilia
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: Cornelis Andries Oosthuizen (b.1828)
Mother: Magdalena Maria van Wyk
Brothers and sisters: 1851Magdalena Maria OOSTHUIZEN

1855Ocker Almalo Oosthuisen

1857Abraham Petrus Oosthuizen

1868Maria Johanna Oosthuizen

1878Hendrika Helena van der Westhuizen

·Cornelis Andries Oosthuizen

·Gabriel Jacobus van der Westhuizen
Children: Anthoinette Christina Keyter

'n Lewe in die rekord

1848 gebore Born
1913 oorlede Died

Ander van dieselfde naam

Afrikaans naming repeats hard, and the Cape Dutch naming pattern reuses a name on purpose, a child who died young has the name given again to a later sibling. These are different people. Never match on a name alone.

Wat ons nie weet nie

Geen gedateerde rekord bind hierdie mens aan 'n bepaalde stuk grond nie.
7 other people in this model carry the same name. Never match on a name alone.

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

Navorsingsnotas

[TREE] Added 29 Jul 2026 under the people-related-to-the-land rule: child Jacobus Daniel Johannes OosthuizenM (PER-000004). Thin record; dates as in the tree.

30 Jul 2026 [FS]: FamilySearch MTLS-FWN, 1848-1913 - both dates new, from FS; she is the eldest of the listed children, born within a year of the 14 Jun 1847 marriage.

30 Jul 2026 [SRC-126/DOC-0086] Listed on her father's 1903 death notice as 'Adriana Cecilia VIVIER born Oosthuizen' (a first attempt 'Hugho' struck through) - so by 1903 she was married to a VIVIER, husband's given names not stated [TO VERIFY].

[31 Jul 2026] MERGED PER-000549 into this row. PROVEN DUPLICATE, resolved on the FamilySearch id. Both rows carry MTLS-FWN; an FS id names one person, so these are one person recorded twice. Created by the 31 Jul 2026 one-degree tree pull, which matched on tree id alone - and 255 model people carry no tree id, so any of them one hop from a tree-linked person was added again. Survivor is the pre-existing row; it carries the prose, sources and land links. DISAGREEMENTS, kept rather than resolved - the FamilySearch id settles these in one click: birth_edtf: kept '1848', PER-000549 said '1853-07-30'; tree id: kept '', PER-000549 said ''. Retired ids kept for the trail: tree - a merged FamilySearch id still resolves, so it remains a usable door.

[31 Jul 2026, audit] A SECOND PARENTAGE CLAIM arrived with the merge of PER-000549 and is recorded here rather than as a second row: that row named PER-000128 x PER-000129 as the parents, while this row names PER-000004 x PER-000136. Two different couples for one person. NOT resolved - both are [TREE]/medium and neither has a register behind it. See the parentage-conflict lead.

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

Two children with two different sets of parents prioriteit 1 · LEAD-0037
PER-000373 Sophia Johanna OosthuizenL (b.1850) and PER-000443 Adriana Cecilia OosthuizenL (b.1848) each carry two parentage rows naming different couples. Which is right?

Wat dit sou uitmaak A baptism entry. Nothing short of it - both rows are [TREE] and neither has a register behind it.
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.
Seven people carry a hand-entered FamilySearch id that the family-tree disagrees with prioriteit 3 · LEAD-0019
Backfilling familysearch_id from the family-tree's _FID tag agreed with the hand-entered value on 103 of 110 people and disagreed on 7. Which id is current for each - or do both resolve to the same person after a merge?

Wat dit sou uitmaak A redirect proves a merge and the survivor id is the one to keep. Two live, distinct profiles means one of them is the wrong person, and the vitals decide which.

Elders

FamilySearch-profiel MTLS-FWN