Family Historian User Group

So coming from FTM looking at FH and have looked through the forum not really seeing this discussed. When I have multiple dates for an event, such as a birth, I want to record what I believe to be the correct one, but also the conflicting dates. How can I do this and yet indicate which one of the facts is the assumed 'correct' one, and have that fact date appear in the system as the date to use? Also, in some areas is there a filter to use so I can filter out the conflicting dates so they don't show, such as on timelines and reports?

Welcome to the FHUG.

Preferred Facts is an FTM feature that does not exist in FH.

See Multiple Events and/or Assertions (11274) for a full discussion.

Also see Wish List Ref 11 Mark preferred Occupation/Event etc that you can vote for.

If any of the above is not clear then please ask again.

Welcome to FHUG.
There was a similar question asked here: Set primary facts in Property Box (12662)

FH does not have a standard way of designating "preferred" facts but in the case of birth the usual recommendation is to have only one birth event (as nobody can be born more than once) and cite all the evidence against that fact, using the note field to record your reasons for choosing one date or range as the most probable.

I'd create the birth event with the preferred date but put a note in the local note mentioning the conflicting dates and I'd link the birth event to the multiple source records via citations. (Edit: And I see Lorna posted the same solution a couple of mins before me! )

I'm another FTM refugee and I'm not surprised to see a couple of posts on this topic. It seems odd that a genealogy program wouldn't make it easy to promote an alternate fact, such as an alternate birth date, to primary or preferred. It's not unusual to find enough evidence supporting an alternate date to justify considering it to be the correct one. It ought to be easy to switch dates in a way that maintains the source citations for each. FTM made this very easy, and the other two programs I've been trying out (Legacy and Roots Magic) have reasonably easy ways to make the switch. I wish FH did too, as it's so far the only problem I've found with it. Otherwise, I've found it to be the best alternative I've tried.

This is one area where the GEDCOM spec'n is a bit inadequate. It seems pretty clear that if multiple birth events are present, then the spec'n intends the preferred value to be the first one.

There is no other means of designating preference - relying on physical order is generally felt to be bad design, by the way.

The GEDCOM spec'n is not clear why the software should identify a preferred value in the case of a birth but not in the case of a residence or occupation. Other than that one is presumably supposed to say, "It's obvious innit?"

The issue with using physical ordering in GEDCOM is that people like me rather like to see our events in date order - and if we re-order the events in date order, then our preferred birth will be the first one. Which is probably not the case....

So I guess there ought to be an ability to have an explicit "preferred" marker in the GEDCOM file.

Sorry, but I go back to the argument that someone can only be born once and can only die once so, although GEDCOM will allow multiple Birth dates, researchers shouldn't, as it makes no sense in the real world.

- If you have documentary evidence which suggests differing dates and you can't determine which date is correct the the logical and sensible thing to do is to use a date span of between 'X' and 'Y'.

- If you have documentary evidence which suggests differing dates and you can determine which date is correct then the logical and sensible thing to do is to only use that date as a fact and to provide details of why other date(s) have not been accepted.

e.g.

1. As far as I'm concerned I have sufficient evidence that one of my Gt-Grandparents was born on a date not recorded in any official records (a different date appears on her Birth Certificate). The family recorded all important dates/events in the Family Bible (and her gravestone) both clearly show a different date and the date on which her Birthday was always celebrated. Why, because it was more than 6 weeks before her Birth was officially registered so they made up a date to avoid the possibility of being fined for late registration. I record the true event and date, link the alternative evidence and explain the reason for the discrepancy.

2. Another of my Gt-Grandparents recorded all of his children as if they were at 'home' on the night of the 1911 Census, but 5 of them completed their own Census Forms showing them at their own homes, with their own families. Am I going to give them two 1911 Census entries showing them in both places? No way, as that would be an impossibility.

Incidentally, GEDCOM will allow you to record all facts in whatever sequence you want and will make no judgements of that order as it's only a text file. It's the software application which reads and writes that text file which controls everything else. And the majority of software, in general, is coded to present things in logical date order by default.

If there is any deficiency then, in my opinion, it is not in the GEDCOM 'standard' which was never intended to define the structure of an electronic database anyway, but only to provide a method of transferring data between compliant database applications that fully subscribe to the standard. Of course, most people forget that it is not in the best commercial interests of software companies to make it easy for their users to migrate their data to competitor's products.

Mervyn

Arguments about the GEDCOM 5.5 Specification in this context are a bit weak.

If Calico Pie chose to add say a Preferred Flag to Facts in FH (e.g. INDI.BIRT._PREF) then they could do so without infringing GEDCOM 5.5.

They have in other places such as Individual Flags (_FLGS), Source Type (_TYPE), Media File (_FILE), etc, as documented in glossary:gedcom_extension_list|> GEDCOM Extension List.

It occurs to me that Wish-list item 11 is not really what is wanted here. There are two distinct uses of "preferred" items in my view.

Firstly, in a case where an individual has several Occupations through their life, the desire might be to mark the most important one as the one to be displayed in certain places - e.g. on the Main tab, or in a diagram text scheme or a (non-narrative) report of some sort. Wish-list item 11 seems to match this case.

It is clear that multiple Occupation values should be permitted both in FH and in the real world.

Secondly (and more controversially), in a case where an individual has several Birth Events - the meaning of this is that there are alternate values for Birth, which the researcher wishes to record, each with their own citations, etc. The desire is to mark one of these as "most probable" or "working assumption". The marked birth event should certainly be the one to be displayed in certain places - e.g. on the Main tab, or in a diagram text scheme or a (non-narrative) report of some sort (i.e. it is the "most important"). But it is also the single birth event that is to be used to calculate ages, life-dates, etc., etc.

It is clear that that multiple Birth events are a nonsense in the real world. The controversy is whether multiple Birth events should be allowed in FH. It is clear that they are allowed in FTM and in the GEDCOM spec'n. Personally, I would not use multiple birth events as, to me, FH events are my conclusions and someone can only be born once. All records contribute to the final conclusion, even the contradictory ones, so I'd cite the contradictory sources against the single birth event, using the "text from source" and / or event notes and / or citation level notes to highlight where the contradictions come in.

I believe that this topic is, at least as far as the examples go, asking for the second type of preferred event, i.e. "most probable" or "working assumption", so isn't really appropriate for Wish-List item 11 - unless that item is updated.

I think there are still issues that need to be resolved. For instance:

• What exactly is the effect of marking a Birth as "most probable" or "working assumption"? Exactly what changes? Calculated ages? Estimated ages? Life Dates? Focus Window? Diagrams? Reports?
• What else needs "most probable" or "working assumption"? I suggest Death. What else can be marked as Preferred in FTM?
• I would suggest that no other events should be allowed to have "most probable" or "working assumption" coded against them. That way we resolve the ambiguity of - is it an alternative or a multiple value? Marriage and Baptism should not be allowed as it is perfectly possible to have multiple baptisms and also multiple marriages between the same couple - and I don't mean Richard Burton / Elizabeth Taylor style with intervening divorces, but two consecutive ceremonies. in other words, multiple marriage events (or baptisms) should always mean multiple, never alternate. This may be a touch restrictive but is, I believe, important to resolve ambiguity.

Would this help FTM users? Does the FTM GEDCOM mark up preferred Births, etc.?

Adrian, I am not sure I agree with your arguments.
I would say Preferred is allowed to apply to any type of Fact.

Its consequences do vary depending on the type of Fact, but the general rule is to treat the Preferred Fact as if it were the 1st or only instance of that Fact.
i.e.

• Display it on the Main tab (perhaps only where no [instance] is defined in the Data Ref). This DOES apply to all Facts because the Main tab can be customised by the user to show any Fact.
• Similar arguments apply to Diagrams, except where looping index [1+] is used to show all instances.
• Reports usually show all instances of Facts, but perhaps any Preferred Fact should be indicated somehow.
• Estimated Birth/Death involves a whole raft of Events: Birth, Baptism, Christening, Death, Burial, Cremation, to name a few. So the Preferred Event should be the one used in the estimation instead of the 1st or only Event.
• Date Validation involves a whole raft of Events as above, and the same analysis applies.

Hmm. I just tried an experiment.

I created an entry for someone born in 1590 and in 1600 and baptised in 1601. When the All-tab shows the 1590 birth first, then they are aged 11 at baptism.

When the All-tab shows the 1600 birth first, then they are aged 1 at baptism. And the Main tab of the property box shows 1600 (i.e. the first one on the file). As does the Focus Window. And the Life-Dates on the Descendant Outline Report shows (1600-).

And the same applies to multiple values of Death - I think.

In other words, I'm beginning to get the idea that Calico Pie programmed all this in from ages ago, to match the GEDCOM Spec'n. But, and it's a big but, I have "Enable Automatic Ordering of Events/ Attributes by Date" set. As soon as I entered any other event for this experimental chap, then the 1590 birth reverts to its chronological place and takes precedence as the preferred item.

So to set an alternate Birth as the preferred one, then (a) ensure Tools / Preferences / General / "Enable Automatic Ordering of Events/ Attributes by Date" is not set and (b) use the All-tab to shunt the preferred item to the top.

Issue 1 - that will only last until a re-ordering by date is forced on the file by request. But you do need to request that yourself.

Issue 2 - setting "Enable Automatic Ordering of Events/ Attributes by Date" off does not seem to affect the display of facts - they are displayed in chronological order regardless of the physical. (I never knew this because I always save the stuff in chronological order!) But the All-tab looks a mess because the facts are in order of entry not chronological order.

Note when setting "Enable Automatic Ordering of Events/ Attributes by Date" off, you may need to set it off, save and close the program down before re-opening to start shunting your preferred items to the top.

So - for those from FTM who want to set certain births, etc. as preferred - does this work for you? Bear in mind that I've not tried all the options. And may have missed something.

tatewise wrote:... Its consequences do vary depending on the type of Fact, but the general rule is to treat the Preferred Fact as if it were the 1st or only instance of that Fact ....

Possibly - it's just that to me, non-Preferred Occupations are a different kettle of fish from non-Preferred Births. Hence my instinct to split them off. If, at the end of the proverbial day, there is no need to differentiate, then fine, I accept your view. But I'd not got there yet. (And I have no real understanding of what the types of fact might be - hence I might be a bit dogmatic above in order to resolve ambiguities).

The ordering of Facts manually via the All tab has been discussed before in this context in Set primary facts in Property Box (12662) and Incorrect lifespan dates in Focus window (12402) and others. But the user must take care to never auto-order-by-date, and must perform manual date ordering, and that is tedious. Yes, the Facts tab can list in Date order without affecting record order, but the same cannot be said for Diagrams and Reports, that I think always list in record order.

I think your distinction between non-preferred Birth/Death and non-preferred Occupation/Residence/Census, etc, is a human perception bias, but the FH software implementation is, as I said, and your experiments confirm, just a matter of treating the Preferred Fact as if it is the 1st Fact. How you choose to interpret the meaning of Preferred is up to you.

By types of fact I simply mean each fact defined by the Fact Sets in the Tools > Fact Types dialogue.

Thanks Mike. Good job you remember these previous threads exist (and I'd actually contributed to the 2nd one you mention).

Diagrams and Reports seem to be slightly inconsistent - my text scheme for the diagram shows both births, and in physical order (i.e. the one I set as preferred comes first). The Individual Summary Report shows the Individual Events in chronological order but the birth in the life dates, and the age at baptism, are driven by the physical order and show the preferred one first.

The Narrative Report is in chronological order but the birth in the life dates is again the physical order so shows the preferred one.

It's highly debatable what the correct order of the Individual events on the IS Report should be. If you actually write "Preferred Value because..." in the Note to the event, then showing the events in chronological order, rather than physical / preferred order isn't bad, because it prints the Note (or it does on my settings). And frankly, if you don't write "Preferred Value because..." in the Note to the event, then, I'm sorry but you get everything you deserve if there is confusion. No, a simple marker isn't good enough, you need to explain things. OK - I apologise for coming off the fence there...

My experiments with highly juggled Facts give different results.

Only Narrative Reports list Facts in chronological order (like the Facts tab).

All others list Facts in record order (Individual Summary, Family Group Sheet, Record Detail).

May be you had not juggled your Facts, so they were mostly chronological in the record?

Use the FH Sample Project and really mess them up, and you'll see what I mean.

The order in Diagrams is entirely dictated by the Text Scheme and is neither chronological nor record order.
There have been debates about putting Census Events before or after Marriage Events because chronological/record order does not apply.
In most cases only the 1st instance is included, unless [1+] looping index is used, or an explicit [3] index used.

Thanks Mike. I thought I had two births out of order for the Individual Summary Report - though that was the only issue on this guy. I can't be certain now, especially as I took care to revert the Enable Automatic Ordering option.

Thank you Adrian and Mike for the tip. Disabling the Automatic Ordering feature does do what I was wanting, in that my currently "preferred" dates are shown in places like the Main tab and the Focus Window. I'm still undecided as to whether I should go that route or break down and consolidate on single facts for birth and death, using a more detailed system of notes to keep track of contradictory evidence. I understand that much of what I do and how I do it has been shaped by how FTM works and this is a chance for me to rethink my methods.

That being said, my Googling the past couple of days has turned up some interesting discussions on the topic of conclusion-based versus evidence-based genealogy, where the former would support the entry of a single birth date after weighing the evidence and drawing a defensible conclusion, and the latter would allow for entry of multiple competing versions of the truth as they are discovered and using source citations and notes to show the relative strength of each. It seems professional genealogist would fall into the conclusion-based category, as they eventually need to wrap up their research and draw a conclusion on things like birth date. But as an amateur, I may never completely wrap it up and want to use my genealogy software as a way to easily see all potential facts along with sources and notes supporting each. That drives future research that, hopefully, strengthens one or another "fact" and points me to the most likely version of the truth. With that in mind, years of using FTM trained me on a certain way of visualizing all of this. Change is hard, but not necessarily a bad thing.

One last thought, the vast majority of individuals in my tree have only a single birth/death date. Either I have only one source, or multiple sources more or less converge around a single assertion. So I want to be careful not to make a bigger deal about this issue than it deserves. But where it is an issue, the flexibility that FTM and others provide is nice.

I ...want to use my genealogy software as a way to easily see all potential facts along with sources and notes supporting each.

This goal can still be achieved with only a single birth or death event. The event does not have to have a precise date or even a precise year. Simply use a date range for the event, for example 'btw 1880 and 1883'. Then link multiple sources to the single event and summarise the conflicting evidence, and any tentative conclusions, in the Note for the event. When you generate a report you will then see a single birth event with associated note. This looks much more sensible to the reader than a list of multiple birth events or, in the case of a narrative report, a string of sentences saying 'He was born on XXXX. He was born on YYYY. He was born on ZZZZ'. If you gather more evidence which suggests that one particular date is the most likely, you can replace the date range with the exact date but still keep a record of any conflicting evidence in the Fact Note. The conflicting evidence will then still be visible.

Thanks Lorna. I've considered shifting more toward date ranges for those situations, as was suggested earlier in this thread and elsewhere. In many cases that is a good compromise. In others, maybe not so much. For example, there is a discrepancy of 9 years for the birth date of one of my ancestors, where I prefer the later date found on the grave stone and in biographies until someone can convince me otherwise, whereas other researchers gravitate to the earlier date based on weak evidence, in my opinion. So I'd really rather stick with the later date for him until I'm swayed toward the earlier one, rather than showing a crazy wide date range. But that's one very odd example. I would need to consider each individual on a case by case basis.

That's an example of a case where you could record a single date (the one you think more likely) but still keep a note of the conflicting evidence in the event note, explaining your reasons for the conclusion you have reached. You can also still link any conflicting Sources to the same event. All the information will be recorded but without the need for a second birth event which makes it look as if he was born twice.

In my tree I have an ancestor who has 2 separate dates of birth recorded in different sources (just a different day of the month - 24th and 25th).

I simply created a custom event called 'Alternate Birth' to record the second date and put my preferred date as the birth event date. Doing it this way lets me attach sources for the individual dates as well as different notes if needs be.

Still ploughing through an import from RootsMagic (not full-time - other things intervened!), I've come up against this old question of multiple Birth events and conflicting evidence etc.

My imported data contains a number of individuals with alternative birth data. I'm not sure whether it's native RM behaviour, or something that it allowed me to import from my previous program, Legacy, but these people have one main Birth event (which happens to be marked with the UDF tag _PRIM) and one or more Alt Birth events containing the alternative information. (Incidentally, unlike multiple Birth events, Alt Birth events avoid possible issues with inaccurate age calculations.)

In the light of suggestions in this topic and others, I was about to start moving the information in these Alt Birth events into the Notes of a single Birth event, when two things occurred to me which don't seem to have been addressed here.

First, all that I've read has been about conflicting dates, but many of my discrepancies relate to places, eg because of census returns giving different birthplaces. However, if the conflicting place information is only in the Birth notes, the place concerned is not going to appear in the Places list.

Second, an Alt Birth event stands out more clearly than something in the Birth notes as a marker for conflicting evidence, research still to be done, or a decision to be reached about the discrepancies. If it wasn't there, I might want to replace it with a To Do item or similar, which until now I haven't used much.

So, rather than getting rid of my Alt Birth events, I'm now wondering whether it's better to keep them, at least as an interim measure. Until I'm sure that an event did not happen in a particular place, I feel it's better for the place to appear in the Places list. And until I've fully resolved any discrepancies, I feel it's helpful to have some kind of fact which is easily spotted in a person's record, and easily found with a query, to alert me to what's still to be done.

Maybe in time the conflicting evidence will be dealt with and I'll be able to reduce these to a single Birth event, but I suspect there will always be a few that remain uncertain. I know ultimately it's up to me, and FH will allow me to use Alt Birth events if I wish, but I'd be interested in any comments on this, particularly from anyone who believes strongly in single Birth events.

Arthur

Arthur

As you will see in my previous post I also prefer the Alt Birth method - it certainly makes things a lot clearer to me in reports, etc.

As has been said previously, a person can only be born once, which is why I prefer to have just one Birth event and an Alt Birth event for alternative possible births.

Also, this gets around the subsequent "Age at ..." events problem in having to put events in their correct order. As you may have guessed I'm a big fan of sorting events in chronological order!

Steve

Arthur wrote:

if the conflicting place information is only in the Birth notes, the place concerned is not going to appear in the Places list.

If the place is already in your Places list (i.e. there is a Place Record with that place name) it will still remain there even if you delete all instances of its use. You can delete the Place Record manually, but if you think you might want to refer to it again it does no harm to leave it there.

There are clearly some benefits in using the Alt Birth approach.
Just beware of putting too much credence in Census data, some of which is notoriously unreliable.
It all hinges on contemporary 1st hand data, versus secondary information.
e.g.
The Place and Date on a Birth Certificate is contemporary 1st hand data because it was recorded at the time of the event.
Whereas, those details on a Census Return (or a Death Certificate) are NOT contemporary and thus less reliable.
Conversely, the contemporary details of Place of Residence, and Occupation are reliable, as is Date of Death.
Somewhat confusingly, Names recorded on Census Returns are unreliable with regard to the formal Birth Name, because people change their name and adopt nicknames that they record on Census Returns.

Regarding alternative Place names, they can be recorded in the Notes of the main Place record.