The Genealogy Bits Rotating Header Image

Software

Sourcing on Ancestry.com

Entering information directly onto Ancestry.com is often frustrating with the occasional stab of fright. While the site does offer unprecedented access to millions of transcribed records, the way it handles that information is unpredictable and sometimes scary. For the purposes of this article, I’m not going to address the misapplication of Marriage and Marriage License dates (bugs me), Birth and Baptism dates (really bugs me), and the site’s inexplicable desire to create multiple instances of the same marriage within the same record (really, really bugs me). Today, I just want to talk about sourcing. Sources, for the uninitiated, are the blocks upon which family history projects are built. Without good, reliable, detailed, and verifiable sources, all you have is a jumble of names and dates that may or may not be true. Ancestry.com is brimming with these “junk trees”, Frankenstein-like projects cobbled together from the parts of other trees. The site makes it easy to import information from others’ trees regardless of whether they’re supported by good research. These unsourced projects are like Red Light Districts. They’re interesting to look at, but if you get too close you’re going to catch something. Which brings me back to sourcing, the cornerstone of building a vibrant, disease-free tree.

Given that the site prides itself on providing original (i.e., scanned) sources, you would think they would hold the information gleaned from those sources as inviolate. They do not. Each individual’s profile page has a “Edit this person” button. That opens a tabbed page with options for Vital Information, Facts & Events, Relationship Events, Relationships, and Notes. For the purposes of this article, I will be addressing the Name, Birth, and Death facts. There is no point in talking about Marriage facts, because you’re only allowed to have one date, place, and description for a given marriage, even if you’ve found multiple sources for that event. The problems with Name, Birth, and Death sourcing are identical. If you choose “Preferred” for one of these, not only will it overwrite your existing information, but consequently your original source will then be attributed to the updated information. Clear? No? Let me give you an example. Let’s say in an interview with your grandmother she indicated that your uncle’s name was “Joe Bob Smith”. In Ancestry, you can create a source called “Interview: Grandma Smith” and attach that source to your uncle’s name. Later, you find him listed in the Social Security Death Index, but he’s named “Joseph Robert Smith”. Thinking that you’d rather use his full name, you select “Preferred” (instead of “Alternate”) and click OK. Everything good? Not quite. If you click on “Edit this person” and then “More Options…” (to the right of the name fields) you’ll find there are no alternate names, and both the “Social Security Death Index” and “Interview: Grandma Smith” are both attributed to his full name. What did Grandma used to call him? If you don’t have it written down somewhere, it’s gone, because Ancestry assumes that “Preferred” means you don’t care about the other version. That, to me, is scary. I don’t want a research tool that erases my research. A name or date that might not seem important or correct now, might be both.

To confuse matters, if you do have a person with name variations, you can click on “More Options…” and “Make this the preferred name”. This option does not overwrite anything. For this reason, users should ALWAYS use the “Alternate” option when entering new data (e.g., Name, Birth, Death) rather than “Preferred”. It might also be helpful to create an unsourced alternate name, birth, and death fact that incorporates elements from multiple source citations. I guess that’s my take-home message. Remember to use the “Alternate” option, always. You can make it preferred later.

Tackling Census Data in TMG

I mentioned earlier that I’m experimenting with the GRAMPS family tree software. I’m still waffling on whether to make that switch. Adopting another application would be nothing short of life-changing. I have no idea how much time I’ve invested into TMG, but it could probably be measured in the 1,000s of hours. Any move to another application would almost certainly mean that some of that data would be lost. I probably wouldn’t lose names, dates, and relationships, but would probably lose a great deal of painstakingly recorded sources. So, while I weigh which way to go, I continue to enter data and learn about TMG.

Today, I experimented with recording and reporting census data. To date, I’ve been using tags for each individual, i.e., if John Stanley appeared in the 1880 census, I would give him a “Cen 1880” tag. I would also include the date and place of enumeration, dwelling and family numbers, his age, birthplace, and occupation. If he had six people in his household, each person that was enumerated with him would also get a “Cen 1880” tag. Though inelegant, I liked being able to see (at a glance) if a given individual was missing the census tag for a given year. The problem with this method is that the structure of each household is lost. This has bugged me for sometime but I didn’t know what to do about it. I have used thousands of census tags, and am not about to go back through the database and change everything. Today, I found a solution.

The first thing I did was look at how other TMG users handle census data. The program is very customizable and there’s no one right way to handle censuses. A number of published solutions (here, here, and here) suggest establishing one census tag per household and attaching all other members as witnesses to the Principal. I’ve known about this solution for years but never implemented it because I didn’t like a bunch of undifferentiated Witness tags floating around. After clicking around the Master Tag Type List, I discovered that within a given tag’s properties (Tools > Master Tag Type List > Cen 1880 > Edit) there’s an option (in the Other tab) to use the tag’s original title, rather than Witness (Display Witnessed Tags / Using the Label Above). Now, even the witnesses to the primary “Cen 1880” tag have the same apparent tag. Squee!

Attaching people to the Principal as Witnesses recreates the census households, it does not however give a sense for the household’s structure. For that, I created dozens of roles for each census tag. Within the “Cen 1880” tag, I currently have the following roles: Head, Wife, Dau01, Dau02 thru Dau10, Son01, Son02 thru Son10, and Boarder. I can add more as needed, e.g. Mother-in-Law, Grandmother. Each of these roles has a sentence associated with it. Dau02 for instance, has: “[RG:Dau02]<,  aged [WM],> appears in the 1880 Federal Census <at [L]> as the daughter of [P].” Since the roles are gender specific, there’s no need to create a Female Sentence Structure under the Tag Type Definition. When adding Dau02 as a witness, I now enter her census given age (whether it’s correct or not) in the Edit Witness / Memo field. That supplies the [WM] variable with the age required. Earlier censuses that do not list relationships include sentences like: “[RG:Enum02]<, aged [WM],> appears in the 1870 Federal Census <at [L]> in the household of [P].” Other than this, the sentences do not vary much between censuses, so I used cut-and-paste liberally when building roles.

So, why create a Head role instead of just using Principal? In my original implementation of census tags, every person that appeared in a census had a Principal role. In my new system, the Head role has the following sentence: “[P] appears as head of household in the 1880 Federal Census <on [D]> <at [L]>.” By leaving the Principal role intact, I do not have to go back through all my old census tags and adjust everyone’s role to fit the new system. The old sentences remain unchanged. When entering new families however, I can select their appropriate roles. The system requires a lot of upfront work creating roles and sentences, but I think the result is much cleaner. Anyway, that’s how I’m entering census data now. I hope this write-up helps someone! As always, feel free to e-mail me with questions and/or ridicule.

TMG vs GRAMPS

Like most contemporary family tree historians, I use genealogical software to help me with my research. Without it, I wouldn’t be able to organize the tens of thousands of data-bits that constitute my family tree. My first solution was an MS-DOS program called Brothers Keeper. That was a good solution until my database reached several hundred people. From there I moved to The Master Genealogist (TMG), and my database grew to almost 20,000 people. My current dilemma is that TMG hasn’t kept pace with my research needs. For one, it only works on Windows (I prefer the Ubuntu Linux and Mac OSes). Secondly, it doesn’t support Unicode characters, because the designers seem locked into an outdated (and unsupported) MS-FoxPro architecture. The TMG designers frown on people even mentioning the Unicode problem on their forums. While migrating is a scary proposition (e.g., what will happen to my: thousands of sources, customized tags, flags, roles, and sentences), the alternative isn’t much better, i.e., cling to an outdated system and the Microsoft OS *shudder*. I’m currently looking at GRAMPS, a cross-platform open source family tree solution that looks like a good candidate. It has a good deal of online community support. I’ve played with it some, but there’s an entry level learning curve that I’m butting my head against. Maybe I should read the manual? If anyone has any other ideas for software, drop me a line! Thanks.