index the 4 digit year instead of just 2 digits
Please ask indexers to write all 4 digits for the birth year, or any other year that they are extracting. When only the last two digits are extracted, then the Source Linker will incorrectly show the birth year as 100, or somethings, 200 years after the correct date. Such as : a extracted birth year is "87", it will show in the Source Linker as "1987" when the correct date is "1887" on a 1930 census record. Or a date might show up as "2028". Same problem; the date is after the actually vital record and incorrect for the birth year of the person it is for.
Even if only the last two digits of the birth year are actually written on the record being indexed, somewhere on the document is the year of the record. Obviously if the record is a 1930 census, the birth year is not 1987 because that would be in the future, and not 1787 either because the person would not still be alive in 1930. The birth year is 1887. Please index it as such.
It is problematic in many way when the wrong year shows up; Research hints could be rejected because, at first glance, the years don't match. I've seen census records that weren't attached to everyone in the record because it seems that the names might be different people. It takes a bit of sorting out to see to see the matches. It adds time to the process and someone, myself included, may miss a piece of important information because of it.
Comments
-
This is an example of where common sense should override the general instruction to record everything exactly as it appears in the original.
I have encountered some nonsense dates during my searches of indexed records. These have almost certainly appeared due to an incomplete date being indexed and leave one clueless as to what the original date of the event should be.
FamilySearch personnel usually respond to posts like this by saying indexed records are only a guide, so the original record should always be consulted. True, to some extent, but in many cases the original images are just not available, so the indexed date is proving to be useless.
1 -
That is a very common sense comment especially for any dates recorded in 1818, 1919, or 2020. Because how would we know if was the year or the century. Is it say something 18 or 18 something? In this century it might not be so much of a problem but for previous centuries it could be.
0 -
For some projects it is not possible to record the four digit years since the project may span many centuries. We have to follow the project instructions and the field helps when we index.
Our General Indexing Guideline for Indexing the Year: If only a 2-digit number was recorded, you can sometimes determine the first 2 digits of the 4-digit year from other information, such as the project dates or other contextual information on the image. If you cannot determine the 4-digit year, index the 2-digit number.
0 -
I wonder if you have seen the results of what happens when these indexed records finally make it to a published historical records collection? I have found that not indexing a date in full proves completely useless when trying to establish the actual year. It's not even that it appears as "20", so you might guess whether it's meant to be 1820 or 1920 - the format is just nonsensical. If those who wrote the project instructions were to check the results of their insisting everything should be recorded "exactly as written" they would find the uselessness of what a computer program then determines how that reads in the final product.
0 -
Of course I have seen the results of these indexed records. Why would I be indexing if I was not interested in family research? I index to pay it forward for the records I have received and to give others the opportunity to find their ancestors.
I'm not here to debate the usefulness of the data, or the way the project instructions are written. My only reason for posting was to share why indexers may not be posting 4 digit years. Our task as indexers and reviewers is to provide an exact index of what is written on the record, not to make assumptions or perform calculations. It is up to the researchers to review the hints, check the images, and make their own assessments.
0 -
I am sorry if I caused offence, Melissa. My remarks were not meant to be of a personal nature, but I just cannot agree with the idea that appears to be FamilySearch's set rule - that records should be indexed exactly how they are recorded in the record. This especially should not apply if this is going to lead to confusion, and possibly errors, when researchers try to make sense of the results.
The example I illustrate below is not the best, but the only one I could find today. As you can see, the birthdate has been transferred as "April 0002", but I know from experience this does not necessarily mean the date of birth was 2 April 1826. I have found that when a computer program reads incomplete dates it often assigns a random figure that does not always bear any relationship to the date that has been indexed.
I have previously suggested there should be no hard and fast rules that lead to the loss of accurate information if the project instructions are so strictly applied. Many users have agreed with this (at posts on the old GetSat forum). Surely common sense and accuracy should be paramount in relation to users being able to accurately determine what was shown in the original document?
Again, sorry for any upset caused, but this "rule" really does not help in establishing the recorded facts, in many instances.
0 -
It seems to me that an Indexer could determine what the 4-digit year should be by the year on the document they are indexing. For example, if they are indexing a 1890 census, someone's birth year is going to be before that. It certainly isn't going to be "20.." Yet that's what will should up on the Source Linker if the first 2 digits aren't put into the index form. It seems like a simple request to please put in all four digits of the year.
0 -
I understand your concerns, but, if indexers and reviewers do not follow the established set of rules and instructions, then there is chaos. These records would go through many reviews and it would take forever to get anything published. We all have to sing from the same song sheet to establish good order.
If the indexer can determine the 4 digit year, then they are asked to index the year. For instance, if someone is indexing Civil War records and the birthdate is 1/26/43, then they would index 1843. But, if they are indexing a project that spans 400 years worth of records, then 1/26/43 is not going to have a 4 digit year, unless there is other information on the document that suggests the century.
I'm not too sure there were any birth years indexed from the 1890 census since there wasn't a birth year question. The years were estimated by computer based on ages. This example sounds like it is more a problem with the source linker than an indexer.
It really isn't a simple as it seems. As an example, I will share the Field Help instruction from a county marriage project that spans 1806-1969. In this project there would not be a two digit year indexed, the year field would be rendered blank if the 4 digit year could not be determined. This is happening on more and more projects! So, that will solve the problem of indexers not including a four digit year.
Marriage Year:
If only a two-digit number was recorded, you can sometimes determine the first two digits of the four-digit year from other information on the document, such as the project dates or other contextual information on the image. Sometimes adjacent images give the missing information or additional context.
If a marriage date was not indicated, type the date based on the following priority:
- License date
- Latest banns date
- Consent date
- Recording date
- Any date other than a birth date
If an image shows a list of records that continue from a previous page, you may find the year of the records indicated on the previous page.
If no date other than a birth date was recorded or if you cannot determine the four-digit year, press Ctrl+B to mark this field blank.
I hope that helps to explain how indexers strive to get the information as perfect as possible and why we are bound to rules created by the owners of the records and developers of the projects.
0 -
Melissa S Himes Thank you.
0
