Events and facts - seeking to summarise understanding

[Myles O]

specific questions:
- does the choice of fact or event have an impact on listing - for example if I record occupations as events (multiple occupations and dates are important to show progression / decline :-) can I still list all occupations?

- how does one record an event type that is not in the standard GEDcom list - in a way that can be exported -> imported somewhere else via a .ged file?


Longer version...

I'm trying to sort out facts from events and what to call events that are not listed either in Reunion or in GEDcom event or fact types.

As far as I can see the distinction between a fact an an event is that an event has a date on it.

So there have been threads here on 'have you moved occupation and education' from facts to events - you have many occupations in a lifetime.

Hence the list of facts closely resembles the list of event types.

Any other considerations that an experienced Reunion user has found and wished they knew when they were setting things up?

If I have an event - such as a bankruptcy order, an operation or an accident for instance - events that have a dramatic impact on someone's life but are not religious or BDM's, what does one do - I can see that I can add custom events, but then what happens when I export these to ged files to import somewhere else - what's best practice in these circumstances?

[Myles O]

Agh, In GEDCOM it is more sophisticated than date/no date -

I found this on GEDCOMX - Is it also applicable to Reunion?

https://github.com/FamilySearch/gedc...vents-vs-facts

2.5.2 Events Versus Facts


GEDCOM X implementations need to be able to recognize the difference between the concept of an "event" and the concept of a "fact" as defined by this specification in order to correctly use the data types associated with these concepts. This section is provided for the purpose of explicitly defining and distinguishing the two concepts.

An "event" is an occurrence that happened at a specific time or period of time, often at a specific place or set of places. Genealogically relevant events are often described by referencing the persons that played a role in that event. Hence events often refer to persons and might infer relationships, but events are described independently of those persons and relationships.

A "fact" is a data item that is presumed to be true about a specific subject, such as a person or relationship. A time or place is often, but not always, applicable to a fact. Facts do not exist outside the scope of the subject to which they apply.

Events are often used to infer facts. A marriage event, for example, infers the fact that two persons were married, and birth event infers the fact that a person was born. Facts also sometimes infer events, but the existence of a fact might not always justify a description of an event. For example, a birth fact provided by a census record might not warrant a description of a birth event, even though the existence of such an event is implied. On the other hand, a birth record that provides information about biological parents, adoptive parents, additional witnesses, etc. might justify a description of the event in addition to descriptions of any facts provided by the record.

Despite the occasional inference of facts from events and vice versa, this specification dictates that the two concepts are described independently. This version of the specification does not provide a direct association between instances of the two data types, although an indirect association can be found via the event role.

The problem is that this would imply a kind of double entry in many instances - I'm not sure that I would ever manage that!

I'm kinda interested in where people lived and why they uproot - I have family on four continents and islands in between and they bounce around all over the place.

So I would record the fact of residence, and an event of moving from and moving to (if that information is available) - If I take a source such as the 1939 England Register, it tells me where various people lived - a fact that in 1929 x lived at this address in Manchester, and y lived in Liverpool at this address... but I've no events of them moving to either.

The only problem with this is, as far as I can see, Reunion (and presumably GEDCOM) has no structure to facts and doesn't appear to allow duplicates of fact types - so you get "occupation" but no way of providing an ordered list of occupations with dates - you'd need to write a long text entry which would mess up listings. Or am I wrong about that?

From the help file:

In Reunion, a fact is an item of information relating to a person that can fit on one line. Examples include: nickname, eye color, hair color, social security number, etc.

It might help to explain what a fact isn't: if a piece of information has a date associated with it, it is probably an event, not a fact. If a piece of information requires several lines of text to describe or explain, then it should probably be recorded as a note.

Which doesn't seem to implement the GEDCOM schema since in that schema a time and/or place may be applicable to a fact. Which seems logical as there are very few facts that are immutable. eg... happy romantic -> married -> divorced -> married -> divorced -> live together -> split up -> jaded old fart

[Blaise A. Darveaux]

I don't believe GEDCOM X was ever an official version. FamilySearch Family Tree software seems to be the only one to adopt it. GEDCOM 7.0 dated 27 May 2021 is the latest version (According to Wikipedia.)

Edit:

And yet, when you click on the link in Wikipedia you get a PDF of v. 7.0.9 dated 7 Jun 2022. In the end, it depends on if your software has implemented one version or another - both for exporting and importing.

[Blaise A. Darveaux]

Here are example of my father's Events and Facts. Maybe you can get some ideas from them.


Jerry events.jpg


Jerry facts.jpg


You will note that there are multiples of the same Event types and Fact types. Also, note that dates can be ranges.

[Myles O]

Hey, thanks for that Blaise - yes I can see how I can approach things - do you know what happens when you export some of the more unusual facts - have you matched them to GEDCOM tags - and what happens when there is no suitable gedcom tag.

Don't you love these branching standards! I guess I'll have to suck it and see - the export should tell me what form of the standard it is using.

Thanks again for sharing, it was very helpful to see.

[Blaise A. Darveaux]

Myles, the GEDCOM Standard allows user-defined tags. The tags have to be preceded by an underscore (ex. _POP for a population fact) AND they must be unique (can't be the same as the defined tags that already exist or any of your other user-defined tags. Use the Reunion Help to show you where to define your own tags.

I have been lazy over the years and not done a good job of making names for my new tags. I don't hardly ever export in GEDCOM, preferring to use Reunion's Web Cards on a free service site to put out part of my research. I guess it's another thing to put on the to-do list after I'm done with the project I'm working on presently.

The current standard can be found here https://github.com/FamilySearch/GEDC...0.9/gedcom.pdf. You can see all of the defined Individual Events, Family Events, Individual Attributes, and Family Attributes on pages 59-64.

[Myles O]

Agh, perfect, thank you Blaise -