* Multiple Facts/Events to the same thing

[Rancher]

I am a new FH7 user moving over from Family Tree Maker 2019.

Forgive me for this (probably) basic question, but how are users handling data entry from multiple sources referring to the same event, but with different (or only partial) data given? For example, I have an ancestor with at least 5 different birthdays, all derived from different sources, and not all sources give the place of birth.

In FTM2019, I have been entering each birth date as a separate fact, noting the source, and tagging the preferred one. This way, I know where the information came from, and also what it does not state as well (for example, a source only documents the birth place, but not the date). In many cases, there is no one single source that has all of the "right" answers, so I reconstruct a "preferred" event entry that combines all the information.

A good example is where, say, a USA census will state an individual's parents where born in Germany, but they are otherwise anonymous. I can use that to add to an unnamed parent and give a source. Later I might learn the father's name and year of birth, but not the mother's.

In FH7 I can of course enter all the birth events that I want for an individual, source them, &c., and mark one as "preferred," essentially as I have been doing in FTM2019. However, all of them—not just the one marked as "preferred"—are being outputted to reports; I'd rather have the report just ignore the non-preferred events.

Similarly, is it possible to have a reconstructed "preferred" event that (fictionally) combines all the details in various sources that went into it? I guess the easiest answer is to just add the sources, regardless if they have all the info or not, but somehow remembering that the event is, by itself, a reconstructed one.

Anyhow, any thoughts on this? I suppose everyone has a different approach, so I am not looking for a definitive answer, just some ideas as to "best practice."

[Gowermick]

If you take a birth fact as an example, you have date and place items associated with that fact.
Each source invariably confirms one or other or both (i.e. date and/or place) but note one cannot source one item without the other.

What I tend to do is use the date from my most accurate source (i.e. usually the earliest) and leave it at that, and use later ones merely as confirmation. If later sources are ‘wrong’, it will show up in the age field, where reported age will have an explanation mark against it.

Place of birth is similar, with it starting broad (i.e. usually Registration District), but narrows down as further facts emerge, but I find that christening ususally gives the most accurate place, which often includes an actual adress.

In summary, I fix date from earliest reference and don’t change it, but the place is narrowed down as research progresses, and I am satisfied it is as accurate as it can be.

Note: I treat 1939 register as a good source for day and month of birth, but if year differs from what I know, I don’t change it!

EDIT I forgot to mention I otoo nly have one Birth fact and one Death fact!

[jbtapscott]

Taking again, Birth as an example, I normally only have one Birth fact and will cite multiple Source records as required.

If the Birth "story" get too complex then I will add a Note to that Birth fact and explain what I have done / guessed and my reasoning, cross referring to those Source records as necessary - in need (because I publish my data on a website), I make use of the hide text markers ([[ and ]]) to stop any parts of that Note that I consider too contentious / questionable being published.

[AdrianBruce]

I have one birth fact only per individual - at least, I do 99.9% of the time - I think I have had at least one occasion where things were so "complex" I had multiple birth events.

The one birth fact has, of course, multiple citations against it and the important thing is to ensure that each of those citations has "text from source" set to the crucial text from the, err, source. If the "text from source" contains an explicit statement of the birth details, that might be enough. If the "text from source" only implies the birth details (e.g. an age on a known date), then the Note for that citation will contain the implied birth data from that single source - e.g. "text from source" reads "Aged 72 Years <at death>" and Note reads "Gives btw Nov 1933 and Nov 1934".

If I have to mix and match individual items, then the Note for the citation explains what's discarded or given preference and why - e.g. "Birthplace contradicted by all other censuses so discarded".

I will seldom record this sort of stuff in the Note for the Birth fact as in my head that Note is about the person's story, not about my attempts to work the story out. In a sense one's about them, the other's about me. However, where the multiple values are part of that person's story (e.g. they gave false names and ages "all" the time) then discussion can go into the Note about the Birth fact if thought useful / interesting.

[kfunk_ia]

I am a new FH7 user moving over from Family Tree Maker 2019.

In FH7 I can of course enter all the birth events that I want for an individual, source them, &c., and mark one as "preferred," essentially as I have been doing in FTM2019. However, all of them—not just the one marked as "preferred"—are being outputted to reports; I'd rather have the report just ignore the non-preferred events.

I am also new to FH and I am currently giving it a workout to see if it fits my needs. I don't have an answer for the other bits of your questions but what I have been doing when I have multiple facts, say birth, is marking the preferred on as Preferred and marking the others as Private. In the Report Options screen, under the Privacy tab, there is a 'Hide all private fact...' option. With this marked, all of the other birth facts do not show in my report. So far I have only worked with Descendants by generation reports, but it seems to do what I need it to and it allows me to keep all of the different facts and sources.

[tatewise]

Like the others, I usually have only one Birth (and one Death) event per person.

FYI:
If you give the non-preferred Birth events the Private Flag then those events can be excluded from most report types via the Report > Options > Privacy tab 'Hide all private facts ...' option.
In Diagrams, you can choose %INDI.BIRT[preferred]% to ensure the Preferred Birth is shown.
If there is no Birth with that flag then the first Birth even is used instead.

[ColeValleyGirl]

I usually have one birth (and death) per person as well. However, if the identification of the birth (or baptism) date (and/or the identification of the individual (with parents) has been particularly convoluted, I'll write an explanation at how I arrived at my preferred conclusion and attach it (as a PDF file) to the birth or baptism in question, so that others can see my reasoning. As a PDF it doesn't intrude unless somebody goes to the trouble of opening it.

[KFN]

I guess I’m an outlier as compared to the others in this thread.

As a researcher I enter all of the information I find about an event, so birth, death, burial could all have multiple entries during my research phase.

As I collect information, some sources will be considered primary, while others may be secondary or even tertiary. For me it kind of depends on the perceived accuracy of the source, i.e. a birth certificate is higher order than an interview.

Once the research phase is complete (or I’ve exhausted my standard sources) I move to the conclusion phase which turns most of the duplicate events that are from secondary (or less reliable) sources into notes and cautionary statements that I provide to clients or enter in my own genealogy.

HOWEVER, I am also aware and use as part of my conclusion that the GEDCOM standard allows multiple birth, death, burial events, it also notes that where conflicts exist the first event encountered is the primary one, or most likely event to be correct. This resolves for me any cases where two sources of the same quality/accuracy exist, but one could be more probable. I also enter a value for the quality of the source as part of the GEDCOM entry.

[tatewise]

Your last 'HOWEVER' section is a challenge to implement in FH.
You want the first Birth (Death, Burial) event encountered to be the primary one as suggested in the GEDCOM spec.
FH is strongly biased towards sorting facts into date order, so by default, the first Birth (Death, Burial) event will be the one with the earliest date, which may not be your preferred event.
If you disable the default sorting, then you must not only manually set Birth (Death, Burial) events in your preferred order, but must also manually sort all other facts into the desired order. Otherwise, Reports may not show facts in chronological order.

Having said that, it sounds like you are not so far removed from the majority, because eventually, you reduce most cases to a single Birth (Death, Burial) event after detailed analysis.

[LornaCraig]

I'd rather have the report just ignore the non-preferred events.

As kfunk_ia and tatewise have both said, the non-preferred facts can be suppressed in reports by setting the Private flag on them and hiding all private facts in reports. That is the easiest way to do it.

However I notice that in the FH help files it says "You can optionally choose to display default or preferred facts in reports or queries. To learn how to reference default or preferred facts in reports and queries, see Understanding Data References - an advanced topic." The section on Data References explains how to reference preferred facts, but not how to reference them in a report, which is supposed to be possible. The editable list of event/attributes to be included in a report doesn't appear to allow the addition of the [preferred] index. What am I missing?

[tatewise]

Lorna, I don't think you are missing anything. I looked for a similar capability but could not find any way to use Fact Flags in Reports except for the Privacy tab Private Flag option.

Maybe that needs to be raised with CP?

[LornaCraig]

OK thanks, I'll ask CP to explain that paragraph in the Help file!

[Rancher]

My thanks to everyone for their thoughts on this.

I admit that I am recalcitrant to have "one fact only." This will almost never document accurately every source as most sources will have problems of some sort. I don't like, for example, citing a source for a birth event when only the date, but not the place, is given (and vice versa); it gives a wrong impression of what the source is actually stating, even if one adds a transcription in the note field. Similarly, while I might personally have a good idea when a birth actually took place, despite a number of birth years given in source records, to definitively state one is correct is an interpretation/judgement; this of course needs to be made clear to the reader.

As an academic who works with historical sources (outside of genealogy!), I am very careful of not wanting to give a false impression of what a particular source does or does not state, hence my probably too-conservative view.

However, I will play around with the private tag for hiding "non-preferred" facts. Perhaps that will work.

Thank you all!

[tatewise]

It sounds like you may have conflicting strategies at work.
You are keen to have multiple events with distinct Source Citations for different components such as Date, Place, Address, Age, Cause, etc.
If you don't include all those multiple events in a Report, then many of those Source Citations will not be included, and that would give a false impression to the reader.
So if you only include the preferred event in the Report, that must have all the Source Citations from all the other events in order to give the complete picture to the reader.
The alternative is to include all the multiple events and their associated Source Citations, perhaps with some indication of the preferred event.

[Jane]

Another option if you are talking about narrative reports might be to use the {blank} option in the sentence for the fact to suppress them.

[Rancher]

It sounds like you may have conflicting strategies at work.

Of course, but that is an issue that genealogical software has generally. It both records data in the database, but also presents that data in polished reports where a conclusion has been reached.

I guess in the end, I will continuing collecting the data, documenting it as best I can, and when I decide to present it to others, exclude or hide what I need to when I generate a report. In FTM2019 I can just have a report use the "preferred" Fact (where other issues can be noted if necessary) and others Facts to the same item are ignored. It does not seem I can do this in FH7 automatically, but can use the various work-arounds kindly suggested here.

Thank you everyone!

[KFN]

Rancher’s example outline the clear difference between conclusion based and evidence based genealogy.

First, Evidence Based will add their sources and data as soon as they become available. This approach will lead to multiple and duplicate data points for individuals even for data points which are considered single-occurrence-events. A specific conclusion is not the necessary outcome of this process.

While, Conclusion Based will collect data points and at some point they will make a conclusion on the sum of that data and enter their conclusion into their database, thus only having one entry for the event.

A hybrid of this is stating, You can not conclude that someone was born on a date and place without evidence stating the two attributes together, therefore evidence based genealogy kicks in, and would keep the two bits of information separate as multiple events, each with their source. Whereas, if one source indicates all data points, you could concede a conclusion statement and only cite the one source. THE HICCUP HERE is that if you have multiple conflicting data points and no clear winner, how can you conclude? What happens if new information comes along and you have already concluded by elimination of all “lesser” sources?

[ColeValleyGirl]

Rancher’s example outline the clear difference between conclusion based and evidence based genealogy.

First, Evidence Based will add their sources and data as soon as they become available. This approach will lead to multiple and duplicate data points for individuals even for data points which are considered single-occurrence-events. A specific conclusion is not the necessary outcome of this process.

While, Conclusion Based will collect data points and at some point they will make a conclusion on the sum of that data and enter their conclusion into their database, thus only having one entry for the event.

A hybrid of this is stating, You can not conclude that someone was born on a date and place without evidence stating the two attributes together, therefore evidence based genealogy kicks in, and would keep the two bits of information separate as multiple events, each with their source. Whereas, if one source indicates all data points, you could concede a conclusion statement and only cite the one source. THE HICCUP HERE is that if you have multiple conflicting data points and no clear winner, how can you conclude? What happens if new information comes along and you have already concluded by elimination of all “lesser” sources?

I understand the distinction you're drawing, but would say you can do Evidence-Based genealogy without creating multiple facts. If it isn't possible to conclude a date or place for e.g. a birth, I will create a Birth event with no date (or perhaps a before date or estimated date) and/or no place/address, citing all the sources (however conflicting) that contain information about the individual's birth. The multiple data points are the sources, not multiple birth facts. And I never discard any of the source citations, even if I've reached a conclusion, because somebody else could still reach a different conclusion from the same evidence; or a new piece of evidence would come along that threw my conclusion into doubt.

[LornaCraig]

If it isn't possible to conclude a date or place for e.g. a birth, I will create a Birth event 'o date (or perhaps a before date or estimated date) and/or no place/address, citing all the sources (however conflicting) that contain information about the individual's birth. The multiple data points are the sources, not multiple birth facts....

Like Helen I only ever have one birth fact, for the simple reason that a person can only be born once! (Similarly for death.) And I'd like to emphasise Helen's point that the birth fact, as recorded in FH, does not have to contain a precise date and place. If I have a variery of sources which collectively suggest a birth date in a certain period I use a 'between' date, e.g. 'between 1 January 1840 and 12 July 1843'. And if the exact town/village of birth is uncertain but all sources indicate the same county I record the place as the county, e.g. ' ,Hampshire, England'. An explanatory note outlines the collective evidence and all sources are kept. If further conflicting evidence is found the birth date period or place can be 'tweaked' without creating a whole new fact.

[Mark1834]

FWIW, I’ve never been comfortable with the term “Fact”. Fact is defined as “something known or proven to be true”. We are not recording facts. We are recording events. These events have a variable degree of confidence, from “beyond reasonable doubt” to “highly speculative”. How high the bar has to be to include the event in our trees is a personal choice.

A person can be born just once. Therefore, in this analysis they have one birth event, supported by an overall assessment of the various sources cited. As the evidence changes, I modify the event record accordingly.

[KFN]

I understand the distinction you're drawing, but would say you can do Evidence-Based genealogy without creating multiple facts.

No. A pure evidence based researcher, collects sources and the distinct data points associated with each source as they relate to an individual. You can not mix data points from different sources into the same entry because the data recorded can not be associated with a specific source, (i.e. date with one source, place with another, family associations with a third, notes or causes with a fourth, etc).

A genealogist using GEDCOM does not record “facts”, they record “events” and “attributes” and their associated sources as they pertain to a person. “Facts” are a conclusion based activity that may or may not be part of a genealogical report or for that matter a scientific paper. I have many family association in the 1700’s that are not 100% facts, they look good based on a small amount evidence, but as a scientist I would not conclude they are facts! Science is not exacting, it can change as more evidence is uncovered, so we could say their no true facts!

Many people (probably all to some degree) want everything neat and tidy as truisms, but it is not that simple. You have a father and mother until you learn that you are adopted! You have a birth date or place until you learn that you were born in a country that does not exist today, or a place that physically moved, or a burial cemetery that has been moved! What are the true facts and what the events or attributes that occurred?

[KFN]

When a scientist (or researcher) writes a paper they present a conclusion based on their research (evidence). It is a summary of their work, but other scientists want to see their work to verify their findings, this requires all data and the evident for that data. The data to evidence association can not be broken!

[tatewise]

FYI: The terms Event, Attribute & Fact have a meaning in GEDCOM terms (and in FH) that may not agree with the dictionary or popular understanding of the same terms. (The same goes for other GEDCOM & FH terms such as Citation and Source.)

GEDCOM says:

The individual record is a compilation of facts, known or discovered, about an individual. Sometimes these facts are from different sources. This form allows documentation of the source where each of the facts were discovered.

FH says:

In Family Historian the word 'fact' is used as shorthand for 'event or attribute'.

[KFN]

Tatewise,

Based on my past association with the development of GEDCOM I can assure you that the team wrestled with the understanding of evidence and conclusion within their goal. For the purposes of LSD “the conclusion” was the ultimate goal, but evidence based genealogists and scientists needed to show and maintain their work product, but had to keep it within the overall goal of LDS.

If you study the evolution of GEDCOM, and some of the papers written on the early list-serv (now deleted) they only envisioned one individual name and many more event/attribute types and only one inline source for their conclusion. The GEDCOM file was meant as an upload of conclusions to the master database at LDS. It evolved over time and some of the documentation was either not update to explain the logic and use case behind the changes or not fully fleshed out because of mixed values from the designers.

So even though I am an advocate of strict GEDCOM for the purposes of transportation of data between software companies thus preventing lock-in, I also understand that GEDCOM v5.5.1 and the new v7.0.4 do not match my goals and requirements as a genealogist, database designer, data manager, librarian and knowledge manager. I’ve been in the field of data management since the late 70s, became a librarian and knowledge manager in the late 90s, but learned about genealogy from my great uncle in the early 70’s, he start his family tree in 1920s.

Some definitions don’t really change, people sometime just make them match what think they should be rather than what they really are!

[Mark1834]

Indeed - the FHUG is well populated with both practicing and retired scientists, engineers, librarians, researchers, managers, designers, etc, etc, (are there any full-time practicing professional genealogists?) but for most of us, we don't get too hung up on the details. It's a hobby, and we adapt what we have to what is appropriate to what we want to achieve... .