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

STEMMA Latest

 

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 neocities.org. 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 https://parallaxview.co/stemma. The URI http://stemma.parallaxview.co is, as before, reserved for STEMMA namespaces. The legacy URL of http://www.familyhistorydata.parallaxview.co should redirect if still used (once my DNS configurations does what I tell it).

Friday, 22 May 2020

MetaProxy (v3.0)


MetaProxy was introduced at the start of 2019 as a free tool allowing meta-data such as archival descriptions, search terms, provenance, and even transcriptions, to be associated with images and other data files in your genealogical data. This article describes the new features in V3.0 of the Windows edition; these do not apply to the Mac edition.

Although the program has a small following, it is not yet well-known, and is not even considered a "genealogical tool" in some quarters. However, following some recent work to fix reported issues with Windows 'Photo Viewer' and the 'Photos' Store App under Windows 10, it was decided to give those users more control over their layout.

To re-iterate some previous details: the program and a PDF guide can be downloaded from:


The Mac version has its own Dropbox folder, but the associated Facebook support group deals with both editions: https://www.facebook.com/groups/541621946332678/.

So What is New?

A particularly useful feature of MetaProxy turned out to be its collection feature, where double-clicking on a root buddy file would automatically open up a series of image data files and their individual buddy files. The new INI-file setting of Collections=False can be used to turn this off if required (the default is True), but this also allows the use of a different file type for such root buddy files. We'll here talk of *.coll for root buddy files and *.meta for normal buddy files, but the actual file extension may be chosen by the user.

Because of the similarity between the display of a collection and the use of a traditional photo album, a tiled mode has been implemented. This is controlled by two new INI-file parameters: TileH and TileV, which specify, respectively, the number of horizontal and vertical tile positions over the screen area. If both are zero (the default) then tiled mode is disabled, otherwise each will default to 1 if unspecified. This mode employs overlay mode for individual buddy files, and so it overrides any separate SideBySide setting.

If the root buddy file of the collection example in the original article (RisalpurCemetery.meta) is renamed to RisalpurCemetery.coll, then the INI-file might specify a grid of 3x2 for the display as follows:

[metaproxy]
CreateType=.meta

[.coll]
TileV=2
TileH=3

This would then result in a layout similar to the following, where each individual image data file is overlaid with its specific buddy file, and the original root buddy file (if it has no data file of its own) is tiled separately:


But the tiled mode is not just for collections. If a normal buddy file has multiple data files associated with it then they can be tiled in a similar way. For instance, given a buddy file called Test_ID-34.meta2 that's associated with two separate images (a *.jpg and a *.jpeg file) and a Word document (*.doc in this case), then an INI-file setting of:

[metaproxy]
CreateType=.meta

[.meta2]
TileH=3

would result in the following layout:




This shows the Word document and the two images spread across the width of the screen, and the buddy file overlaid on the last of the images. Where people have larger screens than the one used in this example then this becomes a convenient way to see all of the related details.

NB: if you're using the normal overlay mode (SideBySide=False setting) then specifying TileH=1 or TileV=1 will force the image viewer to occupy the full screen area rather than its default size and position.

Microsoft Mechanisms

While developing this tool, it became clear that Microsoft has a variety of ways for launching the viewer for data files (e.g. image viewers), and no central mechanism for finding their main windows. For instance:

1.    Normal process creation for the image viewer (or document viewer). The handle of its top-level window is then determined. Most cases fall into this category, including Microsoft Office Picture Manager, Microsoft Paint, Microsoft Word, and of course the Notepad text editor.

2.    When launching the viewer, the data file is simply handed over to an existing instance of the program, which then creates a new tab for it. Adobe Acrobat and Web browsers are examples of this.

3.    When the viewer is actually a DLL rather than an EXE, it has to be loaded into a special 'container process' called dllhost. Windows 'Photo Viewer' is an example of this. 

4.    When the viewer is one of the cut-down 'Store Apps' available under Windows 10 then it follows a different set of rules, and the normal Windows APIs have limited accessibility to them. 'Photos' (aka 'Microsoft.Photos.exe') is an example of this.

Note that if the data file is shown in the tab of a single-instance viewer (case 2) then the tiled mode mentioned above will not work as intended since the viewer cannot occupy more than one tile location.

Diagnostics

In the event of problems being reported within the Facebook support group, a diagnostic log file can now be generated via the program copy called metaproxy-D.exe (also available from the same Dropbox link).

These log files should be emailed to the author in order to assist in a resolution. There's a 'Contact Form' in the right-hand panel of this blog-post.

Thursday, 30 April 2020

Weight of Evidence


A very short educational piece, this time, on the subject of evidence.

Evidence is very important to genealogists. It is information that supports, or contradicts (as in 'evidence to the contrary'), some specific claim. When we make claims, such as those about parentage, then we need supporting evidence, and we also need to explain any evidence that appears to go against our claims.
But is that everything we need to know? Well, no; not all evidence carries the same weight. In order to illustrate this particular point, I want to introduce you to the 'raven paradox', sometimes known as 'Hempel's paradox' since it was formulated by philosopher Carl Gustav Hempel in the 1940s to illustrate a contradiction between inductive logic and intuition.

Hempel starts this paradox with the proposition 'all ravens are black'. This can be turned about-face to yield the equivalent proposition 'if something is not black then it is not a raven'.  The first of these is quite straightforward, and the sight of a black raven would be evidence supporting that proposition. However, that about-face proposition is less straightforward because the sight of anything other than a raven, and that isn't black, would be evidence for it. Hence, if you were eating a green apple then it's not black and it's not a raven, and so it supports the second proposition. The paradox is that something totally unrelated to ravens, or even to birds of any kind, appears to be evidence for that first proposition: 'all ravens are black'.

So what gives? Surely, the fact that you're eating a green apple, or wearing a red hat, or any number of unrelated observations, cannot really be evidence about the colour of ravens. Philosophers have debated this paradox ever since because that's what they like to do, but the answer is relatively simple. Yes, those observations really are evidence but their weight is so weak that they're effectively insignificant.

In order to understand what's going off, we need to consider the scope of the propositions. In this particular case, where the proposition is about discrete entities (ravens) and properties that are fixed (colour), then you can imagine sets of possibilities, but a more general scheme would involve abstract mathematical spaces of possibilities. Anyway, the spaces of possibilities for black-ravens, non-black-ravens, black-other, and non-black-other are vastly different in extent. Having an observation that supports non-black-other (an astronomically huge space) is insignificant compared to one that directly supports black-ravens, even though the propositions all-ravens-are-black and if-non-black-then-not-a-raven are logically equivalent. In contrast, if we observed just one instance of non-black-ravens (the space for which we've asserted to have zero extent) then it would be hugely significant.

The lesson, here, is that the same claim can be expressed in different, but logically equivalent ways, and this has a huge bearing on the significance of an item of information supporting the claim. The weight, or significance, of some evidence depends on the scope of the claim, and some cases — such as demonstrating beyond reasonable doubt that 'if something is not black then it is not a raven' — would be impractical to pursue. Putting things another way, the concept of 'sufficient evidence' depends on the scope, or the number of possibilities, covered by the claim.