18 replies to this topic

[magmatic]

How do you edit fact details that are wrong coming in from a GEDCOM? I imported a GEDCOM. For example, it put a Birth place in the Details, and shows in the Place on the right. But I have a customized fact coming in called Conflicting Information, and it thinks that is a Confirmation. My field is CONF, which is the same as Confirmation for RM.

 

It has details that don't show on the right. Also, it breaks each line or paragraph of the detail into a separate fact. It is misreading the CONT tag.

 

How should I massage the GEDCOM  so RM reads it correctly? Pre-setup special facts before I do the import?  It seems I am losing data in my import. RM does not seem to ask me how I want to handle data it does not understand in the import. It seems to just proceed.

 

How do I make it not break up the lines into multiple facts?

 

Also, I have notes that come in as a person note. But I lose the source citations from within the note. Do you know of a way to fix that?

 

Thank you for any ideas.

[Renee Zamora]

What program is the GEDCOM coming from?

 

You can use a text editor like notepad to massage the GEDCOM file.

[magmatic]

The GEDCOM comes from Generations, the Windows version of Reunion.

 

I know I can edit the GEDCOM with a text editor. But I have to know what to edit it to. I have to know what codes or tags RM will accept.

 

My special note field Conflicting Information is tag CONF, and that is the problem. I can change it to something else, but it needs to be something RM will recognize. I also need to know what the tag code for that is. I need to do that with all my special fields, like Questions, Eye Color. That tag codes are not in the Roots Magic book. I suppose they are on the Internet somewhere.

 

It WILL take my Misc. Notes field. But I lose the source footnotes in it that Generations so elegantly maintains. I guess I have to manually insert the source text.

 

Thanks so much.

[Ludlow Bay]

Try changing, for instance, your CONF tag to _CONF

 

That will tell RootsMagic that you are using a non-standard tag and it should avoid conflicts with the standardized tag.  Otherwise, you can try to match up your tag with one in the GEDCOM Standard Release 5.5 -

http://homepages.roo...om/55gcappa.htm

[kbens0n]

You want to bring these miscellaneous notes in as events of type miscellaneous.
Example:

1 EVEN Miscellaneous fact about John Doe with note and source
2 TYPE Misc
2 DATE 20 JUL 2016
2 PLAC New York City, New York, New York
2 NOTE Here's the Miscellaneous fact note
2 SOUR @S48@
3 _TMPLT
4 FIELD
5 NAME Page
0 @S48@ SOUR
1 ABBR NYS Vital Records Index
1 TITL NYS Vital Records Index
1 _SUBQ NYS Vital Records Index
1 _BIBL NYS Vital Records Index.
1 _TMPLT
2 TID 0
2 FIELD
3 NAME Footnote
3 VALUE NYS Vital Records Index
2 FIELD
3 NAME ShortFootnote
3 VALUE NYS Vital Records Index
2 FIELD
3 NAME Bibliography
3 VALUE NYS Vital Records Index.
1 REPO @R3@
0 @R3@ REPO
1 NAME Rochester Public Library
1 ADDR
0 _PLAC Minneapolis, Hennepin, Minnesota
1 MAP
2 LATI N44.9800000
2 LONG W93.2636100
0 _PLAC Minnesota
1 MAP
2 LATI N46.2502800
2 LONG W94.2502800

[magmatic]

Let me try the Miscellaneous somehow. The trick, I see, is getting Generations to write out such an event as Miscellaneous with the right tags. I would have to know what its field is called. It will do GEDCOM 5.5, but with limited sucess so far.

[Vyger]

Let me try the Miscellaneous somehow. The trick, I see, is getting Generations to write out such an event as Miscellaneous with the right tags. I would have to know what its field is called. It will do GEDCOM 5.5, but with limited sucess so far.

 

Generations is not writing this as a custom fact and in the edit of gedcom I can see a problem if you also had Confirmations. Is there a way within Generations to edit the Gedcom tag for that particular fact?

 

It should write as follows;

 

1 EVEN
2 TYPE Conflicting Information

 

Any Description field information would appear alongside EVEN, Place, Place Details and Source information would follow after TYPE.

[Jim Byram]

Generations is a tough nut to crack. The Generations GEDCOM export is minimal and omits much of the data. We spent considerable time developing a direct import of the Generations database to TMG. If you wish, I'll import the Geneartions database to TMG and make a GEDCOM. You can then try to import to RM both from the TMG database and from the GEDCOM and use what works best.

 

You can contact me by email by clicking on the link below...

Jim Byram

[magmatic]

Try changing, for instance, your CONF tag to _CONF

 

 

I tried something that, but RM did not see it. I also don't think some standard tags would work, if RM doesn't recognize them.

 

I think my problem is I am trying to change the tag for a Generations FACT. But that is not the same as a RM Fact. Apparently, RM does not have true Facts. What RM calls a Fact is really an Event. (Events have dates; Facts do not.)

 

So, I need to manually copy my Generations Facts data to some Generations Event.

 

I have Facts, such as Eye Color and Grave Inscription. I have to change those to events, which makes no sense.

 

And yet, according to the book, RM has "Namesake". Where would that appear? As an Event, with a space for a date?

 

CORRECTION TO THE ABOVE: I see now RM DOES have true facts. Fact Edit window control whether it has a Date or Place (aka Place and Details) or Description. "Description" is what the Fact means. But why does Ordination not have a description but say, Property does? I was thinking of putting my Conflicting Information in the Details field, but I see that is not what it is for. But that is the only option. Yet, you can't see the whole field if there is a lot to go in there. This is all very limiting. Right now, I don't know what to do with my data.

[magmatic]

You want to bring these miscellaneous notes in as events of type miscellaneous.
Example:
 

 

That might work if I can figure out how to make Generations have a miscellaneous event in the right GEDCOM format.

 

I found that RM writes out a misc. fact like this. I hope it also RECEIVES in the same format.

 

1 EVEN contents of description field

2 TYPE Misc

2 DATE

2 ADDR contents of details field

2 NOTE any note attached to the event

 

It didn't do 2 PLAC

[magmatic]

 

Is there a way within Generations to edit the Gedcom tag for that particular fact?

 

It should write as follows;

 

1 EVEN
2 TYPE Conflicting Information

 

 

 

Generations will let you call a Tag what you want. It does not put out the 1 EVEN 2 structure that I can see. I can call a fact anything I want. Is this structure in GEDCOM 4 or 5.5 or both?

[magmatic]

If you wish, I'll import the Geneartions database to TMG and make a GEDCOM. You can then try to import to RM both from the TMG database and from the GEDCOM and use what works best.

 

 

That's a very generous offer. Thank you. I'd like to try to handle this on my own first if I can. Since I can see the incompatibility of a Generations Fact to a RootsMagic "Fact", which is really an Event, you must be doing some awesome conversion there.

[magmatic]

_{Another issue with Generations is that in addition to Events and Facts, it has "Flags". A Flag is a fact that is either Yes or No. For example, I have a Flag for "Left-handed". I have to figure out what RM Event to manually combine those to.}

[Vyger]

 

That might work if I can figure out how to make Generations have a miscellaneous event in the right GEDCOM format.

 

I found that RM writes out a misc. fact like this. I hope it also RECEIVES in the same format.

 

1 EVEN contents of description field

2 TYPE Misc

2 DATE

2 ADDR contents of details field

2 NOTE any note attached to the event

 

It didn't do 2 PLAC

 

It does but the one thing I find missing is what Generations is exporting?

 

Can you post the Generations Gedcom example of one Conflicting Information event which contains Description Field and Notes, I am not sure what you are putting into Place Details without a Place?

[magmatic]

Generations puts this out in GEDCOM 5.5

 

1 NAME Malcom (Mack) McDaniel /McCourry/
2 SOUR @S43@
1 SEX M
1 BIRT
2 DATE 6 NOV 1826

...

1 CONF @N167@
 

RootsMagic just puts "@N167" in the details field. It does not see what N167 refers to.

 

In GEDCOM 4, Generations does

1 NAME Malcom (Mack) McDaniel /McCourry/
2 SOUR @S43@
1 SEX M
1 BIRT
2 DATE 6 NOV 1826
...

1 CONF Birth 1836 Birth 1839 Death Aug 1909
1 CONF
1 CONF The inscription of his modern grave marker reads: Mack McCurry /
2 CONT Pvt Co C 16th Regt NC State Trps / Confederate States Army /
2 CONT 1839 (Cross) 1909.
1 CONF
1 CONF Bailey does mention children Amanda and Jane. Cornelia did not
2 CONT mention Addie.
1 CONF However, the marker placed by Bailey near the Zeph McCourry
2 CONT cemetery mentions Amanda and Jane, born and died in the 1860's.
2 CONT Neither mentions Euranus (who was pointed out by Carol in the
2 CONT video at the Milt McCourry cemetery as a son of Mal. III.) I am
2 CONT placing him with George W.
1 CONF
1 CONF Video notes show that Milt and Sid were brothers. There was was
2 CONT a Klate - Ida Parsons. Klate killed Pearl Harbor. and Seth.
2 SOUR @S26@
2 SOUR @S31@
2 SOUR @S23@
 

I don't see a way to attach a screenshot of what RM looks like with the GEDCOM 4.

 

[TomH]

That's a very generous offer. Thank you. I'd like to try to handle this on my own first if I can. Since I can see the incompatibility of a Generations Fact to a RootsMagic "Fact", which is really an Event, you must be doing some awesome conversion there.

You will need to wade through the GEDCOM "standard" as well as do trial exports from both RootsMagic and Generations as you have been doing to compare behaviours. Add to that, RootsMagic imports differently according to what it sees in the GEDCOM HEADer. That is, it processes a TMG GEDCOM differently than a FTM GEDCOM differently from a RM GEDCOM differently from a Generations GEDCOM. So you could also muck around with editing the header. Many variables make for a long and frustrating process.

 

I would jump on Jim's offer because a lot of work was done to get a good import of TMG, initially its GEDCOM and then direct import, into RM, largely guided by him. If there had also been a decent import from Generations to TMG, then this may well be the fastest and most transparent (or least distorted) route to go.

[KFN]

In GEDCOM the CONF tag represents a CONFIRMATION.

If your current software does not support the GEDCOM standard way of creating a new Event or Fact,

1 FACT
2 TYPE conflicting data

I would jump on jim's offer to create a GEDCOM.

The GEDCOM standard suggests the following: "Conflicting event dates and places should be represented by placing them in separate event structures with appropriate source citations rather than by placing them under the same enclosing event."

It also states: "The occurrence of equal level numbers and equal tags within the same context imply that multiple opinions or multiple values of the data exist. The significance of the order in these cases is interpreted as the submitter's preference. The most preferred value being the first with the least preferred data listed in subsequent lines by order of decreasing preference. For example, a researcher who discovers conflicting evidence about a person's birth event would list the most credible information first and the least credible or least preferred items last."

In general I use notes to indicate my thoughts on which one is more correct and why.

[Jerry Bryan]

The GEDCOM standard suggests the following: "Conflicting event dates and places should be represented by placing them in separate event structures with appropriate source citations rather than by placing them under the same enclosing event."

It also states: "The occurrence of equal level numbers and equal tags within the same context imply that multiple opinions or multiple values of the data exist. The significance of the order in these cases is interpreted as the submitter's preference. The most preferred value being the first with the least preferred data listed in subsequent lines by order of decreasing preference. For example, a researcher who discovers conflicting evidence about a person's birth event would list the most credible information first and the least credible or least preferred items last."

 

Notwithstanding this text in the GEDCOM standard, I wonder if the preferred GEDCOM way of handling conflicting data is obsolete. I certainly don't feel like RM handles duplicate events/facts very gracefully. And I'm not sure that RM's interface with FSFT handles duplicate events/facts very gracefully.

 

I have striven to avoid duplicate facts/events in RM whenever possible. If somebody was married more than once, then obviously they were married more than once. But I avoid duplicate birth events or death events, etc. Instead, I enter one event with my preferred dates and places and I include a note about the conflicting data and my analysis of which data is preferred. I'm probably doing it wrong, but that's what works the best for me.

 

Jerry

[KFN]

Jerry,

I would not say you are doing anything wrong. Much of the issues that arise using and recording data in software is that 1) programs don't follow or implement all of GEDCOM, 2) using the fields supplied in the software and for that matter in GEDCOM little is documented as to how yo use the field, 3) reporting and data display does not include the ability to customize the presentation experience. 4). Most importantly, many of us do not separate data collection, decision making and conclusion reporting in our data and software usage.

This final point is probably the biggest issue. If all I was doing was presenting conclusions I would not need much of the GEDCOM standard, date, place and conclusion text/commentary and good source documentation. However, data collection requires more data POINTS and relationships than GEDCOM provides. While I don't thing it is obsolete, I do think that most programs don't take multiple data points into consideration in their reporting as they relate to source quality, or help us to develope a conclusion. Obviously GEDCOM does supply some ways to deal with this but it would be nice to include additional data points and relationships to aid and record our reasons for assigning a datapoint to a person or event. GEDCOM is more geared toward conclusions rather than data collection and decision making. This is not to say that GEDCOM needs a lot of changes, since I still believe that it was designed to transfer conclusions not to be a database design for data recording and decision making database and therefore as such does almost everything it should and with proper use can continue to do that. Software can provide better data collection features and then create a good GEDCOM to transfer conclusions.