This page documents how I collect, store and re-publish genealogical data from my research. This is also a discussion of my standards for proof and privacy restrictions. I am making this information public in order to make transparent to other genealogists how reliable to consider my published family trees.
I strive to for a standard of “best evidence available to me, at the time.” Everything is subject to revision if better evidence becomes available. I have made mistakes but I am willing to correct them. Without time travel, history is subject to revision based on better evidence, and often we must accept that there is no evidence, only hypotheses or speculation.
The standards listed below apply to the GEDCOM files that I might publish, and any online family trees that I maintain or collaborate on. This is a living document and is subject to change over time. Any comments are welcome.
I will use any credible sources that I find. Other researchers’ family trees, family lore and personal papers will be used as “seed material” to help build a framework of names and dates. These sources will be cited as such, and facts gathered from them will be considered unverified if they can’t be corroborated by vital records or another more reliable source. In the Internet Age, it is very easy for people to find and transcribe one researcher’s work into their own GEDCOM. Many amateur genealogists at the bottom of the spectrum will not list their sources or even record the sources found in the documents that they copy. Published genealogies that cite sources and adhere to standards similar to mine will be given more credence.
There are many online sources of records these days. The quality of those records depends on many factors which are not always documented in the online service. Is there a surrogate image of the actual record included? When and by whom were the images or transcriptions made? How reliable are the original records? Were the records transcribed or translated accurately? Is there information in the record images that is not included in the presentation layer (e.g., unindexed fields)?
When feasible, I will try to retain images of records used. I will also try to read the original records to verify the information in the presentation layer and try to verify the transcription. With online services that allow linking records, such as Ancestry, I will link the records that I use. In cases where the records contradict my existing research, or each other, I will retain alternate names, dates and places if the discrepancy is credible. Reflecting back on the quality of some sources that might be seed data, I am very likely to overwrite data obtained from a family history with data obtained from a vital record, unless there is enough ambiguity that both facts need to be retained.
I will share the results of my research freely with other genealogists, upon request, and in several publicly available sites. A list of places where my data is published is available here.
The scope of my family tree database extends well beyond persons within my primary or secondary areas of research interest. For some of my lines I include very broad family data. You might find your name, or a relative in my database only because a member of your family married into one of my principal lines. Please use the tools available (name list, tree browser) to find where you are connected. The database is constantly being updated and revised as new information is discovered.
I would request that researchers who access my data provide me with information about missing information, errors, or other data that might help my research. I would also ask that you share your data with me, within the scope of your own privacy policies.Be aware that I may need more evidence than a GEDCOM or a narrative of family lore before I include your data into my database. While my standard of proof is not “lineage society rigor” — there is far too much bad genealogy and wishful thinking out there. My goal is not to propagate more cruft.
Privacy Exceptions to Sharing Policy
- Non-public data about people who are believed to be living will not be shared publicly without their explicit permission.
- Non-public data about living persons may be shared, at my sole discretion, to family members and other researchers who agree to abide by the same privacy terms described here.
- Other data may be sanitized, at my sole discretion, for other reasons.
- A reasonable approximation of whether a person is still living will be made in lieu of a known death date. I currently use 100 years from the birth date as a cutoff.
Database Deletion Requests
- A living person, or the parent or legal guardian of a living minor, may request privacy sanitization of their data within my database. Privacy sanitization requests will be honored for ten years from the date that the request is accepted. Privacy requests for minors will be honored until their eighteenth birthday.
- Sanitized data will be moved to a completely private database that will not be shared with anyone. Data will not be purged or destroyed, and it will be restored upon expiration of the sanitization request.
- Sanitization requests will only be accepted for yourself or your children. Requests to sanitize data for ex-spouses or other family members will have to be requested by them.
- Non-living persons will not be sanitized. You have the right to have your name sanitized from the database. The deceased have no right or need for privacy.
You should not be using family data, such as your actual “mother’s maiden name,” as a security password or authenticator or a password reset reminder. Never. Make something up, write it down, give that to your bank, and treat that like any other password. The fact that most banks are run by idiots is no reason to compromise genealogy research. You can do this any time. Call your bank, tell them that you want to change your mother’s maiden name to “Johnny Appleseed with Aphasia” — they will do it.
- Any sanitization request that does not include full contact information will be ignored. Proof of identity may be requested in the case of questionable identity.
Scope of Research
Genealogical Heirs / My Genealogy Estate
Typography, Diacritical Marks and Transliterations
Umlauts are good! I will write Württemberg, not Wuerttemberg; Fränkel, not Fraenkel; Götternacht not Goetternacht, etc. When I find that umlauts have been transcribed as “ae”, “oe”, “ue” I will untranscribe them. That convention was only useful in the age of typewriters, in my opinion.
I will stick to the Roman alphabet, and transliterate or Romanize anything in other languages. I don’t even want to think about trying to convince output reports how to switch from left-to-right to right-to-left for Hebrew or Arabic. If a non-Roman spelling is absolutely necessary, it will be in parentheses.
Diacritical marks in Slavic and other languages that use them will be preserved.
Personal Names – Formatting and Retention
Names used by people are very mushy things. The further back in time you progress, the mushier they become. Some genealogy software allows nicknames and alternate names. I believe that the GEDCOM standards also support aliases. However, it is very cumbersome to create alias records for every possible name used by a person.
Family histories often record nicknames or familiar names instead of the proper name of individuals. Names change, usually informally, after emigration. In the case of the deceased, we seldom know what their preferred name was. In the case of vital records, there can be discrepancies in the records even from the same agency. Spellings also vary. People often wrote what they heard phonetically.
I will record names with my best guess of what the earliest legal name as the primary, with nicknames, alternative spellings, or changed names in parentheses. If there are ambiguious spellings of the surname, those will be parenthesized as well. For example, a man born Friedrich Wolfgang Smetters, who was known as “Rikke” by his family, and who changed his name to Fred Smith when he emigrated to the United States, will be recorded in my database and GEDCOMS as Friedrich (Fred, Rikke) Wolfgang Smetters (Smith). In my database software I will record surnames with an initial capital letter, not in all capitals. When corresponding or writing about persons in the database, I will use the convention of surnames in all capital letters, so Fred would be written out as Friedrich (Fred, Rikke, Wolfgang SMETTERS (SMITH).
Women will be recorded by their maiden names, with additional fact records added for unusual circumstances such as not using the husband’s surname after marriage or a legal name change for any reason. In written documents where the women’s married surname is relevant, the convention of placing her maiden name in all capital letters in parentheses (after all the given name and nick name variants) followed by her married name. For example, a woman born Ingrid Celeste Dreyfuss, who was known as “Letty” which was sometimes spelled “Lettie” and whose family name was sometimes spelled with only one “s” and who married Fred Smith above after he started going by Smith, would be recorded in the database as Ingrid Celeste (Letty, Lettie) Dreyfuss (Dreyfus) and when written out in the context of her married name would be Ingrid Celeste (Letty, Lettie) (DREYFUSS/DREYFUS) SMITH.
There are problems with place names in genealogy. People are often imprecise about where they lived or where an event happened. Place names changed. In Germany and other parts of Western Europe, where most of my research is focused, it’s a total nightmare. Germany was not unified into one country until 1871. There are some places in family lore that are referred to as “a place that went back and forth between Poland and Russia so often that most people said they came from both countries.” Everyone who lived in a part of the Russian Empire, or the Austro-Hungarian Empire would say that they came from “Russia” or “Austria” respectively, even if those towns are now in Ukraine, Poland, Czech Republic, Germany, Latvia, Lithuania, or Hungary.
It is beyond the scope of my research to determine unequivocally what the political enclosures of a particular town were at the time that a date was recorded. Unless the original name is historically significant, I will record the modern place name for an event. If it is historically significant, I will record the original place name with the modern name in parentheses.
In general I will use the Getty Thesaurus of Geographic Names® Online (TGN) as my guide for modern place names. The standards below are applicable to the modern place name.
Whenever possible, City/Town, County, State and “United States” separated by commas, will be my standard.
New York poses a particular problem because counties and boroughs overlap. Also many people considered any part of the five boroughs to be New York City … others considered only Manhattan to be New York City. There is some ambiguity that will never be resolved. I will use:
- New York, New York, New York, United States for Manhattan, specifically, or when the place was just listed as “New York.” Arrivals by ship or plane usually went to one of the airports, none of which are in Manhattan, will also be recorded thus.
- Bronx, Bronx, New York, United States when it is known that the residence or event was in the Bronx.
- Queens, Queens, New York, United States for Queens.
- Brooklyn, Kings, New York, United States for Brooklyn.
- Staten Island, Richmond, New York, United States for Staten Island.
I have started to run into some issues with towns in “Indian Territory” or other pre-incorporated area names recently. Again, unless it is really important to know that where they were born was Indian territory at that time, I will use the modern place name after looking it up in TGN.
I will use City/Town, Current State, “Germany” as a general rule. The state name will be in German (e.g., “Rheinland-Pfalz” not “Rheinland Palatinate”, “Bayern” not “Bavaria”, etc.). No Kreiz or Stadtkreiz information unless it is critical to disambiguate.
City/Town, State, Country will be my convention. City or town name and state name will be in the preferred form based on TGN. Country will be the English spelling. In general I will defer to TGN wherever possible.
To avoid the ambiguity created by a different standard of writing dates between Europe and the English-speaking world (MM/DD/YYYY vs. DD/MM/YYYY), I will always record dates using a three-letter abbreviation for the Month name, in English, preceeded by the day, written as a numeral, followed by the year written out as a four-digit number. When dates are encountered in other formats they will converted. If it is impossible to disambiguate whether the European or American standard was used, both dates will be presented. For example, if I come across an entry of 02/10/73 and I have no way of knowing which way it was meant to be interpreted, I will record it as 02 Oct 1873 OR 10 Feb 1873 unless the database software prevents it, in which case it will be noted separately.
I have not had to deal with dates between 1582 and 1752 that use “double dating,” but if it is necessary, I will record the double date retaining the rest of the format above. For example, February 25 1635/6, would be recorded as 25 Feb 1635/6. Ugh. Here is a description of the problem.