Saturday, 5 June 2021

When a Place Unlocks a Bit of History

This small post recounts a heart-warming case where knowledge of a place unlocked a bit of family history, and painted events in the lives of my parents and their friends that no document could ever yield.

I have long held that a place is more than just a name, or even just a string of jurisdictional names; it has a history and properties all of its own. I have written many posts that have tried to get this message across — often focusing on the legacy of the GEDCOM model — and have even devised a research data model capable of recording the history, documents, images, name changes, and connections of a place in a fashion analogous to that of persons.

My parents, Stan and Ann, were young when they married: my mother was only 17, and she had me by the age of 18. My father had just completed his two years of National Service when he took a job with Nottingham knitwear manufacturers Harry Prew-Smith Ltd, and it was here that he and my mother first met. They were married towards the end of 1955, but he left that job after less than a year to try and find a better one. He tried working on the railway, first in a shunting yard and followed by a spell in the parcel yards (about seven months in all), after which he tried selling vacuum cleaners and then brushes (about six months in all). He then took a job with Stanton Iron Works but had to give it up after about ten months because of knee problems. He often told me how the heat and heavy manual work there was extremely tough, and how he would come home soaked in sweat, but with not an ounce of fat on him — he weighed less than ten stone when he left. But he then blagged his way into a cooking job, based almost entirely on what he had learned during his National Service. This was certainly not the end of his job-changing but it will suffice to set the scene for this article.

I still remember the St. Ann's district where I lived until the age of five, and where my grandparents continued to live after that. It consisted of Victorian back-to-back terraced houses with little if any amenities: no hot water on tap, no central heating, and no inside toilet. The district had a reputation, but it also had a community — something sadly lost when the slum-clearance programs of the 1970s not simply demolished the houses, and dispersed the residents, but also tore up the streets to lay down different ones. This left people clinging to their memories of that community and any old photographs because there was virtually nothing left that they could point to and identify with.

Facebook groups can be a great comfort to such people, and I was a member of several groups that shared photographs and memories. It was here, in 2018, that I connected with David Marriott, a man who remembered my parents, and my father's family. He even admitted to a romantic "fling" with my father's younger sister, Gill, and that she had a best friend, Christine Broadley, whom she went everywhere with; the pair even dressed the same. He recalled that my father and his younger brother, Ray, were older than him, but my cousin (also a David) was about the same age. There was a youth club — the Sycamore Youth Club, run by an Eric Wheatley — on Lavender Street, and my father and cousin used its basement as a gymnasium since it had the weights and other equipment down there.

He then shared a photograph of himself taken in about 1957; he knew it was in my "mother's living room", but not really where or by whom.


Figure 1, David Marriott, around 1957, displayed with his kind permission.

I took one look at the awful wallpaper behind him and thought 'I know that pattern. I've seen it before somewhere'. So I went through my own photograph collection looking for something similar, and came up with the following:


Figure 2, Ann Proctor, around 1957.

A closer match you could not find: the wallpaper is the same, the seat and cellar door (to the right) are the same, and the lighting is the same. The picture of my mother was taken by my father with a homemade pinhole camera (real ones were very expensive back then), at 9 Manning Grove, Nottingham, and developed by himself. David's picture was not only taken at exactly the same place but probably on the same evening, too.

My grandparents lived at 15 Manning Grove, and 9 Manning Grove was the house of Keith Walker, which my parents rented for about a year. My mother and Keith Walker's wife used to make the tea at the gymnasium.

That was enough to jog David's memory. "Goodness," he said, "I recognised her straight away". He recalled that my father was working night shifts at Stanton Iron Works, and so she was on her own, except for yours truly who was only about one year old. Because she was a bit lonely and scared in someone else's old house, David, Gill, and a few more friends used to go round to keep her company, eat chips (that's "fries" to my American friends) and drink all of her tea. I passed these recollections onto Gill, my cousin David, and my mother (my father having sadly died a few months earlier) and they all wanted to know how the others were doing. My mother said they used to have a great laugh on those late evenings, and it really helped a young mother cope.

That's real history, painted in vivid colours!



Friday, 16 April 2021

What is SVG? Publishing Trees for Free

This question should be of interest to anyone who has considered publishing their family tree on a subscription-free website that requires nothing extra to be installed.

Maybe you haven't thought about this in any great depth, but the website or desktop product that you currently use to maintain your tree is going to be inappropriate for some of your family and friends. Assuming that you do want to share with them, they will simply want to link to some web page, without paying for anything or having to install anything, and see a presentation edition of your tree, your family history, your images, etc. They won't want to see any buttons or options for maintaining that information.

This was the situation with all but two of my extended family wanting to see my own research (those two also happened to be genealogists), and so I decided to develop some software with this goal in mind. I also had a goal of drawing trees that could be included into my blog-posts so I came up with a tool that satisfied both requirements: SVG Family-Tree Generator (SVG-FTG). But what is this SVG?

SVG stands for Scalable Vector Graphics. It is a language for defining graphical shapes in your browser, and handling user interaction with them. It is quite different to normal image formats as it scales indefinitely without going fuzzy when you zoom in. SVG-FTG converts your family tree, including biographical notes and images, into an HTML document that employs SVG to produce the graphical parts of your tree, CSS to style the presentation, and JavaScript to handle user interaction.

Figure 1, a common example of what SVG can create.

I will try not to get too technical, but I do need to make some clear and careful points as SVG often gets "bad press" for inappropriate reasons. SVG is like a sister technology to HTML: HTML is good at presenting text, forms, menus, images, and frames around such content. It's ubiquitous so I don't need to describe its full capabilities; SVG is good at drawing shapes and lines, and including text or images within those shapes.

Superficially, their structure looks the same with their elements defined by opening and closing tags, each in angle brackets. For instance, this small HTML extract presents a level-1 heading with a paragraph of text following it:

<h1>This is a title</h1>

<p>This is a paragraph

of text</p>

The following SVG extract draws a rectangle with a circle inside it:

<rect x="100" y="100" width="200" height="200" fill="yellow" stroke="black" stroke-width="3"></rect>

<circle cx="200" cy="200" r="90" fill="orange" stroke="navy" stroke-width="10"></circle>

SVG is technically a separate XML-based language, which means that its syntax follows slightly different rules to HTML, but that difference is not relevant here. It does mean, though, that it can be placed in specific files of its own — usually named *.svg — and they can be treated like normal image files, but more on this in a moment.

When the SVG is embedded within an HTML document then it is referred to as "inline SVG", and this is what SVG-FTG generates in order to produce a graphical user interface (UI). Together, these two contributions to the UI — HTML elements and SVG elements — can produce a very sophisticated presentation. They also share the event mechanism, which basically means that the way they respond to user clicks and button presses is the same, and that means that they collaborate to implement an application: a tool delivering useful functionality to the end-user.

Figure 2, Example of application generated by SVG-FTG.

So, in this guise, there is nothing sinister or risky with SVG; it is simply another contribution to the UI. It uses JavaScript and CSS in the same way as most HTML pages do.

But the other scenario — that of separate SVG files — is subtly different. They're really document files rather than image files and so can also contain JavaScript and CSS. The problem comes if they are naively treated as image files because they can harbour malicious content. For instance, if they are deployed as a CSS background image, or a logo on some website, or in some image gallery then such content could be activated. At the very least, this could lock-up your browser (the so-called 'Billion Laughs' attack), but could also lead to 'HTML Injection' and 'Cross-Site Scripting' attacks.

This means that many sites capable of loading images are very careful to either disable such SVG image files or sanitise them by removing any script. Unfortunately, this protective action can spill over into a complete rejection of SVG because the two scenarios that we've mentioned have not been sufficiently well defined and distinguished.

One example of this involves — not which is the self-hosted and unrestricted variant. It is well known that you have to jump through hoops to get any <script> or <style> elements into your page, as well as certain special ones such as <embed> and <object>; but it also seemed to strip out inline <svg> elements for no apparent reason. Note that the <svg> element is not mentioned at all on their page: (at the time of writing), leaving its viability in some doubt.

There are various plug-ins that may be used with but all of the ones that I am aware of relate to the loading or sanitising of "SVG files", which we explained is not our situation.

When pressed on this point, and given the specific example of the TimelineExample.html mentioned in the SVG-FTG guides, their support provided the following details.

Users would most likely need to upload the above mentioned HTML file through SFTP and not including it between the custom code widget/block. They’d also need to be upgraded to at least the Business plan to be able to do that. [13 Apr 2021]

When specifically asked about support for the <svg> tag, the following response was given:

By default SVGs are something that’s not allowed/supported by WordPress, so I guess they’d need to install a third-party plugin that allows them to be able to work with and include SVGs... [13 Apr 2021]

The term "SVGs", used here, would appear to mean "SVG files", which I went to great pains to eliminate as not relevant to my question. It does seem as though they are fixated on "SVG image files" and have little concept of its usage to provide a graphical UI for an application.

However, after escalating this issue, demonstrated to me that it is actually possible to host these SVG-FTG applications on their site under the Business Plan, and that the process is not too different from the one. In their words: “It is also a simple process of copy and pasting. Although, I added all the CSS and JS to the head of the site as on your example URL and only loaded the content in the body via the Custom HTML block”. Hence, although neither of these Wordpress scenarios is actually free, it is possible to host SVG-FTG applications on them both. It’s just a shame that “inline SVG” is so poorly understood and catered for, generally.


Friday, 26 March 2021

SVG Family-Tree Generator (v6.0)


The word is catching on about this free tool (SVG-FTG, for short), whether for publishing family trees on your website or blog, or simply for providing an interactive visualisation for the benefit of you and your family. As a result of this, some considerable effort has been made to produce a much-enhanced V6.0.


In fact, during its time of steady incremental growth, this is by far the biggest set of changes as they are greater than all the previous changes combined.

So what's new in V6.0? Well, there are three main areas of change:

  • Applications and Services: Packaged interactive applications and services that can be selected from a simple menu. No more coding.
  • Viewpoints: The ability to view and maintain different parts of a large tree separately.
  • GEDCOM Export: SVG-FTG already supported import from GEDCOM files, but it now supports export to GEDCOM files, too.

What is SVG-FTG?

SVG-FTG generates Scalable Vector Graphics (SVG), in combination with HTML, CSS and Javascript, to display interactive family trees in your website or blog. Unlike normal images, SVG is a format that does not go all fuzzy when you zoom in. There are several packaged applications that can be run from your tree, and an open framework to develop your own. It supports complete control over layout, thumbnail images, hover text, HTML biographical or historical notes, scrolling/zooming of individual trees, GEDCOM, timeline reports, and linked trees. The designer is Windows-based but the output is neutral and runs in all modern browsers. Note that the output is non-proprietary, royalty-free and needs nothing to be installed first; it is therefore ideal for sharing with friends and family.

Where is SVG-FTG?

There have been several previous posts about SVG-FTG: Interactive Trees in Blogs Using SVG, More on SVG Family Trees, and SVG Family-Tree Generator (v5.0).

The distribution kit, in Dropbox, includes installation files, documentation, and sample files. The Facebook Group includes access to instructional videos and tips on how best to achieve things. All of the previous instructional videos in the Facebook Group have been replaced by eleven new ones for V6.0, covering both standard features and new ones such as applications and viewpoints. Although these will still be accessible from that Group, they are now hosted on YouTube (channel since Facebook's video support seems irretrievably broken at present.


The general presentation quality has been improved again, particularly under high magnification (i.e. when zooming in to a high degree). For example, there is now no visible overlap where lines join. The colours have been standardised to remove previous differences between SVG-only and mixed HTML/SVG modes.

A number of presentational enhancements are placed under the control of the end-user:

  • It is possible to nominate a background image upon which your tree will be drawn, including its opacity and whether it is repeated across the available height and width. The image at the head of this article shows an example.
  • Improved choice between scrolling and scaling of large trees. In other words, whether you want to see everything at once and zoom in to see the detail, or to see a part of the tree at normal magnification and pan around to see the rest.
  • Person-boxes can now be opaque or translucent, without changing the visible colour. This will be a consideration if you have a background image, or if you are using "fanned" lines rather than the normal horizontal/vertical ones.
  • You can nominate stock images, according to sex (e.g. head-and-shoulders silhouettes), to display in the absence of thumbnail images for persons.
  • You can add custom CSS class names to person-boxes, family-circles, lines, and notes panels, either for application purposes or to change their presentation.
  • Default size of person-box buttons has been raised from 10x10 to 12x12 pixels, but this may be changed via the settings form.
  • There are now fields in the settings form to change the size of person-boxes and their separation.
  • SVG-FTG never worked properly before with Internet Explorer (IE) 11 because it is such a non-standard browser; but this has now changed.

The following image shows a partial tree demonstrating the possibility of bigger buttons (in both default and icon modes) and the use of stock images for person-boxes having no thumbnail image. It also demonstrates the use of opaque person-boxes in conjunction with "fanned" lines.


Applications and Services

One of the main goals of SVG-FTG was to produce interactive trees — not just static images. That means being able to utilise a tree as the user interface (UI) to different applications and services, or in other words to make a tree do things for you. Previous versions already offered some examples in the form of 'Timeline Reports' and pop-up 'Information Panels', but they sometimes required editing of the code.

This is arguably one of the biggest changes to SVG-FTG as those previous applications, and several new ones, have now been packaged up. This means that their definitions and configurations have been placed in a separate registration file, and the end-user just selects the required ones from a simple menu; there is no longer any requirement to see or change code as it's now generated for you, based on your selections.

If you require applications to be configured differently (e.g. change the mouse-click operations, change the button allocations, or even to add new buttons) then it can be done with a small adjunct to the standard registration file; you don't have to edit the distributed standard one.

Additional applications (i.e. in addition to the existing Information Panels and Time Reports) include:

Expand Notes

If you are working in SVG-only mode, or you have lengthy biographical notes, possibly with multiple images, then the existing Information Panels may be insufficient. This application allows them to be displayed in a separate browser tab instead. For instance:

Notes for family of Henry Proctor and Elizabeth Turton


Married 2 Oct 1858 at Nottingham St Nicholas.

Find Persons

With a large tree, it can be hard to find specific persons. This application provides a floating (i.e. movable) search box that allows you to filter a list of the available person captions until you can see the one(s) that you want. You can then select from the list which will cause them to become highlighted.

As you type a partial caption name into the search box, the list of possibilities is filtered. You can select multiple captions, and the borders of the selected ones are highlighted as shown above. As well as highlighting a relevant person-box, a selection also ensures that it is visible by automatically scrolling the tree as necessary.

The 'Clear' button removes those highlights, and the 'Hide' button collapses the search box until you need it again.

Ancestor Links

This application is similar to the standard RootKey feature provided by SVG-FTG, except that it is dynamic. Clicking on the button (a tree icon by default) for any person will show their maternal and paternal ancestral paths, all the way to the top of your tree. For instance:

Alternatively, performing a shift+click operation on the button will just highlight the relevant person-boxes of the ancestors, as in the Find Persons application, above. An alt+click operation will show both modes together. A control+click operation on the button clears the current highlighting.

The application collaborates with the older RootKey feature to provide a "start-up person" in your tree. Such a person is highlighted and scrolled into view.


This application uses pairs of titles and URL data links held in the "program data" tab of persons (and families). Clicking on the button (a document icon by default) will present a list of any such references in a floating dialog, and clicking on any of the entries will show their contents in a new browser tab.

These references may be to articles, blog-posts, documents (e.g. PDF), images, or anything with the URL link.


A shift+click on that button will highlight all persons or families that have at least one data link in common with the clicked one, implying that they share references in the same article or appear in the same image. An alt+click on the button will highlight all persons (and families) having any such references available. A control+click on the button will clear any current highlights on all elements.

Linked Trees

This application allows you to link together separate trees such that clicking on a person-box button will take you to some associated person in a target tree, or present you with a menu if there are several to choose between. The application is general-purpose, but it is also employed by the Tree Viewpoints, described below.

Application Development

The packaging framework for interactive applications and services is open, meaning that it is documented and it can be added to, allowing custom applications to be shared with other users. If you are a developer, or a "power user", then you can write your own applications and register them for selection by end-users using the same mechanism provided for registering and configuring the predefined ones.

There are many new features for helping such development, including several libraries of code for accessing 'navigation data' (data about persons or families, and their relationships), 'notes data' (i.e. biographical notes, images, links), and 'program data' (application-defined data). Services, as distinct from applications, include reusable UI elements, such as a message-box dialog for reporting errors or asking questions, and a menu dialog for making a choice from several alternatives.

Tree Viewpoints

A disadvantage of presenting all your persons and families at the same time is that (a) it rapidly becomes unreadable, (b) the lines become messy because they usually have to cross over each other, and (c) it consumes more memory. Most products avoid these issues by keeping all the persons and families in a database, and only showing you a selected group at once, which inevitably means that you no longer have any control over their layout.

A viewpoint is a view onto a sub-tree of your loaded persons and families. What this means is that although the full tree will still show every person and family that you have defined, a viewpoint can be used to focus on just a few of them. You can have many viewpoints defined, and persons or families may appear in multiple viewpoints if required.

When a viewpoint is loaded into the Tree Designer, things operate virtually the same as when a full tree is loaded, except that there is less clutter and complexity. A typical usage of viewpoints is to break down a large tree by surname or by family groups.

It is very easy to flip between your viewpoints in the Tree Designer, or to find a person among multiple viewpoints. A Viewpoint Manager is provided to help with creating, deleting, and modifying viewpoints, but also to manage the allocation of persons and family groups to at least one viewpoint. A typical goal is to view your final family tree as a set of sub-trees, each in a separate browser page, and all connected by hyperlinks. In order to achieve this, the Viewpoint Manager helps you manage the dividing-up of the full tree, and ensuring that no person has "fallen through the cracks".

When the HTML (or SVG) code is generated for your browser, by the 'View' button, then it utilises the Linked Trees application. This general-purpose application allows users to link their trees according to different person roles, but the viewpoint feature also uses it to link the viewpoints according to persons in common between them.

The following illustration of clicking on a button in a person-box and selecting an option to go to another viewpoint in a second tab is based on a sample distributed with SVG-FTG.

An important feature of the Linked Trees application is that it names the tabs, which allows it to maintain a finite set of them. If a target tree is already loaded then control is transferred there rather than loading it yet again. Having parallel access to these "tabbed trees" is very powerful given that they can each run their own applications.


Previous versions already allowed the importing of GEDCOM data, but it is now possible to export your current tree in GEDCOM format. It should be noted that the tree definition format, as used by SVG-FTG, and GEDCOM serve quite distinct purposes, and so totally lossless round-trips (e.g. when importing a GEDCOM file and re-exporting it) is not guaranteed.

As well as exporting all the person and family details (including their notes) that you have loaded in SVG-FTG, this operation also saves your place-key mappings, your tree layout (i.e. person-box coordinates), and any local settings on your persons and families. It saves a copy of the remote (URL) version of any image references that employ place-keys (i.e. the mechanism used to access both local and remote resources in parallel). It does not save any details from the 'Program data' tabs or any of your viewpoint definitions.

The existing GEDCOM import has also been enhanced in the area of personal names, particularly where a person has multiple names, or they have been stored in itemised format rather than as a single string. The import operation also acknowledges any adopted or fostered status of children in a family.


The standard settings form has been split into one for core settings (as used by everyone) and one for advanced settings (as used more by developers or "power users"). The first of these is very similar to the form used in previous versions, except for a few new options and control over any stock images to be displayed in the absence of thumbnail images. The advanced-settings form contains options relevant to the size and position of person-boxes, button configuration, code generation, and nominating a background image.

Media Enhancements

Users may have experienced problems with record terminators when moving files between Microsoft and Apple systems, or even when loading GEDCOM files exported by certain systems. SVG-FTG now endeavours to identify which terminators are being used, and then honour appropriately. This even includes the non-standard CR-CR-LF that often results when a file generated on one system is processed on a different one.

Through a limitation of a code library being used by SVG-FTG, it was not possible to specify PNG images in the Tree Designer, although all image formats are accepted in the output files by the browser. This has now been fixed by adding custom code to specifically support PNG. The change should be seamless so that you can select either PNG, JPG, or the other formats, in the same way.


The edit-person form can now capture multiple personal names, as distinct from the long and short person-box captions. This is particularly important if you intend to interface to other systems, such as through GEDCOM export.

The editing of HTML notes for persons or families has been enhanced so that it automatically finds the corresponding start and end tags, and offers forms for editing selected elements. Those forms will preserve any attributes that it does not yet support.

When creating either a person or a family, a default key name is automatically generated. This can, of course, be modified if you don't like it, but it is designed to help make the process quicker.

Previous versions of SVG-FTG offered three sex options: male, female, and unknown/unspecified. This is now supplemented by a further indeterminate/other option.

The 'Find Person' menu option in Tree Designer now scrolls a selected person-box into view if it is not currently visible. It will also find a person across any viewpoints that you may have defined. The option can now be accessed using a Ctrl+F shortcut in addition to the normal menu option.

SVG-FTG relies on a number of external resources for the output HTML/SVG to work, and this includes JavaScript files, CSS files, and icons. Although these were held in a folder on a site, all references now use a custom domain in order to obscure and decouple that connection (i.e.

Saturday, 2 January 2021

Putting the Record Straight

We would all like to be remembered fondly by our descendants, and many of us already pass on tales and stories, either using a blog or in the oral tradition (e.g. over a family meal). Personally, I would hope that the future depiction of me is more than a mere box on a family tree with names and dates, but I'm sure there will be sources to help future researchers in that endeavour, including the usual newspaper archives but also social media.

What happens, though, when you know that the newspaper record will be inaccurate, and that your family may be misled? I raised this question several years ago, but without hinting at the reasons for asking. Rather unusually, this article is designed to fully detail specific events from 1991 while they remain within the living memory of the people involved, and so provide an alternative source.

February 1991 was very cold, and this particular day (around St. Valentine's Day) was not only icy but foggy; there was a pea-soup fog that meant you could barely see 20 feet ahead. I had driven with my girlfriend of the time, Dorothy — now my wife — to a local beauty spot called Alton Water to exercise my two border collie dogs. Alton Water is a large man-made reservoir, about 8 miles in circumference, that plays host to walkers and water sports, and I knew a back way in where I could let the dogs have a run around. Walking from the car to the water — which we still couldn't see — we heard someone calling for help in the fog. As we got closer, we realised that a man and his dog had both fallen through the thick ice on the reservoir, about 20 yards out.

The man's name was Ken Bloom, and he had tried to rescue his dog (Penny) after it ran out and fell through the ice. This was pre-mobile phones, and I knew there were no buildings close to this back entrance, even though we couldn't see much at all. If there were any lifebuoys then we couldn't see them either. This was one of those life-changing situations where you find yourself having to make a really difficult decision without daring to think it through. I decided to slowly walk out to him, all the time watching for bits of ice that looked thin and listening to it creak underneath me. I was very scared! When I got to him, I laid down flat on the ice to spread my weight and extended a hand to him. I hadn't considered how much distress he was in, though, and he yanked at my hand. He was heavier than me so I slid straight towards him and ended up in the same hole.

Things began to happen very fast from then on. We were both trying to tread water and some distant walkers could hear the cries for help but couldn't locate us. It's not possible to tread water in open wellington boots as they pull you under as you try to kick, so I had to push them off. I had been under the water a few times by now and I recall that the emerald green weed looked surreal under the diffuse light coming through the ice. But each time, I was jerked back to the reality of the situation, as though an internal voice was shouting at me: "Get out! Focus and get out!"

Few people will realise just how difficult it is to get out of a hole in the ice. As soon as you put weight on the edge, it tips towards you and you slide straight back in the hole. No wonder so many people drown under these conditions. I really thought I was going to die there, and that Dorothy was going to watch me drown from the shoreline. I had warned her to stay off the ice, but morbid thoughts were creeping into my head: am I going to go under without fuss and fanfare, or in a mad panic screaming for help? Luckily, those internal voices kept bringing me back to the here-and-now.

Ken was struggling as he was losing the use of one arm, and one side of his body was numb. The skin on my knuckles was becoming stiff and inelastic such that the skin was splitting when I bent my fingers. For some unknown reason, I had neglected to cut my nails, and so I was trying to dig them into some small cracks I had noticed in the ice. By pulling very slowly, I was making progress, but it was a helpful shove from Ken that finally made it possible. I was then back on the ice and lying on my belly.

What would you do then? I could have scrambled back to the shore and tried to find help, or I could have turned around to help my new-found friend. I did the latter! In fact, I remember thinking about the way ABS brakes work, and the difference between static and dynamic friction (I had been a physics student). I grabbed Ken's hand and told him to pull very slowly. If I started to slide then all grip between me and the ice would disappear (dynamic friction being less than static) and he would have to let go quickly, but to trust me. This was frightening because as the ice began to take Ken's weight, it started to dip and I could feel the grip starting to disappear. The last thing we both wanted to be back where we started. It took three or four attempts, but (surprising) we did it! We were both out of the water but still on the ice.

I wanted to turn my attention to his dog, who was still treading water a little further out, but the ice was very broken in that area. I wanted to help, but I knew that I would have to get back into the water, and that I had nothing left in me. Having to look away from the dog was something that will forever haunt me.

About that time, the fire service turned up and they put ladders on the ice to come out to us both and bring us back to the shore. They managed to get to the dog, but it was too late by then.

Ken was taken away in the ambulance, but I was taken to the shower facility at the reservoir and allowed to thaw myself out as I hadn't been in the water as long as him. Although not the stuff of nightmares, the events left me with disturbing dreams in which the outcome turned out differently. I revisited the reservoir the following day to avoid becoming afraid of the place, but Ken and his wife, Kate, admit that they've never returned there since.

 Ken Bloom, taken during the 1990s.[1]

There was a small report in the local paper the following day, but my name could not mentioned as no one had bothered to take it. A close friend of mine, who worked at the newspaper, persuaded me to own up and to be interviewed, which I did, but virtually none of it appeared in the follow-up report because it didn't fit with the prior report. Unfortunately, this left the impression that the fire service pulled us both from the water, and that we were both foolish for having been near the ice at all. I didn't want to argue with this as the fire service handle events such as this on a regular basis, and have saved many lives, but I still wanted our descendants to know what really happened.

Myself, taken in the foyer of the newspaper.[2]

Some days later, Ken and Kate, bought me a replacement pair of wellington boots, and a replacement watch. The watch was a Longines "Presence": a thin classic-style men's watch that was perfect for me, but there was no way that they could have known this — it was just a wonderful coincidence, and I still wear it to this day. But the coincidences didn't stop there.

The following Christmas, I was shopping for presents in Ipswich when I started to think about him. I wanted to send him a card, and wondered if his sense of humour would appreciate a skating scene — a touch of humour can often tame the worst of memories. Having suddenly stopped in my tracks, I crossed the street to buy a card and bumped straight into him on the other side. This was one of the spookiest things ever to happen to me. The street was quite broad at that point, and I had no idea that he was directly opposite me, talking to someone else.

We have exchanged Christmas cards every year since, sometimes with skating scenes on them. I met them both face-to-face in about 2008/2009 and spent an evening recounting the events over a great meal. It'll be the 30th anniversary this February (2021) and so I felt compelled to document that day in the knowledge that it cannot now change, and that it was what it was.

[1] Displayed with permission of the family.

[2] Picture taken 18 Feb 1991 in the foyer of the East Anglian Daily Times, and appearing in the Tuesday 19 Feb edition. Photo credit Archant Suffolk. Displayed with kind permission of Archant Suffolk Newsprints.

Thursday, 17 December 2020



If you are involved in the software representation of family history then you might justifiably ask what happened to STEMMA.

STEMMA is a private project to look at the digital representation of micro-history, including but not limited to family history. Work on it commenced in 2011, and the first specification appeared online in 2012. Primary goals were a distancing from the ubiquitous "build your family tree" notion of genealogy, avoidance of the use of trees as "wardrobes of hangers" upon which all and sundry can be placed, and a stemming the software trend of digesting everything to name-value pairs (usually described as "facts").

Its significance in relation to recent work by both FHISO and FamilySearch is low because it still treads a quite different path. It is not interested only in people, or in biological lineage, and its wider choice of historical subjects (including places, groups, and animals) has allowed software to leverage their similarities and orthogonality, such as hierarchical relationships and the handling of multiple names.

STEMMA does not use a database, which means that it is its own import/export format, and so is better-suited to long-term data storage because it does not require a separate backup format. More than this, though, a STEMMA file can be considered a "non-sequential document". Opening a STEMMA attachment will begin with a prescribed landing page, but the choice of where to navigate to from that page is a decision to be made by the reader. There is no sequential or hierarchical ordering of any pages, but there are many internal semantic links that can be followed based on some conscious rationale, and these might uncover lineage relationships (including trees), images, places, maps, or even narrative — all of which are integral parts of the data.

It is shocking that so few products accommodate narrative text, either for documenting the research process, authored works, story telling, memories, documenting biographical details, or for the transcription of old documents; and I do not know whether to laugh or cry when I hear software people still talking about programmatically generating text to lace together their recorded "facts". Software does not "understand" your research process, and should merely help you with its organisation and analysis. Human beings do not understand computer-speak and should not be presented with whatever it is that software people think is so convenient for their endeavours. Text is here to stay, and it should be an essential component of your data!

The latest public version of STEMMA is still V4.1, although a number of small changes in specification and direction have occurred internally. Little work has taken place on the informational sub-model that was to support a dynamic research process (see Our Days of Future Passed — Part I, and its follow-up parts II and III), but a spin-off of the associated experimentation was the SVG Family-Tree Generator (SVG-FTG) that is now a separate product, and soon to get a major upgrade. Work has focused, instead, on the conclusional sub-model, and one of the changes involves place hierarchies.

STEMMA recognises that places are not the same as point locations that can be given specific coordinates. Even if such a point is relaxed to be a closed polygon (say for describing the boundary of a town or village) or an open polygon (say for mapping a street, noting that European streets are rarely straight), then a place still has an identity that is independent of its location or its name(s). Boundaries and names may change over time, but a place is still a place. Originally, it was hoped that each place would have a unique parent place that was appropriate to the nature of the hierarchy. For instance, that an administrative place would have an administrative parent, or an ecclesiastical place would have an ecclesiastical parent, but the reality is too messy. The difference between geographical and administrative relationships can be vague, especially when including local administration in additional to national administration. As a result, each place is now deemed to have a single (but time-dependent) canonical parent, but the hierarchy is no longer of a specific type (i.e. it may vary depending upon the level in the hierarchy). The scheme still makes use of related entity linkages to connect items across hierarchies, such as registration districts (for civil registration of births) to ecclesiastical parishes (for baptisms), but the whole field remains challenging.

The only other project that I am aware of that is treading a similar path is the History Research Environment (HRE) that began in 2016. This has an incorporated not-for-profit UK company, History Research Environment Ltd, although work seems to be centred more in Australia. It comprises an open-source project to "create a free platform-independent application for the serious amateur or professional historical researcher", and was still under development at the time of writing. The main similarity with STEMMA is in the focus towards general history, and their tagline is "Towards a history of almost anything". It will be very interesting to see if they can muster commercial success in a field that might be considered specialist, and which high-profile genealogical advertising blatantly ignores.

The STEMMA project now has to share my efforts with the SVG-FTG (and other tools such as MetaProxy) as well as the publishing of my first book — not genealogy, but more on that another time.

The website for STEMMA has recently been moved from Google Sites to This was necessary because the old Google Sites (which was always a little clunky) is being replaced with a new one, and users have been given an ultimatum to convert, but the conversion tools are wholly inadequate for porting my old site across, despite the content being primarily textual. Google have also made a policy decision to provide no HTML editor and no way of importing the HTML of any pre-existing site. Good luck with that! It sounds like it could be another project ready to flounder.

So, the new link for the website is The URI is, as before, reserved for STEMMA namespaces. The legacy URL of should redirect if still used (once my DNS configurations does what I tell it).