Notation

Dorenbos/Hoogeveen/Leur

The Dorenbosch.net Databases Last updated: 11 September 2026

The use of any material derived from this website for commercial purposes is strictly forbidden.

Dorenbos Hoogeveen Leur

Home Database Home Database Home History Notation Search Tips Links Contact

Notation

The notation used in this database was designed to be as concise as possible for the purpose of building readily readable, two-dimensional tree structures of extended families. All the information for each individual, including his/her spouse, is encoded in one line, followed by his/her children, again one person per line. An exception is made for multiple marriages, where additional marriages appear sequentially much like siblings. You can think of it as a kind of genealogy meta-index, combining and merging existing genealogical indexes in a way that simultaneously captures the family relationships. Researching further genealogical information, such as lifestyles, in-laws, etc., is left to the users of this database.

The formal rules of notation are:

1) Each node of the tree is a single text line whose indentation level and location relative to its neighbors denote its parent-child-sibling relationships.

2) The node format is: <principal> (<birthyear>-<deathyear>) & <spouse> (<birthyear>-<deathyear>) (<marriageyear>div<divorceyear>)

3) Any elements of this node may be missing.

4) The <principal> is the full name of the Dorenbos, Hoogeveen, or Leur family member, whether male or female (gender neutral). Any and all spelling variants of “Dorenbos” are allowed, regardless of the spellings of their neighbors. Likewise for “Hoogeveen” and “Leur”.

5) Occasionally a family member with a different surname may appear as a <principal>.

6) The <principal> name need not be unique but, taken together with <birthyear> , <deathyear> and indentation level, will uniquely identify the individual appearing in different contexts, such as in multiple marriages, <spouse> of another <principal>, or when a large branch of the family is moved to a different location to improve readability.

7) The <spouse> is the full birth name of the spouse, if any. If the spouse is also a principal elsewhere, the surname is a hyperlink to his or her birth family in the appropriate database. Likewise, the <principal> may be hyperlinked to a <spouse> elsewhere.

8) If the exact year of birth, death, or marriage is unknown, an estimate may be present using the conventional symbol <, >, or ~ (“before”, “after”, or “estimated at”) based on what is known about the individual’s life.

9) Every principal has exactly one node or line—with one exception: multiple marriages are expressed in multiple lines at the same indentation level, much like siblings (below). In rare cases the location data may appear on a separate line due to space limitations.

10) The parent-to-child relationship is expressed by placing the first child immediately after its parent, indented one level to the right, and followed by all further siblings at the same level. Siblings may be physically separated from each other by (further indented) descendants of the prior sibling, but the originally assigned indentation level is scrupulously retained for each sibling.

11) Siblings are usually ordered by birth year, but this rule can be ignored for readability considerations, such as when a younger sibling (or earlier marriage) has many descendants.

12) A surname in parentheses implies that the name was assumed sometime after birth, usually when in transition from patronymic to surname conventions. Typically, the earlier records for that individual used patronymics alone, and later ones appended the new surname.

13) Occasionally parentheses are used for other purposes as well, say, for nicknames or unusual spelling variants.

14) N.N. denotes an unknown or nonexistent given name, such as for an unnamed stillborn child or an incomplete document entry.

15) A red node denotes a speculated or “best-guess” relationship for that node, including all its child nodes, to the previous line.

16) A red detail item similarly denotes a “best guess” in the association of some detail.

17) Location data is aligned to the right of the page so as not to distract from the family structure itself. The format is described at the bottom of this page.

18) Square brackets are used for other comments, especially witness information to help clarify relationships, and is inserted to the left of the location data. Right margins are adjusted for space and readability considerations

19) Witness data: dget=doopgetuige, or witness to baptism; tget=trouwgetuige, or witness to marriage; kget=kinds-doopgetuige, or witness to a child’s baptism.

Location Data

Location data format: (<place>/<place>/<place>/…)

1) The first <place> is always the birthplace.

2) If the <principal> was married, then the second <place> is the spouse’s birthplace and the third <place> is the place of marriage.

3) The subsequent spaces are available for any place or places where the <principal> or couple may have lived.

4) The last <place> is usually the place of death or burial of the <principal>, but may be missing if unknown.

Structure of place names: <local place> <sp> <region code>. Note that <region code> is always preceded by a space (<sp>).

<region code> depends on the country:

Netherlands: 2-letter province code, e.g., GR (for Groningen province), NB (Noord-Brabant), etc.

Other countries: 1-, 2-, or 3-letter commonly-used country codes, e.g., DE (Germany), PL (Poland), A (Austria), etc.

North America: 2-letter province or state code <sp> country code, e.g., TX USA, ON CAN, etc.

The reasons behind these three structural variations are purely historical.

Space optimization of place name lists:

A missing (unknown) <place> can be indicated by a lone known region code, or by a single blank space which may be omitted entirely if it is in the last position.

If a place name is identical to any later one in the same list, it can be replaced by any recognizable two-letter abbreviation of it.

If a region code is identical to the next region code in the same list, and the place name is present, the region code can be omitted.

If a country code is identical to the next country code in the same list, the country code can be omitted.