Treebard's Policy on GEDCOM Imports
May 3, 2022 15:39:07 GMT -8
Post by Uncle Buddy on May 3, 2022 15:39:07 GMT -8
Treebard GPS is a showcase of genieware functionalities, not meant to be a full-featured genieware. It's not created specifically for many people to build big family trees. If there is ever a Treebard v.0.0.0, that will be the start of the backwardly compatible genieware that genealogists would use to do their daily work.
Treebard GPS has two main categories of thrust. GUI and database. The database is meant to point the way to a data structure that could be complete and accurate enough, a good enough reflection of the real world, that it could replace GEDCOM. Every vendor could use the same back-end, a true SQL database like Treebard's or better, and each vendor's respective selling points would be its GUI and features list. The user doesn't care what the database does, until it does it wrong. Since every vendor currently uses a different data structure, there is an unending jousting with windmills attitude, a romantic quest for a mythical means to accurately and completely import and export data among different apps. Everyone knows that GEDCOM has failed, but there's a carrot-on-a-stick notion still out there that GEDCOM can be fixed. But just because something is inadequate doesn't mean it can be fixed. Treebard's database structure or one even better, as a common database running the back-end of the various vendors, is the only way to solve the problem simply and well.
With that in mind, it seems odd that I'm currently spending all my time making it possible to import family trees to Treebard using GEDCOM. Well, I need to know what it is I'm trying to replace, know what I mean? And until you figure it out for yourself, you don't understand it. The more complex the problem, the more this is true.
However it would be silly for Treebard, under the circumstances outlined above, to handle custom tags. Besides the fact that GEDCOM is incompatible with SQL, user-defined tags are the very reason that GEDCOM actually does not import and export very much of our genealogical data. The software vendors, in order to protect their secret data structures, have to pay for the luxury of secrecy by 1) doing most of the import/export programming themselves or 2) structuring their back-end to match GEDCOM's idiosyncrasies. Being dishonest about the problem prevents any real solution. Pretending that custom tags can reasonably fill in the gaps is just going to keep the pot of discontent simmering.
So anyway, Treebard will import real GEDCOM tags, written correctly according to spec, and put literally everything else in an exceptions report for the user to input manually through Treebard's GUI. The exception report, unlike the ones I've seen, will be succinct and readable. It will be for the user to read and instantly understand, without any GEDCOM jargon at all. It will include instructions on how to use it. Since Treebard doesn't currently and never will use a family ID (unless someone can tell me why such a redundant thing should exist), I'll try to import the individuals and the pertinent data and just ignore the redundant, unneeded junk data. But I'll have to export family tags, no?
I don't know what I'm going to do about exporting GEDCOM. I haven't gotten there yet, but it should be quite a challenge since Treebard's data structure is SQL and GEDCOM breaks SQL rules all over the place. No doubt GEDCOM 7 is better in some ways, but we are beyond needing incremental improvements. If you break your bowling arm, you have to wear a cast, despite the inconvenience, 24/7 for a while. You can't take it off for an hour or two so you can go bowling.
Of course the right way to export a database is for all the GUIs to rest upon the same back-end. Nothing could be more logical and I guess I'm about to start repeating myself, so I'd better stop there.
But I can't, so here's a wee rant for Treebard's real fans.
One reason GEDCOM is still clinging to life is that programmers enjoy solving problems. GEDCOM is fertile ground for this, for various reasons, but most especially because of user-defined or custom tags, which is a nice way of saying illegal GEDCOM.
If programmers didn't enjoy solving problems so much, GEDCOM would have been replaced long ago with a SQL database.
Treebard GPS has two main categories of thrust. GUI and database. The database is meant to point the way to a data structure that could be complete and accurate enough, a good enough reflection of the real world, that it could replace GEDCOM. Every vendor could use the same back-end, a true SQL database like Treebard's or better, and each vendor's respective selling points would be its GUI and features list. The user doesn't care what the database does, until it does it wrong. Since every vendor currently uses a different data structure, there is an unending jousting with windmills attitude, a romantic quest for a mythical means to accurately and completely import and export data among different apps. Everyone knows that GEDCOM has failed, but there's a carrot-on-a-stick notion still out there that GEDCOM can be fixed. But just because something is inadequate doesn't mean it can be fixed. Treebard's database structure or one even better, as a common database running the back-end of the various vendors, is the only way to solve the problem simply and well.
With that in mind, it seems odd that I'm currently spending all my time making it possible to import family trees to Treebard using GEDCOM. Well, I need to know what it is I'm trying to replace, know what I mean? And until you figure it out for yourself, you don't understand it. The more complex the problem, the more this is true.
However it would be silly for Treebard, under the circumstances outlined above, to handle custom tags. Besides the fact that GEDCOM is incompatible with SQL, user-defined tags are the very reason that GEDCOM actually does not import and export very much of our genealogical data. The software vendors, in order to protect their secret data structures, have to pay for the luxury of secrecy by 1) doing most of the import/export programming themselves or 2) structuring their back-end to match GEDCOM's idiosyncrasies. Being dishonest about the problem prevents any real solution. Pretending that custom tags can reasonably fill in the gaps is just going to keep the pot of discontent simmering.
So anyway, Treebard will import real GEDCOM tags, written correctly according to spec, and put literally everything else in an exceptions report for the user to input manually through Treebard's GUI. The exception report, unlike the ones I've seen, will be succinct and readable. It will be for the user to read and instantly understand, without any GEDCOM jargon at all. It will include instructions on how to use it. Since Treebard doesn't currently and never will use a family ID (unless someone can tell me why such a redundant thing should exist), I'll try to import the individuals and the pertinent data and just ignore the redundant, unneeded junk data. But I'll have to export family tags, no?
I don't know what I'm going to do about exporting GEDCOM. I haven't gotten there yet, but it should be quite a challenge since Treebard's data structure is SQL and GEDCOM breaks SQL rules all over the place. No doubt GEDCOM 7 is better in some ways, but we are beyond needing incremental improvements. If you break your bowling arm, you have to wear a cast, despite the inconvenience, 24/7 for a while. You can't take it off for an hour or two so you can go bowling.
Of course the right way to export a database is for all the GUIs to rest upon the same back-end. Nothing could be more logical and I guess I'm about to start repeating myself, so I'd better stop there.
But I can't, so here's a wee rant for Treebard's real fans.
One reason GEDCOM is still clinging to life is that programmers enjoy solving problems. GEDCOM is fertile ground for this, for various reasons, but most especially because of user-defined or custom tags, which is a nice way of saying illegal GEDCOM.
If programmers didn't enjoy solving problems so much, GEDCOM would have been replaced long ago with a SQL database.