To be brief, I agree with what you say.

Louis

1) We agree – Evolve Gedcom (Thou shalt not lose the work of prior researchers)
2) We agree – gedcom is isomorphic to JSON or XML (and HTML); It is also isomorphic to 3NF(relational db modeling technique for Third Normal Form) or my preference BNF (Backus-Naur Form, a rigorous 3NF)); So it is isomorphic to 3NF, BNF, UML, SQL (at least Create-Table and similar DDL). These are implementation details. I leave it to each developer to use whatever isomorphic projections you wish, but GEDCOM is the core we all start from and is the lowest common denominator, agreed?

All these things are languages are represented by grammars. Hence my obsession with Graphic Syntax Diagrams to speak to all people(USERS and DEVELOPERS — albeit I expect most users have glossy eyes now and don’t care how we get there)

3) We disagree – on what a data model at 3NF would do. As a data architect who started as a coder back in high school 35 years ago, I have learned that a simple and complete model makes programming simpler — not harder. You have shrewdly seen that I am after making GEDCOM conform to a model that could be easily modeled in 3NF/BNF (isomorphic to UML for Ryan Heaton / GEDCOMX) with an eye to making an end user’s data entry and maintenance minimalist and reducing possibilities for errors due to redundancies that never get cleaned up everywhere.

Tamura chided me for my 1,020 INDIs being a small family tree (isomorphic to gedcom). I have too many redundancies to cleanup; What must the people with LARGE family trees think? I also have an eye towards making a STAR model (where I denormalize my 3NF data that the users enter into a star schema that can be queried/analyzed). This is the domain of my professional career and what I understand well. The “vision” is similar to what Ancestry does or what GENI does. Mashup a bunch of family trees together in a transactional (3NF) model, cleanse data and conform dimensions and do all of the 38 steps that Ralph Kimbal says we need to make/manage a star schema, then do really cool things with genealogy.

All we need is a rich, consistent standard GEDCOM and then we also need standard API’s into the transactional model (in whatever geek tech the vendor chooses) and standard APIs into the star schema (in another geek’s dream technology) and we should be able to do miraculous things with genealogy and by projection into other fields (like history — which isomorphic to genealogy). Every genealogy vendor that wants to tackle some problem space would be enabled to do so. But we must have a STANDARD (possibly ISO). No foundation, no building this Tower of Babel to Heaven. Actually that’s a pretty good analogy!

Our common language has become befuddled and it confounds the engineers from continuing their building their goal. So I guess gedcom is isomorphic to building a Tower to Heaven too.

Forgive this jester, I have failed again at brevity.

Stanczyk:

Hmmm. Lots to chew on. Overall, you’re proposing “tweaks” to GEDCOM similar (but different) than the tweaks I propose. Both of us are different than the vast majority who want to do a total re-write.

There is no difference between GEDCOM syntax capability and XML capability and JSON capability. One can be mapped into the other. A simple mechanical method can be used to translate a GEDCOM file into an equivalent GEDCOM-XML file. If the standard is written in one, it is effectively written in the others as well. Any program should be allowed to input one or the other, because there will be programs written that will translate between them. The syntax and prettiness and size of file is irrelevant. The structure is what’s important.

Who cares about readability. GEDCOM is meant for data transfer. For that reason, you want to make it easiest for the programs to read – not for humans. I know you’ve already capitulated on whitespace, but you continued on about other niceties like alternative localized tags and omitting the BOM (Byte Order Mark) to make it easier for people viewing the file. All these considerations simply make it harder for the programmer. For us, the simpler you can make it, and the least number of option to choose from, the better.

Your “DOCUMENTS” are no different that the MULTIMEDIA_RECORD (OBJE) that is already in GEDCOM. So it’s there, and just in need of tweaks.

I see what you are trying to do, but putting Dates, Location, Events, Documents and Groups at a record level. This allows information to be attached to them. But you’ve got to be careful in not over-normalizing the GEDCOM structure like this. Too much disaggregation will make it tough for programmers to support. Most existing genealogy software don’t have a place for this data in their databases. They won’t want to add a new datastructure just to support a standard or just to allow a soundex to be transferred between programs. It’s got to be something important and truly required – not just something that would be nice to have.

Louis

Hmmm. Lots to chew on. Overall, you’re proposing “tweaks” to GEDCOM similar (but different) than the tweaks I propose. Both of us are different than the vast majority who want to do a total re-write.

There is no difference between GEDCOM syntax capability and XML capability and JSON capability. One can be mapped into the other. A simple mechanical method can be used to translate a GEDCOM file into an equivalent GEDCOM-XML file. If the standard is written in one, it is effectively written in the others as well. Any program should be allowed to input one or the other, because there will be programs written that will translate between them. The syntax and prettiness and size of file is irrelevant. The structure is what’s important.

Who cares about readability. GEDCOM is meant for data transfer. For that reason, you want to make it easiest for the programs to read – not for humans. I know you’ve already capitulated on whitespace, but you continued on about other niceties like alternative localized tags and omitting the BOM (Byte Order Mark) to make it easier for people viewing the file. All these considerations simply make it harder for the programmer. For us, the simpler you can make it, and the least number of option to choose from, the better.

Your “DOCUMENTS” are no different that the MULTIMEDIA_RECORD (OBJE) that is already in GEDCOM. So it’s there, and just in need of tweaks.

I see what you are trying to do, but putting Dates, Location, Events, Documents and Groups at a record level. This allows information to be attached to them. But you’ve got to be careful in not over-normalizing the GEDCOM structure like this. Too much disaggregation will make it tough for programmers to support. Most existing genealogy software don’t have a place for this data in their databases. They won’t want to add a new datastructure just to support a standard or just to allow a soundex to be transferred between programs. It’s got to be something important and truly required – not just something that would be nice to have.

Louis