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[1]
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[2].
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.
[1] I’m also using
capitalisation here to distinguish software entities from the everyday usage of
such words.
[2] 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.
No comments:
Post a Comment