UNIGEDS definition--to replace GEDCOM--must be squeaky clean
May 7, 2024 0:33:48 GMT -8
Post by Uncle Buddy on May 7, 2024 0:33:48 GMT -8
What is clean? That's when you and dirt are separated. Funny thing about dirt, it accumulates all by itself, but to get rid of it requires sustained effort.
What is a definition? It's a limit. A separation, a boundary. To define something you have to say what it is and what it is not.
GEDCOM as used by genieware vendors is full of vendor cruft. If vendors use UNIGEDS in this way, it won't catch on. As creator of Treebard, the first genieware to use UNIGEDS as its back-end, I have to make sure that UNIGEDS is defined right.
The primary elements of genealogy are the things that pre-exist genealogy out in the world. Persons, places, events, assertions, citations and sources. Maybe a few other things.
UNIGEDS has to be defined (limited, made clean and thus universally useful) for the transfer of primary genealogical data. It can't store vendor data, app data, or user data. When importing a family tree from some other program, the last thing we want to see is some vendor's GUI solution being stored in a GEDCOM file with a bunch of custom tags. That's one reason vendors should not use GEDCOM as their GUI's back-end; doing so guarantees filthy .ged files packed full of irrelevant noise.
So I've been working hard. It just hit me maybe about a week ago, if UNIGEDS is to be useful to everyone, it has to ignore all app data, user data, vendor data. How does a vendor work out the creation of charts, reports, and other output and products? Not UNIGEDS' problem. Genieware output is not primary to genealogy, as essential as it is to the genieware (so the genieware will have secondary features to brag about in marketing the app), the primary data (facts about the world) have to be kept separate from the application's moving parts. Mixing them together guarantees a tool as klunky and cumbersome as GEDCOM.
I've removed many tables from UNIGEDS, some of which I'd never used since I'm not very interested in most secondary features of genieware. I am very interested in themes/color schemes/font sizes and the like. I had to take this, my pet feature, out of UNIGEDS while leaving it in Treeabrd. I've created a new way of storing app data in Treebard. SQL wasn't needed for this sort of configuration stuff anyway, some of the tables only had one row which is not what SQL is needed for. My color schemes table had lots of rows, and it now works just as well but this data is stored in a text file that is rewritten if the user edits, creates of deletes a theme.
This is a huge step, a lot of work, but what to do with notes?
In a sense, Note is a catch-all category for data about the real world (the facts which pre-existed genealogy) that don't fit somewhere else. And whatever else someone wants to use them for. We can't tell users what they can do or not do with a note. In Treebard we make notes re-usable, every note has an ID number and can be linked to any number of primary elements. For one-off small notations there's the "particulars" field on the events & attributes table.
But my notes_links SQL junction table has fields that don't belong in UNIGEDS. To help the user re-use an existing note, so he doesn't have to find/copy/paste existing notes, each note has a title. Each note dialog has a table of contents so you can see all the notes linked to the current element. The table of contents lists the titles of linked notes. You select the title in order to display the note. You can reorder the table of contents.
So I have to make a place outside of UNIGEDS to store app data like note_topic and especially note_topic_order. I have to decide whether to move the notes themselves out of UNIGEDS. I don't want to, because UNIGEDS is meant to be not just Treebard's back-end, but potentially everyone's back-end. Genieware needs notes, they take up the slack for data that is too detailed or not easily pigeonholed in the main categories.
It's similar to the current_element problem. Treebard has a current_person, a current_place and a current_source. But just because there's a current_person datum that has to be stored separately from UNIGEDS to keep UNIGEDS from accumulating vendor cruft, that doesn't mean that persons now have to be stored outside of the UNIGEDS back-end. I ended up storing references to the current elements in family_tree.txt with other stuff like the tree title and directory name. Here the current person ID can also be stored. That's a compromise, since there's no foreign key enforcement between a text file and a SQL file. But there's a big advantage to doing only one thing with SQL and handling all the app/user/vendor data in a different way. Using a separate SQL database for app-wide data worked, but connecting to both the app-wide db and the tree db led to my least favorite thing: boilerplate code. And it promoted the mixing of oil and water which is something that is hard to maintain.
What is a definition? It's a limit. A separation, a boundary. To define something you have to say what it is and what it is not.
GEDCOM as used by genieware vendors is full of vendor cruft. If vendors use UNIGEDS in this way, it won't catch on. As creator of Treebard, the first genieware to use UNIGEDS as its back-end, I have to make sure that UNIGEDS is defined right.
The primary elements of genealogy are the things that pre-exist genealogy out in the world. Persons, places, events, assertions, citations and sources. Maybe a few other things.
UNIGEDS has to be defined (limited, made clean and thus universally useful) for the transfer of primary genealogical data. It can't store vendor data, app data, or user data. When importing a family tree from some other program, the last thing we want to see is some vendor's GUI solution being stored in a GEDCOM file with a bunch of custom tags. That's one reason vendors should not use GEDCOM as their GUI's back-end; doing so guarantees filthy .ged files packed full of irrelevant noise.
So I've been working hard. It just hit me maybe about a week ago, if UNIGEDS is to be useful to everyone, it has to ignore all app data, user data, vendor data. How does a vendor work out the creation of charts, reports, and other output and products? Not UNIGEDS' problem. Genieware output is not primary to genealogy, as essential as it is to the genieware (so the genieware will have secondary features to brag about in marketing the app), the primary data (facts about the world) have to be kept separate from the application's moving parts. Mixing them together guarantees a tool as klunky and cumbersome as GEDCOM.
I've removed many tables from UNIGEDS, some of which I'd never used since I'm not very interested in most secondary features of genieware. I am very interested in themes/color schemes/font sizes and the like. I had to take this, my pet feature, out of UNIGEDS while leaving it in Treeabrd. I've created a new way of storing app data in Treebard. SQL wasn't needed for this sort of configuration stuff anyway, some of the tables only had one row which is not what SQL is needed for. My color schemes table had lots of rows, and it now works just as well but this data is stored in a text file that is rewritten if the user edits, creates of deletes a theme.
This is a huge step, a lot of work, but what to do with notes?
In a sense, Note is a catch-all category for data about the real world (the facts which pre-existed genealogy) that don't fit somewhere else. And whatever else someone wants to use them for. We can't tell users what they can do or not do with a note. In Treebard we make notes re-usable, every note has an ID number and can be linked to any number of primary elements. For one-off small notations there's the "particulars" field on the events & attributes table.
But my notes_links SQL junction table has fields that don't belong in UNIGEDS. To help the user re-use an existing note, so he doesn't have to find/copy/paste existing notes, each note has a title. Each note dialog has a table of contents so you can see all the notes linked to the current element. The table of contents lists the titles of linked notes. You select the title in order to display the note. You can reorder the table of contents.
So I have to make a place outside of UNIGEDS to store app data like note_topic and especially note_topic_order. I have to decide whether to move the notes themselves out of UNIGEDS. I don't want to, because UNIGEDS is meant to be not just Treebard's back-end, but potentially everyone's back-end. Genieware needs notes, they take up the slack for data that is too detailed or not easily pigeonholed in the main categories.
It's similar to the current_element problem. Treebard has a current_person, a current_place and a current_source. But just because there's a current_person datum that has to be stored separately from UNIGEDS to keep UNIGEDS from accumulating vendor cruft, that doesn't mean that persons now have to be stored outside of the UNIGEDS back-end. I ended up storing references to the current elements in family_tree.txt with other stuff like the tree title and directory name. Here the current person ID can also be stored. That's a compromise, since there's no foreign key enforcement between a text file and a SQL file. But there's a big advantage to doing only one thing with SQL and handling all the app/user/vendor data in a different way. Using a separate SQL database for app-wide data worked, but connecting to both the app-wide db and the tree db led to my least favorite thing: boilerplate code. And it promoted the mixing of oil and water which is something that is hard to maintain.