A Grave Too Far

My granduncle died in an area of British India which is now within Pakistan. At the time of writing, the UK Foreign and Commonwealth Office (FCO) were advising against all travel to this area[1], so how much could I find about his death without a visit?

Albert Edward Rowland was my mother’s uncle. I was told by his younger brother, George Rowland (now aged 87), that Albert died in Peshawar, near the eastern end of the Kyber Pass, aged just 23. Peshawar was the capital of what was the North-West Frontier Province (NWFP) of British India. It became part of British India in 1849 following the Second Anglo-Sikh War, and later became the frontier headquarters from 1868. It was always a very troubled region because of its strategic location between South Asia and Central Asia. In 1947, when the British ended their rule in India, this region was incorporated in the newly-created state of Pakistan.

George provided me with a photograph of Albert’s headstone but he had no details of Albert’s death. He recalled Albert had been stationed in Egypt and returned to the family home in Nottingham over Christmas 1933, only to be posted out to India the next day. He believed that Albert was killed during an ambush but he had no evidence for this.

The thing that struck me about Albert’s headstone was the last part of the inscription:

To the memory of L/Cpl Albert Rowland. 14th/20th Hussars who died at Peshawar on 29th April 1934. Aged 23 years. This stone was erected by his comrades.

Many soldiers lost their lives so why would Albert have a headstone erected by his comrades?

Albert was born 2 Mar 1911 in Sneinton, Nottingham, England. He managed to make an appearance in the 1911 census[2] aged just one month. He was then living at 103 Clarence Street with his older brother, Benjamin (my grandfather), and his parents, Albert and Gertrude, who had been married for two years.

The first thing I did was to get a copy of Albert’s death certificate[3]. This confirmed the death occurred at the British Military Hospital, Peshawar, and the cause of death as ‘Cerebral Haemorrhage, result of motor accident’. It also gave his rank as Lance Corporal in the 14^th/20^th [King’s] Hussars[4], and his service number as 551091. Interestingly, the registration of the death was on the same day but in nearby Risalpur rather than Peshawar.

The next item of information to obtain was a copy of Albert’s service record[5]. This was short since he was such a young man when he died. He had been an ‘Electrical Storeman’ when he enlisted on 5 Jan 1931. He was appointed Lance Corporal on 4 Apr 1933, aged just 22, so he was doing very well. In fact, his record was full of glowing phrases such as ‘Clean hard-working’, ‘A good man’, ‘Clean & smart & good worker’, ‘Very promising NCO, gaining confidence’, and ‘Honest, sober, hardworking, intelligent’. His postings were:

Country	From	To	Length of Service
Home	5 Jan 1931	22 Sep 1931	261 days
Egypt	23 Sep 1931	30 Dec 1933	2 years 99 days
India	31 Dec 1933	29 Apr 1934	120 days
(total)			3 years 115 days

Unfortunately, there were no additional details of his death.

I managed to find the following mention of his regiment moving to India in the Times newspaper[6]:

The 14^th/20^th Hussars from the Cairo Cavalry Brigade arrive at Karachi today in the transport Nevasa. The regiment will go by rail to Risalpur, and take up duty in the 1^st Cavalry Brigade on Thursday in relief of the 15^th The King’s Royal Hussars who leave Risalpur on Friday to embark for home.

Searching specifically around the date of his death, I found that the accident was covered in several of the British newspapers. It’s hard to determine which of those reports are derivatives but the following summarises the material in the reports I consulted[7]: On Sunday 29^th April 1934, a disastrous motor accident occurred when a lorry carrying troops collided with a tree on the Grand Trunk Road from Peshawar to Lahore, near a small town called Pabbi. Two soldiers died the same day (L/Cpl Albert Rowland and Farrier Bottomley) and 12 others were injured. L/Cpl W. Newland died the following day. By the Thursday, four were still on the danger list, and five others were still in hospital. All soldiers were in the 14^th/20^th Hussars, stationed at Risalpur near Nowshera.

I wasn’t very familiar with this region so I used Google maps as a guide:

View Larger Map

You can see that the Grand Trunk Road leaves Peshawar from the east and heads towards Nowshera, about 43km away. The town of Pabbi is about 25km outside of Peshawar. Risalpur is about 15km north of Nowshera along the Nowshera-Mardan Road. My guess is that the troops had been off-duty in Peshawar over the weekend, and were returning to their base in Risalpur on the Sunday evening — possibly in the dark — ready for resumption of duty on the Monday. Although the Grand Trunk Road is a fine road nowadays, it would have been little more than a dirt track back then, and a pothole in the dark could easily have caused this accident.

At this point, I didn’t know where Albert was actually buried. This was a concern because some of the cemeteries in that region were in a very bad state, such as the Tehkal Cemetery in Peshawar which had suffered from neglect, desecration and vandalism. A worse example was the British Soldiers' Cemetery, Lower Topa, Murree Hills, where bulldozers were destroying parts of the cemetery and disinterred coffins were lying exposed. I obtained a copy of a published survey of the Peshawar Cemetery by Susan Farrington[8] but this contained no one with the surname Rowland, thus suggesting that he wasn’t buried in Peshawar.

I then looked at the India Office Records collection held by the British Library using their online Family History Search aid[9]. This gave the location of the burial as ‘Risalpur (C of E)’. However, I still couldn’t precisely locate the Christian cemetery in Risalpur.

I then contacted Dr. Rosie Llewellyn-Jones of the British Association for Cemeteries in South Asia (BACSA). This organisation has been recording the locations of cemeteries and monuments — British and other European — and the inscriptions on headstones, since 1977. She suggested I contact the Asia, Pacific and Africa Collections (APAC) department of the British Library who held a BACSA file on Risalpur. Dorian Leveque, of APAC, not only located Albert in a photocopy of the burial register from the Garrison Church (St Mary’s), Risalpur, but sent me a copy too. The Risalpur Cantonment was a military barracks to the left of the Nowshera-Mardan Road when heading north out of Nowshera towards Risalpur. To the right of the road is an associated cemetery, just over the railway line. The Cantonment is still used by the Pakistan Army, and the cemetery is apparently still open (last burial in 1969 according to the photocopied register) and well-maintained.

Near the end of the burial register[10] were the entries for all three of the soldiers who died in that road accident:

Burial	Name	Age	Rank	Cause of Death
29 Apr 1934	Cecil Bottomley	21	Farrier	Motor accident (died out of hospital)
29 Apr 1934	Albert Edward Rowland	23	L/Cpl	Cerebral haemorrhage
30 Apr 1934	William Henry Newland	23	L/Cpl	Fractured skull/cerebral haemorrhage

On passing this information back to Dr Llewellyn-Jones, she put me in touch with Susan Farrington who had surveyed that cemetery in 1982 (see note [8]). She confirmed that when she was last there the headstone was still standing and the inscription was clearly readable. Not only that, she shared a photograph she had taken of the cemetery, and ones of its lychgate before and after it was restored. Prints of these I promptly shared with Albert’s brother, George.

---

[1] “Foreign travel advice: Pakistan”, GOV.UK (https://www.gov.uk/foreign-travel-advice/pakistan : accessed 5 Jan 2014).

[2] "1911 Census for England and Wales", database,  FindMyPast (www.findmypast.org.uk : accessed 7 Jan 2014), household of Albert Rowland (age 26); citing RG 14/20577, RD430, SD3, ED37, SN39; The National Archives of the UK (TNA).

[3] England, death certificate for Albert Edward Rowland, died 29 Apr 1934; citing 1934, p.29, station Peshawar, Indian Subcontinent; army death indices (1881 to 1955), General Register Office (GRO), Southport.

[4] British cavalry regiment created through the merger of the 14th King's Hussars and the 20th Hussars in 1922. The honorific "King's" was added back into the title in 1936 (https://en.wikipedia.org/wiki/14th/20th_King's_Hussars : accessed 7 Jan 2014).

[5] Compiled Army Service record, Albert Edward Rowland, 14th/20th Hussars, service number 551091; photocopy provided by Army Personnel Centre, Historical Disclosures Section, Glasgow.

[6] "Cavalry Change at Risalpur", The Times (Tuesday 9 Jan 1934): p.15.

[7] “Two Soldiers Killed”, Daily Mirror (2 May 1934): p.15. “British Soldiers in India Accident”, Daily Telegraph (1 May 1934): p.?. “Three Soldiers Killed”, Derby Daily Telegraph (1 May 1934): p.1. “Nottingham Man’s Fate in India”, Nottingham Evening Post (1 May 1934): p.8; also contains a picture of Albert; surname misspelled as ‘Roland’. “Births, Marriages and Deaths”, Nottingham Evening Post (2 May 1934): p.3; death notice for ‘ROWLAND – Albert’. “British Hussars Who Were Killed in India Lorry Crash”, Nottingham Evening Post (3 May 1934): p.1. “Telegrams in Brief”, The Times (2 May 1934): p.13.

[8] Susan Maria Farrington, Peshawar Cemetery: North West Frontier Province, Pakistan (British Association for Cemeteries in South Asia (BACSA), 1988).

[9] “India Office Records”, transcribed by British Library, India Office Family History Search (http://indiafamily.bl.uk/UI/AdvanceDiscovery.aspx : accessed 8 Jan 2014), burial entry for Albert Edward Rowland, 30 Apr 1934, reference N/1/557 f.215.

[10] Garrison Church (Risalpur, NWFP, Pakistan), Burial Register (1915-1947); photocopy provided by Asia, Pacific and Africa Collections (APAC), The British Library, London; source of photocopy was a typed document so unclear whether original was typed or whether it was a transcript itself.

Role of the Role

Most people have come across the concept of a Role in the context of a census return. However, they are an essential component of shared (i.e. multi-person) events. How much consideration and flexibility do we give them though? How do Roles differ from Relationships?

Think of a Role in your census data and you will probably think of terms like Head, Wife, Son, Lodger, etc. Although there is a fairly common set of terms that represent relationships, occupations, and circumstances, there is no fixed or standardised set. Enumerators sometimes had to elaborate or invent terms to describe an unusual situation. For instance, in the household of George Binch in the 1911 census of England & Wales[1], the explicit terms ‘Daughter Of Father’, ’Son Of Father’, ‘Son Of Mother’, and ‘Son Of Daughter’ were all used in the ‘Relationship to Head of Family Column’ column.

The intention of this census column was obvious but there were cases where the reason for a person being in the census household weren’t ideally expressed as a relationship relative to its Head; of which there should have been just one. You could argue that a visitor was actually a visitor to the household rather than to the Head. I have also seen cases of “Wife” being implicitly relative to a “Boarder”, and “LodgerHead” as an explicit way of setting a new reference point for subsequent relationships. In effect, that column was overloaded with person-to-person relationships — not all of which were relative to the same person — and event-specific roles.[2]

Enumerators are known to have made mistakes, too, so it’s important to have a way of recording both what we found and our interpretation of it. This topic was covered in more detail in my previous post at Is That a Fact?, and a STEMMA® example that deals with erroneous roles and relationships can be found at Census Roles. That particular worked example involves the household of a Samuel Brady [Bradley][3] where two separate women were given the relationship-to-head of Wife. It is clear that the enumerator was leaving implicit the fact these were relative to different men on that census page; one to the head of the household and one to a boarder. I apologise in advance but I need to present a small amount of code here to show how this situation is handled in STEMMA. The following two lines represent the way the Relationship Property (aka Relationship “fact”) is encoded for the two women:

<Property Name=’Relationship’ Key=’pSamuelBradley’ Value=’Wife’>

    Wife

</Property>

<Property Name=’Relationship’ Key=’pJohnBradley’ Value=’Wife’>

    Wife

</Property>

In other words: ‘(Samuel Bradley).Wife’ and ‘(John Bradley).Wife’, respectively. Notice that they both capture what was recorded (i.e. “Wife” in both cases), and this may also include any uncertain characters or explanatory notes as in the full worked example. They supplement this, though, with a separate field for its interpretation. At first sight, it may appear that this is just expressing a simple relationship between two explicit people, but there’s a little more to it than that.

Before I explain what I mean, let me just expand the scope from census events to general multi-person events, as suggested previously at Eventful Genealogy. One or more Roles are essential to specify the part that each person played in an event. Usually, this means they were physically present and alive during the event, but not always. Examples include: a deceased person during a funeral, or an entry struck-out in a census because they were away, or someone talked about or mentioned during an event. The thing they actually have in common is one or more references to them within the sources supporting that event. The previous example cases would be distinguished by a separate Property called Status which could be ‘Deceased’ or ‘Absent’, in addition to more common cases like ‘Single’ or ‘Widow’.

I mentioned above that the census field may represent different things, such as a relationship (e.g. Son), an occupation (e.g. Servant), or a circumstance (e.g. Boarder). In general, a Role will have a well-defined interpretation for the current event type, whereas a Relationship must be relative to another person. In general, that reference point may be identified by name (e.g. John’s brother) or by a Role, such as Head in the census, or Bride/Groom at a wedding, or Mother during a birth.

Relationships may be applied to each other, too, resulting in a chain of more than two terms. In the George Binch household, cited above, the enumerator’s use of ‘Son Of Daughter’ would actually involve three terms, as follows:

<Property Name=’Relationship’ Key=’pGeorgeBinch’ Value=’Daughter.Son’>

    Son Of Daughter

</Property>

This would be read as ‘(George Binch).Daughter.Son’ since the first value-term applies to the identified person whereas each subsequent value-term apply to the preceding one.

In addition to event Roles, and direct Relationships, this diagram also depicts an indirect Relationship type. The difference is that there is at least one implied person who is missing, and so one Relationship is indirectly related to its preceding one. The example I’ve chosen is a familiar one to genealogists, and corresponds to a newspaper death notice where, say, a grandchild is quoted. In this diagram, the missing person is depicted as a male because the surname of the grandchild, and that of the deceased, may indicate a paternal descent. However, that’s not always the case. If only the given name was quoted then we have no clue as to her immediate lineage. Even knowing the surname, though, it is not the same as recording a value of ‘(Deceased).Son.Daughter’ if the source provides no evidence for the son.

If there are any heroes out there who managed to read through my earlier post, Digital Freedom, on a single cup of coffee then you may be thinking about custom Roles and Relationships. These are essential if we’re using multi-person Event entities to represent arbitrary events in our family histories. In order to illustrate this without using too much code, let me describe a contrived example: A newspaper report of a wedding describes how the neighbour (Alison) of the sister of the best-man (John Smith) fainted during the ceremony (a common occurrence?). Now STEMMA declares its Relationship Properties to be of a data-type it calls EnumList (see Extended Properties), which basically just means that it is a period-separated list of Relationship terms, each of which can be a custom one. For this example, we need custom Relationship name of Neighbour.

<Dataset Name=’Example’  xmlns:r=’http://mydomain.com/relationships’>

    <Event Key=‘eWedding’>

        <SourceLnk Key=’sWedding’>

            <PersonLnk Key=’pJohnSmith’>

                <Property Name=’Name’> John Smith </Property>

                <Property Name=’Role’> BestMan </Property>

            </PersonLnk>

            <PersonLnk>

                <Property Name=’Name’> Alison </Property>

                <Property Name=’Relationship’ Key=’pJohnSmith’>                 Sister.r:Neighbour </Property>

            </PersonLnk>

        </SourceLnk>

    </Event>

Let me try and put this into plain English now. The owner of the domain name mydomain.com has registered a private relationship term called Neighbour. The <SourceLnk> element of the Event is assembling the Property values for the referenced persons from the associated source, together with their properties such as their roles and relationships. John’s role is simple enough (BestMan) but Alison’s relationship to him is a little more complicated. It is effectively (John Smith).Sister.Neighbour, and this is necessary because there was no explicit mention of John’s Sister.

Before you ask, the way these Roles and Relationships are described on your screen, or in your report, would be different from these programmatic terms, e.g. “next-door neighbour” or “neighbor” (US spelling). Also, the “r:” prefix simply tells the software who defined those programmatic terms, and prevents any clashes with someone else’s terms, so no end-user would see them.

Furthermore, this example relies on the fact that John Smith has his own Person entity (pJohnSmith) and so the normalised Relationship Property of Alison can be represented relative to him. In a more analytical phase, it might be the case that none of the subject references have had a final identification with respective subject entities, and that the relationship isn’t ready to be normalised. That is a situation where the Source entity (sWedding) would be used as it allows a profile to be built for each any every referenced subject, and for the relationships to be described in plain language rather than normalised equivalents.

What I’ve presented here is a scheme for describing the relationship of one person to another person, or to the underlying event, using a normalised vocabulary. The vocabulary itself can be easily extended such that the scheme can be used to model any real-life event in our own family history (i.e. no straightjacket). The normalised vocabulary allows a software product to depict those relationships rather than simply showing some piece of text extracted from a supporting source. Although the vocabulary is locale-neutral (since they’re programmatic terms), remember that the majority of non-biological relationships are culturally dependent and so if you’re modelling worldwide event types then this capability is extremely important. As an instance, consider all the parts of the world where the concept of a Godfather has no significance in any of their events.

** Post updated on 22 Nov 2015 to align with the changes in STEMMA V4.0 **

---

[1] "1911 Census for England and Wales”, database, FindMyPast (www.findmypast.org.uk : accessed 18 Dec 2013), household of George Binch (age 49); citing RG 14/20397 RD429, SD2, ED6, SN7; The National Archives of the UK (TNA).

[2] STEMMA V3 adopted these distinct terms, and corresponding Property names, to avoid the confusion and overloading in its previous versions.

[3] "1861 England, Wales & Scotland Census", database, FindMyPast (www.findmypast.org.uk : accessed 18 Dec 2013), household of Samuel Brady [Bradley] (age 30); citing RG 09/2560, folio 23, page 6; TNA.