Family Historian User Group

Gary_G wrote: ↑23 Nov 2023 14:19 ...how does one handle "Occupation" attributes without resorting to specifying a date, which is typically something reserved for events?

Attributes can have dates. The difference between attributes and events (in FH) is that attributes have an additonal field for the value, which events don't have.

Gary_G wrote: ↑23 Nov 2023 14:19 A question came to mind regarding trying to conform to FH7's current usage of events and attributes. Is there a way in FH7 to list those "facts" that don't conform to the GEDCOM definition of event or attribute? I'd like to be able to revise those entries to look as they would had they been entered directly into FH7.

I'm not sure what you asking. By definition, every Fact in FH7 and in GEDCOM is either an Event or an Attribute, because FH7 conforms to GEDCOM. So there cannot be any Facts that don't conform.

Gary_G wrote: ↑23 Nov 2023 14:19 A second one is how does one handle "Occupation" attributes without resorting to specifying a date, which is typically something reserved for events?

As Lorna says, the only difference between Events and Attributes is that the latter can have an attribute value.
Otherwise, all the fields and features are identical.
Some other products do not differentiate between Events and Attributes and allow both to have a value often called a description. It is importing such Events with a value/description from other products where FH offers options for handling the value/description text that it does not allow. i.e. The text is moved into a local Note field or a special UDF field.

LornaCraig wrote: ↑23 Nov 2023 14:59

Gary_G wrote: ↑23 Nov 2023 14:19 ...how does one handle "Occupation" attributes without resorting to specifying a date, which is typically something reserved for events?

Attributes can have dates. The difference between attributes and events (in FH) is that attributes have an additional field for the value, which events don't have.

Thanks for correcting that Lona. If RM9 treats attributes and events the same, what is the equivalent RM9 field to the value and to where does it get mapped in FH7 for events? Is it an RM9 event Description field and does it become an FH7 Note? Need to get this straight in my mind, so the import goes smoothly.

Tatewise;

W.r.t.

I'm not sure what you asking. By definition, every Fact in FH7 and in GEDCOM is either an Event or an Attribute, because FH7 conforms to GEDCOM. So there cannot be any Facts that don't conform.

If FH7 makes a distinction between events and attribute and RM9 does not, does FH7 automatically adjust for the presence of a description in some RM9 facts and how does it handle them?

Gary_G wrote: ↑23 Nov 2023 15:30 If RM9 treats attributes and events the same, what is the equivalent RM9 field to the value and to where does it get mapped in FH7 for events? Is it an RM9 event Description field and does it become an FH7 Note? Need to get this straight in my mind, so the import goes smoothly.

Yes, it is the RM9 event Description field.
How it gets imported should depend on the Tools > Preferences > File/load Save option Move invalid data into note fields where possible but I'm not sure if that is honoured with a direct import from RM9. Can you check?
If ticked then each Event Description goes into the Event Note field but gets tricky if there already is a Note field.
If not ticked then it goes into an Event _UNCAT UDF field.
Then if you use the Change Any Fact Tag plugin to convert such Events to Attributes it automatically moves the _UNCAT text to the Attribute value.

Thanks, Mike.
Now that I know what to look for, I think I can figure things out by trial and error.

I found that, for a Death "fact", the RM9 "Description" field is mapped to the FH7 "Cause" field on direct import. I suppose it makes sense to think of it as a description relating to the death. However; some RM "refugees" have been using it for the name of the institution in which the death occurred. This is because the description occurs just below the address field in RM( input screens.

The same type of thing likely happens for other instances of RM9 using a "Description" field with an event. So; it looks like I may have to check the transferred data for other instances in which the RM9 "Description" field is used and adjust it as necessary.

For general background - RM uses fact definitions that are very similar in concept to FH Fact Set files, except that they are entirely local to a specific database, not defined at system level. By default, the description field is active for attributes, but disabled for events. If users don't change these defaults, Events and Attributes are properly distinguished on import to FH. A custom RM fact is treated either as an Event or Attribute, depending on this setting.

Where it gets potentially messy is where a user has overwritten the defaults to enable the description for a standard GEDCOM Event, such as Birth. In this case, any description associated with the Event is moved to a Note field, irrespective of the Move invalid data into note fields where possible setting. If the Event already has a note associated with it, the Event description is appended to the start of that note on import, not created as a second note, which is not generally supported within RM.

Edited to reflect Gary's posting - I tested it with a Birth fact, but it looks like FH might be making a fact by fact assumption of what that value is most likely to represent. We could do with those assumptions being documented, as I don't think they are included in Importing From RootsMagic on the main FH website. These values are moved silently on import without explanation. IMO, it would be useful to have them logged so the user can easily find and review them. A simple plugin could screen the RM file prior to import, but that should not be necessary (again, IMO of course!).

Thanks, Mark.
I thought I was going crazy, since I hadn't seen this behaviour documented and dreaded trying to "reverse engineer" how it was designed to work. What I really need is an import log that tells me about anything that has been moved or altered based upon a decision that FH7 has made as to where it "belongs". At least I could then validate it without too much trouble.

It’s one SQL statement to enable the Description field for all Facts in an RM test file, so after a bit of testing, it appears that all Event descriptions are migrated to Notes apart from Death (and curiously, Retirement ), which both go to Cause.

Until CP updates the FH documentation, can all this knowledge be captured in Importing to Family Historian under the Import from RootsMagic (RM) accordion.

Good idea - it’s overdue for revision, as I think we can lose a lot of the stuff pertaining to GEDCOM import, which hasn’t been relevant for over two years now. Anybody who needed to fix their old import will have done so by now, and it could just confuse new users.

It’s on the list!

Mark1834 wrote: ↑23 Nov 2023 20:09 It’s one SQL statement to enable the Description field for all Facts in an RM test file, so after a bit of testing, it appears that all Event descriptions are migrated to Notes apart from Death (and curiously, Retirement ), which both go to Cause.

Thanks, Mark. That explanation helps.
There's so many things to keep in mind when preparing for or actually importing RM9 data.
Do it correctly and it's a wonderfully easy task. Do it the wrong way and one's life can be hell.