GEDCOM's Missing Elements
May 20, 2022 5:38:04 GMT -8
Post by Uncle Buddy on May 20, 2022 5:38:04 GMT -8
GEDCOM can't even be imported to a better GEDCOMesque text file till parts of it are rewritten to make sense.
DATABOY has to be more radical than I'd assumed. It can't just import and translate GEDCOM into a proper exportable, accurate form. Some of it works that way already, but a new method has to be run first, before primary keys can even be saved. GEDCOM has to be way more than translated. Parts of it have to be transplanted with corrected lines of text to prevent large chunks of code becoming necessary during a process that should be predictable and routine.
Before running make_primary_key(), GEDCOM's missing elements have to be upgraded to primary key status. GEDCOM's missing elements include NAME and PAGE. A study will have to be done on all the tags that can be used in 5.5.1 with citations; PAGE might not be the only one, though maybe some/all could be lumped into the citation's data tag in DATABOY.
If you watched the video I uploaded today, there's a moment when I come up short, having assumed without careful inspection that my code was working right on citations input to the database. This was before I started using the same code to import GEDCOM to DATABOY instead of the SQL. The problem was caused by accepting GEDCOM's opinion that PAGE (i.e. what should be CITE) is a subordinate tag. I'm not sure why this worked on the NAME tag (just making a primary key for it on the fly--possibly worked because unlike SOUR>PAGE, in the INDI>NAME progression, at least the tags are in the right order within the hierarchy.)
There's actually no one-way hierarchy, and this becomes clear when trying to look at how citations really work. The citation database table needs a foreign key column for source_id. That's easy, but the links_links table needs to be used to eliminate the need to repeat the citation text for every NAME or other linked element that wants to be linked to the same citation. Linking subordination in a real database isn't just a simple one-way progression. It's more like three-dimensional instead of one- or two-dimensional. There's no problem doing this in DATABOY and SQL; it's easy.
The problem is that GEDCOM has already told everyone to do it wrong, so GEDCOM files transmit data a certain limited way that doesn't match reality. With a practical need to get data in and out of their program, apparently vendors have just accepted the limitation of a GEDCOM which misrepresents reality as one- or two-dimensional, and built their simplified programs around this limitation.
So in order to import GEDCOM to anything that isn't structured to match GEDCOM, the right way to do this might be to rewrite portions of GEDCOM files when they're imported to DATABOY, to include all the necessary primary keys, The GEDCOM on its way in has to be copied, then the copy has to have major organ transplants done on it before it can be simply translated to DATABOY.
And there are also those extra tags--I'm thinking FAM/FAMC/FAMH--that have to be eradicated, and their subordinates such as HUSB/WIFE/CHIL which have to be reworked into a format that translates directly to the way foreign keys need to be used in real database relationships.
It's 9:38 pm and my work day is over. I will be asleep in less than a minute. See you at the break of dawn, when my dogs inspire me once again to leap out of bed and take them for a walk.
DATABOY has to be more radical than I'd assumed. It can't just import and translate GEDCOM into a proper exportable, accurate form. Some of it works that way already, but a new method has to be run first, before primary keys can even be saved. GEDCOM has to be way more than translated. Parts of it have to be transplanted with corrected lines of text to prevent large chunks of code becoming necessary during a process that should be predictable and routine.
Before running make_primary_key(), GEDCOM's missing elements have to be upgraded to primary key status. GEDCOM's missing elements include NAME and PAGE. A study will have to be done on all the tags that can be used in 5.5.1 with citations; PAGE might not be the only one, though maybe some/all could be lumped into the citation's data tag in DATABOY.
If you watched the video I uploaded today, there's a moment when I come up short, having assumed without careful inspection that my code was working right on citations input to the database. This was before I started using the same code to import GEDCOM to DATABOY instead of the SQL. The problem was caused by accepting GEDCOM's opinion that PAGE (i.e. what should be CITE) is a subordinate tag. I'm not sure why this worked on the NAME tag (just making a primary key for it on the fly--possibly worked because unlike SOUR>PAGE, in the INDI>NAME progression, at least the tags are in the right order within the hierarchy.)
There's actually no one-way hierarchy, and this becomes clear when trying to look at how citations really work. The citation database table needs a foreign key column for source_id. That's easy, but the links_links table needs to be used to eliminate the need to repeat the citation text for every NAME or other linked element that wants to be linked to the same citation. Linking subordination in a real database isn't just a simple one-way progression. It's more like three-dimensional instead of one- or two-dimensional. There's no problem doing this in DATABOY and SQL; it's easy.
The problem is that GEDCOM has already told everyone to do it wrong, so GEDCOM files transmit data a certain limited way that doesn't match reality. With a practical need to get data in and out of their program, apparently vendors have just accepted the limitation of a GEDCOM which misrepresents reality as one- or two-dimensional, and built their simplified programs around this limitation.
So in order to import GEDCOM to anything that isn't structured to match GEDCOM, the right way to do this might be to rewrite portions of GEDCOM files when they're imported to DATABOY, to include all the necessary primary keys, The GEDCOM on its way in has to be copied, then the copy has to have major organ transplants done on it before it can be simply translated to DATABOY.
And there are also those extra tags--I'm thinking FAM/FAMC/FAMH--that have to be eradicated, and their subordinates such as HUSB/WIFE/CHIL which have to be reworked into a format that translates directly to the way foreign keys need to be used in real database relationships.
It's 9:38 pm and my work day is over. I will be asleep in less than a minute. See you at the break of dawn, when my dogs inspire me once again to leap out of bed and take them for a walk.