error in import from Rootsmagic
Posted: 13 Jan 2021 19:11
Sorry about the long post.
There has been some discussion on this forum about the GEDCOM standard and how FH interprets and implements that standard. In FH version 6 I was having difficulty importing from RootsMagic since they have implemented their interpretation of GEDCOM 5.5.1 to allow an EVEN tag in the GEDCOM file to have a descriptor on the same line. FH when importing implemented their version of GEDCOM 5.5 to disallow the descriptor on the same line as the EVEN tag resulting in thousands of error messages for me.
When FH version 7 came out I was happy to see that at least FH allowed the descriptor on a FACT tag in the GEDCOM file. I was thus able to edit my GEDCOM file and change all 1 EVEN to 1 FACT. This resulted in a clean import into FH.
Since facts or events are not transferrable from RM to FH I set about creating all my added facts (about 20) into FH and was able to import my file without errors. I tried this again a couple of days ago and again found all my FACT tags rejected and uncategorized and not matching up to my already created fact types. They were even reported as EVEN errors. In addition I am now getting many errors (info only) about image files:
l.477 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "2 FORM jpg"
l.483 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "2 FORM jpg"
l.493 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "2 FORM tif"
l.503 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "2 FORM jpg"
l.513 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "2 FORM jpg"
l.523 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "2 FORM jpg"
I have included references to the GEDCOM standards and the various corrections and interpretations by more knowledgeable GEDCOM people than I am. I would like to know if people think this is an error on FH’s part or that their implementation is correct. If an error should I report this to CP?
Addendums:
Gedcom 5.5.1 update released 11/15/2019 LDS
GEDCOM - FamilySearch Developer Center — FamilySearch.org
• Page 21 and 35 shows:
o 1 EVEN
• Page 48 clearly shows
o 1 EVEN Description
Another take on EVEN and FACT and the descriptor
Events and attributes · GenealogyJ (sourceforge.net)
“The GEDCOM standard is inconsistent on this fact. It mentions two variants:
Example 1: For a person that signed a lease for land dated October 2, 1837 would be recorded in
GEDCOM as:
1 EVEN
Events and attributes ꞏ GenealogyJ http://genj.sourceforge.net/wiki/en/manual/events
1 of 3 6/12/2020, 4:01 PM
2 TYPE Land lease
2 DATE 2 OCT 1837
Example 2:
1 EVEN Appointed Zoning Committee Chairperson
2 TYPE Civic Appointments
2 DATE FROM JAN 1952 TO JAN 1956
2 PLAC Cove, Cache, Utah
2 AGNC Cove City Redevelopment
FACT (Attribute)
The FACT tag is intended for a noteworthy attribute or fact concerning an individual, a group, or an
organization that cannot be expressed by predefined attribute types. In 5.5.1 it was introduced
additionally to the EVEN tag, to express the semantic difference between events and attributes.
A FACT must be qualified or classified by a subordinate TYPE tag (see below).
For example, the attribute could describe a person's skills, such as woodworking,:
1 FACT Woodworking
2 TYPE Skills
This groups the fact into a generic skills attribute, and in particular this entry records the fact that this
individual possessed the skill of woodworking.”
GEDCOM 5.5.1 Annotated version by Tamura Jones
www.tamurajones.net/DownloadGEDCOM551An ... tion.xhtml
The EVEN with descriptor is shown on page 35.
GEDCOM 5.5.5 released 10/2/2019 This is an update to correct errors only and not to provide additional functions.
GEDCOM Specifications www.gedcom.org/gedcom.html
GEDCOM 5.5.5: Just a Revision (tamurajones.net) www.tamurajones.net/GEDCOM555JustARevision.xhtml
Keith Riggle posted this about the EVEN tag at
genealogytools.com/the-event-structure-in-gedcom-files/
The partially expanded structure for a Family Event is as follows (you can find the full definition on pages 32 and 48 of the GEDCOM 5.5.1 standard):
n EVEN [<EVENT_DESCRIPTOR> | <NULL>]
+1 HUSB
+2 AGE <AGE_AT_EVENT>
+1 WIFE
+2 AGE <AGE_AT_EVENT>
+1 TYPE <EVENT_OR_FACT_CLASSIFICATION>
+1 DATE <DATE_VALUE>
+1 <<PLACE_STRUCTURE>>
You would think that, with the exception of the HUSB and WIFE elements, the Individual Event structure would be the same, but from the partially expanded structure that follows, we can see one crucial difference:
n EVEN
+1 TYPE <EVENT_OR_FACT_CLASSIFICATION>
+1 DATE <DATE_VALUE>
+1 <<PLACE_STRUCTURE>>
The crucial difference is that the Individual Event structure lacks the EVENT_DESCRIPTOR. Now why would this be? Clearly it was an oversight on the part of the authors and editors of the standard, because on page 48 of the standard, the following example is provided for an EVENT_DESCRIPTOR on an Individual Event:
1 EVEN Appointed Zoning Committee Chairperson
2 TYPE Civic Appointments
2 DATE FROM JAN 1952 TO JAN 1956
2 PLAC Cove, Cache, Utah
2 AGNC Cove City Redevelopment
The definition of EVENT_DESCRIPTOR even states that it is “Text describing a particular event pertaining to the individual or family” (emphasis added). So it should be obvious that omitting “[<EVENT_DESCRIPTOR> | <NULL>]” from the Individual Event structure was an oversight. Which brings me back to my original question, what should apps do about this mistake?
GEDCOM release schedule
date version status brief notes
1984 1.0 proposed standard First Version
1985-12 2.0 standard PAF 2.0
1987-02 2.1 standard PAF 2.1
1987-10-09 3.0 standard lineage-linked form
1989-08-04 4.0 standard
1991-09-25 5.0 standard lineage-linked structures
1992-09-18 5.1 draft
1993-11-04 5.3 draft Unicode, multimedia, name parts, schema (abandoned)
1995-08-21 5.4 draft citation-source-repository model, more name parts, submission record (obsolete)
1995-12-11 5.5 standard structured addresses, more name parts
1996-01-02 5.5 standard GEDCOM 5.5 with errata
1996-01-10 5.5 errata GEDCOM 5.5 errata sheet
1999-10-02 5.5.1 standard UTF-8, email, URLs, geographic coordinates
2000-12-18 5.5.2 unpublished draft no more escape sequences, GEDXML
2018-05-10 5.5.1 AE special release Annotated Edition; annotations & corrections.
2019-10-02 5.5.5 standard Maintenance release. Quality. Simpler & Stricter.
There has been some discussion on this forum about the GEDCOM standard and how FH interprets and implements that standard. In FH version 6 I was having difficulty importing from RootsMagic since they have implemented their interpretation of GEDCOM 5.5.1 to allow an EVEN tag in the GEDCOM file to have a descriptor on the same line. FH when importing implemented their version of GEDCOM 5.5 to disallow the descriptor on the same line as the EVEN tag resulting in thousands of error messages for me.
When FH version 7 came out I was happy to see that at least FH allowed the descriptor on a FACT tag in the GEDCOM file. I was thus able to edit my GEDCOM file and change all 1 EVEN to 1 FACT. This resulted in a clean import into FH.
Since facts or events are not transferrable from RM to FH I set about creating all my added facts (about 20) into FH and was able to import my file without errors. I tried this again a couple of days ago and again found all my FACT tags rejected and uncategorized and not matching up to my already created fact types. They were even reported as EVEN errors. In addition I am now getting many errors (info only) about image files:
l.477 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "2 FORM jpg"
l.483 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "2 FORM jpg"
l.493 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "2 FORM tif"
l.503 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "2 FORM jpg"
l.513 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "2 FORM jpg"
l.523 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "2 FORM jpg"
I have included references to the GEDCOM standards and the various corrections and interpretations by more knowledgeable GEDCOM people than I am. I would like to know if people think this is an error on FH’s part or that their implementation is correct. If an error should I report this to CP?
Addendums:
Gedcom 5.5.1 update released 11/15/2019 LDS
GEDCOM - FamilySearch Developer Center — FamilySearch.org
• Page 21 and 35 shows:
o 1 EVEN
• Page 48 clearly shows
o 1 EVEN Description
Another take on EVEN and FACT and the descriptor
Events and attributes · GenealogyJ (sourceforge.net)
“The GEDCOM standard is inconsistent on this fact. It mentions two variants:
Example 1: For a person that signed a lease for land dated October 2, 1837 would be recorded in
GEDCOM as:
1 EVEN
Events and attributes ꞏ GenealogyJ http://genj.sourceforge.net/wiki/en/manual/events
1 of 3 6/12/2020, 4:01 PM
2 TYPE Land lease
2 DATE 2 OCT 1837
Example 2:
1 EVEN Appointed Zoning Committee Chairperson
2 TYPE Civic Appointments
2 DATE FROM JAN 1952 TO JAN 1956
2 PLAC Cove, Cache, Utah
2 AGNC Cove City Redevelopment
FACT (Attribute)
The FACT tag is intended for a noteworthy attribute or fact concerning an individual, a group, or an
organization that cannot be expressed by predefined attribute types. In 5.5.1 it was introduced
additionally to the EVEN tag, to express the semantic difference between events and attributes.
A FACT must be qualified or classified by a subordinate TYPE tag (see below).
For example, the attribute could describe a person's skills, such as woodworking,:
1 FACT Woodworking
2 TYPE Skills
This groups the fact into a generic skills attribute, and in particular this entry records the fact that this
individual possessed the skill of woodworking.”
GEDCOM 5.5.1 Annotated version by Tamura Jones
www.tamurajones.net/DownloadGEDCOM551An ... tion.xhtml
The EVEN with descriptor is shown on page 35.
GEDCOM 5.5.5 released 10/2/2019 This is an update to correct errors only and not to provide additional functions.
GEDCOM Specifications www.gedcom.org/gedcom.html
GEDCOM 5.5.5: Just a Revision (tamurajones.net) www.tamurajones.net/GEDCOM555JustARevision.xhtml
Keith Riggle posted this about the EVEN tag at
genealogytools.com/the-event-structure-in-gedcom-files/
The partially expanded structure for a Family Event is as follows (you can find the full definition on pages 32 and 48 of the GEDCOM 5.5.1 standard):
n EVEN [<EVENT_DESCRIPTOR> | <NULL>]
+1 HUSB
+2 AGE <AGE_AT_EVENT>
+1 WIFE
+2 AGE <AGE_AT_EVENT>
+1 TYPE <EVENT_OR_FACT_CLASSIFICATION>
+1 DATE <DATE_VALUE>
+1 <<PLACE_STRUCTURE>>
You would think that, with the exception of the HUSB and WIFE elements, the Individual Event structure would be the same, but from the partially expanded structure that follows, we can see one crucial difference:
n EVEN
+1 TYPE <EVENT_OR_FACT_CLASSIFICATION>
+1 DATE <DATE_VALUE>
+1 <<PLACE_STRUCTURE>>
The crucial difference is that the Individual Event structure lacks the EVENT_DESCRIPTOR. Now why would this be? Clearly it was an oversight on the part of the authors and editors of the standard, because on page 48 of the standard, the following example is provided for an EVENT_DESCRIPTOR on an Individual Event:
1 EVEN Appointed Zoning Committee Chairperson
2 TYPE Civic Appointments
2 DATE FROM JAN 1952 TO JAN 1956
2 PLAC Cove, Cache, Utah
2 AGNC Cove City Redevelopment
The definition of EVENT_DESCRIPTOR even states that it is “Text describing a particular event pertaining to the individual or family” (emphasis added). So it should be obvious that omitting “[<EVENT_DESCRIPTOR> | <NULL>]” from the Individual Event structure was an oversight. Which brings me back to my original question, what should apps do about this mistake?
GEDCOM release schedule
date version status brief notes
1984 1.0 proposed standard First Version
1985-12 2.0 standard PAF 2.0
1987-02 2.1 standard PAF 2.1
1987-10-09 3.0 standard lineage-linked form
1989-08-04 4.0 standard
1991-09-25 5.0 standard lineage-linked structures
1992-09-18 5.1 draft
1993-11-04 5.3 draft Unicode, multimedia, name parts, schema (abandoned)
1995-08-21 5.4 draft citation-source-repository model, more name parts, submission record (obsolete)
1995-12-11 5.5 standard structured addresses, more name parts
1996-01-02 5.5 standard GEDCOM 5.5 with errata
1996-01-10 5.5 errata GEDCOM 5.5 errata sheet
1999-10-02 5.5.1 standard UTF-8, email, URLs, geographic coordinates
2000-12-18 5.5.2 unpublished draft no more escape sequences, GEDXML
2018-05-10 5.5.1 AE special release Annotated Edition; annotations & corrections.
2019-10-02 5.5.5 standard Maintenance release. Quality. Simpler & Stricter.