1. Parental Associations – Better defining of parental associations – I’ve blogged about this a lot, but basically, this is the most important record as it defines ancestry. GEDCOM has an ASSOciation field, but no predefined “Biological Child of X” relation type. I use this field extensively so that I can add sources to the relationship. Just adding a child to a family does not give you this ability (http://ancestorsnow.com/press/news.php?item.8.2)

2. Source Categories – All sources should be categorized by any of several attributes to establish reliability. I support 3 categories: Authority, Concurrency, and Association (http://ancestorsnow.com/press/news.php?item.9.1)

3. Certainty Assessments – Each claim made needs to have a certainty assessment field that can be set to indicate how certain a claim is especially if the claim has been disproved but remains in your database so that it is not lost (http://ancestorsnow.com/press/news.php?item.45.1).

4. Multiple Source Citations/Quotations – We need to be able to add multiple citations per source under each source. I use the NOTE field for this, but that is not its intended use.

5. Better privacy controls – we need to have a privacy tag for every record at every level, so that they can be restricted from use by displaying applications. We also need to be able to mark individuals as living and as dead. When applications hide living persons, we need to be able to selectively show records using a special tag. Likewise, we need to be able to selectively hide records when not using privacy restrictions (http://ancestorsnow.com/press/e107_plugins/forum/forum_viewtopic.php?77).

6. Marriage Order – There should be an easy way to set the marriage order separately for husbands and wives. Likewise for children’s order of birth. This is a claim so source references must be allowed (http://ancestorsnow.com/press/e107_plugins/forum/forum_viewtopic.php?81)

There are of course may others, like URLs and file PATHs for persons, sources, source quotations, and perhaps locations. I use all these on my website when displaying my data making for a much richer experience for the visitor. My description of GREnDL 2.0 (http://ancestorsnow.com/press/news.php?item.52.1) includes these features and others.

[Editor -
Tim,
Thanks for your comments -- the more the merrier! GEDCOM needs to be open to all comments. Welcome/Thanks for improving the conversation on GEDCOM.

--Stanczyk ]

All three of you have pistol whipped me on whitespace. I am afraid to capitulate on my need, but I guess I will have to abandon my need (and laziness) and continue to edit gedcom files for my own edification since it is evident nobody else sees the need for debugging gedcom files (or they expect programmers and other gedcom detectives to do for themselves). I certainly do not want to bloat the GEDCOM. But then I will also expect/demand the same kind of universal revile for XML which would bloat a gedcom file far/far more than a few blanks at the beginning of a line (which could be turned off/on).

Please look for my response post .. soon

I’ve been following your blog since the “Is GEDCOM Dead?” posting. I’m happy to see you are picking up the GEDCOM torch!

Am I a GEDCOM fan? Yes & No. Yes, because of the immense investment of genealogists who have stored their years of research in this format. Yes, because the format is easily comprehended and humanly readable. No, because of the lack of support for the standard. No, because software vendors have polluted the standard with custom tags or don’t follow the published specification. Despite the “No’s”, I have developed a GEDCOM reader for android (https://market.android.com/details?id=com.sourcequest.ezged).

Having spent quite a bit of time with GEDCOM recently, I thought I’d weigh-in on your proposals:

Whitespace: I suspect the number of people who handcraft or read GEDCOMs is rather small. Although I find the indentation makes the structure more obvious, I don’t think it belongs in the standard.

UNICODE: Although the specifications state that UNICODE is supported in 5.5 and UTF-8 in 5.5.1, I think there should be clarification about distinguishing UTF-16LE and UTF-16BE. Also the specification sections on supported languages needs to be updated.

Level Zero Records: I think candidates for level 0 are either shared or reusable records. They are given unique identifiers so they can be referenced elsewhere in the file. A Date applies to the information it is associated with, so I don’t see a benefit in separating it from that information – so I would keep it embedded in the related structure. Similarly, a Name is associated with an individual and it should remain embedded in the INDI structure. However, there are certainly some improvements that can be made in the Date and Name structures. Since Places tend to be shared or reused, I would agree with creating a level 0 LOCN record.

I’m not sure how your proposed DOCS record would be different than a SOUR record. I agree some facility needs to be added to support modern citation principles (e.g. Evidence Explained). The linkage I would hope to see is from source to reference note to event/fact. Events and facts are now embedded in INDI and FAM records. Splitting them out might be the way to go, but it depends on how the new records interrelate. This is the area where I would hope to see the most improvement.

I look forward to reading your future musings on GEDCOM!

-Stan

I’m enjoying all your posts.

I’m a developer and GEDCOM evangelist and I am a GEDCOM supporter. See: http://www.beholdgenealogy.com/blog/?p=803 or http://bettergedcom.wikispaces.com/message/view/What+IS+BetterGEDCOM/32188988 where I say: “I am probably alone in this view, but … GEDCOM is NOT as bad as everyone thinks.”

First, I don’t agree that GEDCOM needs whitespace. It’s only techies like you and I who look at GEDCOMs. All other people who simply use them don’t care what they look like. They only want them to store and transfer their data corrrectly.

For top level groups, I don’t feel the need for Dates or Names or Documents. We do need Locations (or Places if we want to call them that), and like you say possibly Groups.

With regards to Event records, I once thought they’d be useful, but my vision has since changed. What is really needed is a “Source Detail” record, so that the various specific items within each source can be identified. Currently, these are hacked into GEDCOM as subdetails under the SOUR link that is in the INDI and FAM records. This mixes conclusion information with evidence information and is bad-bad-bad. By separating out a Source Detail record, the raw evidence (just-the-facts) can be cleanly dividide from the conclusion information that is with the event info under the INDI or FAM. This will finally allow source-based data entry and a proper implementation of evidence/conclusion modeling. Think about this. It’s a much better solution than Event Records which will cause more complication and confusion than benefit.

So in summary, I say only Location, Source Detail, and possibly Groups are new needed GEDCOM records.

Dates are actually quite well defined in GEDCOM. Just a few tweaks would be needed there.

Names are okay and a bit of simple things can be done to improve them.

GEDCOM 5.5.1 already has Unicode. It supports UTF8, but they did not change the document enough to make that apparent everywhere in it.

I say the OBJE record would be a decent placeholder for your multimedia items.

Keep up the great work. And keep thinking!

Louis