Monday, June 21, 2010

The Evidence Architecture of the New FamilySearch Tree

See “Evidence Management” for an overview of this series and for links to other articles.

Let me show you that the New FamilySearch Tree (NFS) has the architecture needed for evidence management. You may not want to try this at home; I’m a trained professional on a closed course.

Before we dive into New FamilySearch, it will help if you know some NFS technical terminology.1

  • An evidence summary (a green box in the evidence management diagram) is called a persona.
  • An individual (blue box) is called a person.
  • A conclusion (purple box) is called an assertion.

If I specify both my term and the NFS technical term, I will separate the two with a slash, like this:

conclusion (assertion)


To illustrate evidence management in NFS, I again use an example from David Rencher. I created an evidence summary (persona) in NFS for Angeline Clements for each of the five sources, below.

Source Name Persona ID Evidence Summary  
Image 1850 Census Peyton C Clements LWXX-TPN Evidence Summary: 1850 Census Peyton C Clements Link
Image Peyton Clements probate finalized LWXX-5Y3 Evidence Summary: Peyton Clements probate finalized Link
Image 1880 Census W H Goldsmith LWXX-BGT Evidence Summary: 1880 Census W H Goldsmith Link
Image Death certificate A J Goldsmith LWXF-M6T Evidence Summary: Death certificate A J Goldsmith Link
Image Marriage W H Goldsmith LWXF-9ZV Evidence Summary: Marriage W H Goldsmith Link

Click the image link to see a digital copy of the source.

Name (Persona ID)

I included evidence summary names in the table even though NFS doesn’t support them. Instead, NFS uses persona IDs. Remember, a persona in NFS takes the place of an evidence summary.

Evidence Summary and Link

Click the thumbnail to see an image of the evidence summary. Compare a source and summary to see that the two match.

I included the images of the summaries (personas) because once connected—combined as NFS calls it—to an individual (person), NFS provides no way to see just the summary. I included links to the summaries, but once connected (combined), the link brings up the individual rather than the summary.

Creating Evidence Summaries in NFS

With such a perfect architecture under the covers, it is unfortunate that FamilySearch chose to dumb-down the interface to the lowest-common denominator. I think it is possible to adequately serve patrons of all genealogical maturity levels. Because NFS doesn’t give direct access to personas, and because I know that creating an individual (person) also creates an evidence summary (persona), I clicked on Add Information and then Add an Individual That Is Not Connected to My Family Tree.

Then I added the evidence from the source:

Entering evidence for: Peyton Clements probate finalized 
Evidence from the “Peyton Clements probate finalized” source.
Click on this and subsequent images to enlarge.

Since the summary was to be combined with Angeline, I entered only her information. Because it was not obvious how I arrived at a birth date of “Before 25 November 1852,” I clicked on the note icon and entered: “Probate file states Angelina is over 21 years of age.”

For each summary, I clicked on Source details and added a citation. A true evidence summary has but one source for the entire summary. Because NFS doesn’t have true summaries, I clicked the checkbox, Use this source for everything… As mentioned in the past, NFS source templates are inadequate. Consequently, I entered the entire citation in the Comment field, as illustrated below.

Source of evidence summary: Marriage W H Goldsmith
Source for the “Marriage W H Goldsmith”
evidence summary

Once I completed an evidence summary, I clicked Continue. For summaries without death information, NFS gave me the opportunity to enter it.

NFS message: Death info must be added

I appreciate the reminder to enter information that might have been inadvertently missed. But It is unfortunate that NFS insists on adding information—a death flag—even when the source did not contain death information. It seems superfluous, given that NFS is already completely convinced that the person is dead.

NFS then let me review the information.

Review evidence summary: Angeline death certificate 
Reviewing the evidence summary, “Angeline’s death certificate”

Notice that all the information is repeated twice. This is one of the nice features of NFS. I can enter information exactly as it appears in the source document. Below the original text, NFS displays its standardized interpretation so I can see if it understood. Most programs either throw away the original text, or silently—and perhaps incorrectly—interprets it.

If NFS truly supported evidence management I would click Review Possible Duplicates to see if anyone else had already entered an evidence summary for this source and this person. Then I would click Done.

After I clicked Done I saw the completed evidence summary (persona).

Evidence Summary: Peyton Clements probate finalized
The “Peyton Clements probate finalized” evidence summary

Reaching Conclusions

Conclusion entry in NFS for name of Angeline ClementsAs I’ve mentioned, the big payoff for evidence management comes next, when making a conclusion. NFS requires that evidence summaries (personas) be connected (combined) to individuals (persons) prior to using the evidence to make conclusions. The process is messy and reflects the duplication problem that FamilySearch painted itself into. Indulge me if I gloss over it and go right to entering conclusions. Suffice it to say, I connected all the summaries to the individual.

I then clicked on the Summary tab. In the context of evidence management, it could be called the Conclusion tab. The Conclusion tab shows the basic vitals: name, gender, birth/christening, and death/burial. Next to each is a down arrow (pointed out by the mouse pointer in the illustration to the right). I clicked the down arrow and NFS displayed all the values entered into the evidence summaries. I pointed to the one representing my conclusion (pointed out by the hand in the illustration) and clicked it.

Below, compare my suggested conclusion entry (left) with that of NFS (right) for the birth date of Angeline Clements.

Suggested conclusion entry for Angeline Clements birth date  NFS conclusion entry for Angeline Clements birth date

Comparing the two you will notice several shortcomings in NFS conclusion entry:

  • Without a summary name, it is difficult to remember where each piece of evidence came from.
  • The notes I entered in the summary are not displayed.
  • Obviously, since NFS has no provision for recording the attributes of the evidence, none can be displayed.
  • There is no place to enter analysis about each piece of evidence, so other users have no way to know if contrary evidence has been handled.
  • There is no place to enter the overall reasoning used to reach the conclusion.

No Benefits

The evidence management compliant architecture of NFS has given FamilySearch nothing but problems, so I expect they will discard it. One reason it has proven problematic is FamilySearch’s decision to preload millions of junky, sourceless evidence summaries (IGI patron submissions, Ancestral File, and Pedigree Resource File). But I digress.

One reason that NFS users have derived no benefits from the NFS evidence management architecture is that NFS designers failed to give users a way to see whole evidence summaries. Clicking on the  details tab of Angeline Clements doesn’t allow users to see the evidence summaries or even a list of the summaries. Instead, it shows all the evidence interlaced and out of context:

Details of Individual LWFZ-RDZ

Use the Combined records option to see the connected (combined) evidence summaries:

Use the Combined Records option to see NFS evidence summaries

This option gives users the ability to disconnect (separate) summaries (personas) mistakenly connected to the wrong person. When you do this, all the assertions from the source come out in a group. And when the summary is reassigned to the correct person, all the assertions come in as a group.


Because I understand the NFS architecture, I can tap into the strength of its evidence management. But doing so is painful. FamilySearch users have not benefitted from their architecture for two reasons. First, since FamilySearch preloaded garbage into NFS, garbage is what they’re getting out (GIGO). Unfortunately, user interface and architectural decisions are now being driven by the resulting ripples. Second, FamilySearch chose not to provide a different user experience to immature users and mature users. FamilySearch then had to simplify the user experience by hiding the existence of evidence summaries (personas).

To conclude this presentation of the New FamilySearch Tree architecture, let me say that it is extremely impressive and ideally designed for evidence management. Hopefully, FamilySearch will one day leverage their technical superiority by opening up persona management—or, as I call it—evidence management.


     1.  Rob Lyons, “Family Tree Combine/Separate,” FamilySearch Developers Conference, 2008; online archive, “Recorded Presentations,” FamilySearch Developer Network: for Software Programmers ( : accessed 18 June 2010). Also “Glossary,” FamilySearch Developer Network.


  1. Good article. It's too bad that FamilySearch decided to suck in all of the IGI instead of cherry-picking it.

    You seem unfamiliar with the Gentech Genealogical Data Model (GDM). ( There's a summary of the main concepts here:

    A "persona" in the GDM is the representation of a person in a source. The GDM incorporates layers of "assertions" to extract evidence from sources and to combine that evidence into a description of an actual "person".

    The point of all of this is that NFS has picked out one small piece of the GDM, that personas from individual sources should be linked to the conclusional aggregate "person" -- and that those links might be erroneous and should therefore be movable. That's analogous to TMG's tags, which allow one to easily change a person link in a tag to assign it to a different person in the database.

    As you rightly point out in the article, it's not evidence management. But it's a lot further away from evidence management than you seem to think.

  2. Good, thought provoking stuff. The examples are really beginning to make sense to me now.

    I was interested in your comments about "a different user experience to immature users and mature users". Since this stuff is not self-evident, I believe any software must be able to do this in some fashion - wizards or whatever. The beginner will undoubtedly start by entering their own family details and their attitude will be "I KNOW who my own father is, I just want to enter it - NOW please!" But these simple statements need to be entered and stored in such a way that later on, it must be possible for them to peel back the layers to what they've previously done and see the assertions, evidence, whatever, that have previously been masked. (Apologies for going on again about the user experience)

    I also wonder whether mature genealogists will necessarily want to write out the full process for every item. I can see the benefit for something like a birth date or establishing a relationship, because are multiple bits of evidence to deal with. But if I'm processing a census, do I really want to go through a full investigation just to record someone's occupation at that time? Yes, we may get contradictory evidence later so we need to be able to see the detail, but I need to have a smooth workflow that starts with a single document first.

  3. Dear brucefuimus,

    You make a good point regarding occupation. The philosophy the vendors need to take is that users never have to type anything twice. Consider this scenario:

    The user wishes to enter the occupation and only the occupation from a census. He doesn't have an evidence summary for the person/record.

    * He clicks on Add Occupation.

    * Whether he knows it or not, the popup for entering the occupation is an evidence summary. He enters the occupation.

    * He has an opportunity to enter a source if desired. If not, it requires no additional clicks. Entry of the source requires minimal keystrokes by utilizing previously entered information.

    * He has an opportunity to enter additional assertions from the source. If not, it requires no additional clicks.

    * He clicks done.

    -- The Insider


Note: Only a member of this blog may post a comment.