* Consistency of data

[peterjiminy]

I went to the site Geneanet (which I think is French in origin) and uploaded my gedcom from FH7. It reported over 50 inconsistencies of my data, such as a baptism earlier that a birth, a marriage after death. Does FH7 support any such checking, as I have not found it?

[BillH]

Native FH does not have that capability, but there is a plugin, Show Project Statistics, which will report on possible errors of that type.

Bill

[ColeValleyGirl]

FH checks for that sort of problem when you create a Fact, but not (as far as I know) when you import from another programme.

How did you create the Facts where problems are being reported?

From the Help File:

Normal Time Frame

Each fact is associated with an approximate time frame. This time frame is used for various purposes. First, it is used to check for possible errors when dates are entered. Suppose, for example, you added 'Conception' as a custom fact type and gave it the time frame "Pre-Birth". If you then entered a date of conception for a given person, which was after their recorded date of birth, you would be warned that the date looked inconsistent with the person's birth date.

Some of the checks that are done when dates are entered make use not only of the known time frames for the relevant facts, but also estimates of the maximum likely life span for people, and their likely age at childbirth etc. These estimates can be altered in the 'Estimates' tab of Preferences. For example, if a given fact has a time frame of 'post-marriage' (e.g. divorce), a warning will be given if you enter a divorce date for a person, that - taking their known date of birth into account - would mean that they would have to have got married at an age which is less than the estimated minimum age for marriage. For example, a warning would be given if the divorce date would mean that they got divorced aged 10, say. These warnings can be safely ignored if the dates, however unlikely they may appear, are in fact correct.

Time frames may also be used when Family Historian orders events and attributes - for example, in reports, or in the Facts tab of the Property Box. Where ordering can be determined by dates alone, these will always be given priority. But suppose there is no date, or none that determines the ordering? For example, a person's baptism, birth and death might all be recorded simply as 1910. Time frames will be used to ensure that the birth is listed first, followed by the baptism, and then death.

Finally, time frames are also used in the Facts tab of the Property Box, to determine whether or not age information should be calculated, if not provided. Age information is always calculated unless the Time Frame is Birth, Pre-Birth, Post-Death or none.

Normal Time frame for each FactType can have one of the following values:

Screenshot 2022-12-21 182607.jpg (17.78 KiB) Viewed 1162 times

[tatewise]

Native FH does not have that capability, but there is a plugin, Show Project Statistics, which will report on possible errors of that type.

Those kinds of inconsistency reported by the plugin are derived from the FH Fact Date Warnings.
The Tools > Preferences > General tab, Warn of possible errors on data entry enables that feature (see its Help).
The Query > Facts and Events > Fact Date Warnings will list all the warnings.

As Helen says, perhaps those inconsistencies were imported or the facts were entered in a much earlier FH version before the warnings were introduced. I don't believe they are governed by the Normal Time Frame of facts, but the 2nd paragraph from the Help is relevant.

[ColeValleyGirl]

If an import's involved, might it be that the standard facts (with Normal TimeFrames) have been overwritten by custom facts with the same name. but no TimeFrames?

[BillH]

I knew about the warnings at fact creation, but I thought John was talking about reports of errors on facts that already existed. That is why I mentioned the plugin. I forgot about that new query so that is a good reminder.

Bill

[tatewise]

If an import's involved, might it be that the standard facts (with Normal Time Frames) have been overwritten by custom facts with the same name, but no Time Frames?

That may be true, but if the facts have actual Dates, the Normal Time Frame has no effect on the order of facts.
In FH it is perfectly possible to have say a Baptism Event date before the Birth Event date and saved in that order in the GEDCOM file even if it contravenes the Normal Time Frame.

My interpretation is that Geneanet is complaining about the chronology of facts based on their Dates in the same way that FH produces Fact Date Warnings.

[AdrianBruce]

Bear in mind that the warnings are just that - warnings - and the relevant facts may describe "perfectly legitimate" circumstances. (Note my scare-quotes... )

From memory of my personal experience, the majority of my false positive warnings referred to the relative dating of events on a child's timeline and that of their step or adoptive-parent. It's perfectly possible that a step or adoptive-parent can be a lot younger than the corresponding biological parent - and since the logic doesn't check the "stepness" (or...) of the parent-child relationship, it could be that the step (or...) parent is closer in time to the child than would be expected for a biological parent.

While it might be possible to check the "stepness" (or...), logic has to stop somewhere and I'm unclear whether it's possible to produce a robust definition of this aspect anyway.

Another instance that I just reminded myself of, is the fact "Possessions", which is a "Life" event. However, I've used it to list something purchased by the deceased's estate after their death, so this brings up a warning for a "Life-Event" occurring after Death. Even I, who create new fact-types at the drop of a hat, didn't see why I should create a new fact-type just because of potential time-frame warnings.

So, the plug-in and query are excellent investigatory tools - but don't imagine that they are the full answer, particularly if you've ever been "creative".

[tatewise]

Yes, Adrian, but the OP identifies more fundamental warnings like "baptism earlier than a birth, a marriage after death" that can never be "perfectly legitimate".

[davidf]

If you have a date of 3 March for a baptism/marriage but a date of birth/death of Q1, does that throw these sorts of errors?

[Gowermick]

Although FH doesn’t check for inconsistent data once entered, a very good (free) product that does, and hasn’t been mentioned, is FTAnalyser. I now run this once every couple of months, and it does a very good job!

[tatewise]

If you have a date of 3 March for a baptism/marriage but a date of birth/death of Q1, does that throw these sorts of errors?

No, not in FH V7 assuming the 3 March baptism/marriage event is entered after the Q1 birth/death event.

If a baptism/marriage exists with a date between 1 Jan and 28 Feb and the Q1 birth/death event entered afterwards then FH complains that the Q1 Date range extends later/earlier than at least one "life" event.

[tatewise]

Although FH doesn’t check for inconsistent data once entered, a very good (free) product that does, and hasn’t been mentioned, is FTAnalyser. I now run this once every couple of months, and it does a very good job!

You can just as easily run the FH Query > Facts and Events > Fact Date Warnings but why do you need to check every couple of months if FH checks the data on entry? If it is because you are importing potentially inconsistent data, then run that Query or the Show Project Statistics plugin after each import.

[Mark1834]

I run FT Analyzer occasionally, and it is very good at identifying errors in fixed date events, such as accidentally entering 3 Apr 1871 for a UK census rather than 2 Apr. It's a quick and simply consistency check for those who don't use AS or DEAs. It's easy to use and highly configurable, so very much part of my essential toolbox.

[Gowermick]

Although FH doesn’t check for inconsistent data once entered, a very good (free) product that does, and hasn’t been mentioned, is FTAnalyser. I now run this once every couple of months, and it does a very good job!

You can just as easily run the FH Query > Facts and Events > Fact Date Warnings but why do you need to check every couple of months if FH checks the data on entry? If it is because you are importing potentially inconsistent data, then run that Query or the Show Project Statistics plugin after each import.

Mike, no I rarely do any importing of gedcom files, but like Mark says, it is too easy to make silly mistakes and FTAnaylser picks them up. Doesn’t harm to run it occasionally