Perfecting the UNIGEDS place schema

[Uncle Buddy]

Ideally, nested_place_id should be linked only to events and the current nested place autofill in the places tab, because it is only an autofill string for place autofill fields. Since it's a compound element that exists for display purposes only, it doesn't make sense to do logic with it. Unlike the `couple` element, which is also a compound element comprised only of foreign keys, the nested place "Fairbanks, Alaska, USA" is not a different thing from "Fairbanks". The added information is just what the user needs to see, especially if there are multiple places named "Fairbanks".

Wherever possible, the user is shown the whole nesting, but the code deals with nest0, the place_id that references "Casper" in "Casper, Wyoming, USA" or "West Berlin" in "West Berlin, West Germany". The result of this delineation, which will prevent confusion, is to not link nested_place_id to anything except events and other GUI parts where an autofill is being used. So when the user specifies a nested place, the code has to extract `nest0` and perform logic on that element. For example, in places.py, the `delete_current_place` method gets a nesting string from the user, gets the nested_place_id, gets nest0 from that record, and deletes references to the place_id that equals nest0.

To test this strict delineation, the UNIGEDS table schemas will have to be scoured for references to nested_place_id such as the one in media_links. These have to be removed from the schema and the links put on place_id instead. This is more work now but will hopefully put the finishing touch on UNIGEDS' place schema, by making it as simple as possible under the circumstances.

This raises a question. Possibly also the nested_place table could be removed from unigeds.db and changed to a vendor-added table called nested_place_tbd in Treebard's per-tree copies of unigeds.db. However, there is no genieware on earth that could or should get away with displaying Paris as "Paris" in the GUI, it has to be displayed as "Paris, France" or "Paris, Texas" or the user is lost. Therefore I'm leaving nested_place in unigeds.db as it is an essential part of everything done with places in the UNIGEDS schema in order to store and use place references with the clarity, accuracy and detail demanded by the goal of representing real-world places.

[Uncle Buddy]

Hopefully this will only take an hour or so to implement and test since the affected features already work.

[Uncle Buddy]

Looks like it only took about 5 hours, assuming I've found all the places where the code needed to be changed to follow the new rule. This is good, the difference in purpose between place_id and nested_place_id is now clean and clear.

[Uncle Buddy]

Missed one yesterday. There's a foreign key column in the transcription table for nested_place_id. This will take a little longer.

The whole transcription table came into being because of GEDCOM. I hadn't thought of the transcription element till I got deep in the GEDCOM import field of mud. But GEDCOM doesn't care that 'Dallas' and 'Dallas, Collins County, Texas, United States of America' are 1) the same thing and 2) different things. Little old me to the rescue.

The field in the transcription table of unigeds.db has to be changed to place_id and instead of storing a reference to the full nested place string in the transcription table, the field called `nest0` has to be gotten from the correct row of the nested_place table and stored in the transcription table row. Then a reference to Dallas is stored properly instead of storing a compounding of places.

This won't take long, but another improvement to the UpgradeGEDCOMPlaces methodology is begging to be implemented. Should I do that or put it on the do list and let you do it?

[Uncle Buddy]

My day is slipping down the GEDCOM rabbit hole and that wasn't the plan. I promised myself to try really really hard to stop on July 31, so here's what's going on the to do list.

Like repositories, I'm removing transcriptions from the supported features of GEDCOM, till someone gets on that do list.

Repositories were removed because they are not a part of history but a part of the researcher's task, or else that's an excuse and I just didn't feel like doing repositories from scratch since the way I'd done it was too complex. Or both.

Transcriptions are not part of the research, they're part of the source. They are primary. I've never tried to record them in Treebard and handling the GEDCOM for them is a great big abstraction for me at this point. I literally am out of time and energy so, getting back to that do list, here's what's going on it:

Treebard saves person names as a whole, not split into first/middle/last, because that's how names actually work. One full name references one person. This prevents pointlessly complex code. "Bernard Herbert Jackson" refers to the same exact person as "Bernard" or "Herbert" or "Bernard Jackson". The full name is not a compound name.

Treebard saves place names like "334 Park Drive, Glenwood Springs, Garfield County, Colorado, United States of America" as five separate places and five separate place names--that's ten ID numbers--and an additional ID number for each nested place defined by the user when adding places via the GUI. Unlike the case with person names, "Glenwood Springs" and "Colorado" refer to two completely different places. The nested place name is a compound name. That's how Treebard treats it.

Naturally, GEDCOM gets this exactly backwards, splitting person names into parts for no reason and treating Jackson, Mississippi, USA as one place instead of three.

In order to handle place name transcriptions accurately in gedcom_import.py and gedcom_export.py, we have to look into splitting the transcription. Is it even possible? In other alphabets, it won't be possible or worth doing, if that alphabet doesn't separate single places within the nested place by commas.

As for completing this feature in Treebard, a further complication: my code was wrong. The queries (or one of them) is saving a place name ID, which is either correct or well-intentioned, while the SQL query schema has a nested place ID. I already replaced the nested_place_id column in the transcriptions table with a place_name_id, but the other considerations mentioned above gradually occurred to me and it became apparent that this is not going to be redesigned and fixed in an hour or two.

I'm out of time but I suspect that the transcription table row needs to link to a place_id OR a nested_place_id AND a place_name_id. Objections and problems loom in my mind but it's lunchtime and I only have enough time to comment out the code, not enough time to fix it.

[Uncle Buddy]

Obviously the simplest solution would be to dumb down UNIGEDS places to match GEDCOM places. That's been tried, by every other genieware, and there's no reason for Treebard to exist if we're planning to stay at GEDCOM's level. Even Tamura Jones, who is persnickety about details, suggested that one or more aspects of my approach to places was going to prove impossible. This could be true in alphabets without commas. Transcriptions might prove to be the exception. They might have to be saved as full nested place strings. That doesn't ruin the idea of handling places as they exist in the real world.

Don't mistake my impending retirement from the Treebard project as giving up. Six years of full-time+ work is not giving up. It's not a big altruistic sacrifice either. I did it for fun and fun is what I had. Someone else can finish it or not, I care, but not enough to lose sleep over it. I have plenty to keep me busy doing other things while I still can.

[Uncle Buddy]

I ended up adding a transcription_id foreign key field to the notes_links table in unigeds.db. That's good enough for now.

The eventual solution probably involves a nested place name transcription table but the depth of this rabbit hole is disproportionate to what would be gained by trying to find the bottom of it. Just put transcriptions in notes for now.