Who’s Your Father?

We all have cases where we have had difficulty identifying the father of a child. Usually, it was because no father was listed on the birth or baptism record. This small bit of research deals with a slightly different case where the father’s details were deliberately obfuscated.

One of my direct ancestors, Samuel Rowland, was born 1857 in Belper. Belper is a town towards the centre of the Derbyshire, England, and about 7 miles north of Derby. Two of the most predominant industries in Belper were nail-making and cotton mills[1], and both of them show up in this research.

Samuel, and his wife Mary, supposedly had a child called Eliza, but tracking her down was not easy. In the 1891 census[2], Samuel was a widower, working as a ‘Coal miner’, and living with the family of his brother, Joseph Rowland. Samuel had three children of his own with him:

Eliza Rowland, b. c1882 in Heage, Derbyshire

Anthony Rowland, b. c1885 in Belper, Derbyshire

Albert Rowland, b. c1886 in Belper, Derbyshire

In the subsequent 1901 census[3], Samuel and his three children were still living with Joseph. His occupation was recorded as ‘Coal hewer, underground’. However, his daughter was then recorded with a middle initial (Eliza G. Rowland), and the children’s birthdates were calculated as 1883, 1884, and 1886 respectively.

At this stage, I had a problem because I could find no Eliza G. Rowland born 1882–1883 anywhere in Derbyshire. There was one Eliza Rowland, b. 1881 in Chesterfield, but she could be eliminated on other grounds. Luckily there was only one candidate marriage for Samuel Rowland, and that was to a Mary Bradley on 3 Mar 1883 at the Parish Church of Duffield, Derbyshire[4]. Their marriage certificate provided the following details:

o   Samuel (bachelor, aged 25) was a ‘Collier’ living in Belper.

o   Samuel’s father, Anthony, was a ‘Labourer’.

o   Mary (spinster, aged 26) lived in Belper.

o   Mary’s father, John, was a ‘Nailer’[5].

o   Witnesses were Joseph and Lucy Rowland (i.e. Samuel’s brother and sister-in-law).

These details collectively pointed to Mary having died in Ilkeston[6] in 1889 aged just 31[7]. I could equally have obtained Mary’s maiden name from the birth certificates of her two sons, although the older daughter, Eliza, was still a mystery. There was no Eliza G. Bradley registered either so it wasn’t a simple case of the child being registered under the mother’s surname.

I then did something unusual that’s certainly recommended when all else fails. I looked for the surname, Rowland in this instance, as a middle name. This turned up the baptism of an Eliza Rowland Gregory[8]. A little light went on in my head because in the 1881 census[9] Samuel Rowland was single but he had a live-in ‘house keeper’ called Mary Gregory of about the same age as Mary Bradley. So, could Mary Gregory and Mary Bradley be the same person? Things were getting complicated very quickly.

The birth certificate for this Eliza [Rowland] Gregory[10] (middle name was present on the baptism but not on her civil birth registration) said she was born on 3 May 1881 at the Green Man, Heage, Derbyshire, which matched the place-of-birth listed above even though the date was a couple of years out. The informant was Mary Gregory, formerly Bradley (mother), but no father was recorded. In other words, Mary Gregory was heavily pregnant at the time of that 1881 census (3 Apr 1881). The aforementioned baptism record showed that Eliza was baptised on 8 Jan 1882 at the Heage Free Methodist Chapel, Derbyshire, and the father’s name was recorded as “Saml Gregory”. So, we now have two Marys (Mary Gregory/Bradley and Mary Rowland/Bradley), two Samuels (Samuel Gregory and Samuel Rowland), a possible name switch for the child, and a dubious date-of-birth for the child (Eliza Rowland Gregory was b.1881 but later census returns for Eliza G. Rowland said 1882–1883).

Now that same 1881 census also said Mary Gregory was a widow so it would be a fair guess that she was previously married to a Samuel Gregory. Well, she was married, but to a Walter Gregory[11]. The parish record showed that this occurred on 10 Jun 1877 in Duffield, Derbyshire. Walter’s father was recorded as Alfred Gregory, and Mary’s mother as Eliza Bradley. It’s interesting that this Mary didn’t give her father’s name on her marriage, but even more interesting is that I could find no viable death record for a Walter Gregory between the date of their marriage and the census date. Was the father’s name listed on Eliza’s baptism (i.e. “Saml. Gregory”) simply a composite of Samuel Rowland’s and Mary Gregory’s?

The mother’s maiden name wasn’t added to the GRO Index of birth registrations until after September 1911, and so it would be hard to identify any civil registrations as belonging to Walter and Mary without buying lots of expensive certificate copies. However, given the absence of any visible parish baptisms on FamilySearch.org, I would suggest that there were no such children.

Looking further afield, it appeared that Walter was actually lodging in Durham in 1881 (i.e. not dead at all), and that he claimed to be single[12]. This together with the evidence that there were no children for four years of marriage between Mary and Walter, that Mary’s daughter, Eliza, was initially baptised as Eliza Rowland Gregory, and that the baptism recorded a father of “Saml Gregory” (i.e. Samuel Rowland’s forename and Mary’s surname), suggest Eliza was Samuel’s child – not Walter’s. It is therefore likely that Walter and Mary split soon after their marriage and that Mary was “house keeper” for Samuel well before the 1881 census.

Following Walter in Durham, he met an Alice Whitfield (b. c1856 in Liverpool) in about 1878 and had 3 children with her (Eliza Jane, James, and Mary Ellen), all registered in Alice’s maiden name. He finally married Alice in Gateshead in 1885 before having another child, Abigail. Note that 1885 is 7 years after 1878 and so they could have legally married by claiming no knowledge of his previous spouse (aka “poor man’s divorce”[13]). So, in conclusion, Walter remarried in a legally-acceptable way in 1885, but Mary had to lie in 1881 because she was pregnant by Samuel. Eliza’s age in subsequent census returns had been adjusted to fit in with the marriage of her parents in 1883 and so to cover the tracks a little.

After solving this little puzzle, I decided to look for Mary Bradley’s parents. From the details mentioned above, we know that Mary’s mother (Eliza Bradley) was mentioned in her first marriage (but not her father), and that her father (John Bradley, a ‘Nailer’) was mentioned in her second marriage. Mary’s second marriage implied she was born Mar 1856 to Mar 1857 (i.e. Mar 1883 – 26) and her death implied she was born in c1858 (1889 – 31). However, I could find no marriage of a John Bradley to an Eliza in that county in the right timeframe.

What I did at this point was to go to the 1861 census, when Mary would have been a child, and look for Eliza in the same household as a John Bradley with an occupation involving the partial word “nail”. This found absolutely no matches so I substituted the child’s name (Mary) for Eliza’s. This turned up just one instance in the whole of Derbyshire[14]… which was nice! However, the details weren’t quite what I was expecting. This Mary was living with her grandparents, John (a ‘Nail maker’[5], b. c1796) and Rebecca Bradley. No sign of Mary’s parents anywhere. I therefore looked for John and Eliza in the 1851 census, even though that might have preceded any marriage, and specified the same partial occupation. This found just one instance in the whole of England, and it was for the same John (a ‘Nailer’)  and Rebecca, with Eliza Bradley being their daughter[15]. If I had the right Eliza and Mary then there were some important repercussions: Eliza was born a Bradley, and she was probably single when she had Mary.

John and Rebecca can be found in the same local area of Cow Hill, Belper since the first census in 1841. This is interesting since it had the greatest number of nailers (John’s occupation) in the Belper region in the mid-19^th Century[16]. Hence, the name of the occupation would be well-known and unlikely to have been substituted with something less specific.

The 1861 census showed Mary was born c1857 and that she had a younger sister, Ann M., who was born c1858; both in Belper. I could find no online baptism records for these children in the Belper region, maybe because they were illegitimate, but I easily found civil birth registrations in the Belper District that fitted the census dates closely: 1856 Q4 for a Mary and 1858 Q1 for an Ann Maria[17]. I purchased copies of both certificates and they confirmed that Eliza Bradley was the mother in both cases; neither listed any father.

Mary was born 13 Oct 1856 and Ann Maria on 7 Feb 1858, both at Cow Hill, Belper, which matched the household location in both the 1851 and 1861 census. Although neither specified a father’s name, Mary’s birth certificate listed the father’s occupation as a ‘Cotton rover’. This all made nonsense of Eliza being married to a ‘Nailer’ called John Bradley. Although Mary had an Uncle who was also called John, he was a ‘Slater’ (see note 5) who moved to Cheshire in the period 1851–1855 and died there in 1866 aged just 31. We can conclude, therefore, that Mary listed her grandfather’s name and occupation in the details of her second marriage.

I don’t like loose ends so I continued and found Eliza Bradley later married a Joseph Austin (b. c1836 at Belper) on 4 Jul 1858 at Duffield, Derbyshire, and that they had a child of their own, Sarah Elizabeth Austin, in 1859. Unfortunately, Eliza’s death was recorded in the very next quarter, possibly as a result of complications from the childbirth. Joseph’s occupation in the 1861 census was a ‘Carder, cotton factory’[18], and was very likely to have worked with the father who was hinted at on Mary’s birth certificate since the Strutt family had a complex of cotton mills on the nearby River Derwent[19]. Although the jobs are related, Joseph is unlikely to have been the real father of Mary and Ann Maria since their surnames were never changed after Eliza’s marriage to Joseph, and Joseph was not acknowledged in Mary’s later marriages. Mary’s occupation in 1851 was ‘Silk embroiderer’ which doesn’t immediately suggest she worked in a cotton factory. Although silk embroidery was performed on many cotton products, such as stockings, this is more likely to have been part of the local hosiery business of Ward and Brettle[20]. Joseph latter remarried to Grace Taylor on 31 Jan 1865 at Duffield, Derbyshire, and died in 1884, in Belper, aged 48.

I haven’t provided an exhaustive list of all the avenues I explored during this research. What I’ve done is to present the crucial bits of information that allowed me to break down a number of brick walls, and get closer to the truth. This was despite a concerted effort on the part of these family members to obscure that truth. Let’s just recap on the lies and smoke-screens:

• Eliza Rowland Gregory switched her name to Eliza Gregory Rowland in later life. Maybe not a deliberate attempt to hide anything but it certainly added to the confusion.
• Eliza’s age was bumped up by a couple of years in the census to make it appear she was born after her parent’s marriage.
• Eliza’s father was recorded as “Saml. Gregory” which was a composite of the forename of her biological father (Samuel Rowland) and the married name of her mother (Mary Gregory).
• Mary declared herself to be a spinster in her second marriage, thus ignoring her first marriage.
• Mary used her maiden name (Bradley) in her second marriage.
• Also in her second marriage, Mary said her father was John Bradley, a nailer, whereas this was most likely her grandfather’s name.
• Mary Gregory declared herself to be a widow in the 1881 census, whereas she had simply separated from her first husband.

A corollary to this is that there’s no such thing as a “fact” on an historical record. As someone with a background in mathematical physics, I admit that I initially struggled with the concept of a ‘proof’ in genealogy because the term implied some sort of absolute proof to me, although I more easily accepted the concept of a proof argument. However, a fact is “a thing that is known or proved to be true”[21] and so the concept of some item of evidence being declared a fact is anathema to me.

---

[1] Gill Stroud, “Derbyshire Extensive Urban Survey: Archaeological Assessment Report: Belper”, report dated 2004, Archaeology Data Service (https://archaeologydataservice.ac.uk/catalogue/adsdata/arch-881-1/dissemination/pdf/EUS_Texts/Belper/Belper.pdf : accessed 9 Feb 2021), p.7; funded by English Heritage.

[2] "1891 England, Wales & Scotland Census", database, FindMyPast (www.findmypast.org.uk : accessed 5 Dec 2013), household of Joseph Rowland (age 36); citing RG 12/2665, folio 77, page 48; The National Archives of the UK (TNA).

[3] "1901 England, Wales & Scotland Census", database, FindMyPast (www.findmypast.org.uk : accessed 5 Dec 2013), household of Joseph Rowland (age 46); citing RG 13/3150, folio125, page 8; TNA.

[4] England, marriage certificate for Samuel Rowland and Mary Bradley, married 3 Mar 1883; citing 7b/820/351, registered Belper 1883/Mar [Q1]; General Register Office (GRO), Southport.

[5] A number of counties in the heart of England were involved in the production of slate, and especially for roof tiles which are still a characteristic feature of some villages. A Nailer was basically someone who made nails, especially for these roof tiles, and a slater was someone who attached the roof tiles.

Interestingly, some of the slang words generated by this profession crept into US usage, albeit slightly corrupted. The term 'collywest' (or colleywest, or collywesson) came from Collyweston (http://en.academic.ru/dic.nsf/enwiki/934694), a village in Northamptonshire that was well-known for such slate (although theirs was not true slate), but the full etymology is uncertain. Descriptions fall into two groups: (1) anything a bit crooked, awry, wobbly, or generally disordered, and (2) opposite, wrong way, or contrary. The story I heard (Diarmaid Ó Muirithe, Words We Don't use (Much Anymore) (Gill & Macmillan, 2011)) was that from the slate they quarried, they sold the nice even pieces but used the crooked poorer-quality pieces for their own homes. Hence, the village rooftops were especially disordered. I cannot cite a reference but I believe the term 'collywobbles', which relates to any disordered feeling in the stomach, is a derivative of this. In the northern US, the term 'galley-west' is widely held by their dictionaries to be a derivative of colly-west.

[6] Ilkeston is a town in Derbyshire, although it is actually closer to Nottingham than it is to Derby. It appears in the Basford Registration District of the Nottinghamshire Registration County.

[7] Transcribed GRO Index for England and Wales (1837–1983), database, FreeBMD (http://freebmd.rootsweb.com/cgi/seach.pl : accessed 5 Dec 2013), death entry for Mary Rowland; citing Basford, 1889, June [Q2], vol. 7b:76.  "England Deaths and Burials, 1538-1991", index, FamilySearch (https://familysearch.org/pal:/MM9.1.1/JZMD-QMW : accessed 5 Dec 2013), Mary Rowland, 6 May 1889.

[8] "England Births and Christenings, 1538-1975", index, FamilySearch (https://familysearch.org/pal:/MM9.1.1/NLBN-63N : accessed 3 Dec 2013), Eliza Rowland Gregory, 8 Jan 1882.

[9] "1881 England, Wales & Scotland Census", database, FindMyPast (www.findmypast.org.uk : accessed 5 Dec 2013), household of Samuel Rowland (age 24); citing RG 11/3415, folio 76, page 33; TNA.

[10] England, birth certificate for Eliza Gregory, born 3 May 1881; citing 7b/614/233, registered Belper 1881/Jun [Q2]; General Register Office (GRO), Southport.

[11] "England Marriages, 1538–1973", index, FamilySearch (https://familysearch.org/pal:/MM9.1.1/NVW3-JXK : accessed 5 Dec 2013), Walter Gregory and Mary Bradley, 10 Jun 1877.

[12] "1881 England, Wales & Scotland Census", database, FindMyPast (www.findmypast.org.uk : accessed 5 Dec 2013), household of William Kerry (age 36); citing RG 11/4904, folio 4, page 1; TNA.

[13] In England and Wales, an act of Parliament, Offences Against the Person Act 1861, contained a clause in section.57, Bigamy, which allowed for a presumption of death if separated for seven years or more.

"Provided that nothing in this section contained shall extend ... to any person marrying a second time, whose husband or wife shall have been continually absent from such person for the space of seven years then last past, and shall not have been known by such person to be living within that time".

Lack of knowledge was all that was required here, and there was no obligation to go and find them. This became informally known as “the seven year rule” or “a poor man’s divorce”.

[14] "1861 England, Wales & Scotland Census", database, FindMyPast (www.findmypast.org.uk : accessed 6 Dec 2013), household of John Bradley (age 65); citing RG 09/2510, folio 94, page 13; TNA.

[15] "1851 England, Wales & Scotland Census", database, FindMyPast (www.findmypast.org.uk : accessed 6 Dec 2013), household of John Bradley (age 52); citing HO 107/2144, folio 617, page 10; TNA.

[16] Stroud, “Derbyshire Extensive Urban Survey”, p.20, sect. “Component 22: Development at Cow Hill”.

[17] England, birth certificate for Mary Bradley, born 13 Oct 1856; citing 7b/400/230, registered Belper 1856/Dec [Q4]; General Register Office (GRO), Southport. Birth certificate for Ann Maria Bradley, born 7 Feb 1858; citing 7b/414/177, registered Belper 1858/Mar [Q1]; GRO, Southport.

[18] A carding, or combing, was a process where the cotton fibres were aligned to make them stronger and prevent snagging. This stage preceded roving (considered a more skilful job) where the fibres were twisted to make the cotton thread and wound onto bobbins.

[19] Stroud, “Derbyshire Extensive Urban Survey”, p.20, sect. “Component 23: Belper Mills”.

[20] Stroud, “Derbyshire Extensive Urban Survey”, p.12, sect. “Textiles - hosiery”.

[21] Oxford Dictionaries Online (http://www.oxforddictionaries.com/definition/english/fact : accessed 7 Dec 2013), s.v. “fact”.

Is That a Fact?

When you record such things as a name, age, occupation, place-of-birth, etc., do you refer to them as ‘facts’ or something else? Are they held as simple text values in your database? Have you thought about the true nature of those data items?

As usual in the digital side of genealogy, we have a plethora of alternative terms for the same thing, and ambiguous interpretations of the more common terms. Genealogists are encouraged to refer to these data items as ‘facts’, although I have already made the point in Evidence and Where to Stick It that their facticity is dependent upon the source from which they came. A number of software developers prefer the term ‘PFACT’, which stands for property, fact, attribute, characteristic, or trait. However, this is squandering five perfectly good words – each with distinct meanings in normal usage – and so reducing the possibility of any of them being given distinct genealogical uses. I will be employing the more generic STEMMA® term of ‘Properties’ in this post.

So, what is a Property? You might say that it is an item of evidence[1] taken from a given source of information. This is a fair description, but as soon as you acknowledge that a Property is “an extracted and summarised item of information” then a number of issues have to be considered and solved for their digital representation. What I’m about to present is my own approach as to-date I’m not aware of any product that tackles all of these issues.

Foremost amongst the issues – and yet rarely discussed in the context of Properties – is the difference between what was written and your interpretation of it. Although this is a fundamental part of supporting evidence and conclusion, or E&C, I need to clarify that, here, this is purely the analysis and interpretation of each item rather than building them into any proof argument; that being a separate phase. For instance, if a place name has been misspelled, or is hard to read, then you need to record it as it was written (indicating any uncertain characters) together with your interpretation of what it should have been. In effect, each Property has two distinct values: the recorded one, including any transcription anomalies, and the interpreted one. As with any form of conclusion-making, you’ll also need a way to add any explanatory notes, and possibly add some level of confidence in your result. I will come back to this duality of Properties in a moment.

All Property values are implicitly associated with a particular time and place. For instance, someone’s name may have changed during their life, and someone’s age will certainly have changed over time. STEMMA copes with this because the Properties are associated with specific Event-to-Person connections[2] in the data, and the Event entity implicitly provides a relevant date for the interpretation and applicability of the value.

Another issue to consider is the nature of the Property. Is it the name of something (e.g. a person or place), a description (e.g. cause of death), a date, or a measure of something (e.g. age, height, weight)? This is termed its data-type. The importance of it lies with the interpreted value (rather than the written value) which should be computer-readable in order to make the most use of it. Whilst I acknowledge that there may be detractors to this statement, let me try and make a number of observations to justify it.

For the simple expedient of consistency checking, software needs to know whether a value should be textual, numeric (integer or real), or a date. More than this, though, a value such as a date can be used in a timeline, and an age can be used to derive dates and to separate events, so their values should be accessible to software. In the case of a person or place reference, these can be linked (using some type of pointer mechanism) to the corresponding Person or Place entity in the data. That linkage, which is as much a conclusion as the interpreted value of any date, is required in order to allow you to follow the reference to the entity’s details. However, the duality of the Property values doesn’t require you to change the name from how it was recorded at that time. Finally, in certain cases, a Property may have a representation that doesn’t correspond to a value in the normal sense, either because the written form was undecipherable or it had a special meaning. For instance, the use of “Full Age” for a young married couple, or “Unknown”, “N/A”, or “LNU” for an unknown name, are special non-values. There’s a golden rule that you do not record anything in a name field that isn’t actually a name[3]. Being able to distinguish the recorded form from an interpreted form avoids this issue.

If a Property is a measure of something, such as a height or weight, then the interpreted value needs to identify the units. In all but one case, it is debatable whether or not software will want to make use of these units themselves as opposed to simply distinguishing values held in different units. That exception involves the age of a person. Ages are normally recorded in years, but ages in months, weeks, or even days, are quite common for infant deaths. These may also be fractional rather than integer values, e.g. “3 ½ weeks”.

Some Properties are necessarily multi-valued. The most obvious case is a Role (i.e. the part a Person plays in an Event). For instance, a witness at a wedding may also have been a relative of either the bride or the groom. A computer representation must accommodate multiple values, and support the duality for each instance.

It would be folly to try and enumerate all possible Properties in advance of them being used. Different researchers, different sources, and different cultures, may all result in unanticipated Properties having to be recorded. What is required, therefore, is a scheme that allows custom Properties to be freely defined without some onerous, centralised registration process, and yet still allows those custom Properties to be loaded by any compliant product. This is certainly possible but it is such a widespread requirement – applying to many types, subtypes, and other sets of named values – that I plan to write about it separately.

If you’re still with me then you’re probably about to say ‘this is way too complicated Tony’. Before you finish preparing your response, though, consider these points:

• We cannot assume that a recipient of your data has access to the same online images, and the T&C’s that you’ve checked probably prohibit you from sharing your images. Also, if you’re one of the minority who still visit archives, etc., then the originals may be locked away, and not copiable or online at all. In other words, our transcriptions can be invaluable. Hence, if we take shortcuts with those transcriptions – even for mere Properties – and assume that we know what the author meant without recording things verbatim (or even literatim), or fail to mention crossings-out and other annotation, then we’re diluting that effort and “short changing” some later recipient.
• Do we want our genealogy products to simply record what we type in? If so then we might as well just use a word-processor. Providing more detail, and making it machine-readable, means that our products can work with the data to provide such things as analysis and consistency checking.

I’ll close by providing some links to a couple of worked examples in STEMMA for any code-junkies: Transcription Anomalies and Census Roles. Between them, these deal with many of the cases discussed here, including transcription anomalies, spelling errors, clarifications, and mis-recorded information.

---

[1] If anyone wants to comment that the evidence in any given source is more than a set of discrete values then I entirely agree. There is usually much context and information that cannot be distilled down to simple values. What we’re discussing here is just the digested pieces of information that many genealogists store in their databases, but also acknowledging that this alone is not fully representative.

[2] For historical references to places, the corresponding STEMMA Properties would be associated with Event-to-Place connections.

[3] This issue is covered in excellent detail by Tamura Jones, “FNU LNU MNU UNK”, Modern software Experience, 11 Aug 2013 (http://www.tamurajones.net/FNULNUMNUUNK.xhtml : accessed 22 Nov 2013); Also his previous works: “The Lnu Family Mystery”, Modern software Experience, 11 Aug 2013 (http://www.tamurajones.net/TheLnuFamilyMystery.xhtml : accessed 22 Nov 2013); “Unk is a Real Name”, Modern software Experience, 10 Aug 2013 (http://www.tamurajones.net/UnkIsARealName.xhtml : accessed 22 Nov 2013).

Evidence and Where to Stick It

… so to speak. Do you attach census pages to people in your tree as evidence of a birth date? If so then there is a good chance that you are currently attaching items to the wrong entities in your data. Read about the pitfalls that we all face when associating evidence, why we often do this incorrectly, and what the future holds for us.

If you find one of your ancestors in a census page, do you cite that page as evidence of where they lived, or their date of birth, or their place of birth? It may yield such evidence but then what do you attach the census information to? Many people would add a citation in the details of that person, and also attach any image of the census page directly to that person, but this is demonstrably wrong. Although this sort of evidence can be gleaned from a census record, the actual record wasn’t generated as a proof of any of those items. In effect, you would be confusing the relevance of extracted information (e.g. something about a given person) with the nature of the source itself (i.e. what the record was originally intended for). This may be a subtle point but it has profound implications when modelling the real-life data relationships.

This issue is as much about data organisation as about philosophy so let’s just take a moment to look at some simple practical problems resulting from this common approach.

The chances are that the same census page includes other family members and relatives so do you duplicate this operation for every member? You cannot always attach a scan to some type of family record since the members may be more distant or loosely-connected relatives, or they may even be unrelated until some later marriage.

We’re not just talking about census pages either. Consider a marriage certificate. You might be attaching details (citation or scan) to both the bride and the groom, but what about their fathers? Both of these would be mentioned on many certificates so you might be able to glean evidence of their names and occupations too. Do you also transcribe the marriage date and record it separately in the timeline for each of these individuals? If you had initially misread the date because it was so faint then does that mean you have proliferated the error? There’s always the very real risk, too, that you may have picked the wrong marriage and need to undo those associations.

The same issue applies to a birth certificate since it probably contains the parents’ names (whether married or not) and the father’s occupation. You may be surprised but this issue even applies to photographs. For instance, I have a group photograph of my grandparents and their family that was printed in a Nottingham newspaper in the 1950s. Do I attach that image to every one of those people in my data, together with details on where and when it was taken, plus the newspaper citation, plus the newspaper caption that went with it? Your choice of software makes a big difference in how serious an issue this is to you, but there is a better way.

[…come on, Tony, get to the point…]

OK, I think the astute readers have already guessed where I’m taking this, especially since I have set the stage by writing about the importance of events in recent blog posts[1][2]. The thing is that the vast majority of our evidence – if not all of it – relates to events; things that happened in a particular place at a particular time. The people involved in all of the cases illustrated here are sharing certain events (i.e. a census, a marriage, a birth, and a family group outing). The record (or document, or artefact) details are therefore best associated with the Event entity in the data, and the relevant Person entities linked to the Event with their respective roles.

Multi-Person Events were described in more detail in my previous posts, but where does that leave the information extracted from one of these event-orientated data sources? For instance, if source details are now associated with an Event then how do you associate the items of extracted information (i.e. Properties[3]) with each of the Persons sharing that Event?

This figure illustrates a marriage event using similar symbols to those of my previous posts. We can see that bride and groom are both connected to the Event entity, as well as the pairs’ fathers, and they would each be distinguished by their respective Role[4]. The source details (citation, image, etc.) are associated only with the Event, but the Properties – the items of extracted information that are relevant to each of those Persons – are associated with the individual Event-to-Person connections, not specifically the Persons or the Event. This is important since an Event may have more than one Person connected to it, and each Person will have more than one Event connected to it.

This natural factoring of the data results in less duplication and redundancy, but at no loss of information. What we’re avoiding is dumping the same source details on every associated Person simply because that source yields some evidence about them. When several Persons are sharing the same Event, different Properties may be derived for each of them but the source information as a whole describes the Event.

For any code-junkies, an example of how this is represented in STEMMA^® can be found at Single Source Events, and a further example involving multiple sources for the same event at Multi-Source Events.

Of course, not all software can actually do this since it requires support for shared Events. You’re probably thinking, though, ‘what if I have conflicting Properties such as a date-of-birth?’. We all know that we may get conflicting Properties from different sources, but I haven’t changed that by describing this approach. The final set of conclusion Properties that you associate with each Person will be the result of assessing the aggregated evidence for them – the evidence Properties from each of the Events in their timeline. This has always been the case since no one has multiple dates of birth! All I’ve done is re-factor the sources and the evidence.

So what’s the advantage of this? Well, apart from avoiding unnecessary redundancy, the scheme is modelling the true nature of the data relationships. This is what I meant by the issue being partly philosophical above. Perhaps more important, though, is that your data is then organised according to the natural timeline. If you want to present a timeline, either in a report or on your screen, then it doesn’t have to be forced, and it can accommodate the lives of multiple people when necessary.

Unfortunately, the future looks a little bleak for this. There are many people who do not adopt this approach, either because their software cannot handle it or because it’s not the way that they were taught, and their data will never change. Even if their software improves or changes, and even if some new data standard emerges that better models real-life, then their data cannot be re-factored automatically to become better organised. It’s set in stone.

By far the biggest issue, though, is the use of so-called collaborative online family trees. When these models actually accommodate sources, and when their contributors actually enter them, then they have no choice but to associate them directly with Person entities because that’s all they have. They’re not representing event-based history and so their misplaced sources will be inherited by anyone copying from them. This does not bode well for anyone wanting to adopt an event-based approach to family history, or even micro-history. Genealogy’s preoccupation with mere family trees will continually pollute the waters.

---

[1] See “Eventful Genealogy”, Blogger.com, Parallax View, 3 Nov 2013 (http://parallax-viewpoint.blogspot.com/2013/11/eventful-genealogy.html).

[2] See “Eventful Genealogy - Part II”, Blogger.com, Parallax View, 6 Nov 2013 (http://parallax-viewpoint.blogspot.com/2013/11/eventful-genealogy-part-ii.html).

[3] ‘Properties’ is the terminology adopted by STEMMA for items of extracted and summarised information such as a date-of-birth (see http://parallaxview.co/stemma/home/document-structure/person/properties). I feel strongly that the word ‘facts’ is misleading since the possibility of something being factual depends on the nature of the associated source. I also do not like the software term of ‘PFACT’, which stands for property, fact, attribute, characteristic, or trait.

[4] The Roles might be something like Bride, Groom, Bride.Father, and Groom.Father in this case. I will discuss how extensible roles can easily be accommodated in a future post.