* Multiple Events and/or Assertions

[jmurphy]

Here's the top of the Facts tab (this file is missing her four marriages and other later information). You can see the messy results of my saving every birth event as an alternate on Ancestry, in a futile attempt to save which database had which information in it.

'Hapton' in the Residence fact is brightsolid's transcription for 'Slapton', which I've left in place as a reminder that their transcription is wrong.

fanny-facts.png (12.64 KiB) Viewed 12343 times

[tatewise]

Regarding the multiple Birth Events I suspect you are aware that in FH there is a neater way:

Create enough Source Records to cover each 'database'.
Merge into one Source Record any that are almost identical, and note the small differences in the Note or Text From Source fields of the Source Record.
Attach any source document images to the Multimedia tab.
If the differences are small enough you might manage with just one Source Record.

Reduce the multiple Birth Events to one with the most likely Date and Place and Address.
Then cite the Source Record(s) for the 'databases'.
Repeat this for other Facts such as Parent details and cite the same Source Record(s).

[ColeValleyGirl]

Or, you could adopt Elizabeth Shown Mills approach: To What Do We Attach Our Citations? and retain separate assertions for every citation.

[tatewise]

That is fine as a very formal approach to recording the research status.

But if you use standard Birth/Death Events for your multiple assertions what happens in Diagrams and Reports?
How do you obtain a normal Diagram or Report in which Individuals are only Born once and only Die once, etc?

Instead, perhaps you use multiple custom Birth/Death Assertion facts defined in Tools > Work with Fact Sets.
Each Birth/Death Assertion fact would thus have its own Citation of a specific Source Record.
Then these Birth/Death Assertion facts can be easily omitted from Diagrams and Reports.

There would need to be one standard Birth/Death Event with a best interpretation of the research assertions to date.
This would be what appears in normal Diagrams and Reports.
This Birth/Death Event could Cite a Source Record that assessed & summarised all the assertion Source Records.
The Note field is perhaps where such assessments would reside and it could Cite all the assertion Source Records.

[ColeValleyGirl]

There would need to be one standard Birth/Death Event with a best interpretation of the research assertions to date.
This would be what appears in normal Diagrams and Reports.

If I don't have a preferred conclusion or best interpretation for birth date or death date I don't want a misleading 'normal' report or diagram -- I want all the uncertainty visible.

[jmurphy]

Yes, having multiple standard birth and death events so that I can keep track of multiple assertions is a kludge, and no, I don't use the diagrams and reports.

In an ideal world, our programs would allow us to display our conclusions for diagrams and reports, but when asked to do so, would expand out the evidence management sub-module in a separate tab or window, displaying all the individual assertions that we have collected and our proof statement about them. (See the video Overview 3 of Ben Sayers' Lineascope demo, or his event sheet, for an example: http://www.lineascope.com/images/sample_event_sheet.pdf).

I like having all the separate assertions visible in the Records Window, so that I can expand out and see all the assertions and their sources at a glance. If I had entered the data in FH rather than on Ancestry, there would be fewer events, and all the sources consistent with each other would be attached to each one; I would be able to expand the list and see that the calculated birth year of 1906 came from the 1911 and 1920 Census, the Nov 1905 estimate came from Ancestral Sources (and despite the fact that FH complains the date range is mostly later than the death of Fanny's mother, it is consistent with her mother's burial date of 05 Nov 1905), and the October 1905 birthdate is actually a Q4 registration date (although once the 1900 US Federal Census has been entered, I will have an actual assertion that Fanny was born in October 1905).

I have been considering keeping all information from finding aids such as birth indices (in the US) and GRO registrations (for the UK) in custom events, so I suppose I could do the same for calculated birth dates from the census records, once I had better evidence. That seems like a good compromise because it leaves the standard birth event (and marriage and death etc) for those records which have a date in them. It wouldn't reduce the standard birth event to one, because there are too many records which have only the month and year, but it would greatly reduce the number of them. (Presumably I could make sure all the vital record dates which are a product of calculations from ages are marked as 'calc', and then use the Change Any Fact Tag Plugin to filter them and to change them to my Custom Fact?)

But I want to have the assertions visible rather than buried in notes to avoid Citogenesis.

http://imgs.xkcd.com/comics/citogenesis.png

[BillH]

There would need to be one standard Birth/Death Event with a best interpretation of the research assertions to date.
This would be what appears in normal Diagrams and Reports.

Mike,

It sounds like I do something similar to Helen. I have a separate birth event for each different birth date that I have come across in my research. If I have one birth event with a date of 1 Jan 1900, I would not create a new birth event if I came across a record of the birth being in Jan 1900 or just 1900. In this case I would create new sources for these records and use them to cite the 1 Jan 1900 birth event. If I have no idea what the actual birth date is, then I don't want to pick one of the options and assume it is the standard one.

Bill

[tatewise]

Helen said:

If I don't have a preferred conclusion or best interpretation for birth date or death date I don't want a misleading 'normal' report or diagram -- I want all the uncertainty visible.

That is fine too. Just enable the custom Birth/Death Assertion Facts in the Report or Diagram and if necessary disable the standard Birth/Death Events.

The key point is that by having different Fact Types for Events and Assertions you can choose to include neither, either, or both.
You can keep separate Diagram Types and Report Types with different options depending on what you want included.

This appears to be what Elizabeth Shown Mills is advising ~ only use Events for conclusions ~ in the meantime use Assertions.

Bill, you appear to go only about halfway towards Helen's approach.
Helen suggests a separate Assertion Fact for every Source even where the Date is the same.

Another problem with multiple standard Birth Events is you cannot choose which one is your preference to appear on the Main tab. The one with the earliest Date will take precedence if you use any of the options to sort Facts chronologically. Ditto for Death, etc.
So by only having one (or none if no conclusions reached) then that appears on the Main tab, and by default in Diagrams and Reports.

[ColeValleyGirl]

Helen suggests a separate Assertion Fact for every Source even where the Date is the same.

No she doesn't, or rather, ESM doesn't:

Q: Should each date be listed and cited individually?

A: Yes, each date is an assertion. Once you record that assertion in your research notes, you then identify the evidence for that assertion.

[snip]

Eventually, of course, our research may resolve the conflicts. If not, then when we reach the writing stage we have all the evidence we need to make a reliable conclusion about a probable date or date range. At that point, we would use the details from our research notes to explain why we have reached a certain conclusion.

I'd actually extend this to cover (e.g.) places as well -- each potential birth place would be an assertion -- so a single source might result in two assertions, one for the date and one for the place. Or it might support an existing assertion for place but introduce a new assertion for date. Or vice versa.

(Incidentally, when ESM refers to 'the writing stage' she's talking about producing a written report (not a machine-generated one) detailing a piece of research, or else a 'proof argument' supporting a conclusion reached, not entering information into a research database such as FH.)

Re using a system of custom Birth/Death Assertion Facts (which is a contradiction in terms -- an assertion is not a fact, it is a claim or hypothesis about a fact), in practice that system would need to be expanded into a pretty comprehensive shadow set of custom 'assertions', one for every possible fact, at the cost of a lot of work for no benefit that I can see -- GEDcom 5.5 and FH both (mostly) satisfactorily support multiple 'facts' of the same type for an individual or couple; why not exploit that?

Flags would be nice on 'facts' to identify the preferred option if one exists, but there's a way around that (I haven't tested this yet, so it needs working through in detail) for diagrams using the Event or Attribute Descriptor that is accessible via the All tab or the record window -- set that to "Preferred" or "Conclusion" or whatever phrase floats your boat, and then use it to condition what's shown on diagrams. Presumably, reports will also display the descriptor if it exists but I can't think of a way to include only the 'preferred event' in a report...

(Doing a search just now, Mike, I notice you're proposed using Descriptor in this fashion elsewhere -- do you know a way around the report limitation?)

This wouldn't help in the Main tab or the focus window, but I rarely use the information in either (they're navigation aids for me, nothing else) -- I make much more use the All tab or the Records window.

[tatewise]

Sorry, I slightly misunderstood the relationship between Assertion and Source. It is much clearer now. I realise Bill is using a very similar method.

I only meant to use the term Fact in the sense of an FH Fact Type (i.e. Standard/Custom Event/Attribute).

I am not aware of a way to use the Descriptor except in Diagrams.
That is why I proposed the use of a different FH Fact Type for Assertions, so it is possible to choose what to display.
The problem with exploiting multiple instances of standard Events, is users cannot choose a preferred one to display.

I try and offer solutions that work for as many features of FH as possible, while recognising that some users may not use them all.

[ColeValleyGirl]

I try and offer solutions that work for as many features of FH as possible, while recognising that some users may not use them all.

I'm in awe of the amount of effort and creativity you put into finding solutions -- and fully recognise that, as everybody's research process is different, no solution will work for everybody. (It's a testament to FH's flexibility that it can be used to support so many requirements).

No doubt a plugin could be used to temporarily 'clean up' multiple instances of events before generating a report.

[tatewise]

A Plugin could do as you suggest, using the Descriptor as the selector, but it would have to work on a copy of the Project, which would be discarded after creating the Report.
It would be too dangerous to use the master Project as the 'clean up' would involve deleting lots of data.

It still would not resolve the problem of the Focus Window and Property Box - Main tab, nor many of the Queries that assume only one Birth/Death Event, etc. (although they could be adapted).

I am also unsure of what happens with functions such as =EstimatedBirthDate() and =EstimatedDeathDate when there are multiple instances of FH Facts, bearing mind that they don't just look at Birth & Death Events.
These functions are sometimes also used by Plugins to determine those Dates.
Again, separating Events from Assertions in different Fact Types would solve that problem.

[ColeValleyGirl]

Again, separating Events from Assertions in different Fact Types would solve [those] problem.

We'll have to differ on this one; as I've said, I think it would introduce more problems than it solves, including:

• the work to define and maintain the 'shadow facts' which aren't limited to just birth and death
• major potential for inconsistency in data entry (e.g. using a standard birth rather than a custom birth and vice versa)
• incompatibility with tools such as Ancestral Sources, other GEDcom manipulation and analysis tools, and applications which use GEDcom as a data exchange mechanism

[jmurphy]

Again, separating Events from Assertions in different Fact Types would solve [those] problem.

We'll have to differ on this one; as I've said, I think it would introduce more problems than it solves, including:

• the work to define and maintain the 'shadow facts' which aren't limited to just birth and death
• major potential for inconsistency in data entry (e.g. using a standard birth rather than a custom birth and vice versa)
• incompatibility with tools such as Ancestral Sources, other GEDcom manipulation and analysis tools, and applications which use GEDcom as a data exchange mechanism

The only 'shadow facts' I have experimented with so far are the ones I created for the GRO BMD registrations, and that worked out well.

The data from the registrations and other finding aids is, by nature, of a different form than the data from other sources. In the USA we have a similar situation where states have statewide indexes of vital records that list the county where the event took place (counties in the USA being comparable to a Reg District in the UK).

Take the case of the mystery marriage registration that I mentioned on G&FH.SE. It was registered in Stoke Damerel Reg. District. Even though intellectually I know that the Reg District is larger than the town of the same name, just as there is more to Alameda County, California, than the town of Alameda, I have to catch myself from making silly mistakes like searching the parish of Stoke Damerel on Family Search to look for a marriage, but not looking at any other parish in the Registration District.

Putting the registrations in their own Fact sets them apart from the records which might contain data which is more specific to the event; it highlights the known fuzziness of the information they convey.

[ColeValleyGirl]

The only 'shadow facts' I have experimented with so far are the ones I created for the GRO BMD registrations, and that worked out well.

I can see the logic of a custom 'Birth registration' event, but not a custom 'Birth assertion' that mirrors exactly the structure of the standard 'Birth' event.

[DavidNewton]

I have been trying to follow this thread and it is fascinating so I thought I would put in my own, probably oversimplified, conclusion. It seems to me that the main thrust is that we should attempt to put our quart of data into the pint pot of a FH database.

I don't think FH was designed for evidence gathering I believe like most of the Family Tree Software it is designed for recording conclusions. Until the software progresses we are stuck with fudging the issue and as can be seen here there is no agreement as to how that should be done but is is interesting to see the viewpoints. Keep 'em coming!

David

[ColeValleyGirl]

I don't think FH was designed for evidence gathering I believe like most of the Family Tree Software it is designed for recording conclusions.

True, whish I why I use my own package for managing the process of gathering evidence gathering, but rather than duplicate functionality, I use FH to record the details of what I find -- ideally (but not always) once I've reached a conclusion, of it I haven't reached a conclusion but want to share my work-in-progress thoughts.

[jmurphy]

I don't think FH was designed for evidence gathering I believe like most of the Family Tree Software it is designed for recording conclusions. Until the software progresses we are stuck with fudging the issue and as can be seen here there is no agreement as to how that should be done but is is interesting to see the viewpoints. Keep 'em coming!

Helen has heard me talk about this at great length already, but if you're interested, you may want to take a peek at my answer to the question How many sources/citations is too many? over on Stack Exchange.

I chose Family Historian because I liked the interface, and because of the Auto-Source Citation feature. But I was trained in a Source-based system, and when I started out, the source-based software didn't seem as mature as the lineage-linked software. So one of the things on my To Do list is to revisit Clooz and Evidentia. It will be annoying to do double-data entry, but that can't be helped.

[DavidNewton]

Jan

Many thanks for the link, more interesting reading. It highlights that there is no agreement as to the right or wrong way to do things and of course that is the basis of all interesting discussion.

I was interested to note the use of 'assertion' as a means of stating that the evidence 'may' be unreliable. In mathematics we used the phrase 'proof by assertion' as a negative comment when marking work in which conclusions were drawn with no proof. Of course in mathematics there is probably a proof lurking somewhere; in genealogy there is no guarantee that there is any proof.

David

[jmurphy]

Jan

Many thanks for the link, more interesting reading. It highlights that there is no agreement as to the right or wrong way to do things and of course that is the basis of all interesting discussion.

I was interested to note the use of 'assertion' as a means of stating that the evidence 'may' be unreliable. In mathematics we used the phrase 'proof by assertion' as a negative comment when marking work in which conclusions were drawn with no proof. Of course in mathematics there is probably a proof lurking somewhere; in genealogy there is no guarantee that there is any proof.

David

And for more interdisciplinary fun -- one of my instructors in graduate school does research on a language which has data source as a required postulate. E.g. in English we have obligatory number, so almost everything is either singular or plural. This language requires the speaker to say how one knows something. The choices indicate:

• personal knowledge
• someone said so
• data that was inferred
• non-involvement
• no one alive could know

I find this a very useful filter for sorting out information on historical records. If a father is the informant on his child's death certificate, he might have been present at the child's birth, and has personal knowledge of his child's parentage (we hope); in the reverse situation, the child would only know his father's father from being told by someone else, and if the father was very elderly, it might also be the case that no one else who was alive would know.