Introducing gedMOM -- a teaching tool

[Uncle Buddy]

My memory's all used up, so I don't know if I've mentioned gedMOM before on this forum. I don't know if gedMOM will find a use in programming. It might, because it imports to UNIGEDS (my genealogy database program) real slick, the data just slides right into SQL.

gedMOM is a gedcomoid (text file that's meant to transfer data between genieware applications). Basically, it is what GEDCOM would look like if it was close to perfect. Its real purpose at this point is to serve as a teaching tool. I also find it soothing to manually type up a gedMOM fragment when the GEDCOM snarl starts to loom menacingly.

Here are two ways to represent some births and adoptions and the like. What GEDCOM calls a "family", I call a "couple". Actually I think I'll just post below a chapter from my upcoming bestseller

Luther's Nearly 95 Theses: The GEDCOM Deconstruction
-or-
Everything You Never Wanted to Know about GEDCOM But Were Afraid to Just Ignore
by Luther Rangely, Uncle Buddy, and Professor U. d'Guru
as well as the entire staff of Treebard University whose motto is:
Regularity Rules!

18. For various reasons already mentioned above, the FAM tag is an exception to the expectations set up by the other primary tags. But this is GEDCOM, irregularity is to be expected, because everything is an exception. You just get used to looking up, and then GEDCOM makes you look down. There is no consistency, no symmetry. Well there's some, for the easy part, but when the going gets rough, GEDCOM gets rougher. This is not necessary. There are two ways to do the same thing, but each requires a different strategy. There's no logical reason to do things two ways. Are we trying to please everybody or are we trying to transfer some data? Are we trying to set a standard, or cater to different thinking styles by a variety of members of the GEDCOM creation committees? The INDI.FAMC (child) tag gives the same information as the FAM.CHIL tag, its bi-directional partner in crime. But the FAMS tag falls short of providing the same information as its partner the WIFE/HUSB tag. If the FAMS tag is actually needed for some reason, then it should be FAMW/FAMH.

Hey now, while I'm complaining about things I already complained about--because when I woke up this morning GEDCOM had not been a bad dream, it was still here, and I still have to deal with it, and this document is still what keeps me sane--I have to mention this cute little bug in the ointment, which I call `INDI.ADOP.FAMC.ADOP`:

0 @I560@ INDI
1 NAME Trevor /Tewksbury/
1 ADOP
2 FAMC @F321@
3 ADOP WIFE

"Bug" doesn't really do it justice. More like a plague of locusts on a biblical scale. That second ADOP tag has already cost me a day or two, although to be honest if I'd gotten more sleep two nights ago, I might have been able to think more clearly yesterday. The right way to accomplish what "INDI.ADOP.FAMC.ADOP = WIFE" tries to convey is to make a different family record (a different couple ID to my way of thinking) that includes the wife and not the husband who didn't adopt the child. I say this because there is no practical reasoning behind the existence of a family element. The element that is helpful is a couple element, used to convey the facts of life, instead of a pretend nuclear family element that's just all over the place looking for ways to pigeonhole data. When GEDCOM treats the family element as a family element, it is lying to us. There is no such thing as a family element because its membership changes so much over time that we can't say who the members are without putting on blinders and shutting out annoying facts. Every snapshot of a family is different, because the family unit is a fluid, not a solid.

The right way to indicate adoption events is not by pretending there is a solid, definable, simple, physical thing--the family unit--and then adding complication every time the pure nuclear family arrangement experiences a hiccup in the real world. Because the real world consists of "what happens to us when we're busy making other plans" according to John Lennon (who was correct), GEDCOM should work like SQL which does not store data hierarchically, but as a network of related pairs. Here are some better ways to represent data, and I'll give the same example in both a nested Python dictionary and gedMOM. The nesting goes pretty deep on the dictionary, and that is hierarchical in a programming sense, by which I mean to say this hierarchical structure represents facts, like which child belongs to which parents and how that came about. But the gedMOM below it, which shows identical data, is structured to exactly mirror UNIGEDS' SQL relationships.

If GEDCOM woke up one day to find that the Blue Fairy had magically transformed it in its sleep to mirror the way SQL works, then the data would slide effortlessly into a SQL database and the structure of the gedcomoid would tell us exactly how to construct the database tables. This is the purpose of UNIGEDS, and the purpose of gedMOM is to demonstrate how SQL databases work without looking at any SQL. I've already tested a manually created gedMOM file, and it was converted to a UNIGEDS database so easily and perfectly that it inspired this whole effort to write GEDCOM import and export programs for UNIGEDS and Treebard.

In the gedMOM example below, the troublesome FAM data of GEDCOM is tamed by representing all the elements of genealogy as elements, not as subordinates to a sometimes-imaginary hierarchy. The annoying INDI.ADOP.FAMC.ADOP complex is simply represented by creating the right number of couples, instead of saying that Jack and Jill are always a couple no matter what actually occurred. Since adoption is essentially a couple event, but a child is sometimes adopted by only one member of the couple, then a new couple_id is needed for those adoption events which do not involve both members of an existing couple. This simple solution didn't come to me the first time I needed a solution. Many versions of UNIGEDS have come and gone over the past five years, and it's only relatively recently gotten good enough to give it its own name.

nested Python dictionary:

self.couples = {
3: {
1: {
"children": [
{"child_id": 93, "event_type_id": 48},
{"child_id": 38, "event_type_id": 1}]},
2: {
"children": []}},
8: {
3: {
"children": [
{"child_id": 65, "event_type_id": 83},
{"child_id": 89, "event_type_id": 1}]},
4: {
"children": [
{"child_id": 65, "event_type_id": 95},
{"child_id": 89, "event_type_id": 1}]}}}

gedMOM text file:
PRSN 1
PRSN 2
PRSN 3
PRSN 4
PRSN 93
PRSN 38
PRSN 65
PRSN 89
*|*
EVNT 74
PRSN_FK 93
EVNT_TYPE_FK 48
CUPL_FK 99
*|*
EVNT 82
PRSN_FK 38
EVNT_TYPE_FK 1
CUPL_FK 99
*|*
EVNT 59
PRSN_FK 65
EVNT_TYPE_FK 83
CUPL_FK 22
*|*
EVNT 78
PRSN_FK 89
EVNT_TYPE_FK 1
CUPL_FK 8
*|*
EVNT 29
PRSN_FK 65
EVNT_TYPE_FK 95
CUPL_FK 33
*|*
CUPL 3
PRSN1_FK 1
PRSN2_FK 2
*|*
CUPL 8
PRSN1_FK 3
PRSN2_FK 4
*|*
CUPL 99
PRSN1_FK 1
PRSN2_FK null
*|*
CUPL 22
PRSN1_FK 3
PRSN2_FK null
*|*
CUPL 33
PRSN1_FK null
PRSN2_FK 4
*|*
EVNT_TYPE 1
EVNT_TYPE_STRG birth
EVNT_TYPE 48
EVNT_TYPE_STRG adoption
EVNT_TYPE 83
EVNT_TYPE_STRG guardianship
EVNT_TYPE 95
EVNT_TYPE_STRG fosterage

[Uncle Buddy]

This is how much code was needed to handle the gastro-intestinally challenging tag `INDI.ADOP.FAMC.ADOP`, a tag which is not used much, (maybe because its rival PEDI can handle foster/guardian/sealing events, not just adoptions?):

   def adjust_for_adoptions(self):
       """ 0 @I560@ INDI
           1 NAME Trevor /Tewksbury/
           1 BIRT
           2 FAMC @F88@
           1 ADOP
           2 FAMC @F321@
           3 ADOP WIFE
           In the example above, the person was adopted by the wife only. Make
           a new couple ID for the wife with a null partner. Don't change the
           existing couple. Change the couple ID linked to the adoption event
           to the new couple ID.
       """
       for idx,lst in self.lines.items():
           num, tag, value = lst[0:3]
           if tag != "ADOP":
               continue
           elif tag == "ADOP" and value == "null":
               continue
           elif value == "BOTH":
               continue
           elif value in ("HUSB", "WIFE"):
               old_couple_id = int(
                   "".join(c for c in self.lines[idx-1][2] if c.isdigit()))
               new_couple_id = max(list(self.couples.keys())) + 1
               if value == "HUSB":
                   parent_id = self.couples[old_couple_id]["PRSN1_FK"]
                   self.couples[new_couple_id] = {
                       "PRSN1_FK": parent_id, "PRSN2_FK": None}
               elif value == "WIFE":
                   parent_id = self.couples[old_couple_id]["PRSN2_FK"]
                   self.couples[new_couple_id] = {
                       "PRSN1_FK": None, "PRSN2_FK": parent_id}
               event_type_id = self.types["event_types"]["adoption"]
               adoptee_id = self.adoptees[old_couple_id]
               for event_id, vals in self.events.items():
                   if vals.get("PRSN_FK") is None:
                       continue
                   elif (vals["PRSN_FK"] == adoptee_id and
                           vals["EVNT_TYPE_FK"] == event_type_id):
                       adoption_event_id = event_id
                       break
               self.events[adoption_event_id]["CUPL_FK"] = new_couple_id