Monument 2024-02-26 to 2024-03-01
to : Martin Holmes
Minutes: 450
Over the weekend, did a couple of merge-and-deletes, but hit an issue with one; got a response on that by Monday, and continued, but quickly realized that many in my list are dependent on forename changes from another list I haven’t yet received, so I’m cherry-picking the items I can do for the moment, waiting on the forename list.
On Tuesday, I got a list of over 800 forename changes from MA. Working from home due to illness, I’ve managed to automate a process which checks to see which of the forename corrections can be done in bulk by automation, then sets up a process to to do those, so I got 675 done by lunchtime; but the remaining 170, by definition, need manual checking. Because SA may be helping me with this process, I’ve described the issue in detail below.
The problem basically goes like this:
The Monument dataset contains two kinds of person records:
- records copied from the original LOI person records, with the same ids and basic data, but with some additions specific to Monument (such as relation elements to link family members).
- records created by analysis of the prose from the original LOI records, being the records of children whose existence was inferred from their parents’ case file records. These have ids starting with m_, so they’re clearly distinct, but in other respects they follow the same pattern. So there may be
xml:id="yama27"being an original LOI record which is copied over to Monument as well, andxml:id="m_yama27"which is a completely different person, being a child of some other Yama* family who was too young to have their own casefile and LOI id.
As the Monument team have done their research, using the LAC redress records and index cards, birth and death records, ship passenger lists, community consultation, and so on, they’ve determined these kinds of forename change:
- The original records fail to record an additional forename (usually a western forename to complement the person’s Japanese forename), so that name needs to be added alongside the existing one.
- he original records got a forename wrong somehow — either it was spelled or recorded wrongly in the original casefiles or by the LOI team, or the original spelling pattern is old-fashioned and a more modern spelling is appropriate, or is preferred by the family.
- A combination of 1 and 2.
In cases where the ONLY change is the addition of a new supplementary forename in the alternate language to the existing one, and no other changes are required, I simply make an automatic change to the Monument records and leave the LOI records alone.
But in all other cases, we need to investigate the reason for the discrepancy, and make corrections not only in the Monument data but also in the original LOI records. For example, if the family or the redress records record a child’s forename as Yasoye, but the LOI record has Yasoe, we would go back to the parents’ original casefiles and check thoroughly; often the LOI error comes from having read only the first page of the casefile and adopted a typo from the original bureaucrats, whereas if you read on you see other documents with the other form, and sometimes, most crucially, you can see the person’s own signature to confirm the correct name. In about 10% of cases (at a guess) the Monument team is actually mistaken, and they’ve adopted an error from a typo or another slapdash bureaucrat somewhere else; and sometimes there’s a genuine puzzle or conflict where the modern descendants are convinced the name should be one way but the period evidence says not.
Generally the objective is to a) get it right as far as we can, and b) keep the Monument and LOI records in sync so that if/when we re-merge them (which I suspect JSR wants us to do — he likes the family relationship data from the Monument records and wants it available in the LOI archive), we don’t create inconsistencies. In the case of children’s names, if the original LOI records were wrong, we need to correct the prose in both parents’ records in both the LOI and Monument recordsets, as well as the child’s record in Monument (and in LOI if they were 16+ and had their own casefile).
There is a small subset of Monument records which are forked from the LOI record for the same person because a different surname is used in each case, usually due to marriage; sometimes the LOI record uses the married name but because they were initially uprooted before marriage, the Monument record needs to use the maiden name. In these cases, the Monument record has <idno type="LOI"> pointing to the original LOI record.
More often than we would wish, surnames also get changed, and then all hell may break loose because the original id may have to change, as well as the filename of the PDF casefile, and the XML records pointing to that. Because we don’t issue LOI editions very often, we have to keep the old PDF filename around because the live site is not going to change yet, so there are now several hundred duplicated PDFs with variant filenames which will need to be cleaned up. Deniz has written some scripting to identify those which are no longer required, and I’ll make use of that when there’s enough breathing space at some point.
On Wednesday, had a lot of discussion with MA and JSR regarding what the Monument project has contributed to LOI, and also regarding the searchability of the land titles in the LOI archive; we definitely need a wider range of filters for that search if it’s going to be useful at all.
On Friday, there was more discussion of whether changes to the LOI source were actually desirable, so we’re temporarily pulling back from making LOI changes. Met with SA and he’s going to take the spreadsheet of potentially complex changes from the last batch of Monument forename updates, and instead of proceeding to do them, will just investigate and list recommendations. This list may be a useful set of examples to help with the issue of whether changes should be made or not.