Many people have written about the ills of online family trees,
including me, but that won't stop me writing about them again. Yes, they're
full of errors — more than some people want to admit — but is there an answer?
Is there a future for them?
I first want to summarise some of those problems, and then
suggest that the current situation is not sustainable. Much damage has already
been done to the collective knowledge of our family histories, but also to the reputation
of genealogy itself. If online trees are wrong then those errors will propagate
through simplified collaboration, they will tarnish the interpretation of DNA
data, and they will stymie any attempt to use AI technology
to suggest further connections.
One basic problem is that users are encouraged to create
their trees directly from raw digitised resources, including transcripts, held
by the online provider. Although it is possible to include data from external
sources, there is some debate about whether all providers acknowledge them when
grading their trees. So what's the problem here? Is there any other way to
create a tree?
Well, yes and no! A tree very rarely captures any of the
logic employed when its relationships were determined, or of the histories of
the individuals in the tree — usually prerequisite knowledge for solving the
hard identity and relationship problems. Yes, they may include citations or
electronic bookmarks to show where information came from, but that isn't the
same as explaining why the information is correct or relevant. Also, they are incapable
of supporting complex conclusions that have correlated information from
multiple sources.
This sets the stage for errors that are unchecked, and when
coupled with the ability to easily copy data from one tree to another then it
means that the errors will proliferate. Not only that, the source of an error,
whether known or not, will likely be permanent, even if the author abandoned
their tree.
I came upon such a case just the day before writing this
article. I don't want to pick on this specific person but it typified a very
real problem with online trees. I had contacted this person because their tree
appeared to offer solutions to a deep problem that I was collaborating on with
another person. On looking at the tree, I could see that the conclusions were
very wrong (e.g. conflating two given names to create a name found nowhere in
the evidence, simply to tie-off an apparent anomalous reference), but there
were no sources given. On approaching the owner they admitted that they had received
a gift of membership to this provider, during the period of which they copied
data from a cousin's tree, and that they were no longer a fully-paid member. So
even though they no longer dabbled with genealogy, their naive tree would
outlive their membership and be used by other beginners, ad infinitum. Ideally, the industry should be generating something
of historical value, but all we have is a cauldron of ills and woes.
Such cases are compounded by the fact that no provider I
know of offers a mechanism to flag a tree, or part thereof, as tentative,
under-construction, or otherwise work-in-progress. This would be useful for
experienced researchers as well as beginners, and could go some way to stopping
the proliferation of erroneous conclusions.
A more complete solution would be to make room for research
narrative — not just pieces of plain text stuffed into the records for specific
persons or families — and I have proposed this several times before, e.g. Feeding
the Trees. The problem here is that there isn't much inclination amongst providers
to do this, possibly because they don't want to be first, or rich-text
(formatted with images, tables, citations, etc.) is somehow harder to handle,
or simply that they don't see the need when everyone has a word processor.
All is not lost, though, because there are genealogists out
there who write-up their research and make it publicly accessible, usually via
a blog. You must be able to see where I'm taking this, now. If there was a way
to reference such research in an online tree then it would relieve the
more-casual user of the burden of the heavy lifting. In effect, rather than
reference raw digitised records directly, and with no logic explained, they
could reference work contributed by others — work that explained how
conclusions were reached as well as citing the relevant sources.
Well, I have proposed this before, too: Blogs
as Genealogical Sources suggested that published research (especially in
blogs) could be indexed as external sources by providers. Also, that the
indexing of an article URL would be done with the author's permission, and with
no bulk text being copied or indexed by the provider — actions that would
violate copyright and divert traffic away from that author's article. This
win-win scenario wouldn't require a large investment by the provider, and so it
was strange that only one showed any interest and asked me for more details.
Such work can already be found by researchers, but only via general-purpose
search engines such as Google. How much more convenient if genealogy subscribers
saw them as another source group and were allowed to perform genealogical searches
that included them.
I had heard rumours of a past RootsTech announcement by Findmypast
of an initiative called "verified
reference trees" but I could find no official mention of it. It
sounded good but would probably be impractical — who could produce them? How
many would you be likely to generate? How much of a given pedigree could one
contributor realistically cover?
What I'm saying here is that online trees need a rethink if
they are to have a future. Simply putting more and more digitised resources at
their disposal is not bad, but there are fundamental problems that need to
be addressed, ones that will ultimately come back to bite those providers who
are ignoring the future.
Will we still be working on the same trees in 20 years time,
and in the same way? Some pundits have suggested that our family histories will
have all been resolved by then through collaborative unified trees. ROTFLMAO! There
are already more inaccurate conclusions online than accurate ones, and it is
not easy to tell which are which — citations alone do not cut it! Some other
pundits have suggested DNA testing will solve everything. ROTF again! Even
limiting yourself to biological lineage, and ignoring much family history,
there are cases for which DNA can never help. For instance, read my conclusion
at Jesson
Lesson.
There are two very broad categories of user that providers
need to consider: those who are experienced and likely to do a lot of the research
leg-work, sharing their research details with others; and those who want to
play with online tools to create a simple tree of their own. Although the
latter category may be able to contribute valuable knowledge and lore from
recent generations, most would struggle to reconstruct older generations from
raw information alone for the simple fact that it's hard.
So whose work should they use? Well, trees don't need to be
officially "verified". Works of written research can be read by any user who can then judge for themselves on the depth of the research
and of the soundness of the conclusions. I'm not suggesting that these users
can't use raw information, only that published research will give them more
rungs on the ladder; bigger pieces of the jigsaw to assemble.
Another RootsTech announcement that I recall was that of
employing AI to find new connections in the data. This is worth a paragraph of
its own before leaving this subject because AI is akin to black magic for many people. Applying AI to raw information is a recipe
for disaster because, as any researcher knows, it can never be taken at face
value. AI would simply be correlating information from many record groups and
attempting naive identity resolution and family reconstruction. It would know
nothing of real-life situations and the reasons that records may have lied or that
families had moved, or of real human relationships and the reasons they may
have been forged or broken. The naivety of such algorithms would ultimately
manifest as the appearance of fictitious people, or of duplicates for the same
person (merging of inappropriate people would also be a risk but probably to a lesser
extent). There will always be the need for human researchers, and any
application of AI must have their additional inputs.
So, has anyone seriously tried to envisage what genealogists
will be doing in a couple of decades time? Will the same providers still be
offering online trees for users to build from raw information, and will
beginners be researching the same people as we are doing now? Will all of
today's trees still be online then, and will the error rate in those trees be
reduced? If so then how? Product Managers beware! Your industry's future is at
stake unless some visionaries step forward. Genealogy is big business at the
moment, but it cannot remain as it currently is. Companies may be throwing
their hat at DNA testing, but what happens when that fad passes its peak and it
is taken for granted? A company's valuation is dependent on a predicted future
for its market, so buyer beware also.
I want to take you on a brief tour of what it means to index
your digital resources, and how this is a better method of organising them than
creating physical connections. Although this articles is primarily about online
genealogical resources, it equally applies to local ones on your personal
computer.
A surprising number of Web sites still try to organise resources
using a physical hierarchy between their pages. For instance, one that had
pages related to places might be organised according to the associated
geographical hierarchy.
Figure 1 – Naive implementation of hierarchical
organisation.
As explained at Impermanent
Links, this is a bad method for multiple reasons including the fact that it
ties the URLs to one particular layout, and that layout is not particularly
useful from the perspective of the Web server (e.g. for maintenance).
An earlier article, Hierarchical
Sources, explained that organising physical resources by their provenance
and then indexing them according to how you want to see or access them is not
only preferential but would be the archival approach. But what do I mean by
"indexing"?
In order to explain further, I need to review some
terminology because people from different backgrounds may use the same terms in
dissimilar ways. People who are familiar with academic articles and journal
submissions will understand the difference between keywords and index-terms: keywords are
specific terms identified by the author — usually in the abstract rather than in
the body — and which would be found through a full-text search; index-terms are
categories or topics used externally to aid document retrieval. Index-terms are
not usually chosen by the author and are part of a controlled
vocabulary, meaning that there are no problems with synonyms, variant
spellings, or name clashes. However, in the field of database indexes, the term
key is a synonym of index-term, and so terms such as keyword and keyword-search may then be ambiguous.
So, to summarise things so far, it is better to organise
resources according their provenance, or their innate properties (as opposed to
content), and to separately index them according to their subjects or categories.
Grouping resources by provenance makes it easier to describe them (e.g. where
and when they were obtained), to move/copy them, to supplement them (with
related or new resources), or to support versioning. Any hierarchical
organisation can then be done entirely through external indexing.
But aren't index-terms simply tags with no implied hierarchy?
How would the place example (above) be handled? Index-terms are not tags —
that's a description that better-fits the concept of keywords. Controlled Index-term
vocabularies are very often defined to be hierarchical, and in the place
example "Nottinghamshire" would be a term subordinate to "England".
Whether the category name itself, e.g. "Place", is considered a
top-level of the hierarchy is a design choice.
The definition of such a vocabulary would not only indicate
which are subordinate to which, but may have associated meta-data that described
each term and enumerated any alternative spellings or historical variations.
Such meta-data would therefore assist in the selection of an appropriate
index-term, after which resources matching that term would be unambiguous.
Note, too, that if the term names had variations in other languages (e.g.
occupations) then the controlled vocabulary is untouched, and those variations
are enumerated in the same meta-data; whether the user selected
"butcher" or "boucher", the retrieval of the resource would
still use the index-term "Butcher".
Figure 2 – Organisation by two hierarchical indexes.
This diagram illustrates that a major advantage of this
approach is that you can support multiple independent hierarchies. Organising
resources according to both place and surname would not be possible using a
single physical page hierarchy, and would be a maintenance nightmare if you
tried to implement multiple physical hierarchies. A resource indexed by both
the place terms "Epperstone" and "Screveton" could also be
selected through the use of the common parent "Nottinghamshire", or
even "England". Also, a resource relevant to both the surname Lincoln
and the English town of Lincoln could be unambiguously indexed according to
both with no confusion at all.
As many hierarchical indexes could be used as necessary, and
new ones could be added without touching the underlying resources.
Figure 3 – Organising by multiple hierarchical indexes.
As well as being separately hierarchical, these indexes are
inclusive. That means resources can be selected based on whether they are associated
with terms in different dimensions. For instance, references to resources
relevant to the Nottinghamshire village of Coddington (expressed here using the
shorthand path "England.Nottinghamshire.Coddington"), "Surname.Astling",
and "Occupation.Tailor". Not only that, resources can be selected
using criteria involving Boolean operators, such as "England.Nottinghamshire"
AND NOT "England.Nottinghamshire.Epperstone".
Relational databases can easily handle this style of
indexing, including multiple indexes and Boolean queries. Each match would
simply yield a physical identifier for the associated resource, such as a
document or page name.
This is the official name (short form: SVG-FTG) of the free software design tool
described in my previous posts Interactive
Trees in Blogs Using SVG and More
on SVG Family Trees. This post announces some important changes for the
v5.0 release.
There has been a Facebook group for this tool for some time
now, called "SVG Family-Tree Generator". The membership is
significant but comparatively low for a free tool with substantial
functionality. One of the reasons is probably that the tool included too many
configuration options for the casual user, and not enough stuff "out of
the box". This has changed for this version, and some of the new features
are described below.
Another reason is probably that the tool (installation kit,
documentation, and samples) were available from Dropbox by invitation only — some
of the previous enquiries about it were obviously from software developers
looking to make a fast buck rather than from genuine genealogists, who I am
happy to support. Details on availability can be found on the summary page: SVG-FTG Summary.
Scaling and Presentation
It was always difficult to find the right magic spell to get
the family trees to display with the correct size, position, and features, in
all page situations. This version has made huge leaps there and it is
recommended that previous subscribers rerun their tree definition files (*.txt)
through the latest version to take advantage of the improvements.
Keystrokes
The documentation was always a bit lax about which modifier
keys (e.g. Shift) could be used with mouse clicks in the final browser output,
and what function they each achieved. In order to help users of different
browsers (especially Internet Explorer), and Mac users, a practical default
usage is now documented, although new options will support reconfiguration if
anyone has a need to match the conventions of some existing Web page.
GEDCOM
Since this tool was originally designed for my own use, and
for representing lineage situations in narrative research articles as opposed
to conclusions in someone's database, then I had no need of GEDCOM support.
After much thinking, I finally decided to implement a GEDCOM
Loader native to the SVG Family-Tree Generator. You can now select GEDCOM files
from disk, browse their contents, and copy-and-paste persons or families
directly into the Tree Designer window. You can also convert whole GEDCOM files
if you wish.
This copying or conversion of the data to SVG Family-Tree
Generator includes the automatic generation of captions, tooltips (i.e.
"hover text"), biographical notes, life events of many types, and the
special HTML mark-up required for its Timeline support.
So what does this mean in practice? Well, if you converted a
GEDCOM file directly to a *.txt tree definition file, and then generated the
usual HTML output using this tool, it would immediately include all the major
features such as pop-up biographical information panels, hover text, controls
to pan or zoom one tree at a time (rather than a whole Web page), and timeline
reports.
This is all "out of the box", with no programming
involved.
Timelines
As a demonstration of these features — all of which could be
used to display your own trees in subscription-free Web pages, or blog posts,
for your family to access — a version of the existing Timeline
Demo is embedded in this article.
Shift+Click will select a specific person-box, or a family-circle (which then selects the two spouses and all their direct children).
The 'Plus' icons in the person-boxes will also do the same as Shift+Click operations. Clicking on a thumbnail image will expand it in a separate browser
tab. The 'Eye' icon will perform the same operation.
The 'Select All' button selects all person-boxes and all family-circles.The 'Show' button collects the timeline events for the selected
items, sorts them, and displays them in a timeline report. The 'Dismiss' button closes the report. The 'Clear' button clears all the selected items.
Pop-up information panels, giving the full biographical details, appear by clicking on the respective person-box or family-circle, and
these can be
dismissed by Ctrl+Click (or CMD+Click on a Mac) on any person-box or family-circle. Note that clicking on a green event description in the timeline report
will also
show the associated information panel containing that event.
As can be seen, the timeline reports can either take events
from a specific tree or from multiple trees, and this can be useful when trying
to correlate different histories.
Buried 2 Jan 1756 at Coddington All saints.
<
Mary died in 1735, the same year as her infant son (John).
No notes available for Elizabeth Willson
No notes available for William Dickinson
No notes available for Rebecca Goodbarne
James was born c1726 and buried 1 Aug 1726 at Coddington All Saints.
Baptised 19 Jul 1730 at Coddington All Saints.
Married Mary Bowman 27 Jul 1756 at Coddington All Saints.
Mary died 1805 aged 74 and buried 12 Feb 1805 at Coddington All Saints.
Baptised 10 Sep 1732 at Coddington All Saints.
Baptised 13 Apr 1735 at Coddington All Saints.
Buried 18 Dec 1735 at Coddington All Saints.
Baptised 17 Sep 1727 at Coddington All Saints.
Buried 10 Oct 1789 at Coddington All Saints.
Buried 26 May 1772 at Coddington All Saints.
d. 1783, aged 52, of "Distemper fever" and was buried 1 Feb 1783 at Coddington All Saints.
Baptised 4 Jul 1743 in Long Bennington, Lincs.
Buried 11 Nov 1824 at Coddington All Saints.
Died before July 1784.
Born 28 Sep 1784 in Coddington.
Baptised on 10 Oct 1784 at Coddington All Saints.
Died 1869, aged 92, and was buried at Woodborough St. Swithun on 13 Oct 1869.
Baptised 14 Feb 1782 at Lowdham St. Mary The Virgin.
Buried 4 Jan 1850 at Bingham St. Mary and All Saints.
Baptised 26 Aug 1753 at Coddington All Saints.
Baptised 5 Feb 1755 at Orston St. Mary.
First wife (Elizabeth) died 1798, aged 40, of "a lingering consumption" and was buried 17 Jul 1798 at Coddington All Saints.
Married Elizabeth Watson (b. c1758) 24 Dec 1798 at Coddington All Saints.
Buried 9 Jul 1815 at Coddington All Saints.
Baptised 14 Nov 1756 at Coddington All Saints.
Married Elizabeth Whaite 3 Jul 1787 at Barnby-in-the-Willow All Saints.
Died 1834 aged 76 and buried 16 Dec 1834 at Coddington All Saints.
Baptised 1 Oct 1758 at Coddington All Saints.
Baptised 2 Mar 1760 at Coddington All Saints.
Baptised 25 Apr 1762 at Coddington All Saints.
Baptised 11 Sep 1763 at Coddington All Saints.
Baptised 24 Mar 1765 at Coddington All Saints.
Died 1841 aged 76 and buried 27 Jul 1841 at Coddington All Saints.
Baptised 1 May 1768 at Coddington All Saints.
Buried 28 Dec 1769 at Coddington All Saints.
Baptised 29 Apr 1770 at Coddington All Saints.
Married 6 Feb 1726 at Averham St. Michael & All Angels.
Married 27 Nov 1738 in Long Bennington, Lincs.
Married 15 Jun 1735 at Coddington All Saints.
Married 19 Aug 1751 at Newark St. Mary Magdalene.
Married 25 Aug 1766 at Coddington All Saints.
Married on 18 Mar 1775 at Coddington All Saints.
Married on 22 Jul 1784 at Coddington All Saints.
Married 9 Feb 1803 at Screveton St. Wilfrid.
Thomas was a POW in Napoleonic France until 1814, while Margaret took up with a Thomas Meads in Epperstone.
b. 1833 in Nottingham; Bpt: 20 Jan 1833 at St. Mary's, Nottingham.d. 1910 in Nottingham aged 77. Bur: Church Cemetery, Nottingham., common grave 8123 in St
Ann's Valley, on 24 May 1910.
b. 1834 in Maidstone, Kent.d. 1905 in Nottingham.
b. c1833 in Bishops Cleeve, Gloucestershire.
Licensed victualler at Worcester Arms, Worcester St, Cheltenham.
d. 1883 in Cheltenham.
b. 1834 in Tetbury, Gloucestershire.d. 22 Apr 1924 at 59 Norland Rd, Nottingham.
b. 21 Apr 1870 in Nottingham.d. 12 Dec 1950 aged 80. Addr: 33 Young St. Bur: 15 Dec 1950 at Wilford Hill. Gr:
G34/51.
b. 1873 in Cheltenham, Gloucestershire.d. 10 Jun 1956 in Nottingham. Bur: 13 Jun 1956 at Wilford Hill. Gr: G34/51.
Married 2 Oct 1858 at Nottingham St Nicholas.
Married 21 Nov 1872 at Gloucester St Catharine.
Married 29 Nov 1891 at Nottingham Emmanuel.
Documentation
The documentation was getting a bit weighty so it has now
been split into a proper User Guide ('SVG User Guide.pdf') and a more in-depth
set of program notes for people who want to get under the hood ('SVG Program Notes.pdf').