Generations Grande Suite 8 Summary

Export:

The Generations GEDCOM, when checked with the GEDCHK program, revealed a number of problems.

1. The TEXT (Text) tag is used for citations without a superior DATA tag. Generations placed the tag subordinate to the SOUR (source) tag

   .

2. The ALIA (Alias) tag is used without a cross reference (@xref@) and the subordinate TYPE or RELA (Relationship) tags. Data simply appended to the tag.

3. The NICK (Nickname) tag is coded at 1st level. Should be subordinate to the NAME (Name) tag

4. The ADDR (Address) tag is at 1st level in one instance. Should be at 2nd level and subordinated to another tag

5. CALN (Call number) tag is at wrong level. It must be subordinate to REPO (Repository) tag.

6. MEDI (Media) tag is at wrong level. It must be subordinate to CALN (Call number) tag.

7. DATE and PLAC tags in source were coded at 1st level. They should be subordinate to a DATA (Data) tag at 1st level with a subordinate EVEN Event) tag.

Data recoding problems:

1. When an EVEN tag (Event) was used to describe a miscellaneous event Generations did not use a subordinate TYPE (Type) tag describing the event.

2. CAST (Caste) information was coded by Generations as a note.

3. CAUS (Cause of death) was coded by Generations as a note

4. Temple names and submission codes all coded as NOTE by Generations.

5. Generations did not code the image information (OBJE).

6. DESC tag (tag is for descendant data) used in place of DSCR (physical description.)

7. Notes exported at 0 level using a cross-reference ( @xref@ ). The user supplied note name not included in transfer. This could lead to confusion on importation to another program.

Export rating: 85.95 %

Import from:

Generations does not produce an exception report. At import a list of the tags contained in the GEDCOM being imported is made available to the user. New tags are identified and may be renamed and directed to events, facts, notes, or flags.

Control file:

1. When two names are included for one individual they will appear in a combined form in the name fields. When the é accent was coded to GEDCOM specs it was recognized literally as âe.

2. All notes exported with a cross reference to a note at the zero level were lost. This happened in both event and source records.

3. The event memo field proved too limited for some event notes and were truncated. Data would have to be recovered from GEDCOM file

4. Age tag information appears in memo field with no descriptive information.

5. Cause of death information appears in memo field.

6. Nicknames were not transferred.

7. The adoption information transferred to the proper person but the adoption status did not appear when the child appears in adopted family. The child does appear in both natural and adopted families. The cross reference tag to adopting family shows in child's memo field.

8. Ordination tag descriptive text did not transferred.

9. When the miscellaneous tag EVEN was used with the TYPE tag the event type was not identified.

10. The Alias tag was mapped to AKA and displayed only the cross reference numbers, not the name of the person referenced.

11. Image location information was mapped to notes. Program does not recognize or link images to individuals.

12. Address information was mapped to fact using residence tag.

13. When recording LDS information the Temple name appears in location field. Actual location information is nor recognized

14. All source quality and role information was mapped to the citation field.

Sources:

The only data that was lost were the cross referenced notes at the zero level. Otherwise all data transferred but in some instances, specifically when the DATA tag convention was used, the data requires some editing to get it in the proper fields.

Summary:

The major problems appear to be the loss of notes at the 0 level and the limited size of the event memo fields. The unrecognized tags are rarely used and in the case of the alias tag usually in an unintended manner. The ability to map information existing field or to create new fields minimizes other data loss.

Import rating: 77.98 %

Family Tree Maker 7.5

Sample 1:

Data export problems:

In this sample, the recorder entered Roles and Quality values in the source citation. FTM has no provisions for recording roles or citation quality at event level.

1. Some notes intended as event notes were entered as citation data rather than in the general note field.

2. Age information was entered in the citation field.

3. The GEDCOM file used two tag extensions, _MDCL and _MILT. On import MILT was mapped to the correct field and MDCL recorded as a fact.

4. Cause of death was not recorded.

5. There are five cross- reference errors in the notes. These notes apparently were not picked up.

6. The ADOP (Adopted) tag appears illegally in the FAM record with the result the adopted child was not properly linked to her biological father and her status as adopted not indicated.

7. The improper use of the Address tag at the wrong level did not affect the importation of the data.

8. The Alias (ALIA) tag in FTM is used to identify the aka name. The test data required it to be used to identify an individual who could be the same person as another individual but where there is inadequate proof.

9. Both annulment and divorce data was entered with two extended tags, _FA1 and _MEND. The first tag identified date and place, the second a note. Generations recognized only the second tag. The note identified there was at zero level and not picked up.

10. The two John Smith's were entered as one person which eliminated the need to use the ALIA tag although it was used as an aka to show John as both Smith and Smythe.

11. Ordination type and source were not recorded.

12. LDS temple and status information was recorded in the citation.

13. The associate information for van Stone was mapped to a fact field. The reference in Reginald Smythe's data was entered as citation information.

14. Source 17 was not entered.

15. Media type and call numbers entered in citation.

Generations importation problems:

1. All source repository information, a number of source notes and quality information were exported by FTM with a cross reference to notes at the zero level. These were not imported by Generations.

2. Name prefix was exported as a title rather than with the prefix tag. The name suffix information was recorded as part of the name which resulted in prefix and suffix both appearing after name.

3. Generations limited citation field resulted in the abbreviation and loss of imported data.

4. The married name was combined with the maiden name on importation. It was also recorded as aka.

5. Image information was not recognized as such. On import it was mapped to facts.

Sample 2:

Data export problems:

The tag exceptions included the following:

1. A NOTE on a Sealed to Spouse (SLGS) entry was coded at level 3 instead of level 2. Information was not transferred.

2. A series of tag exceptions occurred when the cause of death (CAUS) tag was followed by a series of other tags. CAUS can not have subordinate tags. In this instance it was a source tag (SOUR). No data loss although sources were not transferred.

3. Another series of tag exceptions was created by the address (ADDR) tag being improperly used. Address transferred properly.

4. The tag COMM (comment) is not a legal tag and should be indicated as an extension.

26 extension tags are listed in the GEDCOM but only six are actually used.

The six extensions are:

1. _MILT for Military service event. Information mapped to events.

2. _MDCL for a medical entry. Information mapped to facts.

3. _FA1 used as the superior tag for the date and location of annulment and divorce. Information mapped to annulment and divorce facts.

4. _MEND used as the superior tag for the text, annulment, and divorce. nformation mapped to annulment and divorce facts.

5. _MREL and _FREL for parental relationships to a child. Information does not appear to have transferred in the adoption case.

6. Caste (CAST) data exported as a place (PLAC). Caste information (date and type) was mapped to facts.

Other problems were the same as those itemized in sample one. The exception is the exportation of the cause of death. This information appeared in the event memo field.

Generations importation problems:

The same problems occurred with sample two as with the first one. Source repository information, a source note and quality information was not imported. Both name prefix and suffix appeared after the name. Citation field limitations resulted in the abbreviation and loss of data. The married name was combined with the maiden name and recorded as an aka as well. Image information was mapped to facts.

Summary:

Loss of notes at the zero level presents a serious problem. All repository and source textual data is missing. The limited citation field also results in data loss. Generations ability to map the extended tag data to the appropriate fields preserved much of the data that otherwise would have been lost.

Ultimate Family Tree 3:

With the many possible ways of entering data in UFT one can be almost certain the GEDCOM file will vary depending on the experience or preferences of the person entering the data. What is also obvious is that UFT does not export much of the information that might have been recorded. The following are the results of a GEDCOM prepared by a former UFT user who has switched to another program and whose entry methods may be influenced by the new program.

1. GEDCHK indicates UFT codes CHAN(change), DATE(date)when subordinate to change, and QUAY(quality) tags at wrong levels. The CHAN and DATE problems do not result in the loss of significant data.

2. The coding of QUAY at the wrong level results of loss in that information at event level. In some instances the data was not exported

3. Address is also recorded at wrong level. Should be subordinate to attribute. This did not result in data loss. Generations picked it up.

4. UFT uses EVEN(misc. event) tag rather than legit GEDCOM tags and codes This created no problems. Generations mapped the data to new fields.

5. TEMP(temple) at 2 level illegally. Result is loss of Temple location data which is replaced by Temple code.

6. UFT did not export prefix, suffix, nick

7. UFT did not export ROLE(role), RELI(religion), NCHI(number of children), NMR (number of marriages)

8. UFT did not export NATI(nationality), DSCR(description), OBJE(object or image),

9. UFT did not export CAUS(cause of death).

10. UFT use EVEN(misc. event) and TYPE(event type) for CAST(caste). Actual caste data not exported.

11. UFT did not export OCCU(occupation) for Chorday

12. UFT abbreviated some PLAC(place) data. Lowest level place detail was not exported.

13. UFT did not export OCCU(occupation) details. Only occupation type.

14. UFT did not export IDNO or SSN numbers (id number and social security number)

15. UFT exported ASSO(associate) as PROB(probate), no link made to other person.

16. UFT exported citation and event notes as general notes in some instances.

17. UFT exported structured date in place of free form date. Results in loss of date ranges.

18. UFT exported adoption event but did not supply family links.

19. UFT did not export age information.

20. UFT did not export associate information.

21. UFT did not export marriage license information.

22. UFT did not export marriage banns information.

23. UFT did not export married name.

24. UFT did not export Temple code for sealing to spouse.

25. UFT does not export information entered as “unknown”.

26. UFT exported status for LDS events as note. Appears in event memo field.

Source export problems:

UFT does not code all the source data that might have been entered originally. The data is extracted from the source component fields. If the repository is a source component, it will transfer. Any data recorded on the “more” page, repository, annotation, comments, call number, condition, data quality etc does not transfer. MEDIa is not an option in UFT although record type is available.
Monument information exported as event note rather than a citation. Exact source text exported as an event level note.

Generations importation problems:

1. Citation field too small in some instances.

2. Event memo field too small in some instances.

3. Alias tag recognized as aka.

4. Generations did not link source for SSN (Social Security Number) data.

5. Generations did not pick up AFN (Ancestral file number) which was exported as a reference number (REFN)

Summary:

In spite of UFT's use of the EVEN miscellaneous tag for many events having legitimate GEDCOM tags, Generations ability to map events resulted in no data loss from that source. The limited size of the memo and citation fields does create a situation that does result in data loss.

Generations imported all the source information exported by the UFT FAM version of GEDCOM faithfully. Unfortunately this data is very often scrambled and incomplete. Author and title information, author and repository, title and repository, title and repository note, might be combined into one field. Repository may or may not be there, but call numbers were consistently missing. Generations maps abbreviation for source title to a new tag with media or record type mapped to a new REFN tag.

The Master Genealogist 4.0a

Two GEDCOMs were examined for this report. There were some differences, primarily in the source information, based on the how the users chose to input the data.

TMG recorded but did not export the following

1. Role (ROLE) tags

2. Alias (ALIA) tag

3. Physical description (DSCR). NOTE: Tag given GEDCOM tag DESR in program tag list, when the tag was changed to DSCR the information transferred.

4. Individual's address (ADDR)

5. Associate (ASSO) tag

6. Age (AGE) tag

7. Nickname (NICK)

Source media was also recorded on the supplemental screen along with the recorder, fidelity, and indexing information but none of this information is exported.

TMG exported the following but not as expected:

1. Nickname exported using NAME tag, not the expected NICK in one file, second file used NICK. Generations imported the data in both instances.

2. TMG exported the LDS Temple code with the location information. Creates no problems as Generations has no Temple fields. Data imported.

3. TMG exports Citation detail using PAGE(page) and CONT(continued) tags. The PAGE tag is limited to 248 characters to accommodate those programs with field limitations and does not support the use of CONC or CONT tags for some reason. Tags with similar restrictions do support the CONT or CONC(concatenate) tags. The use of the two data extension tags can result in data loss under certain circumstances.

4. Generations recognized the extension tags but the program's limited size fields resulted in data loss.

5. TMG exported the name with both prefix and suffix under the NAME tag. It then exported both suffix and prefix again with their own specific tags. Generations imports both. Editing required.

6. TMG exported both married name and maiden name with the NAME tag. Generations placed both in the name field.

7. The name of individual identified in TMG as a possible duplicate and assigned the ALIA tag for export purposes was exported as an alternate name. Generations combined both names in the name field.

8. Rebecca Moore appears as the natural child of Archibald Moore and has an adoption event. She does not appear as a child in the family of her adoptive father, Reginald Smythe. The second TMG GEDCOM shows her and John Smythe both in Reginald's family but she does not appear in Moore's family. This is consistent with the family information in both GEDCOM's.

9. Generations imported the information consistent with the GEDCOMs. In neither case was the child status shown as anything but natural.

10. TMG records items such as cause of death and Temple status information as notes or in the citation. These items imported correctly.

Generations data importation:

With the ability to map the new tags Generations was able to record all the data from the GEDCOM with the exception of part of the address data for the repositories as mentioned below.

The only difficulty involved the use of the EVEN tag. The tag type information must be recorded in TMG as a note whenever the user intends to use the EVEN tag. This data is exported as a note. On import the user must identify the EVEN tag as miscellaneous during the mapping procedure. The information will then be imported and the note, which will be in the memo field, can be used to identify the type. Failure to identify the EVEN tag at import will result in the data not being imported.

Both the source detail field and the event memo field proved too limited for some of the imported data. This information would have to be recovered from the GEDCOM.

Generations did not recognize the Image tag (OBJE) correctly and place the link in the correct location. The image information in the first GEDCOM was mapped to an event field, in the second to a fact field.

Sources:

The following TMG problems are probably user-caused as they are not consistent from source to source but vary with how the data was recorded in the source template.

1. TMG combined author, published date, call number, record number, and address of publisher with the title data in some instances.

2. TMG exported the record number for fiche in one instance with the extension tag NUMB. This is not a legal 5.5 tag.

3. Generations recorded all the source data it found in the GEDCOM file with the exception of the city, state, postal code, and country information contained in the repository information.

Summary:

The most notable problem is the limited size of the event memo and source detail fields. Otherwise, all data appeared to have transferred. Generations can add to the number of source fields as required. Any data that was combined into other fields can easily be edited after importation.