* Non standard facts?

[E Wilcock]

I would be grateful to know how users of FH record non standard facts.

I have created a new Project in FH . This is not an import. However, I have displayed All fact sets, the GEDCOM and those that come for users of TMG.

My question is how does GEDCOM and or FH provide for events not included in the original Fact type list to record things which crop up for historians:- for example, arrest, release from prison, deportation, or more happily publishing a book?

In TMG Note Tags were dated and I would frequently use a Note Tag for non standard facts. Maybe wrongly I got the impression that other software did not allow Notes to have dates. So I renamed my Notes as Fact type Eventmisc. (Miscellaneous event). I believed (again wrongly) that this Eventmisc was a GEDCOM individual fact. It came into FH when I did a trial import of a TMG project so I have it available but it is listed as a custom fact. So it isnt GEDCOM after all.

I do not want to create custom fact for each of these - I need a general fact or event for which I can edit the local sentence and expand in the note. My sentence always was indiv "was", with note, place and date. And if possible I would like it to export as Gedcom.

What do FH users do?

[dewilkinson]

As you replied to my post I will reply to yours.

You make a good point. I adopted a policy in TMG many years ago to use custom Tags for specific events (e.g. Military Start, Military Service, Military End, Medals, Wounded, Education Start, Education Continue, Education End etc) in order to get sentences correct as my main objective is to write everything up in book style, and this is needed otherwise there is a huge amount of work required to convert Narrative Reports into prose.

The import into FH has been relatively straight forward requiring me to set up a Fact Type matching what I had in TMG, and one in FH style if it did not already exist, then using the PlugIn 'Change Any Fact Tag' to move them.

My approach may not be 'purist', but it is highly accurate and meets my needs.

One thing I haven't looked into yet as I have yet to start data entry into FH, but I haven't noticed anything yet about copying a Fact then assigning the copy to another individual. This was very easy in TMG and made things like Census entries very simple, just having to edit the details for each individual. Have you an answer?

In your reply to my post you mention is there a course, if one appears I might be interested in attending if the price is sensible.

David (former TMG user)

[tatewise]

May I correct some misconceptions.

GEDCOM Standard
This is the GEnealogy Data COMmunication standard, which defines the structure of Individual, Family, Note, Source, Repository, Media, Submitter, Submission and Header records, and standard field Tags such as INDI, FAM, NOTE, BIRT, DEAT, MARR, TITL, etc, so that genealogy data can migrate between products.
There are actually two specifications, Release 5.5 and Draft 5.5.1, with a handful of fairly minor differences.

Custom Facts
GEDCOM defines how to represent custom facts using standard tags EVEN & TYPE, and Draft 5.5.1 adds the FACT tag.
So custom facts are well defined by the standard, which is why they usually migrate well between products.

User-Defined Tags
GEDCOM allows user-defined tags with a leading underscore, such as _SHAR (Witnesses) and _PLAC (Place Records) in FH. These rarely migrate well between products, and are the main reason for the Export Gedcom File Plugin..

GEDCOM Implementation
Few if any products implement the entire GEDCOM standard, and this is complicated by the two slightly different specifications, and the user-defined tags. On top of that, products offer features that fall outside the GEDCOM standard, such as Narrative Sentence definitions for Reports, which do not migrate between products at all.

However, without GEDCOM, the degree of migration currently available would be inconceivable.

[LornaCraig]

I would be grateful to know how users of FH record non standard facts.

Many FH users create custom facts for events which are not covered by the standard fact set. As Mike has explained, GEDCOM does allow user-defined tags (facts), so they are valid. You may need to use the Export Gedcom plugin to transfer the data to another genealogy program, but there are usually minor 'tweaks' needed even if you don't have any custom facts.

but I haven't noticed anything yet about copying a Fact then assigning the copy to another individual. This was very easy in TMG and made things like Census entries very simple, just having to edit the details for each individual. Have you an answer?

Yes, there are copy and paste icons on the Facts tab of the Property Box, in the toolbar immediately below the list of Facts. However, as you mention this in connection with census entries can I suggest that you consider using the Ancestral Sources program to enter census data (and much more), as it takes a lot of the work out of the job.

[tatewise]

I need a general fact or event for which I can edit the local sentence and expand in the note. My sentence always was indiv "was", with note, place and date. And if possible I would like it to export as Gedcom.

You can create a general custom event via Tools > Fact Types > New.
It will have all the standard event fields of Date, Age, Place, Address, Cause, and Note, plus Media and Source Citations.
You can specify a default Sentence Template in the Fact Type definition involving the Individual, Note, Place & Date, but as with any fact, you can create a local Sentence in the Property Box Facts tab that says whatever you like for any specific fact.
All custom events export as perfectly valid standard GEDCOM that is accepted by most other products.
The exception is the Sentence which either only exists in the Fact Set file, or is a user-defined extension to the GEDCOM and unlikely to be recognised by other products.

I think you are confusing the predefined standard GEDCOM facts that come predefined in the FH Standard Fact Set, and custom GEDCOM facts that you can add in FH Custom Fact Sets that are still valid within the GEDCOM specification.

The TMG custom Tag definitions are conceptually the same as FH custom Fact Type definitions, and both produce valid GEDCOM custom facts, which is why they are successfully transferred from TMG to FH, except for the narrative sentence.

[DonF]

Back to Evelyn's original question ("I do not want to create custom fact for each of these - I need a general fact or event for which I can edit the local sentence and expand in the note."), then here's what to do:
Go into the TMG Tag Type list, and for each of the tags you want to get carried across to FH as a single Fact type, do the following: select Edit of the Tag definition, go to the 'Other' tab and set the 'GEDCOM Export' setting. You have a choice of making it just a type of 'FACT" (which is a valid GEDCOM Tag type) or having it as "1 EVEN 2 TYPE same as tagname" (where EVEN is the GEDCOM Tag name for EVENT).

FH will honour the tagname defined in the TMG GEDCOM definition when it does a direct import from the TMG database, OR if you export a GEDCOM file from TMG, then TMG will honour whatever setting you've made in this edit.

[E Wilcock]

That is lovely help but there has been a misunderstanding. This is not a TMG import topic. My personal family trees are still in TMG. I know that I can open my TMG Project files and import them to Family Historian any time I want - I simply dont have the time or inclination to transfer them just now.

New projects are a different matter. I use genealogy software for historical research and I never create new projects in obsolete software.

A month ago I needed to start another project. I have owned FH for many years and also own Roots magic. There was no obligation to use FH. But this time I have got the hang of the basics. To the person above, yes. Go through the instructional videos on line. You can copy and paste any fact or source - just highlight them and use the icon buttons that become active below. I have 147 individuals in 56 families. Data entry has been bliss.

And I was working too hard on data entry to ask questions.

I made a decision to use FH because it was different. But to benefit from the differences one needs to ask experienced users. So I have a list of things to ask. Not harking back to any other software.

Hence this question about how FH users handle miscellaneous facts.

Thank you Mike for explaining that GEDCOM will accommodate custom Facts. I didnt know this and was fussed about custom facts transferring to Gedstar Pro for my Android phone. But after checking, I now think it was due to my user error in the settings that they didnt come across last time I tried.

I want to improve my use of FH and possibly to shed some bad habits I have acquired over the years. I want to ask these questions because I have had a lovely time with FH data entry this last week. Now I am set to get to know its possibilities and have the full benefit.

Because FH uses a text file rather than a database (big difference), searching for anything at all in FH seems quick and simple. One may (I think) produce lists and filter without specifying certain fields or fact types. So possibly this question about custom facts is like questions about how one uses sources, a matter of personal choice? If a soldier is taken prisoner of war or a political prisoner is sent to Siberia or Dachau, is there a benefit of creating a custom Fact?

[tatewise]

There is advice about exporting from FH to GedStar Pro using the Export Gedcom File Plugin in plugins:help:export_gedcom_file:gsp_gedstar_pro_for_android|> Export Gedcom File ~ (GSP) GedStar Pro for Android. I recently liaised with the developer to add features to make it support more GEDCOM tags than before.

The reason FH is so fast is not so much that it uses a text file, but that it loads it all into main memory records within FH, rather than use a proprietary database query engine.

The use of custom facts is something of a personal choice.
However, it is hardly worth the effort of creating a specific custom fact for just one unique fact, which echoes your own point about Fact type Eventmisc.
It is better to try and create more generic custom facts that will accommodate a spectrum of related facts.
See how_to:narrative_report_fact_sentence_templates|> Narrative Report Fact Sentence Templates especially Custom Fact Fields.
See Gaol Record - How best to record information (14300) and Crime and Punishment Record FH6.2 (14227) for examples of using this technique.

[AdrianBruce]

I used to create a lot of different types of Custom Facts. I've tended to draw back from that now and just have a small number of types of Custom Facts, recording the extra information in the note associated with another fact (standard or custom).

In simplistic terms, custom facts and their contents are easy to find because you can just write a query to investigate that fact type.

On the other hand, stuff gets rigidly separated into different facts, which may not read easily if you want to produce a narrative.

My classic example is military stuff. Originally I had a custom fact for military service and another for "wounded". What this meant was that my narrative report (and I have a lot of narrative note against each fact) showed someone serving from (say) 1915-1918 in the Army, with lots of description about their military career, and then the narrative flipped back to 1916 to say that they were wounded then. It did nothing for readability. So I now just record any details about being wounded inside the note for the military fact.

That's my trade-off - someone using FH primarily to record military history might well retain individual custom facts for wounded etc, for ease of searching in queries. Someone else might record details of military history in the standard GEDCOM fact for Occupation. Not my choice because then it'd be difficult to find them again.

I do have a fairly generic "court-case" custom event where I have to adjust the sentence for each such event because I simply couldn't face specifying sentences for each type of court case - e.g. I think that the plaintiff in a civil action is called something different if it's a Chancery Court action. No, please... I'll do it on a case by case basis.

So there's a balancing act to be done about how many different custom fact types you want, one to balance searchability v. readability.

[tatewise]

The searchability versus narrative report readability is a good point, but to some extent you can have your cake and eat it, with a little effort.

Use Adrian's technique to record all Military History in one fact with copious Notes, including the Custom Fact Fields 'labelled meta-fields' concept, so that the Narrative Sentence reads well in Narrative Reports.

Add specific facts to record say Wounded in action, but define its Sentence Template as {blank} so it contributes nothing to Narrative Reports. This allows Query searches for such facts without compromising readability of Narrative Reports.

Yes, it requires some double entry of the wounded details in the Military History fact Notes as well as in the Wounded fact, but it is all down to personal choice depending on your objectives.

[AdrianBruce]

Good point Mike - I keep forgetting that you can suppress the sentence for a fact, removing it from Narrative Reports.

[tatewise]

Having said that, if you use the Custom Fact Fields 'labelled meta-fields' concept, then Query searches on those labelled fields are just as effective as separate facts, providing there is a unique label for each item of interest.

[Wasabi]

You can create a general custom event via Tools > Fact Types > New.
It will have all the standard event fields of Date, Age, Place, Address, Cause, and Note, plus Media and Source Citations.

I'm not getting the Cause field when creating a new event. I would like to duplicate the fields that appear in the divorce and death facts, which include a cause. I'm trying to add an arrest event for a branch of miscreants in my tree, and a cause field is important.

What am I missing? I can only create events without a cause field, similar to the default birth or residence events.

[tatewise]

Yes, the Cause field only appears in the Facts tab for a few standard Facts such as Death and Divorce.

However, the Cause field is supported for all Facts via the All tab (as required by GEDCOM).
On the All tab, right-click the appropriate Fact and choose Add Cause, then enter the details in the box.

That Cause appears in Reports, the {cause} code works in Sentence Templates, and %...CAUS% Data Ref works for all Facts.

[Wasabi]

On the All tab, right-click the appropriate Fact and choose Add Cause, then enter the details in the box.

That's great! Thanks. Now that I know where it is, I was able to find it described in the help (under "Low-level Editing").