If a person died in their 23rd year do we index the age as 22?
If a person died in their 23rd year do we index the age as 22?
Best Answers
-
Please share your batch title and code so we can give you more project-specific help. Generally, we index exactly what is written on the original record - we cannot assume or calculate ages 😎
1 -
As @maryellenstevensbarnes1 indicated, we index the 23, even if the person might not have reached that age depending on the interpretation of "in their 23rd year."
2
Answers
-
Thank you.
0 -
You’re welcome.
0 -
I have received direct advice that, in Chinese, the nearest translation to "in their 23rd year" would mean they have already reached that age.
However, in English, I have never been aware of any other interpretation of the expression that hasn't meant that the individual is still short of attaining the age in question. Put another way, "..in their 23rd year" would always mean them being 22 at the time of the event - their death, in this example.
I find your advice particularly worrying because I was only able to confirm the identity of a relative (born in the 18th century) by knowing his death was "x-1" years from his birth, rather than being the "x" you suggest should be indexed ("x" equalling 23 in this example).
Perhaps the interpretation is open to discussion, according the the accepted meaning in American English, but I assure you that in the U.K. this term has no ambiguity about it, so I feel your advice would be totally incorrect if the record in question applied to an event that took place in England.
The example of an event that took place in the 2nd year of a king's reign acts as a good example. The 1st year of his reign would mean from when he ascended the throne until he had been king for exactly one year, so the 2nd year would mean from the end of the 2nd year to the start of the 3rd year. This would apply, of course, until (say) the 23rd year of his reign, which would represent the period from the start of the 22nd year until the beginning of the 23rd year of such. It's a case of completing the whole year before one can be said to have reached it.
I know indexing instructions are usually to record a date / age exactly as it is written, but this does not say / imply the individual was 23, so (if an aged "22" suggestion is to be ignored) I believe the age should be left blank.
(There was a similar discussion here in Community a month or so back on how to record the "last day of February" from a record. My argument / suggestion was that - as the year in question was not a leap year - the date could have been nothing else but the 28th February: no "ifs-or-buts" - pure historical fact. However, "project instructions" appear to overrule any logical argument when it comes to such an issue and the consensus amongst indexers was that (beyond recording the month as February) the full date should be left blank. Sorry, but I find this sort of stance to be quite perverse in such circumstances.)
2 -
@Paul W, which is why we need an indexer/reviewer to share the batch title and code so we can give you more project-specific help. Generally, we index exactly what is written on the original record - when indexing, we cannot and do not assume or calculate ages, rather we record what is written & leave interpretations to the researcher/reader .
0 -
In the UK, the General Record Office found itself in a real mess when indexers recorded what was written. There apparently being no specific instructions provided on the issue, they only had an option to index exactly what they saw. The result? They recorded "5", "7" or "11" (say) whether the age of death was shown in months or years! A huge amount of records had to be reindexed (showing "0" if the age of death was under 12 months). FamilySearch's indexing methods would not be able to cope with a situation like this - because none of these records would show the actual age as "0" of course. Common sense (based on fact) must play a part in this process, as I have illustrated above. If you know the person was 22, or the date 28 February, there is no speculation involved, so it is plain crazy to add incorrect detail (like suggesting the person was 23, when he was 22) or omitting a date when you know what is was (as in the 28 February example).
If I may add a final example of bad indexing practice, to illustrate how counterproductive this can make the whole exercise. FamilySearch has indexed thousands of English marriage licence records, which show the age of the individuals as "Upwards of 21" on the original documents as...you've guessed it: "21". So Family Tree users have then carried this detail across in the source linking process, so it appears all the individuals were born 21 years before the marriage licence was issued. That is why many researchers have found the birth year to be perhaps 20 years adrift if an individual was, say, 41 years old when they married. "Upwards of 21" should mean the field is left blank, as in very few cases does it mean they were actually 21 years of age. An indexed record should surely be a finding aid, not present an obstacle in finding the birth / baptism of a person whose age has been recorded in this way. Because of incorrect indexing, my own ancestor, James Wrightson, was shown in Family Tree as being born in 1780, instead of 1772. Okay, so that was not too bad - but what if he had been a "John Smith", who married when he was 60 years old? James was also shown as being married at "York" (where the licence was issued) instead of the place where the ceremony really took place (Eston), which is some 52 miles north of that city.
From my use of other websites, this practice (of recording, say, a number (age) - or irrelevant place - shown in the original record) appears to be unique to FamilySearch, and only hinders researchers from finding the true facts about their relatives.
2 -
You make some good points.
I was giving the advice that I was given years ago in the same context (e.g., indexing 23 when we see in his "23rd year") i.e. "typing what you see" and not doing a "calculation." I agree that the usual interpretation in English would be that the person was 22 but had not yet reached their 23rd birthday, just as a baby in its 1st year has not yet reached 1 year old.
Blanking it (Ctrl+B) might be another legitimate option, just as we've recently been told to do for the Military Roster Project when the Military Date is given as, for example, "Last Day of May 1919." We've been instructed to index a Ctrl+B <Blank> for the Military Day field in that case rather than use the old rhyme and try to figure out whether the given year was a leap year or divisible by 400.
In the cases you cited about the "over 21" for males and "over 18" for females on a Marriage License, we've been instructed to index those ages as Ctrl+B <Blank> for quite a while now. And that makes perfect sense since those descriptions really are indeterminate of a specific age.
I'll let Researchers who find the image interpret it the way they best understand the context. Also, perhaps the Moderators can ask the project managers of the involved project what they wish done with this "23rd-year" construction. Or perhaps they can let us know if FS has a current general rule on how to deal with this age description when project instructions are silent on it.
3 -
@John Empoliti Thank you 😎
0 -
You're welcome. @maryellenstevensbarnes1 .
BTW, here, under section (A), below is the current Indexing Help Center guidance ("Knowledge Article") on Indexing Ages. It's important enough that I think it should be part of the new General Indexing Guidelines (GIG) - currently, there is no section on Ages in the GIG. Guidance on indexing ages used to be part of its predecessor, the old Basic Indexing Guidelines (BIG). See further below for a citation from the latest BIG (vintage 2017). You can see that someone indexing 18 or 21 in the marriage license example you cited is not following the old and new indexing rules.
@Paul W . My advice on indexing "in his 24th year" as 24 derives from the third main bullet in the old BIG - see under (B) below. Here it is broken out separately. It isn't part of the current guidance but should be, IMO.
- If an age was recorded as an approximate number, such as "age 14 at next birthday," "about 14," "near 14," or "close to 14," drop the description and type the number alone. (For these examples, the age would be typed as 14.)
(A) From Indexing Help Center on age fields.
How should I index separate age fields?
Article Id: 1706
April 20, 2020
For indexing age, most newer projects have separate fields for days, months, and years. For some records, you may even see weeks. Here are a few suggestions to help you enter the correct information:
- If a fraction is listed for the age, such as "3/12," change the fraction to months (3, in this case) and enter it into the Months field. If it is a strange fraction, such as "1/48," mark the age as unreadable.
- Type only numbers. Do not include a "y" for years or "m" for months.
- If a child was listed as stillborn, index the age as zero: 0
- If the age listed is less than the smallest amount asked for in the project, round up. For example, in a death record, if a child lived for only a few hours, index it as 1 day.
- If a record indicates weeks and there is not a field for weeks, convert the weeks to days (1 week = 7 days), and enter that number in the Days field.
- If the age is blank or the word "infant" or "unknown" is listed, mark the age as blank.
- If the age is listed as "over," such as a male listed as over 21 or a female listed as over 18, mark the age as blank.
(B) From 2017 BIG on age fields:
Ages
- If a recorded age includes days, weeks, months, or fractions of a year, round down to the nearest full year.
- For example: If a child was listed as "5 years and 8 months old," type the age as 5.
- If a child was listed as less than one year old, type the age as 0 (zero).
- If an age was given as a range, such as 65–67, type the first age that was recorded, which is 65 in this example.
- If an age was recorded as an approximate number, such as "age 14 at next birthday," "about 14," "near 14," or "close to 14," drop the description and type the number alone. (For these examples, the age would be typed as 14.)
- If an age was recorded as an uncertain number, such as "over 21" or "over 18," skip the age field by pressing Tab if the field is not a required field, or mark the
- Age field as blank by pressing Ctrl+B if the field is required.
- If "stillborn" was recorded for an individual, type the age as 0 (zero).
- If a specific age was not given, do not calculate an age from other information, such as dates.
2 -
Thank you for your additional comments - and for not taking offence at my comments!
As I'm sure you would agree, these indexing projects need to be completed to a standard that makes them helpful to researchers, once they (the end results) get published at familysearch.org. My posts at https://community.familysearch.org/en/discussion/113051/new-english-records-added-in-december#latest will perhaps help you understand my frustration at the problems created by current indexing procedures, or instructions, in all five of the recently released collections (some updates) relating to England, which had been highlighted here. As you can see, my criticisms are not reserved for the hard-working indexers involved in these projects, but relate to more general issues of project management.
Hopefully, FamilySearch will review its approach to current procedures, particularly with regards to thinking in terms of a whole, integrated process - from the very start of a project to the point where the indexed material appears online. It is surprising how many issues can spoil the hard work of the indexers: material included that should belong under another heading, placenames wrongly standardised to suggest the records relate to a totally different location and many other pre- and post- indexing decisions and actions that can have a detrimental affect on the "final product"!
Apologies for my "rants", but I really do get upset over current issues that (post-indexing) are making our relatives' records so difficult to identify / confirm as being ones relevant to our research.
2 -
I never take offense at thoughtful, well-reasoned, and documented comments.
This whole enterprise - from finding and photographing documents through publication and the wrapper of making them available and more easily useable by normal non-computer-geek folks - is a work in progress. I agree that there have been some backward steps along the way, but earnest people are trying to move it forward with limited resources. I will continue to beat the drum on the Indexing side along with other old-timers to remind those in charge what has worked well in the past and can continue to serve us well in the future. Comments like yours, as a savvy "consumer"/researcher, are important as a quality check on how much work remains to be done, which areas require more attention, and which ones are functioning quite well - for now.
In particular, I think that your idea of a "holistic" approach is particularly important but very difficult to achieve the more complex these systems become. Meanwhile, keep pointing out the areas for improvement that you find, along with the good, and I'll do the same on my end. Hopefully, this feedback from us and others will ultimately lead to a virtuous cycle of improvement. Perfection is out of reach, but better and better would be nice.
3