Monument project 2023-01-23 to 2023-01-27
to : Martin Holmes
Minutes: 350
On Thursday, met with NA and MA to discuss the criteria for inclusion, work plans, etc. Since the team is nearing the end of the low-confidence spousal matches, I moved on to the issue of unmatched spouses.
By the end of the day, I committed some changes which, when the next build is complete, should give us a list of unmatched spouses. My local test build of this generates:
- 1937 unmatched wives
- 2483 unmatched husbands
This aligns with our intuition that it’s more likely a wife (and possibly children) are in Japan and the husband in Canada than the other way round; and I suspect it’s the case that the majority of the unmatched wives will have matches in our records, which should eliminate a lot of the unmatched husbands too.
To get a sense of what’s happening, I dug into a name appearing on this list, Tomo Abe (abet3), whose husband is listed as Takeo Abe. However, the actual husband record has him and all his family listed with the surname Ahe
, which is why there was no match between them. This is despite the fact that the custodian file clearly uses Abe throughout. This kind of change will require a systematic replacement of the old id with a new id, renaming of PDF files, and all sorts of stuff like that; presumably SA should be doing that. I’ve created a spreadsheet in production/admin/personography_errors.ods, where I’ve already listed abac2 (name should be Adachi), and I’ve now added ahet1 on the assumption that Abe is the correct name. I think we’re going to see a lot of this sort of thing.
On Friday, I set up a completely separate Jenkins build for Monument in addition to the regular Landscapes build, and removed it from the Landscapes build, so we can more quickly and easily see our results. This took some substantial reconfiguration, both on Jenkins and in the two build processes, but it seems to be working now. The team is now able to start work on figuring out problems with unmatched spouses.