Version tested: Brother’s Keeper 7.1.11
Portions of text in all capital letters that are not acronyms are GEDCOM tags, with the rest of the plain text field name in lowercase. References to the GEDCOM standard are to version 5.5.1 unless stated otherwise.
Importing a GEDCOM file into Brother’s Keeper (BK) is straightforward, but instructions are in the Help file if you need them; just go to “gedcom import” in the Index. I have two tips that refer to Fig 1:
- If you have multimedia linked to your GEDCOM, check the box “Include names of pictures and media files”
- If your GEDCOM came from Family Tree Maker or Ancestry.com, check the box “Set this option if you want to add a space between CONC lines”
+ GEDCOM import log: All good genealogy apps should produce a GEDOM import error log, and BK produces a text file called GED.LST; when given the option to open it, I recommend that you do. Otherwise, you’ll have to change the extension to “txt” or right-click on it and select “Open With.” It’s clear from the report that BK expects GEDCOMs to be in version 5.5 format, but more about this under Cons. Unfortunately, the report lists problems by BK’s person number; it would be nice if it listed problems by GEDCOM line number to make it easier to find them.
+ FTM’s invalid use of the ALIA tag: Family Tree Maker (FTM) and a few other apps incorrectly use the ALIA tag in GEDCOMs for the “Also Known As” field. The ALIA tag should be used to provide a cross-reference to another person who may be the same. The closest the GEDCOM standard has to “Also Known As” is the Nickname field, whose tag is NICK, or the Name Type tag, which is rarely used. BK imported ALIA as “Also Known As” and exported it with custom tag _AKAN. However, BK did not import correctly structured ALIA references, nor is there any way to add them.
+ Invalid event description: Except for fields that the GEDCOM standard calls “Attributes” and the generic Event field, the only entry that an event description (called a “descriptor” in the standard) may have is the letter “Y” to assert that the event occurred, if and only if both the date and place are blank. Many genealogy apps violate this rule, including FTM, which enabled me to include it in my test GEDCOM file. BK correctly did not import the invalid event description in my file but also did not warn me about it in the import report.
+ Family Events: Organized the event Separation along with other family events, even though it used the generic event structure. However, it exported Separation using a custom tag instead of the EVEN tag.
+ Places: You can add notes and photos to places in BK, which may be useful; the notes are exported to NOTE tags while the photos aren’t exported at all, both of which are correct.
+ Associations: An association in genealogy is a relationship between two people, usually but not necessarily non-familial. Associates could be godparents, sponsors, witnesses, friends, neighbors, co-workers, etc. They’re often summarized using the acronym FAN for “Friends, Associates, Neighbors.” While the FAN club principle of cluster genealogy is often advocated, few apps that I’ve reviewed have a field for associates, and even fewer use the standard GEDCOM structure for them. In BK you can add witnesses to all events; unfortunately, “witness” is the only type of association BK has, and there’s no way to add others like “godparent,” “friend,” etc. When exporting the association to GEDCOM, BK uses the custom tag _EVN to indicate which event the person was a witness for; I doubt if many other apps can read this tag.
+ Help: The BK built-in Help file is fairly detailed, and there is an active BK mailing list at RootsWeb.
— GEDCOM 5.5.1 tags: Failed to import FACT, EMAIL, FAX, PHONe and WWW tags, even though my GEDCOM was labelled version 5.5.1, and there was no mention of these tags in the GEDCOM import report. However, BK was able to export these tags.
— Secondary Names: These are name structures that occur after the first name structure in an individual’s record in a GEDCOM file. BK imported alternate names but exported them using the custom tag _OTHN instead of an additional instance of the NAME tag There are also separate fields for Name Prefix, Suffix, Nickname, and Title, which are standard GEDCOM fields, but only Suffix, Nickname, and Title are exported to GEDCOM, using the standard tags.
— Adoptive parents’ relationships: BK imported an adoptive relationship, but there was no way to display or change the adoptive status that I could find. Also BK used the custom tags _FREL and _MREL to export relationships between parents and children (adopted, birth, etc.) instead of the standard tag PEDI.
— Source citations: Imported “Where Within Source” field (tag PAGE) on source citations into the citation comments and exported them to the NOTE tag. BK has a Page/Reel number field; it should import the PAGE tag into this field instead of the comments/notes. When I filled in a Page/Reel number field, it was correctly exported to the PAGE tag.
— Notes: Failed to display all person notes; only displayed one of two notes on a person. However, all notes were exported back to GEDCOM, so they must be stored internally. If they’re imported and stored, they should be displayed.
— Valid Event Descriptions: The GEDCOM 5.5.1 standard allows generic events to have descriptions, even when there is a date and/or place. For example, I have the following valid structure in my GEDCOM:
1 EVEN Mayor 2 TYPE Election 2 DATE 1868 2 PLAC Szepes County, Kingdom of Hungary
“Mayor” is the event description; GEDCOM 5.5.1 allows Event Descriptors on the EVEN tag, and my GEDCOM was labelled as version 5.5.1. This was a change in 5.5.1 (p. 48); previous versions did not allow descriptors on events. BK imports and exports valid event descriptions, but Location (place) and Description fields are combined into one box on the Person Edit window, which is awkward (Fig 2). Place names are preceded by “Location” if there is also a description (which there should only be for attributes and generic events). This is problematic because the description and place are exported together in the GEDCOM file—there is no separate place tag. There should be separate fields for Location and Description.
— UTF-8 Encoding: BK does not fully support UTF-8 encoding. My test file contained the name “Märîjá /Rüßkövęñškæ/,” and BK’s GEDCOM import log stated, “Had a problem converting some characters from line: 1 NAME Märîjá /RüßkövXñXkæ/.” No kidding! My test file also contained “Johann /孔子/,” which BK imported as “Johann /XX/,” but the import log didn’t say anything about it. (Added 21 May 2016)
— GEDCOM 5.5.1: All GEDCOM files have a GEDCOM version tag so that the apps that process them can interpret them correctly, since there are differences in structure among the various versions. As I’ve explained elsewhere, modern genealogy apps should be able to import and export version 5.5.1, which is the current standard. GEDCOMs exported from BK are labelled with version 5.5, even when they use features of 5.5.1 like the UTF-8 character set and the EMAIL, FAX, WWW, LAT and LONG tags. Apps must label their GEDCOMs with the version of the features and structures that they use.
— Miscellaneous Events: Allows user-defined events to be added using an event called “Event,” but there’s no way to add the Event Type; consequently, they’re missing the required TYPE tag when exported to GEDCOM.
— Events without date or place: exported without required “Y.” The GEDCOM 5.5 standard explicitly says, “The absence of both of these tags require [sic] a Y(es) value on the parent TAG line to assert that the event happened. Using this convention protects GEDCOM processors which may remove (prune) lines that have no value and no subordinate lines” (p. 32).
— Multimedia: Events/Facts may not have multimedia in BK. Some users may find this to be a serious limitation. However, media can be attached to people, places, sources, and citations. In addition, there are no fields for media dates, notes, or reference numbers. If your imported GEDCOM contains them, they will be lost.
— Character Sets: BK offers three character sets that were not available in GEDCOM 5.5: DOS, Windows ANSI, and UTF-8. Version 5.5 permitted only ANSEL, ASCII (USA Version), and Unicode would have referred to UTF-16. BK does offer “Ansel (normal for gedcom [sic]),” which is properly written “ANSEL” because it’s an acronym for “American National Standard for Extended Latin,” just as GEDCOM is a portmanteau of “GEnealogical Data Communication.” As the NISO website states, ANSEL was “Administratively withdrawn by ANSI, effective 2/14/2013;” I think that means it’s not normal for ANSEL to be used anymore in GEDCOMs or anything else. The most widely used character set now is UTF-8, which was added to GEDCOM 5.5.1, so for this reason, BK should export files according to version 5.5.1.
— Name prefixes: Failed to export them, even though it imported them.
— LDS Child Sealing: Missing required FAMC (child’s family) tag.
— User-Defined (Custom) Fields: BK uses too many user-defined tags in exported GEDCOMs, sometimes when there are standard tags that should have been used, like PEDI (Pedigree Linkage Type) instead of _FREL or _MREL. The GEDCOM standard discourages these, for good reason: most other applications will ignore them, since they’re not defined in the standard. The standard has two generic tags that should be used when there are no standard tags, EVEN (for events) and FACT (for facts or attributes).
— Clicking on headings in in the Person Edit window has no effect; the expected behavior is to sort the events. The only way to sort them is to manually move them up or down.
— In the Address and Place Details (Other) forms, I couldn’t tab from one field to the next.
— Most genealogy apps have one or more indexes of people, places, sources, media, etc. I could find only an index of individuals, and it appears only if you select Find in the Person Edit window and type “* *” in the Name or Number field (Fig 3). I think good genealogy apps should have easy-to-use indexes of all the major record types in addition to a Find function.
I added the BK fields to the GEDCOM Crosswalk at Family Tree Maker to GEDCOM to Other Apps Crosswalk. This table shows at a glance how the major genealogy apps name their fields within the app and how they are exported to GEDCOM. The color coding indicates areas of concern: fields in red are not imported and/or exported correctly, while fields in yellow use custom tags that may not be recognized by other apps or websites.
BK has been around a long time, since at least 1988 according to its trademark filing, and the interface looks quite dated to me (see Fig 2 above, although the color scheme was my choice); it looks like it would be quite at home on Windows 95 or even Windows 3. Some people care about appearances, and some people don’t. However, the appearance gives an indication of how much an app has been updated. While BK may be up to version 7, it hasn’t even updated to the most current GEDCOM version. This review focused on GEDCOM handling, because the ability to import and export correctly is one of the most important criteria for an app; GEDCOM is usually how family trees are exchanged between people using different apps. It’s unfortunate that BK doesn’t label its GEDCOMs as version 5.5.1, because that’s really what they are, since they offer the UTF-8 character set as an option, as well as tags like EMAIL and WWW. BK’s next most serious shortcoming is its failure to provide fields for multimedia dates and notes; it also doesn’t allow multimedia to be attached to events. If the developer can be convinced to fix these major shortcomings, then BK might be worth another look—if you don’t mind a retro 90s look.
GEDCOM 5.5.1 Test: Brother’s Keeper fails the GEDCOM 5.5.1 Test. It incorrectly labels files exported using UTF-8 encoding as version 5.5; UFT-8 wasn’t allowed in 5.5.
30 Apr 2016: Added a statement about the GEDCOM 5.5.1 Test.
21 May 2016: Added a paragraph about UTF-8 encoding support.
The Family Tree Software Alternatives Series
Part 1: How to Scrub Your Data
Part 2: How to Get Your Tree out of FTM
Part 3: RootsMagic 7
Part 4: Reunion 11
Part 5: MacFamilyTree 7
Part 6: Family Tree Builder 8
Part 7: Heredis 2015
Part 8: Gramps 4
Part 9: iFamily for Mac
Part 10: GEDitCOM II
Part 11: Legacy Family Tree 8
Part 12: Ancestral Quest 14
Part 13: Family Historian 6
Part 14: Should You Stick with Family Tree Maker?
Part 15: Brother’s Keeper 7
How Well Does Ancestry.com Handle GEDCOM?
Family Tree Maker to GEDCOM to Other Apps Crosswalk
The Perils of Following the GEDCOM Standard
Why All Genealogy Apps Should Support GEDCOM 5.5.1
*Information current as of the date of this post