Jump to content


Photo

GEDCOM Standard


  • Please log in to reply
8 replies to this topic

#1 RWells1938

RWells1938

    Advanced Member

  • Members
  • PipPipPip
  • 215 posts

Posted 29 June 2017 - 06:09 AM

I have downloaded the new RM7.5 and like it. There are some quirks that I need to figure out and some thing that I would like changed but for the most part I think it is a great step forward.

 

But I have one comment.

 

Why are we still limited by a GEDCOM standard created so many years ago that still hampers our genealogy software today. Maybe we should all go back to PAF :( It seems that all of the efforts to replace the GEDCOM standard have failed or are not making any progress.

 

Surely we as genealogist can some up with a standard that could be used. I for sure would buy more software if we could transfer files between programs without loosing data.

 

Are there any in the group that would like to take a shot at a replacement. No white papers or long schema of things just a good old common sense replacement.

 

Roger

 



#2 RobJ

RobJ

    Advanced Member

  • Members
  • PipPipPip
  • 56 posts

Posted 29 June 2017 - 09:33 AM

I strongly agree, and would echo your sentiments.  I've made related comments over here:  http://forums.rootsm...tes/#entry83804

 

I think the first change I would like to see is, like the move from .doc to .docx, change .ged to .gedx or .gedz, and zip up the gedcom and all media and auxiliary files into one .gedx file.  That seems a fairly simple thing to agree on, but there are so many parties to the GEDCOM standards, and you need most of them to buy in.  Try searching GEDCOM, and you will see numerous efforts to advance the standard, but none of them getting wide acceptance.

 

I'd also like to see standardization in the basics - in naming, in dates, in place names, etc etc, and that's just the start.  There's a LOT of work to be done!  But true data portability demands it.



#3 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8414 posts

Posted 29 June 2017 - 03:16 PM

Changed title to reflect this discussion. RootsMagic doesn't have control over setting the GEDCOM standard. I am moving this to the General Messages.


Renee
RootsMagic

#4 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 207 posts

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.

#5 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 207 posts

Posted 29 June 2017 - 05:03 PM

Renee said: "RootsMagic doesn't have control over setting the GEDCOM standard."

This is true, but RM can control what parts of the standard it reads and writes, as do all of the other genealogy programs. Interchange and the ability to own and use multiple programs, using each for the things they do well is important to genealogists. I generate books that are self published for my clients. Many of the programs I would like to use to create parts of these books don't import all of the standard and therefore are useless to me.

#6 RobJ

RobJ

    Advanced Member

  • Members
  • PipPipPip
  • 56 posts

Posted 29 June 2017 - 05:21 PM

I'm ready to carry a sign saying "Down with leading underscores"!  :D

 

Be really nice if someone with considerable GEDCOM experience could set up a wiki page scoring every tool and site that creates, imports, or exports GEDCOM data.  The more conformant to the standard, the higher the score.  The more tags with leading underscores, the lower the score!



#7 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3532 posts

Posted 29 June 2017 - 05:55 PM

This is actually a serious comment, not just trying to be difficult. A good place for RM or any other vendor to start to make the existing GEDCOM standard work better would be to be able to export and then import one's own GEDCOM without data loss. RM fails this test. It sounds like most of the required data fields are there in the GEDCOM standard if they would only be used properly (although I'm very unsure about retaining metadata such as sentence templates and source templates across an export/import cycle using standard GEDCOM).

 

I certainly agree that DNA data could benefit by being stored as actual facts (AKA tags). And I would go so far as to suggest that even such things like the address list, the to do list, the research log, etc. could benefit by being stored as actual facts (AKA tags), even if the presentation of the data in the user interface didn't make the data appear as facts. I tend to use user defined facts for such things, anyway.

 

I do think that you would need a GEDCOMX standard, however, if you were to try to package media or other files along with the existing GEDCOM.

 

Jerry

 



#8 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 207 posts

Posted 29 June 2017 - 07:53 PM

Sentence templates are a phenomenon of a more advance system and are a little program specific in concept. By this I mean each software program may want to use sentence, or even paragraph building as a product differentiator. This is like the concept of mapping where some programs only want an x/y coordinate but others want to be advanced with polygons or some kind of place vs date system. This is not to say that additional structures using new record types should not be built for RM to RM transfer, or other like to like, with this type of data. But would also need a metadata standard to tell the receiving programs what the data in the structure is and how it is to be used. Which is beyond a strict genealogy requirement.

I experience failure of FTM to FTM transfer in GEDCOM as well, using many simple genealogy only structures.

Much of the discussions I was part of in Better GEDCOM revolved around what data was Genealogical and what was not and did GEDCOM need a exportable metadata layer to describe the data being transmitted. XML is supposed to have a self documenting code set, but a lot depends on how non-genealogist programmers and the people who pay them (and want to retain your subscriptions) are willing to document how to move data out of one program into a competitive program.

#9 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6216 posts

Posted 30 June 2017 - 12:36 PM

What Ancestry TreeShare interchange and FamilySearch Central Family Tree interchange are driving users of RootsMagic to is a kind of Lowest Common Denominator of features. If you restrict your use of RM to that set (if indeed there is a usable set), standard GEDCOM with no extensions may be all that is utilised by a RM export!


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.