Posted 29 June 2017 - 04:37 PM
Tom will hate me for this long GEDCOM related entry!! But I feel that the gauntlet has been thrown.
I’ve been working with GEDCOM for a lot of years. Yes it is old (from a last updated sense) and a few data points (primarily Place and the Source_Record) need some work, but the standard, as is, is not the biggest problem.
RobJ, I agree that data portability demands a standard, but the biggest problem is that most software programs have not implement the entire GEDCOM standard, nor have they given their users a universal education in how to use the data points in the full GEDCOM standard.
A lot of people rail on about how the standard does not support DNA. Most programs make up their own DNA tags when they generate a GEDCOM, THIS IS WRONG.
Any generation/creation of GEDCOM that does not create a properly (and well formed) “FACT” tag for DNA is creating something that will universally be misunderstood by the receiving program.
I’m not a DNA expert so the following GEDCOM tags may not be perfect, however they do not have to be perfect since if you can read a well formed FACT tag, it does not have to be perfect to be read into your database. No data loss.
I’ve seen people record haplogroups. I believe there are 20 primary groups, with multiple subgroups. Haplogroup D for instance is subdivided into (D1, D1a (D1a1, D1a2), D1b, D2).
A DNA fact should/could be added as the following well formed GEDCOM, which should have little or no problem being understood by any viewing/receiving program or human reader.
1 FACT Haplogroup D1a
2 TYPE DNA
Mitochondrial DNA has its own organizational values.
1 FACT Mitochondrial H
2 TYPE DNA
If additional notes need to be recorded a NOTE field (either local Note, or Global Note) can still be used.
1 FACT …
2 TYPE DNA
2 NOTE …
Any program that generates a tag that looks like this should have little problem with data loss if the receiver can read a well formed GEDCOM “FACT” tag.
Any program that generates tags that start with an “_” (even though these are allowed) will never have a high chance of data transfer. Many of these “_” tags have GEDCOM equivalents.
Other custom fact/events should also follow these standards. Many attributes of tags found in the GEDCOM standard are ignored by programs with these programs generating their own “_” tags. This includes tags for alternate names and some relating to adoption and marriage alternatives. We do have good standards for Western based names, and dates (multiple date type standards) in GEDCOM already.
PAF was an offender of the GEDCOM standard, several tags were created (and retained) in GEDCOM because of PAF, one example is the database inside PAF could not support multiple name entries for a single person. This is one of the reasons we have the NICK tag artifact in GEDCOM. Many programs today do not differentiate between Alternate Names and Primary Names correctly, they instead add an additional tag like _primary rather than using the GEDCOM standard TYPE tag and ordering the names primary first, followed by secondary, tertiary, etc.
Sourcing issues are a problem as well, but most programs have trouble generating and reading all of the tags that are available to them in well formed GEDCOM. I agree that the standard here could use a few more standardized tags that would fill in some of the holes in modern sources. But not many. A templating standard would help, but here again much of the data loss is due to not implementing the GEDCOM standard for data placement within the standard. For example the PAGE tag is not just for book page numbers, the standard outlines its use for other source types that are not page oriented. Ancestry.Com is one of the worst offenders of data point placement within the GEDCOM standard.
The Place tag could use a lot of help, there is no denying it, however, it is my feeling that place is one of the hardest tags to reconcile, since every country is different and places are date and language specific and generally not a single point but a polygon. No solution that I have seen answers all place issues and then trying to record all of the place variations over space and time is a monumental project. This is not a GEDCOM specific problem.
As you can see I have a rather good understanding of GEDCOM, I don’t know all of the issues that people have with the standard so I can’t say (and will not say) that it is perfect. I’ve worked with one of the current committees regard changing the standard, much of the issues revolve around how to package the data so they can move toward including better support for multiple languages, all alphabets, localizations, non-Christian religious terms and a host of international data requirements.
Before complaining about needing a new GEDCOM I’d rather we force the software industry to support the current standard and move toward fixing the current issues. Moving to a .gedx standard (a zipped, with media file) should be easy. This could be an easy extension.