World Archives Keying Standards

From Wiki
Revision as of 11:49, 20 January 2016 by Seanbmc (talk | contribs) (Non-Data Form Types)
Jump to: navigation, search

The following are keying standards and operational instructions for the Ancestry World Archives Project. Ancestry World Archives Keying Standards (AWAKS) are meant to address general instructions so the same verbiage does not need to be included in every Wiki Article. Refer to the Wiki Article for instructions first, and if the Wiki Article does not explicitly state a particular point, then refer to this AWAKS.

Be aware of the possibility that some projects require special treatment. Special treatment might mean that the Wiki Article and the AWAKS do not agree. In these scenarios, information in the Wiki Article supersedes the AWAKS for that particular project. However, do not apply project-specific instructions to other projects.

- If neither the Wiki Article nor the AWAKS address a particular point, keyers should:
- Post a question to the Discussion Page in the Wiki Article.
- Post a question to the appropriate message board.
- Email the question to

Collection Types

Ancestry works with a wide variety of historical collections. These collections can be based on record type, language and geography or year range. Collections can range from quite small to very large. Depending on the size of the collection, they can be split into multiple projects.

Some of these collections might include:


The registration of events with a civil office such as a birth, a marriage or a death. These events are generally recorded based on civil boundaries such as city, county or state.


The record of different religious events such as birth or baptism or christening, marriage banns or marriage and death or burial. These events are generally recorded based on church boundaries such as parish.


The records surrounding an immigration event of a person, whether that be traveling from one country to another or going through process of obtaining citizenship.


The records surrounding military service such as enlistment, muster, discharge or receipt of awards or recognition.


Records surrounding the probate or reading of a person’s will or the compilation of records about their estate.


Records surrounding the recording of the census either on the national or state/regional level.

Data Types

Data is organized and collected differently dependent partly on location or how it will be structured in the database


Record level data is one line of information that is specific to one person such as their name, a specific date or place or detail that is for them.

When you are keying one line of information from an image such as the census or Criminal Registers this should be entered on only one line of the form you are entering data on. Adding additional lines will appear as additional records on the index and will create an inaccurate accounting of the image.

There are collections that will have more information than can be entered on one line, for example if you are entering data from a marriage announcement and there are two sets of parent names on the image but there is only one set of Parent Name fields on the form, only one line should be entered for this record so only one set of parent names can be entered. Some of the information from the images will not be able to appear in the index.


Header level data is information that is not specific to one person or record on an image. Generally, this information is found at the top of or in the header of the image or at the beginning of a section of an image. It applies to multiple records. Often this would include page details, place information and other data of that nature.

Field Helps
How to Use Field Helps

The Field Helps are specific to each project and provide the instructions that should be followed for entering information in each field. The field helps supersede any other instructions you may read.

Each field on the form has a description of what and how the information appearing on the image should be entered in that field. The Field Helps are found in the tool on the lower left hand side. It can also be viewed on the Project Help page. Clicking on "View More About This Project" in the Help drop down menu will also bring you to the Project page. On this page you can see examples of the form types and descriptions for each field.
Required Fields
These are fields that are expected to appear on each record. They will be highlighted in pink until an entry is keyed. If this information isn't available the fields should be marked “blank”.
Non-Required Fields
We expect these fields to appear on most records, but since not all of the records have this information it would be time consuming to mark all of them blank when the information is not present. If there is a field available and there is information on the record that is applicable, this information should be collected.
Non-Keyed Fields
There is often information on the records that we do not have fields for. Although it would be nice to capture more information, the main reason we don't ask for all of the information available on a record is that we are creating an index. The information we gather is based on information that will be searchable.

Form Types

The Wiki Article is written to instruct how to index each field on a number of different form types. While many examples of different form types are identified during the Definition process, it is not expected that all form types or samples of form types will be identified at that time. If a new variation of a form type provided in the Wiki Article is found, it is expected that the best judgment will be used to extract the defined fields from this new variation.

To change a form type click on the Change button next to the name of the form type on the left side of the keying tool.

Data Form Types

Information to key, (Data) form types are images with records or headers to be keyed.

Non-Data Form Types

No information to key, (non-data) form types are images that do not fit the description of a record we are keying and should be categorized as one of the No Information to key form types.

Cover page, Section header, etc

This form type is to be used when there is useful or interesting information on the record but it is not a record we are keying.

These may be images of archival logos and headers, descriptive details for an entire publication, leading or trailing non-content images, forms or templates that do not have any content added to them, or other non-content and non-descriptive images.

Many records come in packets where the records have the same information so we are only keying one of the records; all of the other records in the packet would be classified as Cover pages.

These are images that do not fit other form type definitions.
Duplicate Image

There are times when you will key an image and then the next image is the exact same image but looks a lot better.

In this situation return to the first image and change the Form Type to "Duplicate Image."

This will prompt a pop-up message stating, "Since you indicated that this is a form type of [Duplicate Image], there are not any additional data to enter from the current image." Click Yes.

If you come across images that are duplicates but one does not appear to be a better quality image than the other, mark one as a Duplicate Image and key the information from the other. Please do not key both images.

Note: Only mark an image a Duplicate Image when they are apart of the same image set.

Image with no data
This is for images that are completely blank.
Camera calibration images. Target images are used to determine focus and color balance in the initial digitizing process.

General Standards

The General Standards are specific instances which can help one to key a specific field correctly. If there are instances that are unclear or are not covered in the Wiki Article or AWAKS, a questions should be asked.


Casing is important and should be keyed as seen. For example, “denning” should not be keyed as “Denning” and “DeAngelo” should not be keyed as “Deangelo”. Note: If the entry is in all uppercase lettering, it need not be keyed that way unless otherwise specified in the Wiki Article. In this instance, key using proper casing.


Fields should be keyed with all information that belongs together. For example, “St Martin in the Fields” would be wrong if it was keyed as only “St Martin” and “van de Kamp” would be wrong if it was keyed as “van Kamp”.

Crossed-Out Information

If information in a record has been crossed out and a correction has been written, key the correction. If no correction has been given, key as much of the crossed-out information as possible.


Ancestry provides dictionaries for specific fields to assist in accurate keying. Dictionaries are only to be used for fields specified in the Wiki Article.

When a matching value is found in the dictionary, it should be used. If a value is not found in the dictionary, key the information as seen. Do not abbreviate or expand terms, unless instructed in the Wiki Article.

Ditto Information

Ditto marks are often used to indicate that the information is the same as in the preceding record. For example, the surname may be written once for the head of house while a ditto mark is used for other family members with the same surname. Dittos may also be used for dates, locations, and other field types. In some cases, information may be dittoed from the previous image.

The most common ditto mark is the double quotes ("). Another common ditto symbol, in English records, is the abbreviation for ditto, "do".

Do not key the ditto mark (“) or the abbreviation “do.” Key the correct information from the previous entry.

In some cases, other marks are used to indicate dittoed information. Other examples of ditto usage:

- Dash or hyphen (-)
- Single quote, hash mark, or tick mark, e.g. (')
- Vertical line drawn down through a column
- Blank space, where it is apparent from the layout that the information applies to subsequent records.

Caution: These other marks might also mean that the information is not known or does not apply. The Wiki Article may include instructions for recognizing other ditto marks.

Illegible Characters - ??

If one or more characters within a particular word are illegible, key all of the characters that are legible. Use double question marks (??) to represent the missing character or characters. If a word is entirely illegible, key two question marks (??).

“Key as Seen”

The instruction “key as seen” means that the following elements should be preserved:

- Apostrophes and hyphens
- Casing
- Completeness
- Commas
- Diacritics
- Periods
- Spacing

No additional characters should be introduced in keying, which do not appear on the image.


Apostrophes (‘) are important and should be keyed if they clearly appear on the image. For example “Coeur d’Alene” “St John’s Wood”

Apostrophes should not be added in keying when not present on the image.
Commas are important and should be keyed as seen when they are clearly present on the image. Commas should not be added in keying if they are not present on the image. For example, “St Thomas, Warwick” should be keyed as “St Thomas, Warwick” but “St Thomas Warwick” would be keyed as “St Thomas Warwick”.

Hyphens (-) are important and should be keyed if they clearly appear on the image. For example “Wilkes-Barre” and “Winston-Salem”

Hyphens should not be added in keying when not present on the image.
Periods may be keyed as seen. For example, “St. Paul” should be keyed as “St. Paul”. Periods should never be added in keying when they are not present on the image.
Record Sequence

Key records in the sequence that they are found on the image.

If the image contains multiple columns, with unique records side by side, these records are generally to be keyed by column, top to bottom, starting with the left-most column first.


Spacing is important and should be keyed as seen. For example, “MacDonald” would be marked wrong if it was keyed as “Mac Donald” and “van Buren” would be marked wrong if it was keyed as “vanBuren”

Special Characters/Diacritics

Characters with diacritical marks, such as the German umlaut a (ä) or the Spanish tilde n (ñ), are to be keyed with the correct diacritic. Do not key the letter without the diacritic. Do not use punctuation or other marks to substitute for the correct diacritic. This rule applies to all fields.

To enter international characters, click the International characters icon located in the menu bar just above the form where data is entered. Once the International Characters window appears, click the character that you wish to enter, then select the Insert button.

Duplicate Entries (Same name listed multiple times)

If the same exact name is listed multiple times on a record generally you will only key the name once. The exception to this is if the name is a secondary name and is listed in reference to a different person. An example of this is keying the parents' names for each sibling listed in the London School Admissions. (In these cases F3 comes in handy to copy the information from the field above.)

Multiple Spouses

If there is an individual with multiple spouses but there is only one set of spouse name fields follow the instructions in the field help or Project Instructions on which to enter. If you do not find specific instructions enter the most recent spouse in the spouse name fields.

Abbreviated Names

When working with names, you should always key them exactly as you see them. For example, if Wm is written on the image, key Wm. It would not be appropriate to assume it is an abbreviation and enter William. If there are abbreviated names with an apostrophe, for example Sam'l, key them as seen on the record.

Pull information from one image to key on another

Unless specifically stated otherwise in the project instructions, information should not be pulled from one image to key on another.

Field-Specific Standards

Field-Specific Standards are specific instances when the CI is not clear as to how to key a specific field. Field-Specific instances generally cover names, dates, gender and numbers. If there are instances that are unclear or are not covered in the Wiki Article or AWAKS, post a question to the appropriate message board or email the question to

Keying Age

The age captured will be the age of the person at the time of the main event. Age is generally captured in the form of a numeral.

- Valid ages include numeric digits between "0" and "120" or certain acceptable fractions for ages displayed in months only.
- If an age includes years, months, and/or days key only the years. For example, “10 years, 7 months” would be keyed as “10".
- If an age includes both a year and a fraction, key only the year. For example, “3 3/12” would be keyed as "3".
- If an age appears only in months, key age as a fraction. For example, “7 Months” would be keyed as “7/12” and “18 Months” would be keyed as "18/12".
- If an age is expressed in weeks, days, or hours, “0” (zero) should be keyed as the age. For example, “3 weeks” would be keyed as “0” and “8 weeks” would be keyed as “0”.
- If the entry states, “Minor” leave the Age field empty.
- If the record states that the individual is "in their 24th year" you would enter their age as 23. (Since they have not yet had their 24th birthday.)
Keying Date

Days will, in most cases, be a numeral between 1 and 31. There are times when the day will not have been recorded.

Whether a day is spelled out or in numerical form, it should be captured in its corresponding numerical form. For example, “Fifth” or “5th” or “05” or “5” would be keyed as “5”

In the U.S.A. dates are recorded in mm/dd/yyyy format while in the UK, and many other countries, the date is recorded in dd/mm/yyyy format.

A dictionary will generally be provided for a month field.

When a calendar month is spelled out, it should be captured from the dictionary using the abbreviation provided. For example, The English month “November” would be keyed as “Nov” and the French month “Février” would be captured as “Févr”.

If the month and corresponding abbreviation are unclear, key the month value as seen.

Years are generally 4 digits but can occasionally be 2 digits. There are also times when the year will be written out rather than in numerical form. This will particularly be more common in older records and records in different languages.

Whether a year is spelled out or in numerical form, it should be captured in its corresponding numerical form. For example, “Eighteen hundred and thirty-two” would be keyed as “1832.”

If only two digits of a year are present on the image, then only those digits should be keyed unless the field help instructs otherwise.

If there is a year range, and the year field help does not specify how to key the range, such as 1932-1933 key the first year in the date range. Follow the field help for each project to determine how the year should be keyed.

If there is a death date and an age on the record should we record the birth year? No, we do not calculate dates - only use the dates present on the records.
Roman Numerals
When dates are represented by both Roman numerals and the Arabic or spelled-out numeral transliteration, the Roman numerals should be ignored. When Roman numerals are present in the absence of any Arabic or spelled-out numeral transliteration, key them as seen within the month, day, or year field they are meant to represent.
Keying Gender

Gender will record whether a record is male or female and is sometimes recorded in a specific column or by using a keyword. It can also be captured by inference based on keywords that are language specific. The values will frequently be outlined in a provided dictionary and can also be captured using abbreviations, depending on the situation.

If the image states that the wife is Male should I correct this? - No, the data should be entered how it appears on the image.

Keying Names

Names consist of several different parts, which can include a prefix, a given name, a surname and a suffix. The most important parts are the given name and the surname. There are times when a person will have more than one given name or will have middle names. These can be recorded as initials as well. All of these parts are important to the name.

There can be different persons on an image that can relate to a record, such as the main or “self” person, a spouse, a mother, a father or a child.

Alias or Maiden Name

There are times when there can be more than one version of a name that has been recorded. Occasionally this can be an alternate spelling of the given name or surname. If an alias field has not been included in a project and alias names are found, the name should be ignored.

Typically aliases are found in parentheses but you may also see AKA to highlight an alias. For example, the name John (Johann) Smith (Schmitt) would be entered with John in the Given Name field, Smith in the Surname field and Johann in the Alias Given name field and Schmitt in the Alias Surname field.

If you can determine that the record contains a maiden name please key both the maiden and married surnames when an Alias Surname field is present.

For example if the name is listed as Brenda Jones, nee Smith, enter Jones in the Surname field and Smith in the Alias Surname field.

Many records will have a maiden name column which will make it easy to determine what the maiden name is.

If you are keying records that do not spell out what the maiden names are, look for determinants such as nee, and fly (an abbreviation for formerly).

If there is not an Alias Surname field, key only the maiden name in the Surname field and the married surname in the Spouse Surname field if present.

If the alias name applies to only the surname, then only key the alias into the Alias Surname field and leave the Alias Given Name field blank and vice versa.

If there is more than one alias listed on the image and there is only one alias name field, you should only enter the first alias found on the record. The additional aliases should not be entered.

Additional lines should not be used for alias names.
Given and Middle Name

The given name is the first name or names of the person.

Middle names should be keyed as part of the Given Name field. For example, if the first name appears as “Alex” and the middle name is “Theodore”, key “Alex Theodore” into the Given Name field.

If there are multiple initials, separate the initials. The initials may be separated with periods, if periods are found on the image. The initials should otherwise be separated with a space. For example, “K.B. Ellsworth” should be keyed as "K.B. Ellsworth" and “KB Ellsworth” should be keyed as “K B Ellsworth”.

When Given Name is missing: If there is no given name and there is a word or phrase that describes the person in the field, such as “infant son”, “stillborn” “daughter of John Brown” or “traveler found by the road”, that entire value should be keyed as seen into the Given Name field.

Where there is no Given Name mentioned, Given Name may be left blank.
Hyphens or Apostrophes in Names

Hyphens or apostrophes that are a part of a name should be keyed. For example, “Pérez-Quiñones” or “O’Neill”.

There are some names that appear to include an apostrophe which is really a superscript "c". Instead of keying M'Cracken you would key it as McCracken.
Military Ranks
Ranks are only keyed in the Prefix field if that instruction is given in the field help. Generally we will include a separate field for keying the rank if we would like it keyed.
Prefix and Suffix

Prefixes are values that precede the given name. If there is no prefix field provided, the following common prefixes may be keyed into the given name field, prior to the name: “Mr” “Mrs”

Suffixes are values that follow the surname, such as “Junior” or “Senior”. If there is no suffix field provided, the following common suffixes may be keyed into the surname field, following the surname: “Junior” “Jr” “Senior” “Sr”
- 'Randolph, Jack, Baron of Friedmar' should be keyed with 'Jack' in the Given Name field, 'Randolf' in the Surname field and 'Baron of Friedmar' in the suffix field.
- 'Rev John Smith, Jr' should be keyed with 'Rev' in the Prefix field, 'John' in the Given Name field, 'Smith' in the Surname field, and 'Jr' in the Suffix field.
- 'William Bradley, Esq' should be keyed with 'William' in the Given Name field, 'Bradley' in the Surname field and 'Esq' in the Suffix field.
- Entries such as Esq, MD, JP, Sr, and III should be keyed.
Keying Titles
- 'Prince Charles' should be keyed with 'Prince' in the Prefix field and 'Charles' in the Given Name field.
- 'Charles Windsor, Prince of Wales' should be keyed with 'Charles' in the Given Name field, 'Windsor' in the Surname field and 'Prince of Wales' as the Suffix.
- 'Prince of Wales' should be keyed with 'Prince of Wales' in the Given Name field.
- 'Lady Stewart of Tullybody' should be keyed with 'Lady Stewart of Tullybody' in the Given Name field.
- 'Duke of Atholl (Sir John William Menses, Bart)' should be keyed with 'Sir' in the Prefix field, 'John William' in the Given Name field, 'Menses' in the Surname field and 'Duke of Atholl' in the Suffix field.
- 'Sir Robert Menzies of Castle Menzies' should be keyed with 'Sir' in the Prefix field, 'Robert' in the Given Name field, 'Menzies' in the Surname field and 'Castle Menzies' should not be keyed as it is not a part of the name.
Mr. and Mrs.
'Mr and Mrs Christopher Anderson' should be keyed as follows:
- Prefix: Mr
- Given Name: Christopher
- Surname: Anderson
- Spouse Prefix: Mrs
- Spouse Given Name: empty
- Spouse Surname: Anderson
Note: Many projects will not have a Spouse Prefix field
'Mr John Chen and Mrs Chen' should be keyed as follows:
- Prefix: Mr
- Given Name: John
- Surname: Chen
next record
- Prefix: Mrs
- Given Name: empty
- Surname: Chen
The surname is the last name of the person. Depending on the type of record, the surname will be listed differently whether that is prominently at the beginning of the record, following the given name, somewhere in a paragraph or perhaps derived from a different person that is related to that record.
Keying Place Names

Places are the location where an event took place and can be comprised of multiple different levels (such as country, state and city). How these places appear will vary based on the record. Places can frequently be found on a very individual level but can also be found in the header of the image.

Place names should always be keyed as seen, unless the CI directs otherwise. When keying place names, all unique characters should also be preserved as they appear on the image, including less common forms of punctuation, like a colon ( : ), semi-colon ( ; ), slash ( / ), etc.

Q: If the image has an incomplete location and I know the county/state/province should I enter it?
A: No, we do not want to infer information that is not found on the records we are keying.
Q: If the cards states American but the Field Help asks for the Birth country should I key in U.S.A.?
A: No, you should enter what is on the image.
Q: If the country no longer exists should I enter the current name of the country?
A: No, you should key what is entered on the image. If the image states Prussia, Prussia is what should be entered not Germany.
Q: If I know that the location is misspelled can I correct it?
A: Unless the Field Help states otherwise, the location name should not be corrected but should be entered as it appears on the image. If the record states Jougoslavia you should key Jougoslavia.
Q: If there is a city and a country given on the record but the project only contains a general location or residence field, how should I enter it?
A: Enter it as seen on the record.
Q: If the record says Jackson County should I enter County?
A: Yes, unless it is a County field it should be entered as seen on the record.