BillionGraves index update: simplistic information display of new entries
On 20 September, I received a number of Research Hints on my home page. These were for BillionGraves burial records. I followed these up by opening the relevant profiles and selecting the research help. The information that is displayed in the Record Information panel is spartan, to put it mildly. It comprises (for 97V7-Z1V Olive Christina Phipps):
- The person's name with the first names in quotation marks "Olive Christina" Phipps;
- The event type Burial;
- Longitude 172.636473 and latitude -43.376368;
- The cemetery name in quotation marks "Kaiapoi Public and RSA Cemetery"
There is no sign of the place (e.g. town, country), or any birth or death dates. It doesn't get any better when I open the source in the Source Linker (REVIEW & ATTACH). In the Person and Spouse section the following is displayed:
- Name "Olive Christina" Phipps;
- Sex Unknown";
- Death 22.8.1908. Note that this is in the potentially-ambiguous numeric format;
- Burial Kaiapoi.
Olive already has a date and place of death and a burial place saved by another user, so I don't know what the source linker would otherwise suggest for those items. I also note that the source linker marks the Name as being Different, because of the quotation marks on the left side.
This is all quite unsatisfactory. In all the examples I have looked at, the records have a datestamp of 19 September 2024. Pre-existing source records in this index don't have these issues.
Answers
-
The underlying data (obtained from the Records API persona JSON) has this:
label
text
EVENT_CEMETERY_ORIG
'Kaiapoi Public and RSA Cemetery'
EVENT_CITY_ORIG
Kaiapoi
EVENT_COUNTRY_ORIG
'New Zealand'
EVENT_COUNTY_ORIG
Waimakariri
EVENT_LAT_ORIG
-43.376368
EVENT_LON_ORIG
172.636473
EVENT_STATE_ORIG
Canterbury
EVENT_TYPE
Burial
PR_DEA_DAY_ORIG
22
PR_DEA_MONTH_ORIG
8
PR_DEA_YEAR_ORIG
1908
PR_NAME_GN_ORIG
'Olive Christina'
PR_NAME_SURN_ORIG
Phipps
so yet again this looks like a user interface problem rather than a data one (apart from the unnecessary quotation marks). The month and day are distinguished properly in the data.
2 -
I've looked at the collection information (via Search / Records, Browse All Collections). The BillionGraves collection has a Last Updated value of 7 August 2024, which is six weeks earlier than the dates in these problematic entries (19 September 2024). Has some "maintenance" been done on the collection that doesn't update the Last Updated value?
0 -
That happens a lot in my experience, I am not sure the Last Updated value on a lot of collections means much.
0 -
Does anyone know if there is an appropriate group that deals with the processing of historical records files from outside bodies and turns them into FS Historical Record files? In the same way that there is for (say) Source Linker? This would appear to be one for them if they existed... (Assuming that I've got my head round what I'm looking at).
The data on the BillionGraves file appears OK in the sense that a human being can read it. I guess that there's a possibility that the BG file has changed format and the FS reformatting hasn't kept up?
1 -
I suspect it's about the specific Labels being used - maybe they have changed. @JulianBrown38 do you have an example (pre-existing) BG record that doesn't show this behaviour? It would be worth my pulling the underlying data for that, I think.
1 -
@MandyShaw1, Thanks for your input. Here are two records for two distinct individuals with the same names "Donald Alfred Brown". The newer one is attached to a relative's profile, and the older one is unattached. I previously encountered both of these people when searching the New Zealand Electoral Rolls (but that's for another story).
These two records can be found by selecting the BillionGraves collection and searching with those exact names and an exact place of New Zealand.
1 -
Well, that's really interesting.
Old format:
label
text
EVENT_CEMETERY
Waikanae Cemetery
EVENT_CITY
Waikanae
EVENT_COUNTRY
New Zealand
EVENT_LAT
-40.868241
EVENT_LON
175.050779
EVENT_PLACE
Waikanae, Wellington, New Zealand
EVENT_PLACE_LEVEL_1
New Zealand
EVENT_PLACE_LEVEL_2
Wellington
EVENT_PLACE_LEVEL_4
Waikanae
EVENT_STATE
Wellington
EVENT_TYPE
Burial
PR_BIR_DATE
12-Jun-42
PR_BIR_DAY
12
PR_BIR_MONTH
Jun
PR_BIR_YEAR
1942
PR_DEA_DATE
28-Aug-97
PR_DEA_DAY
28
PR_DEA_MONTH
Aug
PR_DEA_YEAR
1997
PR_NAME
Donald Alfred Brown
PR_NAME_GN
Donald Alfred
PR_NAME_SURN
Brown
New format:
label
text
EVENT_CEMETERY_ORIG
'Harewood Memorial Gardens and Crematorium Christchurch'
EVENT_CITY_ORIG
Christchurch
EVENT_COUNTRY_ORIG
'New Zealand'
EVENT_LAT_ORIG
-43.464249
EVENT_LON_ORIG
172.584828
EVENT_STATE_ORIG
Canterbury
EVENT_TYPE
Burial
PR_DEA_DAY_ORIG
16
PR_DEA_MONTH_ORIG
6
PR_DEA_YEAR_ORIG
1990
PR_NAME_GN_ORIG
'Donald Alfred'
PR_NAME_SURN_ORIG
Brown
(This does assume all my data analysis logic is correct, obviously …)
2 -
So a definite change of labels in FS - and I guess that gives no clue whether the actual BG interface file has changed. Thanks for this @MandyShaw1 - I am definitely better informed, not sure about wiser! 😉
The thing that strikes me is that the labels in the new format are (nearly) all suffixed with -Orig, which is very reminiscent of how the place handling in Historical Records used to look - Event Place Orig containing the original data (no surprise) and Event Place containing the standardised version. Having said that, I don't see any non-Orig labels (apart from one or two) so I'm not sure what my insight means. If anything 😕
1 -
I thought pretty much the same.
OK, for comparison here's a random NUMIDENT one (https://familysearch.org/ark:/61903/1:1:6KMN-RFLK) - plenty of _ORIG's, plenty of non _ORIG's.
label
text
EVENT_TYPE
Social Program Correspondence
NOTE_PR_NAME_ORIG
Name and form dates: Claim: AGNES T KOPPELMAN (25 Jul 1973), Application: EMMELENEAGNES TIMPERLEY KOPPELMAN (15 Dec 1974), Death: AGNES T KOPPELMAN (Aug 1995)
PR_AKA
Agnes T Koppelman
PR_AKA_2
Emmeleneagnes Timperley
PR_AKA_2_GN
Emmeleneagnes
PR_AKA_2_GN_ORIG
EMMELENEAGNES
PR_AKA_2_ORIG
EMMELENEAGNES TIMPERLEY
PR_AKA_2_SURN
Timperley
PR_AKA_2_SURN_ORIG
TIMPERLEY
PR_AKA_GN
Agnes T
PR_AKA_GN_ORIG
AGNES T
PR_AKA_ORIG
AGNES T KOPPELMAN
PR_AKA_SURN
Koppelman
PR_AKA_SURN_ORIG
KOPPELMAN
PR_BIR_DATE
30-Sep-11
PR_BIR_DATE_ORIG
30 09 1911
PR_BIR_DAY
30
PR_BIR_DAY_ORIG
30
PR_BIR_MONTH
9
PR_BIR_MONTH_ORIG
9
PR_BIR_PLACE
Cranston, Rhode Island, United States
PR_BIR_PLACE_ORIG
Cranston, Rhode Island, United States
PR_BIR_YEAR
1911
PR_BIR_YEAR_ORIG
1911
PR_DEA_DATE
Aug-95
PR_DEA_DATE_ORIG
08 1995
PR_DEA_MONTH
8
PR_DEA_MONTH_ORIG
8
PR_DEA_YEAR
1995
PR_DEA_YEAR_ORIG
1995
PR_NAME
Emmeleneagnes Timperley Koppelman
PR_NAME_GN
Emmeleneagnes Timperley
PR_NAME_GN_ORIG
EMMELENEAGNES TIMPERLEY
PR_NAME_ORIG
EMMELENEAGNES TIMPERLEY KOPPELMAN
PR_NAME_SURN
Koppelman
PR_NAME_SURN_ORIG
KOPPELMAN
PR_PREV_RES_PLACE
Greenville, Providence, Rhode Island, United States
PR_PREV_RES_PLACE_ORIG
Greenville, Providence, Rhode Island, United States
PR_PREV_RES_POSTAL_CODE
02828-0000
PR_PREV_RES_POSTAL_CODE_ORIG
02828-0000
PR_SEX_CODE
Female
PR_SEX_CODE_ORIG
F
PR_SOC_PROG_APP_DATE
15-Dec-74
PR_SOC_PROG_APP_DATE_ORIG
15 12 1974
PR_SOC_PROG_APP_DAY
15
PR_SOC_PROG_APP_DAY_ORIG
15
PR_SOC_PROG_APP_MONTH
12
PR_SOC_PROG_APP_MONTH_ORIG
12
PR_SOC_PROG_APP_YEAR
1974
PR_SOC_PROG_APP_YEAR_ORIG
1974
PR_SOC_PROG_CLAIM_DATE
25-Jul-73
PR_SOC_PROG_CLAIM_DATE_ORIG
25 07 1973
2 -
@MandyShaw1 - thanks for that. A plentiful mix of _ORIG and not _ORIG, much more like what I was expecting.
Mind you, just as an aside, I notice we have PR_BIR_DATE_ORIG = 30 09 1911, alongside PR_BIR_DATE = 30-Sep-11, i.e. the century has been lost from the composite - but PR_BIR_YEAR_ORIG = 1911 and PR_BIR_YEAR = 1911, i.e. the final version of the year includes the century… Curious… Especially considering that the final version of the full date seen by accessing the URL includes the century.
1 -
Another weird thing is that this very-much-US collection formats all its numeric dates as DMY.
1
