MAJW work 2022-10-03 to 2022-10-07
to : Martin Holmes
Minutes: 390
I’m making progress with the TEI build, and have taken some decisions on how to represent the data in consultation with AB; mentions are events, there is a single merged personography, and the places are reorganized so that the multi-county locations are mapped to their component counties.
I’ve also added new diagnostics which attempt to discover and suggest cases where primaries or relatives are possibly the same person as other primaries or relatives, and this is helping a little with disambiguation.
I have a complete working test db with web interface set up so that all db changes can be tested properly before rolling them out.
I’ve added one-to-many hashtag fields to the three main tables, which should help with the practical flagging of cases requiring further intervention, or where decisions have been made that should (for example) remove them from diagnostic outputs.
Next, I’ve sketched out the SQL and PHP for one-to-many fields linking primaries and relatives to each other as potentially the same person. Because of the way the one-to-many relationships work in both SQL and PHP, when they’re relating to the same table (primaries who may also be the same as other primaries), only one record will contain the link. However, I have a slightly cunning plan whereby a trigger would create a matching but reversed version of the same record in the linking table on create, delete and recreate it on modify, and delete it on delete; that might do the job, but it seems likely to be a bit fragile.
On Friday I implemented the easiest case, the one-to-many links between primaries and relatives, and notified AB so she can try it out. I also investigated how we might do one-to-many links between records in the same table, and it seems that there is no feasible approach using triggers because they cannot modify the table that they’re being triggered from. An alternative approach would involve modifying the adaptiveDB one-to-many field so that it can have a flag which specifies whether it’s linking between items in the same table (or it could simply deduce this from the data structure itself, perhaps). In this scenario, it would be clever enough to create, maintain, and delete parallel records pointing in the other direction within the linking table, as it’s doing its regular table writing.