Idiosyncrasies in This Family History

Case-sensitivity makes a difference here. Direct blood lines have their last names in all uppercase letters. That means the ancestors and their siblings. Ancestors additionally have their first and middle names in all uppercase letters.

First Names Missing. This often happens in sources that fail to reveal the first name of a spouse or child. In those cases, the convention in this database is to use, as their first name, '{_?_}' for ancestors and '?' for non-ancestors.
One note about the use of the braces: with the newer workflow for adding sources, a special format was created for the Caption of each source. One thing adopted is using {...} for the Name prefix/title such as "Rev." and "Mrs." and "Captain". They are formatted as {Rev.} and {Mrs.} to distinguish them from First Names. However, that process WILL consider {_?_} as a First Name since it is unique from text letters.

In the legacy system (i.e. pre-2026), a flag had a value or 1 or higher. The value was a count of how many places the ancestor appears on the family tree. Since second or fourth cousins marry, or, two brothers marry two sisters, their ancestors appear on the family tree in multiple places. With the new system in 2026, this value was only set to "1".

For people born as a Twin or Triplet (or more!), they have a special flag called 'Multi-Birth'. Normally that value is null but for these people it would be a value '2' for twins, '3' for triplets, and so on.

Sources are assigned at two main levels: Person and Events for a Person. When a list of all events is gathered for a person, both of these levels are blended as one list. Events get a source when the source validates the values within the event, particularly the Date and Place. This goes towards the goal of showing to other researchers WHY event values are set in the database tables.

In pre-2000, before the first time this system was put onto a website, books were self-published (and a copy given to over 100 libraries in many towns where the ancestors live). To keep each book smaller, and, when sending copies to cousins, family groups were "created". They are basically at my great great grandparent level: Wilson (W), Deaton (D), Searls (S), Moore (M), Douglass (O) and Miller (I). Their one-letter code is in the parenthesis following the family group names. That grouping was also used as the prefix for the photographs and source document images in the legacy system (e.g. W__0123 or O__1234).

A family line is one straight-back lineage through all the fathers and their single surnames. That is broken only by the females that married into the family lines, then, the fathers of these females (who became ancestral mothers) are new "allied" family lines. Each family line generally belongs to one family group. However, because of the cousins-marrying-cousins that puts people into the family tree more than once, some family lines can belong to more than one family group. Family Line IDs are assigned a six-character code. Usually it is the first six letters of the family line surname. However, some surnames appear more than once: SMITH, JONES, WILSON, GREEN, MILLER, DOUGLASS, etc. When that occurs, the sixth (or last if the surname is short) character is changed to a sequential digit. Thus, MILLE1, MILLE2, MILLE3, WILSO1, WILSO2. Exception: THE main WILSON line kept its Family Line ID as "WILSON".

Some family lines deserve special attention when it comes to meeting my main genealogical goals (as outlined in the Help Menu of 'Getting Started'). They are defined in one of three ways:
-- BIG-8 - meaning, I want to thoroughly document the 254 ancestors that make up the first eight generations, including myself
-- TOUGHIE - meaning, finding the appropriate documents to validate the ancestors for some family lines has thus far proved to be quite a challenge, thus, they are the 'Toughies'
-- BOTH - meaning, some family lines are both BIG-8 and TOUGHIE.As of May 2026, those family lines are: WILSON, CAREY, MELVIN, MEREDITH, SPENCER, MAYS, HALSTEAD and JAMESON.

Formatting of Dates is often shown in a variety of ways. Generally they contain the month and day of month and the years. However, dates on Events are often not exact dates. Thus, a level of Certainty is given. Generally, Events after 1750 are expected to have a full MM-DD-YYYY date and dates prior to 1750 are expected to have at least the month, i.e. MM-YYYY. The various Certainty flags used here are (the three-character codes match what is used by the GEDCOM standard, the single-character code is for display purposes):

-- EXACT - full date known, usually denoted by the absence of all of the below Certainty values
-- EST - Estimated - ? - basically, an educated guess based on other events including in the generations before the person.
-- ABT - About - c (for circa) - a date that should be really close to reality, based on other events for and around the person. Example: a person died on May 10, then the burial normally happens within days, thus, burial was "about May 14".
-- BEF - Before - a (of ante) - a date that represents the highest date. Example is when had a baptism date but not birth date, obviously the person was born before baptized.
-- AFT - After - p (post, such as postgraduate) - a date that represents the earliest date. Example: a mother's death date would be post to the date of her youngest child.
-- BET - Between - ~ - a date range such as if a person wrote his will on July 12 and the will's probate began on July 30, then the death date was any date between July 12 and July 30. Additionally, a year range could be given such as living in a certain town from, say, 1750 to 1780 would be 1750-1780. For the newer process of entering Source Captions and the use of the specialized formatting of the Caption text, the expected format of a range of dates is: BET YYYY AND YYYY, or, mmm.dd,YYYY AND mmm.dd,YYYY.
-- CAL - Calculated - = - a date calculated from another date. Example: a death certificate says someone died on April 20, 1765 at age 71 years and 5 months and 6 days. Then subtracting those years-months-days from APril 20, 1765 would calculate a birth date of November 14, 1693.

Place names are usually made up of their different levels which varies by country. Example: Town, County, State, Country. To ensure valid place names are used, a large set of existing places was created. Originally it was a spreadsheet and in 2026 became a set of database tables. The purpose is to validate that a town is actually in the county and that the county is actually in the state. Thus, Kansas City, Monroe county Missouri is invalid because Kansas City (on the Missouri side) is only in the counties of Jackson, Clay and Platte. Gladstone, Clay, Missouri is valid whereas Gladstone, Platte, Missouri is invalid. Of course, over the centuries the boundaries of towns and counties and states have changed. The current dataset for places puts the towns and counties into where they are in 2026. Thus, if an old record from, say, 1710 is found and it says the town was in county ABC at that time, but, today, the town is in county XYZ, that means that county XYZ split off from county XYZ at some point after 1710 (in this example). There is a database table (called "county") that has when each county was formed and from which counties it split off from to form the "new" county.
Note that in the new process for adding Source Captions, places are entered in the format (with semi-colon dividers) of: site; town; county; state; country. When rendered for human readability, that is translated to: Site Name (e.g. Cemetery), Anytown, XYZ county, state-Name, country-Name. Commas were avoided to avoid issues with CSV (comma-separated values) which is often used in tools such as Excel.
The Legacy system, started in 1985-ish, used a place name format of xSSCCCCCTTTTTTT where "x" was the Certainty flag of either "?" or nothing. SS was the two-character abbreviation for U.S. states and for foreign countries. CCCCC was the abbreviation/code for counties or Canadian provinces. TTTTTTT was the abbreviation/code for towns and cities. A separate file (called GenPlace.dat) had each of these three abbreviations/codes separately to translate into the full name. Thus, MASUFFOBOSTON translated to Boston, Suffolk county, Massachusetts. MOKACKSKANSASC translated to Kansas City, Jackson county, Missouri. This scheme was to save storage space which was more of a premium in the 1980's.

Many (maybe most) genealogy systems have a single marriage event and both spouses point to it. This system is a bit different (thanks to my old system started in the 1980's). Each spouse has his or her own Event ID for the marriage (i.e. duplication of the Date, Place, Site, officiator of the ceremony). The way the couple are tied together is via a relationship table that has either spouse-spouse or parent-child. The groom's ID and the parent's IDs are always given first, the bride's ID and child's ID are always given second.

This was started around 1985 and has evolved since then. It is a way to define what type of information is being conveyed by a source document or image. Examples: Birth, Marriage, Jobs, Military service, Land transactions, Taxes assessed, etc. Every Event generally have: a Type, a Date (with a certainty level), and a Place (with a certainty level). Then, one or more Persons "play a Role in each Event. Someone was the "newborn" in a Birth Event. Three people were the "Groom" and "Bride" and "Authority-to-Marry Person" in a Marriage Event. And so on. Truly, if every genealogy system started with the Event as per a Source Document, instead of the Person level, then the genealogy data errors would probably be 10% or less of how many genealogy errors that exist today. I determined the Source and Event level were the proper way to start based on my software developer background. Ideally, if every bit of genealogical data (up to a certain year) was all put into one place, and arranged by Events, then "People" would be created from those Source-Events by tying together "this birth record" and "this school record" and "this marriage record" and "this land/house purchase record" and "this census record" and "that census record" and "this employment record" and "this will written" and "this death record" and "this burial record" all belong to the same one person. Then other researchers can come along and say "and this XYZ record" is also for that person. Relationships between people are only by one of two ways: birth of a child, and, marriage.
For a full list of ALL event types, see the separate Help Menu of 'Understanding Events'.

This was started around 1985 and has evolved since then. It was a way to group source documents, especially the images, by their similar types.

Starting in 1980, all source documents (then they were physical books or copies of book pages or letters from family members). Each was assigned an ID which basically was: six character family line ID, the letter that represented the generation number of the ancestors ("U" was assigned to my generation, "T" assigned to the parent's generation, "S" to the grandparent's generation, etc. The eighth character of the source ID was the birth order number of the father of the person most tied to a source document. The ninth character was the birth order number of the person most tied to a source document. The tenth character was a code representing the type of source document. Examples: B=Book, O=Obituary, L=Letter, Q=Self-knowledge, B=Birth, M=Marriage, D=Death, N=Newspaper article, etc. This scheme fell out of use one the number of source documents reached a certain point, it was replaced by Image IDs.

When I learned (decades too late after starting this in 1980) to keep actual computer images of the source documents, the images were assigned a seven-character code. The first three characters were the family groups that the main person was in (and if all three did not apply then the third, and generally the second character too were replaced by the underscore (_) character). Then a sequential four-digit number was applied. With the new system, the change was made so that the Image IDs were eight characters long. The first three are "IMG" and the remaining five characters are a five-digit sequential number. Example: IMG00358.

The URLs that point to specific webpages can also be a source of information about people and families. But URLs can either be changed, or even dropped, over time. Thus, except for the major websites, the information on a given webpage (aka. its URL) should probably be turned into a screenshot image so as to preserve the information initially found there.

In an attempt to avoid having many genealogical and system values hardcoded across multiple code files, the database table 'helpers' was created. It holds specific values that code files can access via the helpers table names and that provides the otherwise hardcoded values.
Examples include things such as Event Names, First Name placeholders when a First Name of a Person is unknown, etc.

The ability to modify/delete existing database table values or add new values is reserved for those users who have an admin login. Once in, they can:
-- Person Add - Add a New Person, with a Source, to the database tables
-- Person Edit - Modify an existing Person, usually with Sources, in the database tables
-- Person Merge - Merge two existing People in the database tables -- this usually is needed when a Person was a non-ancestor and is later discovered to be an ancestor
-- Person Delete - Delete an existing Person from the database tables -- rare, but does happen
-- Research Entry - aka. Queue-Flow, it starts with an existing Person as 'The Anchor', the relatives of that Anchor Person are added, including their major Events. Sources should be included.
-- Sources - Modify an existing Source, or, add a new Source. There are some various selections that narrow some specifics about the new Source which determines how the new Source will be formatted in its Caption. The Caption is a very specific way of entering textual formatted data (click 'Tag reference' to see the file /family/admin/pages/caption_tag_reference.php which defines the formatting). When a Caption is later rendered with the Source Image, the Caption is converted to a more human-readable format.
         Once a Caption is entered, the SAVE button takes it to the Source Followup which allows the user the chance to specify HOW each Caption item gets applied to the database tables.