Wednesday, December 1, 2010

Test 1: Results of a GEDCOM file, created by Family Tree Maker opened in Roots Magic 4

As part of the BetterGEDCOM project, we thought it might be helpful to post some of our experience about the project on this Blog.

To family researchers, during a conference call, realized that they may be related. As other researchers may do, one of them would generate a GEDCOM file and send it to the other.

A GEDCOM 5.5 file was an existing file in Family Tree Maker Version 2011 and was to be shared with a researcher using Roots Magic 4.

To be clear, this is only to illustrate one issue of a GEDCOM file and not about either of the programs involved.

When there seemed to be some problems, in the Source-Citation by the person receiving the GEDCOM file, and to put a little more control over the test environment, that GEDCOM file was opened by Family Tree Maker 2011.

Number of Individuals: 226
Number of Families: 89
Number of Sources: 208
Number of Records: 2,688
Number of Errors: 0

There were 13,232 lines of data in the GEDCOM, as counted by Microsoft Word.

The same GEDCOM file was opened in Roots Magic 4. The number of individuals imported into Roots Magic 226, the same as Family Tree Maker.
When a GEDCOM file is opened and there are errors on import a .LST file is generated. Below is an example of entries that were in that .LST log file that was generated by Roots Magic 4:

This information was Cut from the error log, and pasted here, and not edited in any way from HERE:

Unknown info (line 933)
    3 _ABBR Ancestry.com, 1930 United States Federal Census (Provo, UT, USA: The
    4 CONC Generations Network, Inc., 2002), Database online. West Chester,
    4 CONC Chester, Pennsylvania, ED 95, roll 2021, page , image 189.0.

Unknown info (line 954)
    3 _ABBR Ancestry.com, 1930 United States Federal Census (Provo, UT, USA: The
    4 CONC Generations Network, Inc., 2002), Database online. West Chester,
    4 CONC Chester, Pennsylvania, ED 95, roll 2021, page , image 189.0.

Unknown info (line 980)
    3 _ABBR Ancestry.com, 1930 United States Federal Census (Provo, UT, USA: The
    4 CONC Generations Network, Inc., 2002), Database online. West Chester,
    4 CONC Chester, Pennsylvania, ED 95, roll 2021, page , image 189.0.

Unknown info (line 996)
    3 _ABBR Ancestry.com, 1900 United States Federal Census (Provo, UT, USA: The
    4 CONC Generations Network, Inc., 2004), Database online. Thornbury,
    4 CONC Delaware, Pennsylvania, ED 188, roll T623 1406, page 1A.


To HERE:

There are personnel information in much of the Error Log, but this is just an example: Many of the other errors were very much like these. These are Citation entries. There were 944 lines of errors. However, some of those lines were blank lines. This test is not for details but an example of issues that two researchers experienced.

The two researcher involved with this test, consider Source-Citations very important, and it appears that some of the Source material was not imported into Roots Magic.

A Follow Up message will contain the results when a GEDCOM file from Roots Magic is opened by Family Tree Maker.

6 comments:

GeneJ said...

Hiya Russ

I imported the same GED to TMG; have sent you the pages of comments (LST file) relative to that import.

The TMG post import project summary was:
227 persons; 354 names; 1086 events; 1169 witnesses; 425 places; 287 relationships; 1647 citations (all are your source, not mine); repositories 67; Tag types, 129; and source elements, 160.

As you asked, I then exported a gedcom from the TMG file. Have sent that to you by E-mail.

Russ said...

GeneJ,

Back from a day trip, working on one of those mysteries that we find from time to time.

Will post updates shortly.

Thank you,

Russ

lambersongenealogy said...

Hi Russ,

A note for anyone who doesn't already know:

In A GEDCOM file, any field name beginning with an underscore (like the "_ABBR" in the error log snippet of this post) indicates a custom field. This means that the application that generated the GEDCOM file couldn't or didn't match the data it contained with something GEDCOM had built in. This could be something a user did or something the application did. It's not necessarily a problem, but it can point you to why something didn't work the way you wanted it to.

Russ said...

Greg,

I know the "user" didn't do this. The application did. However, there is an observation here that you may be missing. It is Citation information that was Generated by Family Tree Maker and not recognized in Roots Magic.

Also, there is NO easy way to Identify, from the Error Message (.LST file), who or what Fact / Event was impacted by this citation information coming into Roots Magic.

Isn't this the type of Issues the BetterGEDCOM project is trying to address?

Thank you,

Russ

Greg Lamberson said...

Russ,

I think if you say it's something we should work on, then we should. It's obviously a huge issue. To my knowledge not a word has been mentioned about this sort of thing on the wiki.

One thing I almost pointed out in my original post was that there are lots of instances in which things happen that a user would consider an error that aren't reported. As you certainly know, it's common for people to have their GEDCOM export/import mangled with no errors.

Unfortunately, all these errors are 100% application generated. I think we need to work on some guidelines addressing this sort of thing in addition to the actual BetterGEDCOM format. There are lots of issues related to how data is handled during the export/import process that need to be addressed but aren't part of a file format.

In this example, there are at least two issues to deal with: Error handling and the actual problem with the data transfer. In regard to error handling, I think we should indicate any data giving an error during import should report what data entity the error was generated from. In other words, when a piece of data doesn't import due to an error, the error should indicate what that data came from or what it is associated with in detail so a user can either go and look or ask the originator of the data to examine the original data and perhaps send it in another format. This isn't a great solution to the end user's real problem, but it's a slight improvement.

Given your insight and seeing the problematic information creates a custom abbreviation tag, I suspect that FTM had additional descriptive fields for the source information that GEDCOM didn't understand. This is one of the core issues that BetterGEDCOM should address in aggressive and thorough fashion.

Russ said...

Greg,

My intent is to do some testing and post results. I will not try to point fingers to applications. Not application to end user. Trying to make observations when sharing information between applications.

Some generic data entry blog entries will also be made here, to see how folks enter data.

Russ