* On Hold until 24 Oct 2024: Ability to Change Type of Fact

[BEJ]

I was unaware that Employment was not a standard GEDCOM fact. Wish there was a way to know which elements of FH will not transfer into standard GEDCOM fields.

To answer you question — I consider Occupation to be an individual’s profession that may encompass several jobs. Employment is each individual job for which they were hired. For instance, my Occupation is as a park manager over my professional life while I’ve been employed at several parks for specific periods of time in specific places and they would be entered as separate Employment facts.

[davidf]

I was about to point out that distinction using the example of "Railway Worker" which was often meaningless as an occupation, whilst Employment: London North Eastern Railway;, Occupation: Clerk;, is more useful.

I tend to use Occupation as the FH fact (which matches to GEDCOM expectations) but put "Employer: London North Eastern Railway" in the fact notes - using =GetLabelledText to extract employer for diagrams etc.

I think that is the best way round (i.e. not "Occupation" in the notes for "Employer") not just because that suits GEDCOM and any program that seeks compliance with the standard, but because as in the previous post the Occupation probably spans multiple employment more often than Employment spans multiple Occupations. Occupation tends to appear more often on official forms (Censuses, Marriage records etc.)

[BEJ]

David — Thanks for the response. Perhaps one disadvantage of only using Occupation, with Employment in notes, is that the jobs would not show up in timelines. Unless, that’s what you propose by using =GetLabelledText . Unfortunately that approach is beyond my pay grade. I frequently think that my choosing Family Historian was a mistake due to the level of technical knowledge needed to make it effective. Alas, I’m committed now and will blunder onward. If GEDCOM uses Occupation, I’ll use Occupation. And I’ll have to research LabelledText when I have a minute.

Next challenge, investigate Change Specific Fact Tag and Change Any Fact Tag plugins by first figuring out what a “fact tag” is.

Perhaps you missed the relevant posting, but there is no need to copy & paste anything external to FH.
The Change Specific Fact Tag plugin in the Plugin Store will change any single nominated Fact.
The longstanding Change Any Fact Tag plugin will bulk change all, or a selected subset of, Facts from one type to another.

[Mark1834]

“Tag” is really just there for historic reasons. It would probably be clearer if the two plugins were called Change Specific/Any Fact Type, but it’s probably too late to change them now .

[davidf]

investigate Change Any Fact Tag by first figuring out what a “fact tag” is

My understanding is that a "fact tag" is the GEDCOM shorthand for a fact type. Some are straight forward: NAME = the Name fact
Others can be decoded: BIRT = the Birth fact
Some are more obscure: CENS = Census fact, BAPM = Baptism fact

It appears that the Change Specific Fact tag can identify a specific instance of a tag in someone's record (some fact tags can appear multiple times - logically, e.g. CENS, others due to confusion or unreconciled queries, e.g. BAPM) and allow you to change the tag (which is what is recorded in the GED file), for instance from Christening (CHR) to Baptism (BAPM).

[tatewise]

I was unaware that Employment was not a standard GEDCOM fact. Wish there was a way to know which elements of FH will not transfer into standard GEDCOM fields.

I'm not sure I understand the question.
Perhaps it helps to understand that GEDCOM has a core of standard fields with which most products comply, while GEDCOM allows custom fields (with a leading underscore in its GEDCOM tag) to be legally added that other products might not understand. It is further complicated by some of those custom fields becoming de facto standards that many products support, e.g. Shared Fact Witness (_SHAR) and Sort Date (_SDATE).
The FHUG Knowledge Base GEDCOM Extension List explains the FH custom fields, although not yet updated for FH V7.

Don't take the names of GEDCOM fields too literally. The GEDCOM definition for OCCUpation is:

The kind of activity that an individual does for a job, profession, or principal activity.

i.e. job, employment, profession, activity, trade, vocation, etc...

[tatewise]

“Tag” is really just there for historic reasons. It would probably be clearer if the two plugins were called Change Specific/Any Fact Type, but it’s probably too late to change them now .

Not entirely true in the case of Change Any Fact Tag whose first line of its description says:

This plugin allows any Individual Fact, or Family Fact, or other level 1 GEDCOM Tag, to be deleted or changed provided that is valid. It supports Standard Facts, Custom Facts, GEDCOM Tags, and UDF Tags.

[Mark1834]

It’s probably a good illustration of why the folks who write the code shouldn’t do the documentation . Yes, they change the tag, but most users will come to them wanting to change a fact type/name. Documentation should be written in user language, not programmer language. Changing them now will create more problems than it solves, but it’s a useful reminder for the future.

[AdrianBruce]

I was unaware that Employment was not a standard GEDCOM fact. Wish there was a way to know which elements of FH will not transfer into standard GEDCOM fields. ...

Leaving aside opening up the GEDCOM in an editor, the simple way to get the basic idea about Fact Types is to go to menu Tools / Fact Types... and look at this window that appears:

Screenshot 2022-07-27 163536.jpg (55.78 KiB) Viewed 2752 times

Have a look at the Fact Set drop down in the top left. If you click the drop down arrow, you should see Standard - select that. The resulting list of Event / Attributes below is the list of Fact Types that should transfer into other software because those are the ones in the GEDCOM Standard. No guarantees about that because other programmers don't always read the manual.

(My screenshot isn't what you will see, I imagine, because I've effectively cloned the facts so that I can play about with the narrative sentences without messing up the original but my clones use the same label / tag as the original Standard so will transfer).

Anything that you see as being in a Fact Set called anything other than Standard, such as Fact Set = Custom, is at risk of being lost in a transfer. (Fact Set is just a collection of fact types).

That does not mean that you shouldn't use them - I use lots - it just means you need to think a bit if you want to transfer your stuff into a different program.

I notice that there is a fact type called Employment in the Fact Set called Extended Set. Because that's not in the Standard Fact Set, it's at risk of being lost in a transfer. I think that the Extended Set comes with Family Historian and represents a fairly typical set of extensions / custom fact types, the idea being (I suppose) to try and corral people's choices when they create their own fact types in order to reduce confusion. Why, for instance, have a Fact Type named ApprenticedAs if everyone else is using Apprentice? (That's a made-up example).

[BEJ]

Excellent. I was familiar with the Fact Types window, as I’ve added custom types and have hidden and shown types. The “custom” type seemed self explanatory. What was not clear to me was that “standard” is more or less equivalent to GEDCOM types/tags and that “extended” are those added by Family Historian. Thanks so much for the tip (this is probably explained deep in the documentation somewhere, but . . . )!

[tatewise]

Adrian has been over-zealous in his explanation.

Of all the GEDCOM custom extensions, custom Events (such as Funeral and Separation) will usually migrate well to other products. However, they will not have any particular significance in the way that standard Events such as Birth, Marriage & Death usually have special side-effects, e.g. FH will complain if lifetime facts are entered with a Date before the Birth Date or after the Death Date.

However, custom Attributes (such as Employment or Known As) may not migrate well because they use the standard GEDCOM tag FACT in FH V7 which is not recognised by some products or the custom tag _ATTR in FH V6 which is not recognised by almost all products. A workaround is to use the Export Gedcom File plugin that knows what other products recognise and converts the FACT and _ATTR tags appropriately. However, it is much better to use the standard Occupation attribute and the standard Name fields, etc.

[BEJ]

Nothing is as easy as it seems. . .
Thanks.

[AdrianBruce]

Adrian has been over-zealous in his explanation. ...

Or over-simplistic...

Yes, that's actually a good point about the difference between custom events and custom attributes. As Mike says, the risk is probably minimal for custom events but much greater for custom attributes.

PS - have we mentioned Emigration and Immigration in this context? They are Standard Events but FamilyHistorian has added a custom second placename to both. That makes the recording in FH far easier because it allows the equivalent of "Eleanor emigrated from Liverpool to New York", whereas standard GEDCOM can only cope with "Eleanor emigrated from Liverpool". So you'd be safer ignoring that second placename.

(It is mentioned in https://fhug.org.uk/kb/kb-article/gedco ... sion-list/ as the "Other Place in EMIGration & IMMIgration Events".)

PPS - it's not a problem I have because I don't use Emigration and Immigration, I use Departure and Arrival custom events - I need to use them in pairs, of course.

[tatewise]

PS - have we mentioned Emigration and Immigration in this context? They are Standard Events but FamilyHistorian has added a custom second placename to both. That makes the recording in FH far easier because it allows the equivalent of "Eleanor emigrated from Liverpool to New York", whereas standard GEDCOM can only cope with "Eleanor emigrated from Liverpool". So you'd be safer ignoring that second placename.

PPS - it's not a problem I have because I don't use Emigration and Immigration, I use Departure and Arrival custom events - I need to use them in pairs, of course.

Given your earlier logic, why would you prefer custom Attributes (Departure and Arrival) over standard Events (Emigration and Immigration) used in pairs?
Those two custom Attributes might not migrate to other products (especially if you use the value), whereas the two standard Events would almost certainly migrate correctly as long as you never use the 2nd Place field.

[AdrianBruce]

...
Given your earlier logic, why would you prefer custom Attributes (Departure and Arrival) over standard Events (Emigration and Immigration) used in pairs?
Those two custom Attributes might not migrate to other products (especially if you use the value), whereas the two standard Events would almost certainly migrate correctly as long as you never use the 2nd Place field.

Minor point - my Arrival and Departure are custom events, so slightly safer than custom attributes.

Nevertheless, it's a fair question and comes down to balancing internal FH usage versus exportability.

As far as use inside FH goes, GEDCOM 5.5.1 defines Immigration as:

An event of entering into a new locality with the intent of residing there

My objection there is the near-impossibility of knowing intent. If I take the guy who spent a year or two working in the grain provinces of Canada - given that he spent the rest of his life working as a planter in various parts of the Empire, it's a fair bet that the Canadian visit was just "work experience" and therefore was a temporary visit with no intent of settling. But another example is a couple who went to the USA - after a year or two, the wife came back on her own, being followed a few months later by her husband. Was that an (intended) emigration that went sour, or only ever a short-term business venture? I can't know...

So, my inner pedant kicks in with a distaste for using emigration / immigration because the implied meaning usually can't be justified. Of course, I could redefine mentally (or otherwise) emigration / immigration as "really meaning" departure / arrival, but that doesn't seem much better. So eventually I settled on custom events for departure and arrival, with their clarity outweighing the extra risk of disruption on exporting to another program. Others may balance things out differently...

PS - and what about the genuine emigrant who makes trips back to the UK on family visits? When they return through Ellis Island, are they emigrating / immigrating again? Surely not.... At least, not in the English language...

[Mark1834]

I must admit, I hadn't thought too deeply about that previously, but that description makes a lot of sense. It's probably analogous to preferring Census over Residence. The latter is discouraged as a census entry does not prove residence, and an arrival/departure doesn't prove intent.

It's a good example of practical use trumping adherence to GEDCOM for its own sake.

[ColeValleyGirl]

I have modified the Immigration fact to be a Travel fact for the same reasons, Adrian. I'm not too bothered about portability.

[tatewise]

Sorry Adrian, I falsely assumed you had used the FH Extended Set definitions of custom Attributes for Departure and Arrival. Your use of custom Events with the same names is comparatively safe and rational.

[davidf]

So is there a general recommendation that rather then custom attributes we should create custom events and put "attribute" type information in the fact note as "Attribute: xyz" and then when creating use =GetLabelledText to put the attribute information in the fact sentences etc.?

This would apply either when anticipating migrating from FH to something else or when "just visiting" for instance a web-based tree publishing application (e.g. Webtrees)?

Does this sort of quirk have to find its way into the kb?

[tatewise]

I said earlier:

However, custom Attributes (such as Employment or Known As) may not migrate well because they use the standard GEDCOM tag FACT in FH V7 which is not recognised by some products or the custom tag _ATTR in FH V6 which is not recognised by almost all products. A workaround is to use the Export Gedcom File plugin that knows what other products recognise and converts the FACT and _ATTR tags appropriately. However, it is much better to use the standard Occupation attribute and the standard Name fields, etc.

It is certainly advisable to use standard Events and Attributes rather than custom facts where there are suitable ones.
As long as the Export Gedcom File plugin is used, any custom Attributes are converted for each destination product as follows:

• Use custom Events with the value similar to Attributes, which is supported by many GEDCOM 5.5 based products.
• Use custom Events with the value moved to a labelled Note as suggested by David.
• Use custom Attributes with the FACT tag, which is supported by GEDCOM 5.5.1 based products.
• Use custom Attributes with the _ATTR tag, mainly for migration from FH V7 to FH V5 & V6.

In the Export Gedcom File plugin, Extra Options tab, see the Custom Attribute options.

Although worth some consideration, there are other custom features of FH that pose far more problems when migrating to other products.

[AdrianBruce]

Sorry Adrian, I falsely assumed you had used the FH Extended Set definitions ...

Curiously (or maybe not) I keep forgetting that Extended Set exists - I find creating new Fact Types so easy (and I know not everyone does!) that it's more work for me to find an existing definition than to create one of my own. (Of course, as per my own advice, that does mean I might have slight variants of what other people use).

[ColeValleyGirl]

Does the Change Specific Fact Tag plugin meet this need (which seemed to get somewhat lost in 4 pages of partly unrelated discussion).

[tatewise]

IMO the plugin is a stopgap workaround. It is somewhat clunky and takes focus away from the Facts tab.
It also only allows Individual to Individual fact or Family to Family fact changes.
An FH implementation should be able to support Individual to Family fact changes and vice versa.
e.g. Census (family) to Census for both Individuals, Residence to Residence (family), or various custom facts.

[ColeValleyGirl]

I'm moving this to On Hold. There's some support, and a plugin has been implemented, but Mike T expressed a view that a Wish List item is still required but nobody has consolidated a proposal out of the lengthy discussion.