More GEDCOM Perspective (simple and spicy)
Dec 25, 2022 4:22:29 GMT -8
Post by Uncle Buddy on Dec 25, 2022 4:22:29 GMT -8
Here's an interesting quote about the limitations of GEDCOM from www.reuniontalk.com/forum/genealogy/10934-changing-software-applications-gedcom-is-poor-minimal-common-subset-tool:
One big difference between Treebard GPS and the commercial apps is that Treebard is not being optimized for a market, a church, a corporate philosophy, or a group of developers competing for control of a project. As closely as possible, Treebard is neither, people-oriented, family-oriented, or event-oriented as the above enlightening quote mentions. Treebard is meant to be genealogy-oriented.
Since Treebard exists for the express purpose of conforming to the needs of genealogy itself--and therefore has no compulsion to conform to the needs of GEDCOM or other forces within the current genealogy community--entire lists of complaints about the state of genealogy today are addressed daily during Treebard development. For example, here is a list of complaints that are all addressed by Treebard's guiding design principles. www.reddit.com/r/Genealogy/comments/cn9sra/anybody_else_find_the_gedcom_standard_limiting_or/
By the way, Treebard development is making strong headway. A variety of new features are being created, cleaned up, restructured, and improved. Chapter two of Treebard development is fun, I'm glad I didn't stop.
As for complaints about GEDCOM, the way I see it, the only sane way to replace GEDCOM is with a serverless relational database model, preferably SQLite since it's a well-established, mature, open-source, ubiquitous database tool. Any number of otherwise-unrelated genealogy programs could use a common database structure for the primary features of genealogy, and a special database for features specific to their program. To look at a Brand X file in a Brand Y application, you would just open the X database in the Y app.
A new transfer method is not what we need. What we need is to drop the notion of a transfer medium and get real. To use data in a variety of applications, the applications need to share the same data structure. What you build on top of that common universal data structure, such as secondary features and GUI particulars, that's what makes your genieware different from mine. There is still all the room in the world for competition and companies trying to outdo each other, even in the future when we get real and admit that without a common data structure, we'll be stuck with GEDCOMoids till the cows come home.
Plus there are three very different philosophies behind the databases.
1) are people oriented, so everything is about Mary Maguire
2) are family oriented, so everything is about Chris Smith and Mary Maquire and family
3) are event oriented, so everything is about Chris and Mary getting married April 2, 2011
and Leona Smith born May 14, 2012
while you can express any person, marriage or event in any package, its a lot easier to do what matches the philosophy and if the philosophies match, transferring data is a lot easier to automate.
1) are people oriented, so everything is about Mary Maguire
2) are family oriented, so everything is about Chris Smith and Mary Maquire and family
3) are event oriented, so everything is about Chris and Mary getting married April 2, 2011
and Leona Smith born May 14, 2012
while you can express any person, marriage or event in any package, its a lot easier to do what matches the philosophy and if the philosophies match, transferring data is a lot easier to automate.
One big difference between Treebard GPS and the commercial apps is that Treebard is not being optimized for a market, a church, a corporate philosophy, or a group of developers competing for control of a project. As closely as possible, Treebard is neither, people-oriented, family-oriented, or event-oriented as the above enlightening quote mentions. Treebard is meant to be genealogy-oriented.
Since Treebard exists for the express purpose of conforming to the needs of genealogy itself--and therefore has no compulsion to conform to the needs of GEDCOM or other forces within the current genealogy community--entire lists of complaints about the state of genealogy today are addressed daily during Treebard development. For example, here is a list of complaints that are all addressed by Treebard's guiding design principles. www.reddit.com/r/Genealogy/comments/cn9sra/anybody_else_find_the_gedcom_standard_limiting_or/
By the way, Treebard development is making strong headway. A variety of new features are being created, cleaned up, restructured, and improved. Chapter two of Treebard development is fun, I'm glad I didn't stop.
As for complaints about GEDCOM, the way I see it, the only sane way to replace GEDCOM is with a serverless relational database model, preferably SQLite since it's a well-established, mature, open-source, ubiquitous database tool. Any number of otherwise-unrelated genealogy programs could use a common database structure for the primary features of genealogy, and a special database for features specific to their program. To look at a Brand X file in a Brand Y application, you would just open the X database in the Y app.
A new transfer method is not what we need. What we need is to drop the notion of a transfer medium and get real. To use data in a variety of applications, the applications need to share the same data structure. What you build on top of that common universal data structure, such as secondary features and GUI particulars, that's what makes your genieware different from mine. There is still all the room in the world for competition and companies trying to outdo each other, even in the future when we get real and admit that without a common data structure, we'll be stuck with GEDCOMoids till the cows come home.