The medium for a standard has to be worth standardizing
May 6, 2022 23:51:38 GMT -8
Post by Uncle Buddy on May 6, 2022 23:51:38 GMT -8
To call GEDCOM a "standard" is to suggest that genealogy software developers should be conforming to GEDCOM. But GEDCOM is not a standard. It is a utility, a tool. It might be potentially a much better tool than what it's given credit for being, but until it stops allowing non-standard use, it couldn't possibly be a standard. As long as the main perceived means of making it usable is to skirt its rules--even if that is a mis-perception--it's a monkey wrench being used as a hammer. While that is still a tool (the wrong tool), it isn't a standard.
Standards are about control and conformity. No, I'm not about to launch into a diatribe on the deity of my first six childhoods, Individuality. "Do your own thing" does have its place, even in genealogy. Even in genieware development: it's called User Interface. But in case anyone hasn't noticed, we're having a problem with importing and exporting our files in a way that increases our efficiency instead of decreasing our efficiency. Let's not argue about whether developers are purposely locking users into their product by playing dumb about how GEDCOM is supposed to work (using real GEDCOM tags). If a developer plots to take away the user's choices, his product is not long for the scrap heap. We don't have to concern ourselves with developers who don't respect their customers' interests, because they are their own worst enemy.
To be honest, this argument isn't really about whether GEDCOM is or is not a "standard". I have my little word play, but who cares? The only reason for having this argument is that we do care about usability, practicality, productivity, accuracy and completeness. To argue that GEDCOM cannot do these things might be a bad idea, because GEDCOM can probably do most of these things and could certainly be fixed to do anything we want it to do (except to do it at the speed of computing). The real problem is that we do need a standard for import and export. And it boils down to this: GEDCOM doesn't deserve to be that standard. I've covered my reasons in previous posts. What we need is a programming medium (not a text file) that actually deserves the hard work that someone will have to do of making out of it a standard that will work for everybody. GEDCOM isn't that medium.
This is where individuality has to fall by the wayside. Every program out there, from Clooze to Gramps, will have to make a hard decision: will we join a consortium of companies that WANT our data to be importable and exportable in its full accuracy and completeness? Or do we want to be a fringe product that users will basically only use by mistake? The harsh reality, for some of these companies, is that not adhering to whatever the standard is will mean they don't belong. How can being an outsider profit any software company? I'd argue that even among today's geniewares, if you could rate them according to how well they handle import and export, you might find a correlation with how well liked the program is.
There's only one kind of standard that will work for transferring data. The kind that transfers data correctly: accurately and completely. There are other criteria that GEDCOM ignores such as how long it takes to get the transfer done. GEDCOM lost the war many battles ago by not showing up. But they didn't just lose by default. GEDCOM's creators maybe cut their losses by not joining the fray. Then along comes Johnny-come-lately, GEDCOM 7. Did somebody say something? I must have fallen asleep. Last I recall, we were not talking about something that was abandoned 20 years ago. We were talking about a real standard, one that works well without our having to put on blinders and make excuses for it, like, "Developers are using it all wrong." It's used willy-nilly because it's a text file, so anyone who can read "Run Dick run" can fiddle with GEDCOM. GEDCOM was born with the flaw of being too accessible.
Standards committees will not solve this problem. It will be solved by the mass appeal of a solution created by one person or company or team of doers. Not committee types: "Let's have a meeting and discuss where to hold our next meeting." Yikes. Doers, I said. Creators of software, not debaters and organization-organizing organizers. Did you hear the one about the new congressional committee that was formed to study why there are too many congressional committees? It literally only takes one person of action to solve this problem.
The simple version: while committees play politics and try to polish up an image in the genealogy community, somebody who doesn't care about all that stuff is gonna actually make the time to replace GEDCOM.
The nice version: most organizations fail because running the organization becomes their first priority, then their only priority, then they reorganize and start over with a new, more officialoid name.
OK, so that wasn't very nice.
My pet solution to the file sharing problem in genealogy is a medium that is way harder to use wrong than it is to use right: SQL. My arguments precede this post. The question is, how many of today's players would prove willing to accept a standardized SQL structure that reflects real people, places, relationships and events in complete and accurate detail, when it means giving up the data storage structure that they're already using? Would vendors stop fiddling with secondary features and glitter-glam fluff long enough to replace their back-end with a structure that makes their customers' labor of love really sharable?
The right product will answer this question for me. The right database structure will make new products viable and old products obsolete. But isn't that how everything works anyway, if you wait long enough? The chances of some truly motivated developer not coming up with a solution to this problem are pretty slim, considering the popularity of genealogy.
Standards are about control and conformity. No, I'm not about to launch into a diatribe on the deity of my first six childhoods, Individuality. "Do your own thing" does have its place, even in genealogy. Even in genieware development: it's called User Interface. But in case anyone hasn't noticed, we're having a problem with importing and exporting our files in a way that increases our efficiency instead of decreasing our efficiency. Let's not argue about whether developers are purposely locking users into their product by playing dumb about how GEDCOM is supposed to work (using real GEDCOM tags). If a developer plots to take away the user's choices, his product is not long for the scrap heap. We don't have to concern ourselves with developers who don't respect their customers' interests, because they are their own worst enemy.
To be honest, this argument isn't really about whether GEDCOM is or is not a "standard". I have my little word play, but who cares? The only reason for having this argument is that we do care about usability, practicality, productivity, accuracy and completeness. To argue that GEDCOM cannot do these things might be a bad idea, because GEDCOM can probably do most of these things and could certainly be fixed to do anything we want it to do (except to do it at the speed of computing). The real problem is that we do need a standard for import and export. And it boils down to this: GEDCOM doesn't deserve to be that standard. I've covered my reasons in previous posts. What we need is a programming medium (not a text file) that actually deserves the hard work that someone will have to do of making out of it a standard that will work for everybody. GEDCOM isn't that medium.
This is where individuality has to fall by the wayside. Every program out there, from Clooze to Gramps, will have to make a hard decision: will we join a consortium of companies that WANT our data to be importable and exportable in its full accuracy and completeness? Or do we want to be a fringe product that users will basically only use by mistake? The harsh reality, for some of these companies, is that not adhering to whatever the standard is will mean they don't belong. How can being an outsider profit any software company? I'd argue that even among today's geniewares, if you could rate them according to how well they handle import and export, you might find a correlation with how well liked the program is.
There's only one kind of standard that will work for transferring data. The kind that transfers data correctly: accurately and completely. There are other criteria that GEDCOM ignores such as how long it takes to get the transfer done. GEDCOM lost the war many battles ago by not showing up. But they didn't just lose by default. GEDCOM's creators maybe cut their losses by not joining the fray. Then along comes Johnny-come-lately, GEDCOM 7. Did somebody say something? I must have fallen asleep. Last I recall, we were not talking about something that was abandoned 20 years ago. We were talking about a real standard, one that works well without our having to put on blinders and make excuses for it, like, "Developers are using it all wrong." It's used willy-nilly because it's a text file, so anyone who can read "Run Dick run" can fiddle with GEDCOM. GEDCOM was born with the flaw of being too accessible.
Standards committees will not solve this problem. It will be solved by the mass appeal of a solution created by one person or company or team of doers. Not committee types: "Let's have a meeting and discuss where to hold our next meeting." Yikes. Doers, I said. Creators of software, not debaters and organization-organizing organizers. Did you hear the one about the new congressional committee that was formed to study why there are too many congressional committees? It literally only takes one person of action to solve this problem.
The simple version: while committees play politics and try to polish up an image in the genealogy community, somebody who doesn't care about all that stuff is gonna actually make the time to replace GEDCOM.
The nice version: most organizations fail because running the organization becomes their first priority, then their only priority, then they reorganize and start over with a new, more officialoid name.
OK, so that wasn't very nice.
My pet solution to the file sharing problem in genealogy is a medium that is way harder to use wrong than it is to use right: SQL. My arguments precede this post. The question is, how many of today's players would prove willing to accept a standardized SQL structure that reflects real people, places, relationships and events in complete and accurate detail, when it means giving up the data storage structure that they're already using? Would vendors stop fiddling with secondary features and glitter-glam fluff long enough to replace their back-end with a structure that makes their customers' labor of love really sharable?
The right product will answer this question for me. The right database structure will make new products viable and old products obsolete. But isn't that how everything works anyway, if you wait long enough? The chances of some truly motivated developer not coming up with a solution to this problem are pretty slim, considering the popularity of genealogy.