Guiding Principles of DATABOY Design
May 19, 2022 19:47:00 GMT -8
Post by Uncle Buddy on May 19, 2022 19:47:00 GMT -8
I may be slowing down on the GEDCOM topic or switching to trying to create a GEDCOM replacement. If the latter, I might start off by trying to use imported GEDCOM to create output that is my new format whose working name so far is DATABOY. If I have any talent for practical revisionism, then it would be better put to use by practicing revisionism vs. beating my head against the same Great Wall of Workarounds as everyone else who's ever tried to use GEDCOM for complex data.
The Refactory is a project I might undertake which intakes GEDCOM and outputs a DATABOY file. The DATABOY file is then imported to your genieware or mine. Like any process of this nature, the developer writing the import file that interfaces between DATABOY and a specific genieware data structure will be doing most of the work. Unless genieware vendors are willing to all use the same data storage structure, that's never going to change.
The advantage of hypothetical DATABOY is that it will be designed to match a data structure that's designed to match real world data instead of GEDCOM's oversimplifications and erroneous assumptions. So theoretically, a DATABOY import should be many times smoother to handle with code than a GEDCOM import. The DATABOY project is less than one day old so I'll stop there. Anyway, my wife's calling me for lunch.
Here are my notes so far:
my_gedcom_replacement
Let's break with the tradition of starting everything with a G that sounds like a J. How about DATABOY? Nah. Two syllables is enough.
DATABOY ain't bad though. It could stand for "Data Be OK Y'all". Or something. But maybe I can think of something better.
Or maybe not. It's starting to grow on me already, and it's only existed for one minute. I might not be able to let go of it. What if it's the best we can ever do, and we just have to live with it till the end of time. Sound familiar?
DATABOY'S slogan: "DATABOY is not a standard for genealogy to conform with. Genealogy is a standard for DATABOY to conform with."
Here are the Guiding Principles of DATABOY Design, in somewhat random order, mostly as they occur to me.
0000. Everything below this point is tentative and optional. I say this first so I can speak freely and directly below, without walking on glass. Everything in this document is subject to being changed, deleted, tempered with better judgement, or replaced with better ideas as experience with working models is gained. Some of what's included below belongs somewhere else and will eventually be weeded out. Some of what's below is redundant, because it's not code, it's human language. For those who believe that human language should be used with extreme terseness and then called a "specification" since it can't be understood and sounds technical, sorry for the redundancy, but actually teaching new ideas to human beings involves repetition. For the terseness lover: your creator did not make you a robot as you requested, and apologizes for the inconvenience.
000. DATABOY is a GEDCOMoid. This means it's like GEDCOM in some ways, but it is not modeled after GEDCOM. It's modeled after SQL database language in terms of how it handles relationships among data. It's like GEDCOM mainly in that it is a text file and a tool for importing and exporting family tree data to and from different software apps.
00. These principles are for guiding DATABOY design, not dictating it. DATABOY will be designed and redesigned by everyone who uses it. There will never be any version numbers or backwards compatibility, so it's up to the dev-user to design his DATABOY input and output to be usable.
0. Genealogy database software is hereafter called "genieware". The term "database" can refer to any data structure including SQL, NOSQL, or anything else that can be allow data to be persisted in computer memory. Data structures used by different genieware providers don't match, so we can't tell anybody what to call anything. DATABOY should be flexible enough so that if a genieware provider prefers to use DATABOY itself as a database, they should be able to pull it off. However, this is not DATABOY's goal.
1. Anything can be linked to anything.
2. All tags are custom, user-defined tags. This will solve GEDCOM's biggest problem: pretending to be an import/export utility while not expecting anyone to actually use its predefined tags. (Dev-users "should" use predefined tags but don't have to... "Should" only works in the movies. OK, well it doesn't work in the movies either, except to define the conflict that the plot centers around since the difference in shoulds from person to person is one of the reasons we are different people.) Dev-users will use any tags they want, and importers will decide where to put each tag in the target data structure. This is how we have to do it anyway, since our data structures don't match. We might get used to having to do this if we stop pretending there are two kinds of tags: official and invented. From now on, they're all invented, they all can either be imported or excepted or ignored, that is the decision of the importing dev. This principle really changes nothing except to remove the underscore prefixed to the user-defined GEDCOM tag. The underscore has heretofore only served to inform us how annoyed we should be with the incoming GEDCOMoid.
3. It's still a text file so it's still slow.
4. To determine what will be kept together on one line, the guiding principle is: Group together in one line those things which can be inserted concurrently to the db for better efficiency. The only lines that should be separate are primary keys and foreign keys. Anything that is not a primary key is a foreign key. So there are no leading line numbers as in GEDCOM, because data which has no foreign key must be on the same line as data that the foreign key goes with.
5. Put the lines in the right order. For example, all zero-tags (which will be called primary keys) should be together so they can efficiently be inserted to a database prior to their need to exist in the database, i.e. when the foreign keys refer to them. This way, the subordinate lines (which will be called foreign keys) can appear anywhere in the file below the primary keys that they refer to. This will force us out of GEDCOM's ridiculous n numbers at the beginning of each line. We will have to think of something more flexible. Like actually having primary keys for every class of element. And actually using foreign keys when they're needed. And using juxtaposition on the same line to indicate one-to-one relationships.
6. Metadata (head and trailer) are kept in a different format so they don't have to be weeded out when trying to parse actual content. Since the HEAD in GEDCOM is in the same (but also annoyingly different) format as other records, the reading utility has to be told repeatedly to ignore it, or else it has to be extracted from the main document and moved out of the way. Making it look different from a data record will allow the reading utility to ignore it unless it's specifically being looked for.
7. The basic structure is modeled on SQL since developers with any common sense are already using SQL and the others can just keep their data in DATABOY if they want, treating it as a database. Those who use neither SQL nor GEDCOMoids to store their data are free to try and get everyone else to conform to their way.
8. Primary keys, foreign keys, one-to-one relationships, one-to-many relationships, and many-to-many relationships define how DATABOY is designed and used.
9. There are no nested structures that don't have a direct correspondence to SQL patterns. The n-number at the beginning of each line of GEDCOM shall never again show its limiting, rigidifying face.
10. Long strings such as complex/nested place names and citations are saved as long strings or chains of elements. The importer decides how to break them up to fit his world. Ex: "line 3 of paragraph 17 of page 99 of chapter 5 of volume 2 of Mad Magazine's Guide to Genealogical Humor" will not be broken into its separate parts anywhere in DATABOY. This is none of our business. The exporter must combine these things. Example: in the source program, Dallas has a primary key and Texas has a primary key. In DATABOY they still have a primary key. If the string "Dallas, Texas, USA" is to be saved separately, it is saved as a string of foreign keys. If the parts don't have separate PKs, such as "page 10, chapter 5", the whole string is saved as a single string.
11. There are no tags, only elements, data, and PKs/FKs (keys). Data have a one-to-one relationship with their elements.
ELEMENTS DATA (examples) KEYS
PERSON male/female, private/public 1, 2, 3...(ditto all below)
PLACE names, lat/long, T/R, jurisdiction
NAME text, type
SOURCE title
etc.
12. Redundancy is always unacceptable. It is blasphemy. If any data ever has to be repeated to make itself clear, then it means that the data structure it's trying to support is meaningless and/or inadequate. Repeating data doesn't replace successful design work.
13. There are no facts, just assertions and conclusions. Assertions are statements of what a source says, made in a computer-data-usable format such as key:value pairs. Example: "marital status: single". Assertions are linked to citations in a one-to-one relationship. Conclusions are linked to assertions in a many-to-many relationship. Conclusions are decisions made by the software user which are optionally linked to assertions and never linked directly to citations. This is because if we are honest, there are no facts, only evidence. So conclusions are linked to citations indirectly through assertions. Assertions and conclusions remain separate and do not affect each other and do not morph into each other.
14. Events and attributes are not the same thing, but they form a single fuzzy category. It's up to the software user to decide how they differ from each other and treat them differently accordingly in his GUI. DATABOY doesn't differentiate between them.
15. Keys are unadorned numerals. If importers like hieroglyphics, they can add as many goofy symbols as they want such as "@f9@" or whatever.
16. Everything is optional. Genealogy is the standard for DATABOY to conform to, not the other way around. Any word with an underscore in front of it should be deleted and ignored by other dev-users, neither imported, handled nor excepted. It is important to DATABOY that all tags are user-defined so that nobody ever mistakes DATABOY for a standard. The standard is genealogy itself. DATABOY is a tool, not a standard.
17. Since DATABOY conforms to genealogy and most genieware currently doesn't, any genieware provider who doesn't want to upgrade their product to conform to genealogy is free to continue to pretend to use GEDCOM. The DATABOY Refactorium Conspiracy (DRC) would, however, like to remind everybody that GEDCOM only pretends to import and export data, and that's why everyone has to use custom tags in order to "use" GEDCOM. In fact, we believe that "using" GEDCOM to import and export data is like using a toothbrush to scrub a floor. It's good exercise, and good punishment. But not a good tool.
18. Since it's actually the importer who has to do most of the work of getting someone else's data into his program, DATABOY's dev-users don't have to pretend that an import/export tool is supposed to do all the work. But since DATABOY is structured to match a non-simplistic SQL database, the amount of work necessary will someday be less than that required for using GEDCOM, after DATABOY's inevitable general acceptance. For example, if an import program has DNA data and the target app has no place to store such data, the dev-user can ignore the DNA data, create new tables to store it in, put it in exceptions and tell the user his data can't be imported, or delete it from the import file and pretend it never happened.
19. The family is not an element of family history. Genealogy is about definite things, and a family is a fluid thing. To define parent, child, sibling, cousin, aunt, uncle, grandparent, and so on, define who are the parents of each child and who are the partners of each person. The rest can be gleaned from these biologically basic relationships and displayed in the GUI however the developer sees fit, such as family units if desired.
20. Lines are primary keys and foreign keys. One-to-one relationships are expressed on one line. One-to-many relationships are expressed by a single foreign key appearing on the "many" line. Many-to-many relationshps are expressed by multiple foreign keys appearing on the same line.
21. One-to-one relationships are expressed on one line of DATABOY because they generally belong in one line of a database table, so are most efficiently expressed in a single line of DATABOY. Everything else is linked by way of foreign keys which refer to primary keys.
22. Anyone who is gender-sensitive is free to say or write "DATAGIRL", "DATAWOMAN", "DATAPAL", "DATAROCK", "DATACROCK", "DATAPERSON", "DATATHING", "NOTGEDCOM", "XWYTERSDDGSK", or whatever trips their trigger. DATABOY tries to specialize in not telling anyone how to label anything including itself.
23. Sources are linked to citations in a one-to-many relationship. Repositories are linked to sources in a many-to-many relationship.
23. A suggested extension for DATABOY files is .dtb, but it doesn't matter. The extension ".ged" doesn't do anything either. These are just text files.
24. It seems like a good idea to store everything that will not be imported so it can be passed on to the next program in an export. This is a gesture of friendship among genieware developers and users as if to say, "The data you sent me is not relevant to me, but your work might be relevant to somebody, so it will not be discarded."
25. Alternate parental relationships such as adoptive parents, foster parents and guardians should be given optionally equal status as biological parents. Instead, alternate parents can be stored as adjunct relationships. Both these options should be available since, for example, not all foster parents are temporary and not all adoptive parents are permanent.
26. Adjunct relationships are treated the same as biological ones, i.e. the person is stored in the same way as a related person. The adjunct role such as "nannie" or "arresting officer" is stored in a separate table and linked to the person.
27. Person names are not attributes. They are elements. They have their own primary key. This allows one person to have many names. Different spellings are different names. All names must have a type, such as "birth name", "a.k.a.", "stage name", "mis-spelling", "alternate spelling", "placeholder name" such as "___" for people with unknown names, etc. Symbol characters, not letter characters, should be used for unknown names. For example, use "---" or "_____" or "?", not "unknown" or "UNK".
28. DATABOY is gender neutral. While we respect the right of anyone to do what they want with gender definitions, we do not build any political trends of the day into our tool. Political correctness changes with the times and it's DATABOY's intent to remain flexible by not incorporating trends or trying to appear modern or progressive or conservative or radical or new-fangled or old-fashioned. Genealogy is about the past and it has to be apolitical. We do respect biological constraints, for example, each person has a female mother and a male father, as long as this is true in the real world.
29. Census is not an event. It's a source. Residence is an event.
30. Zip codes were not used before the 1960s. They change all the time. They should not be used to describe old-time places. They are irrelevant to genealogy.
31. The DATABOY Refactorium Conspiracy (DRC) will provide examples of how to translate GEDCOM import files into DATABOY import files. This tool will be called The Refactory. DATABOY will use Python files to demonstrate how this can be done. We will also provide sample database structures in Python and SQLite, designed to match real-world relationships, so that dev-users who've been hobbled by decades of GEDCOM's limitations can free themselves and rehabilitate their apps' ability to fulfill genealogy's needs with accuracy and completeness.
The Refactory is a project I might undertake which intakes GEDCOM and outputs a DATABOY file. The DATABOY file is then imported to your genieware or mine. Like any process of this nature, the developer writing the import file that interfaces between DATABOY and a specific genieware data structure will be doing most of the work. Unless genieware vendors are willing to all use the same data storage structure, that's never going to change.
The advantage of hypothetical DATABOY is that it will be designed to match a data structure that's designed to match real world data instead of GEDCOM's oversimplifications and erroneous assumptions. So theoretically, a DATABOY import should be many times smoother to handle with code than a GEDCOM import. The DATABOY project is less than one day old so I'll stop there. Anyway, my wife's calling me for lunch.
Here are my notes so far:
my_gedcom_replacement
Let's break with the tradition of starting everything with a G that sounds like a J. How about DATABOY? Nah. Two syllables is enough.
DATABOY ain't bad though. It could stand for "Data Be OK Y'all". Or something. But maybe I can think of something better.
Or maybe not. It's starting to grow on me already, and it's only existed for one minute. I might not be able to let go of it. What if it's the best we can ever do, and we just have to live with it till the end of time. Sound familiar?
DATABOY'S slogan: "DATABOY is not a standard for genealogy to conform with. Genealogy is a standard for DATABOY to conform with."
Here are the Guiding Principles of DATABOY Design, in somewhat random order, mostly as they occur to me.
0000. Everything below this point is tentative and optional. I say this first so I can speak freely and directly below, without walking on glass. Everything in this document is subject to being changed, deleted, tempered with better judgement, or replaced with better ideas as experience with working models is gained. Some of what's included below belongs somewhere else and will eventually be weeded out. Some of what's below is redundant, because it's not code, it's human language. For those who believe that human language should be used with extreme terseness and then called a "specification" since it can't be understood and sounds technical, sorry for the redundancy, but actually teaching new ideas to human beings involves repetition. For the terseness lover: your creator did not make you a robot as you requested, and apologizes for the inconvenience.
000. DATABOY is a GEDCOMoid. This means it's like GEDCOM in some ways, but it is not modeled after GEDCOM. It's modeled after SQL database language in terms of how it handles relationships among data. It's like GEDCOM mainly in that it is a text file and a tool for importing and exporting family tree data to and from different software apps.
00. These principles are for guiding DATABOY design, not dictating it. DATABOY will be designed and redesigned by everyone who uses it. There will never be any version numbers or backwards compatibility, so it's up to the dev-user to design his DATABOY input and output to be usable.
0. Genealogy database software is hereafter called "genieware". The term "database" can refer to any data structure including SQL, NOSQL, or anything else that can be allow data to be persisted in computer memory. Data structures used by different genieware providers don't match, so we can't tell anybody what to call anything. DATABOY should be flexible enough so that if a genieware provider prefers to use DATABOY itself as a database, they should be able to pull it off. However, this is not DATABOY's goal.
1. Anything can be linked to anything.
2. All tags are custom, user-defined tags. This will solve GEDCOM's biggest problem: pretending to be an import/export utility while not expecting anyone to actually use its predefined tags. (Dev-users "should" use predefined tags but don't have to... "Should" only works in the movies. OK, well it doesn't work in the movies either, except to define the conflict that the plot centers around since the difference in shoulds from person to person is one of the reasons we are different people.) Dev-users will use any tags they want, and importers will decide where to put each tag in the target data structure. This is how we have to do it anyway, since our data structures don't match. We might get used to having to do this if we stop pretending there are two kinds of tags: official and invented. From now on, they're all invented, they all can either be imported or excepted or ignored, that is the decision of the importing dev. This principle really changes nothing except to remove the underscore prefixed to the user-defined GEDCOM tag. The underscore has heretofore only served to inform us how annoyed we should be with the incoming GEDCOMoid.
3. It's still a text file so it's still slow.
4. To determine what will be kept together on one line, the guiding principle is: Group together in one line those things which can be inserted concurrently to the db for better efficiency. The only lines that should be separate are primary keys and foreign keys. Anything that is not a primary key is a foreign key. So there are no leading line numbers as in GEDCOM, because data which has no foreign key must be on the same line as data that the foreign key goes with.
5. Put the lines in the right order. For example, all zero-tags (which will be called primary keys) should be together so they can efficiently be inserted to a database prior to their need to exist in the database, i.e. when the foreign keys refer to them. This way, the subordinate lines (which will be called foreign keys) can appear anywhere in the file below the primary keys that they refer to. This will force us out of GEDCOM's ridiculous n numbers at the beginning of each line. We will have to think of something more flexible. Like actually having primary keys for every class of element. And actually using foreign keys when they're needed. And using juxtaposition on the same line to indicate one-to-one relationships.
6. Metadata (head and trailer) are kept in a different format so they don't have to be weeded out when trying to parse actual content. Since the HEAD in GEDCOM is in the same (but also annoyingly different) format as other records, the reading utility has to be told repeatedly to ignore it, or else it has to be extracted from the main document and moved out of the way. Making it look different from a data record will allow the reading utility to ignore it unless it's specifically being looked for.
7. The basic structure is modeled on SQL since developers with any common sense are already using SQL and the others can just keep their data in DATABOY if they want, treating it as a database. Those who use neither SQL nor GEDCOMoids to store their data are free to try and get everyone else to conform to their way.
8. Primary keys, foreign keys, one-to-one relationships, one-to-many relationships, and many-to-many relationships define how DATABOY is designed and used.
9. There are no nested structures that don't have a direct correspondence to SQL patterns. The n-number at the beginning of each line of GEDCOM shall never again show its limiting, rigidifying face.
10. Long strings such as complex/nested place names and citations are saved as long strings or chains of elements. The importer decides how to break them up to fit his world. Ex: "line 3 of paragraph 17 of page 99 of chapter 5 of volume 2 of Mad Magazine's Guide to Genealogical Humor" will not be broken into its separate parts anywhere in DATABOY. This is none of our business. The exporter must combine these things. Example: in the source program, Dallas has a primary key and Texas has a primary key. In DATABOY they still have a primary key. If the string "Dallas, Texas, USA" is to be saved separately, it is saved as a string of foreign keys. If the parts don't have separate PKs, such as "page 10, chapter 5", the whole string is saved as a single string.
11. There are no tags, only elements, data, and PKs/FKs (keys). Data have a one-to-one relationship with their elements.
ELEMENTS DATA (examples) KEYS
PERSON male/female, private/public 1, 2, 3...(ditto all below)
PLACE names, lat/long, T/R, jurisdiction
NAME text, type
SOURCE title
etc.
12. Redundancy is always unacceptable. It is blasphemy. If any data ever has to be repeated to make itself clear, then it means that the data structure it's trying to support is meaningless and/or inadequate. Repeating data doesn't replace successful design work.
13. There are no facts, just assertions and conclusions. Assertions are statements of what a source says, made in a computer-data-usable format such as key:value pairs. Example: "marital status: single". Assertions are linked to citations in a one-to-one relationship. Conclusions are linked to assertions in a many-to-many relationship. Conclusions are decisions made by the software user which are optionally linked to assertions and never linked directly to citations. This is because if we are honest, there are no facts, only evidence. So conclusions are linked to citations indirectly through assertions. Assertions and conclusions remain separate and do not affect each other and do not morph into each other.
14. Events and attributes are not the same thing, but they form a single fuzzy category. It's up to the software user to decide how they differ from each other and treat them differently accordingly in his GUI. DATABOY doesn't differentiate between them.
15. Keys are unadorned numerals. If importers like hieroglyphics, they can add as many goofy symbols as they want such as "@f9@" or whatever.
16. Everything is optional. Genealogy is the standard for DATABOY to conform to, not the other way around. Any word with an underscore in front of it should be deleted and ignored by other dev-users, neither imported, handled nor excepted. It is important to DATABOY that all tags are user-defined so that nobody ever mistakes DATABOY for a standard. The standard is genealogy itself. DATABOY is a tool, not a standard.
17. Since DATABOY conforms to genealogy and most genieware currently doesn't, any genieware provider who doesn't want to upgrade their product to conform to genealogy is free to continue to pretend to use GEDCOM. The DATABOY Refactorium Conspiracy (DRC) would, however, like to remind everybody that GEDCOM only pretends to import and export data, and that's why everyone has to use custom tags in order to "use" GEDCOM. In fact, we believe that "using" GEDCOM to import and export data is like using a toothbrush to scrub a floor. It's good exercise, and good punishment. But not a good tool.
18. Since it's actually the importer who has to do most of the work of getting someone else's data into his program, DATABOY's dev-users don't have to pretend that an import/export tool is supposed to do all the work. But since DATABOY is structured to match a non-simplistic SQL database, the amount of work necessary will someday be less than that required for using GEDCOM, after DATABOY's inevitable general acceptance. For example, if an import program has DNA data and the target app has no place to store such data, the dev-user can ignore the DNA data, create new tables to store it in, put it in exceptions and tell the user his data can't be imported, or delete it from the import file and pretend it never happened.
19. The family is not an element of family history. Genealogy is about definite things, and a family is a fluid thing. To define parent, child, sibling, cousin, aunt, uncle, grandparent, and so on, define who are the parents of each child and who are the partners of each person. The rest can be gleaned from these biologically basic relationships and displayed in the GUI however the developer sees fit, such as family units if desired.
20. Lines are primary keys and foreign keys. One-to-one relationships are expressed on one line. One-to-many relationships are expressed by a single foreign key appearing on the "many" line. Many-to-many relationshps are expressed by multiple foreign keys appearing on the same line.
21. One-to-one relationships are expressed on one line of DATABOY because they generally belong in one line of a database table, so are most efficiently expressed in a single line of DATABOY. Everything else is linked by way of foreign keys which refer to primary keys.
22. Anyone who is gender-sensitive is free to say or write "DATAGIRL", "DATAWOMAN", "DATAPAL", "DATAROCK", "DATACROCK", "DATAPERSON", "DATATHING", "NOTGEDCOM", "XWYTERSDDGSK", or whatever trips their trigger. DATABOY tries to specialize in not telling anyone how to label anything including itself.
23. Sources are linked to citations in a one-to-many relationship. Repositories are linked to sources in a many-to-many relationship.
23. A suggested extension for DATABOY files is .dtb, but it doesn't matter. The extension ".ged" doesn't do anything either. These are just text files.
24. It seems like a good idea to store everything that will not be imported so it can be passed on to the next program in an export. This is a gesture of friendship among genieware developers and users as if to say, "The data you sent me is not relevant to me, but your work might be relevant to somebody, so it will not be discarded."
25. Alternate parental relationships such as adoptive parents, foster parents and guardians should be given optionally equal status as biological parents. Instead, alternate parents can be stored as adjunct relationships. Both these options should be available since, for example, not all foster parents are temporary and not all adoptive parents are permanent.
26. Adjunct relationships are treated the same as biological ones, i.e. the person is stored in the same way as a related person. The adjunct role such as "nannie" or "arresting officer" is stored in a separate table and linked to the person.
27. Person names are not attributes. They are elements. They have their own primary key. This allows one person to have many names. Different spellings are different names. All names must have a type, such as "birth name", "a.k.a.", "stage name", "mis-spelling", "alternate spelling", "placeholder name" such as "___" for people with unknown names, etc. Symbol characters, not letter characters, should be used for unknown names. For example, use "---" or "_____" or "?", not "unknown" or "UNK".
28. DATABOY is gender neutral. While we respect the right of anyone to do what they want with gender definitions, we do not build any political trends of the day into our tool. Political correctness changes with the times and it's DATABOY's intent to remain flexible by not incorporating trends or trying to appear modern or progressive or conservative or radical or new-fangled or old-fashioned. Genealogy is about the past and it has to be apolitical. We do respect biological constraints, for example, each person has a female mother and a male father, as long as this is true in the real world.
29. Census is not an event. It's a source. Residence is an event.
30. Zip codes were not used before the 1960s. They change all the time. They should not be used to describe old-time places. They are irrelevant to genealogy.
31. The DATABOY Refactorium Conspiracy (DRC) will provide examples of how to translate GEDCOM import files into DATABOY import files. This tool will be called The Refactory. DATABOY will use Python files to demonstrate how this can be done. We will also provide sample database structures in Python and SQLite, designed to match real-world relationships, so that dev-users who've been hobbled by decades of GEDCOM's limitations can free themselves and rehabilitate their apps' ability to fulfill genealogy's needs with accuracy and completeness.