Jump to content


Photo

"Unknown info" exception on MARR fact import from Ancestry

GEDCOM Ancestry.com Import Bug

  • Please log in to reply
5 replies to this topic

#1 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5874 posts

Posted 18 July 2012 - 01:15 PM

On an import from an Ancestry GEDCOM, the RM LST report shows 41 exceptions to 76 instances of the Marriage fact, e.g.:
Unknown info (line 916)
1 MARR
2 DATE 14 Jun 1916
2 PLAC York, York, Ontario, Canada
2 SOUR @S-2133199186@
3 NOTE http://search.ancestry.ca/cgi-bin/sse.dll?db=ontariomarr1858-1899_ga&h=1188506&ti=5543&indiv=try&gss=pt
3 NOTE
3 DATA
4 TEXT Birth date: abt 1886 Birth place: Palmerston Ont Marriage date: 14 Jun 1916 Marriage place: York, York, Ontario, Canada
3 _APID 1,7921::1188506
Every instance (1870) of the custom 3 _APID tag was excepted, as might be expected since it is a custom tag. No other exceptions were reported.

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.


#2 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 7949 posts

Posted 19 July 2012 - 10:04 AM

The RootsMagician says: "We need to know the full context of where that 1 MARR tag was. If it was under the INDI tag, then it is invalid. If it is under the FAM tag (as it is supposed to be), then we would need to see the full GEDCOM to test."
Renee
RootsMagic

#3 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5874 posts

Posted 19 July 2012 - 12:49 PM

Thanks, Renee and RootsMagician. I did some more inspection and confirm that the first several exceptions are in fact under 0 INDI tags; that probably holds true for the rest. So I had a look at the Ancestry Tree at one instance and found that a "Marriage to Unknown" fact was added when a marriage source was attached to a person without a spouse person existing. Another instance of an exempted Marriage just says "Marriage" on Ancestry under the person to whom the source was attached and no such fact (or source) under the other spouse; in this case, I think the spouse was added after the marriage source was attached to the first person, her fact probably said initially "Marriage to Unknown" and changed to "Marriage" on the addition of the spouse. An accepted marriage fact shows on Ancestry as "Marriage to spousename" for both; I suspect the two persons existed at the time the source was attached to one. Attaching the marriage source to the husband in my second example resulted in an 'individual' "Marriage" fact for the husband and no change to the existing 'individual' "Marriage" fact for the wife.

So, whatever the interpretation of the GEDCOM standard, Ancestry exports the Marriage fact as an Individual fact along with its source(s) as well as exporting a Marriage fact as a Family fact, depending on the order in which persons are created, coupled and sourced. The INDI MARR fact cannot be undone in Ancestry it would appear except by deletion of the fact from each person, creating the spouse if not existing, creating a family marriage fact "Marriage to spousename", going to the source(s) and detaching them from both persons, and then re-attaching the source(s).

As I and I'm sure others use Ancestry Trees to build pro tem trees for research, and collecting sources, I daresay there might be some justification in wishing that RootsMagic would support INDI MARRs. While one might be puritanical that a MARR fact is inherently a family fact and requires two people, the truth is that maybe we are only interested in the one side. Maybe RM could convert the INDI MARR to a FAMS MARR with an automatically generated "Unknown Spouse", thereby preserving the event and the source that is evidence of it. :rolleyes:

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.


#4 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5874 posts

Posted 20 July 2012 - 12:01 PM

Legacy 7.5 does not reject the INDI MARR nor does it create a fact from it; rather it makes a sentence that is added to the General Note. While that note is not sourced, the source is not lost because it is also cited for Name and Birth. That, too, would be an acceptable result in RM.

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.


#5 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 7949 posts

Posted 20 July 2012 - 12:19 PM

Confirming enhancement request is in our tracking system.
Renee
RootsMagic

#6 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5874 posts

Posted 22 July 2012 - 03:53 PM

Thank you, Renee. To amplify, here is what LFT 7.5 added to the General Note for the person whose MARR fact was within the INDI block:

Married on 14 Jun 1916
Married at York, York, Ontario, Canada
SEX: SOUR @S-2133199602@
NOTE http://search.ancestry.ca/cgi-bin/sse.dll?db=ontario_births&h=1248382&ti=5543&indiv=try&gss=pt
NOTE
DATA
TEXT Name: Adda Jennie Estella Wooldridge Birth: 28 Nov 1884 in Ontario, Canada Death:
_APID 1,8838::1248382
The inclusion of "SEX: SOUR" ff in the note appears to be a bug in LFT picking up some tags from the SEX block later in the GEDCOM.

The note added to her spouse was simply:
Married on 14 Jun 1916
Married at York, York, Ontario, Canada
i.e., despite there being a source listed on Ancestry, and exported in its GEDCOM:
1 MARR
2 DATE 14 Jun 1916
2 PLAC York, York, Ontario, Canada
2 SOUR @S-2133199186@
3 NOTE http://search.ancestry.ca/cgi-bin/sse.dll?db=ontariomarr1858-1899_ga&h=2058386&ti=5543&indiv=try&gss=pt
3 NOTE
3 DATA
4 TEXT Birth date: abt 1886 Birth place: Ballinsfad Ont Marriage date: 14 Jun 1916 Marriage place: York, York, Ontario, Canada
3 _APID 1,7921::2058386
, LFT ignored the source in the Note. In both cases, however, the sources were attached to the Name and to the Birth events.

Of course, one would not want RM to duplicate LFT bugs, but you will get the idea of how the latter handles unrecognised or "invalid" GEDCOM tags without total rejection.

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.