GRO Index death entries
On the UK GRO Index entries that are displayed, such as https://www.familysearch.org/ark:/61903/1:1:2J9Z-19P?lang=en the detail is missing a vital piece of information that is required for the record. It does not give you which quarter the record applies to - you need to know if it is the March, June, September or December quarter.
Answers
-
@Keith Dorey - practical suggestion first - just go to freebmd org UK for the missing information.
TLDR - yes, the FS version is wrong and misleading. I also think there have been issues with this in the past.
Details: My (printable) reaction to the omission is one of sadness. The situation is actually worse than might be thought initially. We can't use that FamilySearch index to order the certificate itself because the volume and page that are key to the ordering process are not unique within the year, only within the (omitted) quarter.
As an aside, there is no known way of entering the Quarter into the FamilySearch date item - the system is far too clever for its own good and misinterprets the Q number, usually as a month, so Q4 is standardised as April, when it is, of course, October thru December. So if you do get the Q number from FreeBMD, it has to go into a note.
I cannot tell from my relatives' profiles whether the Quarter number was originally present - for date standardisation reasons, it must surely have been in a separate item. But I am fairly certain that we have had discussions in the Community about the England and Wales Death Index in the past. It is not actually quite as simple a collection as you might imagine because there are at least (from fallible memory) three major formats, one of which does omit the quarter (because the original index had been computerised?) I have a distinct feeling that the previous discussions centred on FS getting their version of the index wrong for some reason. I simply don't know whether this is the same fault or a new one.
Can anyone work the Community search well enough to find those previous discussions?
2 -
Good morning, @Adrian Bruce1
I, too, recall previous discussions on the omissions in the GRO index. I'll give the Community search a try. I find the search works best if I filter to the contributor's name. That is, if I recall that you were part of the discussion, I search on a term that was discussed, and use the filter on the right to only look for your contribution.
More caffeine first and then I'll look.
2 -
Personally, I'm not too worried about the quarter being missing from the FamilySearch collection of these records.
Firstly, to order a certificate one would have to go to the GRO website, where the reference / quarter can be easily located. True, if the name is a "common" one (e.g. John Smith) it might save a bit of time in being able to narrow down to the quarter immediately one logs into GRO, but the registration district provided (in FS version) helps with that.
Secondly, I often come across inputs that state a death having taken place in, say, March 1860, where this turns out to be the quarter found by the researcher elsewhere (GRO or FreeBMD) and the death has actually taken place in, say, December 1859 and not officially registered until the next quarter / period. Experienced users will always input "about 1860" or "about March 1860"in these cases, but too many take that "March" (or any other "quarter date" - June, September or December) too literally.
In summary, why is it felt that FamilySearch showing this information in their version is so important? As discussed, it still does not pinpoint the exact date of death, nor save a visit to the GRO website if one wishes to order a certificate.
2 -
I found this
"labelId" : "FS_UNSUPPORTED",
"text" : "{"EVENT_PLACE_LEVEL_2_TYPE":"County","EVENT_REG_QTR":"Jan-Feb-Mar","EVENT_PLACE_LEVEL_1_TYPE":"Country","EVENT_PLACE_LEVEL_3_TYPE":"Registration District","EVQUARTER":"1","UNIQUE_IDENTIFIER":"1001822149948"}"in the underlying data for this Record Persona, indicating that the metadata present (which presumably originated from Find My Past) has the potential to allow the inclusion of a clearly labelled registration quarter on the display.
(I am interested that FS thinks of this particular metadata item as 'unsupported'; that presumably means that FS' standard Death Registration metadata set doesn't include it as an option, which seems rather a pity.)
1 -
@Paul W pointed out
… I often come across inputs that state a death having taken place in, say, March 1860, where this turns out to be the quarter found by the researcher elsewhere (GRO or FreeBMD) and the death has actually taken place in, say, December 1859 and not officially registered until the next quarter / period. Experienced users will always input "about 1860" or "about March 1860"in these cases, but too many take that "March" (or any other "quarter date" - June, September or December) too literally. …
Yes and no. This does partly speak to FamilySearch's inability to show the quarter in any form (e.g. Q1 or "Jan thru Mar" or…) . But if the researcher writes down "March 1860" for Q1 1860 (or any variant representation thereof) then they are guilty of not reading the data in Ancestry or FreeBMD correctly. (Although I have a feeling Ancestry isn't too clear in some areas of their GUI)
As for the overlap, again I have a slight difference of opinion here. If I see a date that reads "1860", I tend to assume it means genuinely "1860" because the researcher has read a document that says "I was born in 1860" or similar. In other words, "1860" means "1860".
If I see "Q1 1860" then I am immediately alerted to it being a registration "date" and therefore that all the caveats of it potentially being X weeks after the actual event apply. In other words "Q1 1860" means "January thru March of 1860 - ish.." ("ish" meaning roughly…)
So I'd prefer to see that quarter date mentioned in a note to give me the hint that it is a registration derived "date".
0 -
@MandyShaw1 - thanks for interpreting the underlying source record data. It does confirm that FindMyPast (the supplier of the index) does supply the quarter, and they're not intentionally crippling the data they supply to FS. (This is how paranoid I get if I can't see the full story).
I was about to say that I'd take a wild guess that it's been marked as unsupported because FS has no means of creating a standardised quarter date… And then I looked at the Birth Registration collection "England and Wales Birth Registration Index, 1837-2008" and here's what it has:
Name
Samuel Pickstock
Event Type
Birth Registration
Event Date
1844
Event Place
Market Drayton, Shropshire, England
Registration District
Market Drayton
Page
122
Volume
18
Affiliate Line Number
5
Registration Quarter
Jul-Aug-Sep
Registration Year
1844
Not sure how that will come out when you read it, but in essence the birth and death indexes (both from FindMyPast and both based round quarter dates) are treated quite differently. The Registration Year and Registration Quarter are provided on the birth index but not on the death index.
So, my point still stands about standardising - there's no easy means of standardising a quarter date.
But the Quarter is supplied as text on the birth index, but not at all the death index. This makes no sense. (I wonder if I've said all this before…? (Wibbly wobbly, timey wimey)
2 -
@Áine Ní Donnghaile - I couldn't find myself talking in this Community about GRO death indexes…
0 -
Yes, I didn't mean to imply that you were part of that thread. Just using that as an example of how I use the search. And, search doesn't function if the conversation was in one of the English groups.
0 -
Áine - I did think I was. But maybe not. Or maybe it was a thread in a Group…
1 -
@Adrian Bruce1 writes:
Not sure how that will come out when you read it, but in essence the birth and death indexes (both from FindMyPast and both based round quarter dates) are treated quite differently. The Registration Year and Registration Quarter are provided on the birth index but not on the death index.
Probably no direct connection, but FamilySearch also treats birth registrations and death registrations differently in another respect: when using the source linker, death registration data is carried across into the Death section of the Vitals, whereas birth registration data ends up just as a Custom Event.
2 -
In both the marriage and birth registrations the three months in the quarter are provided. I do not know why it was omitted on death registrations since the format from FMP for all three are identical. What I do know is that an order to fix will likely go to the tail end of the queue in our records data improvement team. Just sayin…..
3 -
It is possible in Family Tree to specify a standardized date as, e.g., "from 1 April 1857 to 30 June 1857" if an event happened in Q2 1857. So it certainly can be done, even if it's not super easy or straightforward.
Note that I'm talking here about Family Tree dates, which are not identical in format to record dates.
0 -
If I recall correctly, on a previous discussion on this topic, Adrian made reference to a very long labor, if we use that format.
0 -
Just to join any dots - these are 2 recent-ish threads on Quarters
As @Alan E. Brown says,
It is possible in Family Tree to specify a standardized date as, e.g., "from 1 April 1857 to 30 June 1857" if an event happened in Q2 1857
I have two concerns with that - although I'm also sure that there are people who will call me pedantic for those concerns…
- Nobody is born from April to June. As a mere male, I might be wrong but I don't think any labour has lasted that long. If only FS would allow a standardised range of between April and June… That makes sense - but I've said it several times in the past.
- Particularly if you include the day of the month in the range, it gives an spurious impression of accuracy. The actual birth can be a few weeks before the start of the quarter, which denotes when the birth was registered. Somehow giving a range that is obviously a quarter prompts me to consider that the birth might indeed lie outside the range.
So I tend to be happy with just putting the quarter in a note.
1 -
@SerraNola said:
In both the marriage and birth registrations the three months in the quarter are provided. I do not know why it was omitted on death registrations since the format from FMP for all three are identical. What I do know is that an order to fix will likely go to the tail end of the queue in our records data improvement team. Just sayin…..
Message received loud and clear, especially the last phrase! 😊
Personally I would like FS to fix the issue and process the "England and Wales, Death Registration Index 1837-2007" in the same way as "England and Wales Birth Registration Index, 1837-2008". Specifically the Death Index should include Registration District, Registration Quarter, and Registration Year. My logic is as follows:
- Data is being lost from the current Death Index leading to possible confusion, especially if there are 2 deaths in the same year and place who have the same name. If information such as a burial record is present, it is very possible that it is feasible to decide which death index is which.
- By matching the Birth and Death logic, it may be possible to reduce the size of the code base (slightly!), reducing confusion or workload for the software guys.
- Adding the Registration District under that description prompts people to realise that the place is a district that might be much bigger than the place it's named after. Mary Ann Tupholme (see above) died in the registration district of Spalding, which contained 10 or 11 civil parishes, only one of which is called Spalding.
On the other hand, there are ways to mitigate the issue:
- FreeBMD and the England & Wales GRO site can supply the missing data at no cost. (Providing you know this…)
- Anyone ordering the death certificate will have to go through one of those sites (unless the researcher orders through a third party supplier)
I'd prefer that other issues such as placename standardisation are fixed first, so I'm not expecting this to happen anytime soon - but if someone's in the coding area…
3 -
Thanks for your reply.
For your first point, I will indeed opine that you are being pedantic. Yes, there's a slight difference in meaning between "from x to y" and "between x and y", but it's minor. Indeed, you can enter "between 1857 and 1858" in a date field, and the suggested standardization will be "from 1857 to 1858", so FamilySearch considers those two forms to be close enough to be treated as equivalent. So we can use them interchangeably, even if we wish there might be more options. And my next point is also quite relevant for this first point.
For your second point, I totally agree that we need to avoid attaching too much precision to any conclusions we draw about a birth or death date from a registration quarter. But I think that is easily handled if we exercise proper care in specifying what we are talking about. With these British registration events, we are certainly talking about Birth Registration and Death Registration — not the birth and death. As long as we make it clear that we are talking about the registration (often by using a custom event for "Birth Registration"), we can indeed be precise on the dates, because a Q2 1857 birth registration did happen between 1 April 1857 and 30 June 1857. If someone wants to draw a conclusion about the birth, there is much more imprecision and guesswork involved, since the person could have been born in March (or even earlier); it's never advisable to specify that a birth happened between 1 April 1857 and 30 June 1857 if all we have is a quarterly registration record.
0 -
@Alan E. Brown - "… Yes, there's a slight difference in meaning between "from x to y" and "between x and y", but it's minor …"
Ouch - it's not minor if you did a maths degree! 😉
"… it's never advisable to specify that a birth happened between 1 April 1857 and 30 June 1857 if all we have is a quarterly registration record …"
Totally agree.
Where I'm highly dubious is over the suggestion to use custom events for "Birth Registration" and (by extension, "Death Registration"). I think this is likely to cause more issues than it cures - there is no other guaranteed method of getting to a date of birth (or death) for England & Wales (or Scotland) aside from splashing the cash to buy a certificate. Occasionally baptism registers include the date of birth (this seems to happen as a matter of course from some point in the 1900s). Censuses give only an approximate date of birth that usually has a bigger margin of error than using the Registration Indexes. So creating Birth and Death Registration custom events is likely to result in either empty birth and death events or birth and death dates that are less accurate than the registration date versions. Not ideal…
1 -
@Adrian Bruce1 : ”Ouch - it's not minor if you did a maths degree!"
Actually, I do have a degree in Mathematics -- I got a chuckle from your choice to make that joke with me! In the context of genealogical dates, I fail to see any significant difference.
I definitely see great value in documenting registration dates as precisely as we can, when there is a source record that provides those details. But that in no way implies that there is any reason to leave a birth or death event blank. You will almost certainly end up with ”birth and death dates that are less accurate than the registration date versions." But if that's all the data we have, then that is indeed ideal, because it's the best we can do, and there is great value in providing a birth or death event. Those vital events are among the most important conclusions we have, and we know a lot about them from the precise registration data, even if those dates are a bit less precise.
0 -
@Alan E. Brown - hoist with my own petard in the topic of degrees, it appears! 😉
Anyway, we both agree on the importance of registration data and how it can be used, so it would be nice to see it more easily visible somewhere on a Profile, whether as a separate date or as text in a note.
2
