Monthly Archives: January 2011

People lie, and so do documents

It’s not uncommon to find records that have intentionally incorrect dates and other information on them. One situation in particular which is common is in passenger manifests for people coming from Europe to the US. Frequently you’ll find someone who lists their age as 17 or 18, when in fact they’re younger but lied to get on the ship to America. Sometimes the age given when coming to America was used in official documents going forward, even if they were wrong. Without a birth certificate or other documentation from the old country, you may forever think someone was older than they really were.

My point with bringing this up is that when you’re doing research it’s very hard to confirm information from a single record, or even multiple records sometimes. A good example of the issues involved is that while you can usually trust a death certificate to have accurate information on a person’s death, it may not be a good idea to trust the birth information listed on it. If the birth information on a death certificate is all you have on that person, go ahead and use that birth information, but always source it properly so you know where the information came from. If you one day track down a birth certificate on the same person and the information is different, then trust the birth certificate over the death certificate.

There are many kinds of records out there, some ‘official’ records like birth and death certificates, and some unofficial like birth announcements and obituaries in newspapers. Obituaries can be a great tool for building your family tree, as they frequently contain lists of surviving children, maiden names, etc. Nowadays many small local newspapers are being scanned and put online, some which you need to pay for and some which are free to use. I was recently searching through a free searchable database of Georgia newspapers, part of the Digital Library of Georgia. Of particular interest to Jewish researchers with family that lived in the southern states in the US, is a publication called the Southern Israelite. It contains issues of this magazine from 1929 through 1986. It started as a local newsletter in Augusta, then moved to Atlanta where it covered all of Georgia and then eventually covered other southern states as well.

In any event, records I found illustrate this point about not trusting records too much. I found an obituary printed on July 8, 1983 about Louis Lesser, who it says died about a week earlier on June 29th. It lists his age as 72.

Obituary printed July 8th

See the obituary as printed on July 8th on the left.

If one had no other records about the death of Louis Lesser, and he was in your family, you would probably enter the information in this obituary into your genealogy program. That’s a perfectly normal thing to do. Make sure of course to properly cite the death infromation as coming from this obituary and where and when the obituary was published. The interesting thing about this is that a second obituary pops up a couple of weeks later, in the July 22 issue of the same magazine. It has different information. I suppose you might assume the first one had mistakes and the second one was the corrected version. See the second obituary, published on July 22 on the right.

Obituary printed July 22nd

Now, what do you see? The age listed is 71, not 72. The date Louis Lesser died is listed is June 30, not June 29. There is also additional family information. So assuming the second version is the corrected version, you would guess Louis Lesser died on the 30th and was 71. What can we confirm here? Well, you could look up the record in the SSDI. The SSDI index doesn’t give the date, only the month, so we can’t confirm the date without ordering the full record, but it does list a birth date of Oct 5, 1910. Again, take this date with a grain of salt, it is only the date used when the person applied for a social security number, but let’s use it to see what the person’s age should be. Clearly, according to this date, he’s 72, and closer to 73 than 71. Thus the age listed is probably wrong in the second record. Not a good sign. Okay, so how can we confirm the date? Well I googled ‘south carolina death certificates’ to see if there was some searchable index and came across the Death Indexes page for South Carolina. If you scan down the list of resources, you’ll see there is a link to cemetery burials by the Jewish Historical Society of South Carolina. The site lets you browse the cemeteries, but without knowing which cemetery the person was buried in, this could take a long time. Luckily, they’ve put in a search box to let you search the whole site. Searching the site brings up a page for the Emanu-el Cemetery in Charleston, SC with his burial record. The good news is it lists the same birth date for him, so although neither the SSDI date or this record are necessarily trustworthy records, at least you now have two records showing the same birth date. For the death date, which is the date listed on his grave, it says June 29th. Nothing is 100%, but if the date is on his grave it’s probably correct. Thus it seems the original obituary had the correct information on his age and the day of his death, not the one published later. Not what you might guess from seeing two obituaries in the same paper a couple of weeks apart.

So to review, don’t trust something just because it’s in print, and while make assumptions like a later revised obituary is probably correct might make sense to you, it isn’t always the right assumption. Always try to confirm the information you find through other sources, and site the source for every piece of information in your records.

Pruning Your Family Tree

Cruft is a term used in computer programming circles to mean the useless code in a computer program that accumulate over time. Cruft is the stuff you added at one point that might have been important then, but is now irrelevant, and worse it causes the rest of your program to slow down. You might have needed, for example, to support what is now an obsolete computer platform at one point, but the code for that shouldn’t still be in your program today.

Family trees also accumulate cruft over time, and just like in computer programs those extra people and extra information can slow you down. There are a number of reasons that bad information can enter your tree, but the most common and most problematic is when you import a GEDCOM from a relative without checking first to see if everyone in the tree is actually related to you. If you get a GEDCOM file from a relative with 2000 people in it and only 200 of them are actually related to you, you’ve just added 1800 that are irrelevant to your tree. Moreover, if you upload your family tree to a site like Ancestry.com or MyHeritage.com where they can do some form of automatic matching between your tree and other trees as well as with records on the site, you’re going to get all kinds of matches for people who are not actually related to you. Following up these false leads is a big waste of time.

I recently uploaded a family tree to one of these web sites and started getting matches to people not related to me. It illustrated to me that when I imported a tree from a relative a couple of years ago I did not properly check out the tree first. When I share a tree with someone, I usually only export those people who are related to the person I’m sending the tree to, plus spouses. This insures the person doesn’t get a lot of records that are not relevant to them. When you receive a GEDCOM from someone else, you should also check it out, create a test file where you import it, add yourself to the file, and then see if everyone in the file is related to you. I obviously forgot to do this with this particular file a few years back, and ended up with about 300 extra people in my tree that I was not related to, which was what was causing these false hits in the matching program (technically they’re not false hits, okay, but from my perspective they’re just as annoying even if they are my fault).

After receiving quite enough of these messages from the web site I decided it was time to remove the incorrect records from my family tree file. While my initial guess about that GEDCOM file was correct, and it was indeed the source of most of the incorrect records, I also discovered something else interesting – that there were other people in my family tree that were not related to me, some of them that I wanted to keep. The important thing here is that while most genealogy programs will let you select all your relatives (and their spouses), it’s not so simple to select your relatives and delete everyone else. The issue of the spouses, by the way, is a simple one. If you only had the program select your actual relatives, your sibling’s spouse would not be chosen. Your sibling’s kids would be chosen, but they would be missing a parent since strictly speaking that spouse is not your blood relative. Thus you need your genealogy program to select spouses as well.

The people I found in my tree that were not related to me fell into a few categories. Most were from GEDCOM imports, with most of those from that one GEDCOM I suspected, but also a few others here and there.

Some of the people were really cruft in that they were small sections that were someone isolated from the rest of the tree. I suspect they were descendants of someone I deleted at some point. They should probably have been deleted a long time ago, but were somehow still in my tree – probably due to a bug in the genealogy program.

Then there were the parents of spouses. I sometimes like to add information on parents of spouses that I add to the tree. This is mainly so that if I want to research the spouse at some point in time, that I know a bit more about them to help me with the research. Knowing the names of a person’s parents can be very important when doing research. The problem, of course, is that if I do a standard selection of people in my tree that are not relatives or their spouses, these parents get left out – yet I still want them in the tree. The solution here is not simple. There is not an automated way to include these people. The answer is probably (and I have not done this yet) to flag those parents in some way. Some genealogy programs let you define custom flags, and then assign them to people. If you carefully check out all the non-relatives in your tree and see which ones you want to keep, you can then flag them for future reference. Each time you add non-relative parents, you can flag them. In the future if you go to prune your tree again, you can do a standard selection of relatives and spouses, and then add the flagged people. Anyone left over can then be removed from your tree.

Yad Vashem teams up with Google

In advance of Holocaust Memorial Day tomorrow, Yad Vashem has announced a new partnership with Google to digitize and put online large portions of Yad Vashem’s archival holdings. As of today, they have made over 130,000 photographs from their archives available online and searchable using Google technology. Google says they are using experimental OCR technology to make all the information on the photos searchable.

I’ve tested out the site and it is a little buggy right now. When searching from the main page you sometimes get a blank page, but if you search again from the blank page, searching works. Also, when you search and get a list of results, they don’t tell you how many photos have been found. In addition, if you choose a photo you expect the previous and next buttons to take you to the previous and next photos within your result set, but instead they take you to the previous and next photos within the entire archive, which is irrelevant to your search results. Hopefully they’ll fix these issues quickly.

You can of course search for the names of relatives using the search engine, but keep in mind that you can also search for locations like your ancestral towns. Even if none of the photos are directly relevant to your family, you might still be able to see photographs from the town your family came from, and learn about how your family lived in Europe.

[Update 1/27/2011: A Google blog entry explaining the partnership.]