Page 2 of 2

Re: Multiple Facts/Events to the same thing

Posted: 19 Aug 2021 15:17
by KFN
Mark1834,
… 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... :)
Yes, I agree. This is why I’m not a pure evidence based genealogist, even though I was trained to be one. I like conclusions too! An end to my research. A product the gives closure to myself, but more importantly to my family (and those that occasionally pay me to help them) who only care about the history in a passing way. This is all good and not an indictment on their or my need for a conclusion. But some times at my wife’s family reunion I laugh to myself when they make statements I know are not historically correct, but family lore says otherwise.

Re: Multiple Facts/Events to the same thing

Posted: 19 Aug 2021 17:27
by ColeValleyGirl
I am not fond of the term 'fact' when we are most often not recording unchallengeable facts (aka conclusions) but assertions (statements of our current beliefs about something that happened in the past.) Those assertions are based on the information available to us in a number of sources, and our interpretation of that information as evidence. They're often also based on the lack of a certain piece of information that we would expect to find under the apparent circumstances -- e.g. great-grandfather John Johnson was baptised at the age of one week in Wolverhampton, but there's no record of his birth being registered there (even though the birth registration requirement was well adhered to by 1900), which suggests that he may have been born elsewhere. (Our tools for recording negative evidence in FH aren't great, although there's a wish list item to add Negative Evidence to the Citation Assessment possibilities.)

I'm meticulous about recording all the sources I find that may be relevant to e.g. the birth of 'person of interest' as separate source records, and citing them all for a single birth assertion that's as detailed or as sketchy as the evidence allows (in my judgement), with a detailed overarching note how about the sources do or do not support my assertion, and how I've resolved any conflicts (or not done so it I haven't been able to resolve them). If new sources come along that change what I believe, then I change my documented assertion. It's very rare that I reach a final conclusion -- they're all temporary pending future new evidence.

Even if a source is a birth certificate that provides all the information about a birth 'on a plate' there's still a need in some cases to explain why I believe that birth certificate belongs to the 'person of interest' -- e.g. why, out of the 365 Mary Ann Harpers whose births were registered in England between 1860 and 1870, I believe that this one is my great-grandmother when the birth location doesn't match the place of birth given in subsequent censuses, the ages don't tie up, and the father's name isn't James. (In reality, I haven't got any confidence yet about which birth certificate might be hers -- or if indeed her birth was registered, so her birth 'assertion' is very sketchy.)

Of course when I publish the current state of my research, it looks like 'facts' rather than 'my current state of beliefs', because that's how GEDCOM was designed. On my copious to-do list is experimenting with the new Lua reporting facilities to see if I can create a report that makes things look less cut-and-dried. In the meantime, some genealogists will look at my published material and review the sources and reasoning, and make up their own minds about what they believe/what they're unsure of; others will take things at face value and blindly replicate my assertions as their facts. I can't do anything to discourage the latter approach other than modifying the output presentation...

Going off at a tangent, I want to some point to experiment with creating multiple 'personas' which may or may not be a particular person of interest, complete with source citations, and linking them as associated persons to the person of interest. I think that might be a better approach than creating multiple e.g. birth 'facts' for a single individuals... Again, reporting would need to be well thought through.

Re: Multiple Facts/Events to the same thing

Posted: 19 Aug 2021 17:44
by KFN
ColeValleyGirl,

You make some very valuable comments, re,
1) Personas, I’ve thought about using this to explain sex changes, two Individual with the same basic attributes.
2) Birth Certificates in modern times some people are actively changing these to update sex at birth, fathers name, and maybe other stuff. Future historian may find different data than we do today.
3) The use of assertion rather than fact. Changing an assertion in your summary is allowed based on new or reread/retranslated sources.

I’m not sure GEDCOM was designed only to present conclusions due to its allowance of multiple birth records and stating that the first one is to be “preferred” over others, but I thing most software pushes the envelope more to only conclusions.

Re: Multiple Facts/Events to the same thing

Posted: 19 Aug 2021 17:56
by KFN
By the way GEDCOM does allow for a persona to be added using the INDI.ALIA tag:

1 ALIA @<XREF:INDI>@

Re: Multiple Facts/Events to the same thing

Posted: 19 Aug 2021 20:05
by AdrianBruce
OK - philosopy time then....

1) I'm not mad keen on calling these concepts "conclusion based genealogy" and "evidence based genealogy". I suggest that 99.9% of the people in this User Group do evidence based genealogy, in that our conclusions are based on evidence. And I'm also pretty certain that most people who describe themselves as "evidence based genealogists" do actually aim to reach conclusions.

2) Facts - given that the only facts which are absolutely true are in maths, why on earth does anyone sweat over how permanent a "fact" is in genealogy? As they say in physics, each theory is just one experimental result away from being proved wrong. All the time. Given that we need to "prove" (another bete noire of a word to some, I think!) events, attributes, names, relationships, etc, I think one overall name is necessary. Call it fact, why not? But just remember that it's always one document away from being shown to be wrong - sort of.

3) I would contend that I could do "evidence based genealogy" in the sense that KFN defines it, in FH, if I could instill in myself the right discipline to include all the relevant data in the text-from-source and notes in the citation to a fact, while allowing the fact to be a single conclusion. That's just moving the home of the evidence data from the fact tab to the citation data. The problem there is that the moved information is that bit more difficult to see and to compile all the evidence from different sources into a single, mental conclusion. So no, FH is not particularly good at "evidence based genealogy" in the KFN sense.

4) If one really wanted software that handles "evidence based genealogy" in the above sense, I think that there are a number of other aspects that need to be considered. Helen referred to assertions and there have certainly been attempts at assertion-based genealogy software (probably a better term than "evidence based genealogy"). They have, so far as I know, never come to much. It may be of interest to know that the FamilySearch tree before the current one was indeed persona based in that one baptism (say) created three (say) personas for child, mother, father respectively. Those were never touched but over-arching persons (or maybe personas again?) combined a life story from the personas for the presumed baptism of someone, their presumed marriage, their presumed children's baptisms, etc, etc. Quite how high the stuff was stacked, personas having personas, having personas, etc., I've no idea. Reader, they gave up on it.

5) And perhaps an important part about assertion based genealogy was touched on by Helen. It's not just about asserting someone's date of birth is X from this source and place of birth is Y from that source. It's also about how the #### do we know that those two sources even refer to the same human being? (cf all those garbage individuals in FamilySearch FamilyTree where the mother is aged 103 when she has her first child - "But it's got a source to it! Why isn't that enough?")

When I started to try to think about assertion based genealogy I lost enthusiasm for it as I considered all the background assertions that I'd need - the dates of the censuses, the dates of civil registration, Hardwicke's Marriage Act, etc, etc....

Well, philosopy that was... Complete not necessarily.

Re: Multiple Facts/Events to the same thing

Posted: 19 Aug 2021 20:09
by AdrianBruce
KFN wrote:
19 Aug 2021 17:44
... I’m not sure GEDCOM was designed only to present conclusions due to its allowance of multiple birth records and stating that the first one is to be “preferred” over others ...
I may be being cynical but I wonder if that was actually a retrofitted justification when they found out that loads of software didn't validate for only one birth event. After all, there's no similar comments for multiple baptisms offering alternatives - rather than multiple baptisms! :(

Re: Multiple Facts/Events to the same thing

Posted: 23 Aug 2021 16:52
by LornaCraig
As mentioned earlier in this topic (on 17 August) I asked Calico Pie to explain the sentence in the Help file which says
"You can optionally choose to display default or preferred facts in reports or queries... "
because we couldn't find any way of using the Preferred fact flag in a narrative report.

They have now replied:
The paragraph is correct. You can't do it in all reports, but you can do it in some - e.g. the Individual Summary report or Family Group sheet. Here's how you can add an entry for "Preferred Occupation" to the Individual Summary report, for example.

Open the Individual Summary report and click the 'Options' button.
On the 'Contents' tab, click the 'Add' button in the "Main Section Items (in Order") area. Set the values as follows:

Label: Preferred Occupation
Expression: %INDI.OCCU[preferred]%
So the Help file is not actually wrong, but somewhat misleading as it cannot be done with all report types.