Yuku free message boards

I stand corrected. Maybe I should have taken German for a language instead of French.

Elsasss it is.

RJ Samp

"And if the census taker spelled the city as Washingten, it should be indexed as Washingten. If you index it as Washington, that would be an incorrect index. Indexes do NOT correct, they just organize and repeat what the source says. It is your job to make the corrections. '

My error, we simply are not communicating. This isn't my index, it's not MY job to correct the bad indexes.It's the index creators job to correct their sloppy work.

1. If the OCR or modern transcriber makes an error, then it should be corrected plain and simple. This is NOT the census taker/enumerator in your example.

So in 1880 a retired German born enumerator walks around an Irish neighborhood and writes down what he thinks he hears is Nerney/Nierney/Nerherney/McNerney/McNierney/McNierherney/Narney/ etc. (17 variations on this one last name in my family, from the actual documents).

And he writes down Narey.

I agree with you, the Ancestry.com/Genealogy.com index should be Narey.

But what if the index is NARY? Shouldn't the Ancestry.com Modern interpretation error in digital format be corrected?

2.
and what if an 'a' could be a 'u' and neither you, nor I, nor the OCR program, nor the transcriber can make hide nor hair out of what the Enumerator scribbled down on a hot windy June day in 1880 with an ink bottle and a worn nib of a pen?

Make your best guess? Who's best guess do you take? Why not make the best guess the CORRECT guess?

Why would you deliberately interpret a scrawl of a letter as a "I think it's a U" or "maybe A" when someone else know it's an definitely A?

3. Why not augment the index by offering alternative match lists, Soundex spellings, corrected spellings...still keeping intact the incorrect interpretation of the original enumerator recorded data? Simply have a second (or 10th) key that points at the same record.

This is much more than programmatically searching for Steve by Steffen, Stephen, Stevie, Steve simultaneously. (Jno, John, Johnathan), (Wilhelmine, Wilhelimina, Minnie, Minna, Mina).

But easy to do ... so you could look up Zump and hit Samp. Or type in Samp and hit Samp. Again, this is not Soundex, this an extra match key.

4. The problem with the indexes is precisely that they don't see the forest for the trees. The 1880 Census doesn't know that J Smith age 10 in 1860, is John Smith 21 in 1870, is Jno Smith 29 in 1880....or that a tombstone for him in 1893 says SMYTHE on it. And I don't have a problem with indexing what was scribbled down.

But the INDEX is not the documentation, the census itself is the documentation. The INDEX is simply a search tool for digitalized searches and speeding up data entry (cut and paste or import). I think that's where you and I aren't seeing eye to eye. The faster and more accurately I can type in known data....and then play around with the search parameters (age being a good one)..the faster I should be able to land on the correct census roll, image page, and LINE of the census. That's the purpose of the index. Not to digitalize 10 different people's (and one machine's) interpretations of the scribblings as one infallible, non-correctable, truth. Or one person's or machines best guess.

IMHO the index should be a SYSTEM for rapidly retrieving digitalized data. What ever speeds up the process and makes it more accurate has my vote. A System needs continuous inputs, outputs, and a feedback loop to grow, otherwise it dies. We provide the feedback, and improve the indexes by correcting them (or augmenting them ).

Example:
Why don't the Immigrants indexes provide a Birth Year search (Year of Arrival - Age upon arrival = approx. Birth year)? Just because the birth year wasn't recorded doesn't mean we can't augment the index of the transcribed manifest. And it makes more sense from a search standpoint.

5.
In the best of all possible worlds.....eventually the decentralized databases would be interconnected....and retrievable by data in other databases.

Example.

A shy wife in 1880 tells the friendly enumerator that she's 43 (1837), one year younger than her husband Adouard. In reality she's 47 and doesn't want Edward to know that she had a previous marriage back in Preussen.

The 1900 Census has her age as Oct 1834, 66 years old. closer, still not her Oct 11, 1833 birth.

And then her obit comes out with the correct birth date.

I'm not advocating going back and changing the index of the 1880 census. But if (and this WILL happen) a person's census records, vital records, SSDI, death certificates were linked together......then you could find the person based on ages in other years.... and an augmented bit of data could be added to her 1880 US Census that her ACTUAL birth year was 1833, not 1837.

I'll bet you could take the 1920 and 1930 Ancestry.com census indexes and run a match against the SSDI and get a TON of hits...... and even some of the 'misses' might be limited to 3 names.... Smith is a problem of course...but 80% is better than zero. And now we've got Actual Birth Dates, and Death month/year, etc. for 40% or more of the 1920 and 1930 census indexes.

That's the power of databases.

RJ Samp
Wheaton, IL