Don’t Key Crazy Things!


By Gillian Sicotte

Occasionally, values get keyed into fields that are descriptive in nature, rather than strictly what is shown on the image. While it is wonderful that individuals are taking the time to make educated judgments, these judgments should not be keyed into project fields. So what should and shouldn’t be keyed into a field? Follow the guidelines below for keying success!

KEY AS SEEN

The wiki page for any project you are working on will have detailed instructions for each specific field being keyed. Some of these fields will include the instruction, “Key as Seen.” This means that the values for this field should match what is on the image, including any punctuation.

The World Archives Keying Standards give further information into the “Key as Seen” instruction. It reads, “No additional characters should be introduced in keying, which do not appear on the image.” This means that even though you may want to show the reviewer (or Ancestry) why you keyed the value you did, only what actually appears on the image should be keyed.

For example: If I was keying the surname on line 11 (see below), and I didn’t know what the fifth character was, I would either take an educated guess, or using the “Illegible ” rule, key double ?? marks into the space where the character should go. If the word is entirely illegible, you should mark the field as illegible using ctrl-I or its corresponding button in the keying tool.
Untitled picture

  • Correct: “Peachmaster”
  • Incorrect: “I think that this could be ‘Peachmaster’ because the fifth letter looks like other ‘h’ characters found on the image.”
  • Also Incorrect: “I don’t know, good luck figuring this out!”

USE THE DICTIONARIES TO GUIDE YOU

One major help in determining whether or not the value you are keying into a field is valid are dictionaries. Dictionaries provide values that are expected to be seen in a specific field, based on the parameters of the project. However, dictionaries do not cover every value. Words may still be correct, and will not be shown in the dictionary. If a value is not in the dictionary, the field will turn red. This does not mean that the value you typed is incorrect, it is just saying that it is not an expected value in this field. Go back and double check that what you typed matches the images, and then click the green check button or press “F7” on the keyboard to validate the field.
Untitled picture2

ADDITIONAL HELP

The following pages can offer further explanation and examples:

Information and Links

Join the fray by commenting, tracking what others have to say, or linking to it from your blog.


Other Posts

Write a Comment

Take a moment to comment and tell us what you think. Some basic HTML is allowed for formatting.

Reader Comments

This is great! Thanks for taking the time to put this together. It is really helpful!

Now if you’d just make a blog post about being careful to choose the correct form type, rather than rushing through your image sets, that would be even more helpful. 😀

I think some people key that kind of comment because they believe it will be seen by the reviewer, who will key in the correct version, but they don’t realise that not every image set is reviewed and that sometimes those messages can go all the way through onto the finished database.

Very useful post. Something like this should be included in a ‘don’t do’ section in the Keying Standards.
I’d like to see more on how to handle keying of unclear text. One example I see often is where the text is not much clearer than you’d see on a blotter, with most words unreadable, but the keyer has spotted what looks like the name ‘Smith’ so keys it. This is despite the fact that there’s no clue from the context whether this name should be keyed or not.

Concerns the USHMM projects. I do not speak polish, Czech or Romanian, but are reviewing projects in these languages. Many mistakes would be avoided if the drop-down list could be relied uupon. Some of of the handwriting is very difficult to read and unfamiliar special characters are different for each language. It would be very helpful if the names and places in the drop-down lists contanined the special characters individual for each country and would be the preferred option on the drop down list. Maybe then more keyers would be tempted to contribute to these very rewarding projects.

I agree with Elisabeth regarding the dropdowns. We can’t expect them to be totally comprehensive, but they can be very poor. When the surnames don’t include some very common names such as Hogan and Douglas, you start to wonder.
More importantly, it appears very difficult to get common entries added or corrected. I’ve managed it a couple of times but it was like pulling teeth.

I have to agree with a couple of others re the Dropdown Lists. It would be good if we could have a message board where we could suggest additions. If something is not in there new keyers do get confused and think they are doing something wrong. For me in particular, the very common abbreviations Elizth and Fredk, often then keyed and expanded to Elizabeth and Frederick.

I am confused when typing newspaper articles. The article usually mentions a name, usually the person who had a loss or who committed the crime. There is also usually a date such as the date of the loss or when item is found. It is rare to fine a date of birth, etc.
So, do I punch anything that doesn’t have a vital record?