Home > EE & GPS Support > Sources and Reference Notes - Application Overview

Application Overview

Application Overview Quick Links

Application source systems
Application GEDCOM Export Mechanics
Application Source Data Other Challenges
Application Data (separate wiki page)

I Application source systems

Based on a preliminary review of Applications that read and write GEDCOM, some Applications offer a basic or default template that is compatible with GEDCOM in most respects. We believe that Application source systems functionality may generally be described in one of four ways, as below.

Note: The groups below were developed as a way to organize particular data related GEDCOM concepts. The groups do not represent user benefits or compliance to any particular standard.

Customized Group: Applications where the source system is largely characterized by user customization or development of both Citation Elements and Citation Templates.

Evidence Explained Group: Applications that enable Evidence Explained style, by some approach to or interpretations of Citation Elements and Citation Templates.

Extended Functionality Group: Applications that have not enabled Evidence Explained style, but allow extended functionality.

GEDCOM Based Group: Applications enabling Citation Elements either identical to or closely aligned with GEDCOM's Data Fields.

II Application GEDCOM Export

Note: Not all of our tests have been completed. As tests are completed, the findings are be reported in on the Application Data page.

Based on our tests to date, we find:

1. Compliant export. Those Applications that have GEDCOM Based systems generally export Citation Elements to the corresponding Data Field in GEDCOM.

2. Non-complaint export. The main reason for non complaint export is that programs have implemented functions that record many more types of information than the current fields (tags) in Gedcom allows. The additional types are recorded in Gedcom as non-standard extensions or by including other information in the Gedcom field that they were intended for.

The data structures in use are described below, and many programs use a several of these structures:

2.a. Concatenating Citation Elements. Some programs that enable more elements than GEDCOM export by concatenating (merging) many Citation Elements into one field, and then associating that merged data with a GEDCOM Data Field. There is no way for a receiving program to unwrap the merged data. Citations exported in this fashion generally must be reconstructed manually by the user. [1]

2.b. Concatenating with separators and labels (Variant of 2). In the process of concatenating elements into a GEDCOM Data Field, one program puts a separator character between the Citation Elements and labels each element. This approach is not standardized, so the receiving program is not able to break up the field into separate Citation Elements. Because the receiving program can not interpret the data, the citations must be reconstructed by the user. [1]

2.c. Non-standard fields. Most programs that enable more Citation Elements than GEDCOM has Data Fields use non-standard tags. The tag (label) of these fields start with an underscore. On import, non-standard tag/label can not be imported because the receiving program doesn't understand it.

The various methods are described for each program on the Application Data page.

Conclusion: The result of this is that it is not possible to transfer source and citation information between most of today's major programs, using GEDOM, because they use the methods described in 2.

Geir's overview: In some cases, it might be possible to solve the problem in the importing program by implementing special functionality for each of the other programs, but this is expensive and it often does not work because of big differences in the way programs structure the information internally.

[1] Geir Thorud to GeneJ, "Why source and citation..." 5 April 2011.

III Application Source Data Other Challenges