The Event is one of the most undervalued entities in a family-history (or any history) collection. Excessive emphasis is usually placed on the Person entity, and virtually none at all on the Place entity. Read how the Event is crucial to binding our information to create a coherent description of the past.
Genealogy is beset by conflicting terminology so I’ll start by defining an Event for the purposes of this post as a representation of ‘something that happened at a particular time and place’. I have previously covered the Person emphasis at OK, I Have a Family Tree. Now What?, and the lack of Place emphasis at A Place For Everything.
Most software products would claim to support an Event concept, although there is much variation, and at least as much scope for improvement. The GEDCOM format typifies the problem since it provides an EVEN record that must be associated with one specific person, or one specific family. This person-orientated approach makes it difficult to handle real-life events such as a census where people may not be directly related or may be totally unrelated at that time. Rather than making an Event subordinate to a Person, or even to a Family, it should be a top-level entity to which other entities may be connected.
If you’re serious about the historical side of genealogy – irrespective of whether you consider this family history, micro-history, or global history – then you’re creating a description of the past. Any evidence that we have is both finite and disjointed which then necessitates some analysis and conjecture in order to create a continuous description from it. However, there’s an important corollary to this: that our evidence is naturally event-based. I can’t think of a single item of evidence that I have in my own data that isn’t related to a given date (even if unknown). Unfortunately, if you’re encouraged to think of events as something in the life of one person, or a couple (e.g. marriage), or a family, then you’re missing the point. Events are things that happened in a given time and place – full stop! Alternatively, if a tree falls in a forest and there’s no genealogist to record it then did it happen?
Let’s look at a specific example: a birth. Certainly the child (or children if a multiple birth) was present, but so too was the mother (well, in the vast majority of cases anyway). The father may also have been present too. It doesn’t actually matter whether the mother and father were married in terms of the representational need. These are not insignificant participants in the event either. My own father delivered my brother because the midwife was late. That’s pretty significant! Hence, it is unrealistic to put the Event entity below a single Person, or duplicate it and put the same information under all relevant Person entities. What is needed is a multi-Person Event where zero-or-more arbitrary people can be associated with it.
This is not a new concept. Implementations that I’m aware of allow a Person entity to be associated with an Event entity using a given a role. This is similar to the collection of people you might find in a household on census night, although the census roles are rather limited in comparison.
Most of our events are assumed to have occurred within a single day (e.g. a birth, marriage, or death) and the recording a specific date is usually deemed sufficient. Let’s refer to these as simple events. What about protracted events though? Supposing you want to represent the fact that some ancestor was hospitalised for a given length of time due to illness, or an ancestor was incarcerated for a given length of time because of some crime or misdemeanour. The Event entity then needs a start date and an end date, where the end defaults to the start if unspecified, and these effectively give the Event a duration.
The above illustration has a single Place associated with the Event which could represent a church or register office. So should we allow more than a single Place or would that be complicating the Event concept? Although we can imagine an event having a duration, it’s more difficult to imagine it occurring at more than one distinct place. To illustrate why we don’t need more than a single place, let’s look at a slightly more complicated event: a voyage from one place to another. We obviously have two important places here – the points of embarkation and disembarkation – but the vessel itself constitutes a place too. A problem with overloading an Event entity with two or more Places is that you lose the option to refer to any of them separately. In effect, you lose the granularity. For instance, something important may have happened during embarkation/disembarkation or during the voyage itself.
What we need is a hierarchical Event concept so that we can model the detailed structure of those real-life events more closely.
In this illustration, embarkation and disembarkation are represented by simple (one date) Events, whereas the overall Voyage is represented by a protracted (two dates) Event, where the start and end points are defined by the child Events. Either of the end points of a protracted Event may be given a specific date but in this instance the dates are the same as those in the child Events and so may be equated. This structure means that evidence can now be associated with any of these Events, and without having to flatten the overall representation to a single entity, or eviscerate the representation into separate disconnected pieces. If a stop-over occurred during the voyage then another child Event could be defined between the start and end points.
In effect, each Event only needs a single, specific Place, although it can be a large-scale or small-scale Place as appropriate to the Event.
The use of nested and protracted Events can be taken to multiple levels in order to model more complicated real-life events, such as someone’s military service, employment, or attendance at a school or college. The simple Events would typically be at leaf level, i.e. with no child Events of their own.
Note that these Events may be shared ones, meaning that more than one Person could be linked to them. This provides a very rich source of information for looking at how lives interact, and for analysing connected timelines. STEMMA® represents a person’s life using multiple Events rather than one single, all-encompassing Event. However, it does impose one important restriction: each Person entity only has one birth Event and one potential death Event. These are the only Event types which are independent of culture, sex, or geography, and which have a well-defined cardinality.
In summary, Events are not needed for lineage-linked data such as family trees, but they are essential where the data has an historical emphasis. This includes family history, micro-history, and any generalised historical data. When present, they should be capable of modelling real-life events rather than merely being some type of software notion. If you’re reading this and thinking that it is all too complicated then you’re probably someone who is more tree-focused. This is not a problem, unless you try to retrospectively get timelines out of your data. Several products betray the fact that they were originally designed around a family tree, and hence lineage-linked data, because they find it hard to generate useful timelines, especially ones involving both shared and private Events. Full support for Events has serious implications for evidence but I will leave that until a much later post. In the meantime, I intend to follow-up on this post with more useful things that Events could deliver for us.
 I’m also using capitalisation here to distinguish software entities from the everyday usage of such words.
 As I write this, I wonder how many software products could cope with the employment history of someone like Neil Armstrong. It’s OK saying that you can divide-up a life into groups of hierarchical Events but if you couldn’t attach a Place entity describing the Moon then there would be a problem for him and other astronauts.