Legacy Family Tree Mapping – Can Anybody Help?

Okay, I’ll admit it. When Millennia, makers of Legacy Family Tree, first introduced mapping I looked at it, but for a variety of reasons never used it much. So when I got a new computer about six months ago and noticed that the Legacy mapping component wasn’t working, it wasn’t high on my priority list to troubleshoot. BUT (there’s always a but, right?) after seeing some of the RootsTech videos I started to re-think mapping and its usefulness.

One of the things that upped the usefulness of mapping (for me, anyway) is that I’ve changed how I input locations to be more specific. For example, I now include things like church names and cemetery names directly in the location as opposed to the address field. (Address are not displayed in the family view, and I wanted to be able to see this information without a bunch of extra clicks.) I even got rid of displaying the burial date so it would be easier to see the cemetery name as well as it’s location. Check out the screen shot below.

Back to the mapping issue. I’m running Legacy on a Windows 7 (64bit) HP laptop with 6 gig of RAM. I have installed IE9 (and Silverlight), but mostly use Chrome. The mapping feature actually did work last night after installing the latest version of Legacy. But upon booting up this morning (which included a windows update install) I am back to getting a blank panel where the map should display, but no error codes or messages. (See screen shot)

I still have the old computer (with a six-month old version of Legacy) and decided to see if mapping works on that. It’s running XP and also has IE9 installed but not as the primary browser. It has less memory and disk space and more installed programs, but mapping works?!  Google searches have yielded no solutions. Legacy support has no further ideas since the re-install fix was not permanent. Anybody have any ideas? I would love to get this resolved!

UPDATE: I am very happy to report that the suggestion by jupiterthreeEd Thompson, which was to run Legacy as administrator, has fixed the problem!

Recording both Historical and Current Locations

There has been a lot of traffic on the Legacy Family Tree Users Group email list (aka the LUG) regarding recording historical vs.current locations for a given event. As several people have pointed out, genealogical best practice is to store the location as it was at the time of the event. But others have valid points when they state that this makes for confusion when reports are generated for non-genealogist family members, hinders mapping and makes for a “messed up” master location list. (If there are multiple entries that point to the same geo-location, is it really a “master” list? Guess it depends on your definition.)

To be honest, in my own Legacy database I’ve been a little wishy-washy and inconsistent with this. Wanting to do the “right” thing, I have in some cases recorded the historical location. Other times, I have just gone ahead and put in the current location, particularly when the source I’m using records the “current” location. (Like a book of records for a church in what is now Montgomery Co, Pennsylvania but was previously Philadelphia Co., in which case some of the earliest data recorded in the record book happened in the Philadelphia Co. time period)  I also have to admit that, although I have intermingled current and historical locations in the master location list, it really bothers me to do so. Why? Well there is no clear and highly visible way to distinguish historical from current. Nor is there a way to link historical to current other than adding a note – and that isn’t readily visible.

It seems to me a more logical implementation would be to allow both a current and historical location to be added to an event – and also to distinguish between historical and current locations. After all, an Historical Location is really a specialization of a Location. It has all the attributes of a Location, with the additional attributes of a date range and a pointer to the current. Of course, if Mellinnia Corp. (makers of Legacy Family Tree) were to provide something like this in the future, a user would have to go back and identify the historical locations already entered into the master list, add the relevant dates and identify the associated current location. Once that task was completed by the user, Millennia could probably provide an automated utility to go back and determine if the originally entered location was historical and if so find the associated current and make the appropriate updates in the event data record. Going forward, entering the current and historical locations (if necessary) would be up to the user.

Just tossing this out to maybe get some people thinking. It really does seem like a problem that could use a solution!

RootsTech observations from a Home Viewer

It seems that the whole genealogy community is buzzing about the recent RootsTech conference – and with good reason! I was one of the unfortunate many who could not attend the conference live, but was able to catch a bit of the excitement by watching several of the presentations that were streamed live on the internet. So here goes with some general observations.

Cloud computing was a huge topic in the sessions that I saw online. This included using the cloud for backups, synchronization, collaboration and storage of family trees. I’ve always been a little distrustful of “the cloud,” but I was convinced to take a few more steps in that direction – or at least check it out in more detail. As an example, I know that a lot of people use dropbox for their genealogy data, but I’ve been hesitant. Hearing all the conference talk, however, prompted me to do a google search which showed a product called SecretSync that encrypts files prior to uploading to dropbox. This gets around some of the concerns people are expressing with the dropbox privacy policy. It probably isn’t necessary to SecretSync every file before adding it to drop box, but I will probably do this for any information I consider personal or sensitive. On the other hand, I didn’t get a warm fuzzy feeling about Geni. I still plan to keep my primary genealogy database on my PC and upload a subset to the various tree sites.

In viewing the presentations, I also realized that I’m under-utilizing some important resources – especially maps. LegacyFamilyTree has built-in mapping based on Bing. But I have been unable to get it to work on my relatively new Windows 7 computer. The LegacyFamilyTree website says that their mapping requires IE7. I don’t use IE, but have version 8 installed on my computer. I am reluctant to go back to version 7. After seeing some of the RootsTech presentations, I’m going to look into using GoogleEarth tours and possibly some basic mapping with GoogleMaps. It won’t be integrated with Legacy, but I guess you can’t have everything. :(

While I enjoyed each and every presentation that I saw, the topic that got me most excited was the Google presentation segment on Historical-data.org. In a nutshell, this is a way to add semantic information to a web page in order for the search engines to better assess it’s relevance to a “genealogy search.” I even went so far as to start to update one of my obituary web pages by defining my ancestor Augustus Bechtel as an HistoricalPerson. I did this after the Historical-data.org schema definitions were touched upon in the Day 1 keynote address. I wasn’t sure how to define the HistoricalDates and felt vindicated when watching the Google presentation on Day 2, when the speaker said even the large companies they were working with struggled with this. They  (Google, et al) are promising to add examples to the Historical-data.org blog, and you can just bet that I am now subscribed and waiting for that post! I even put in a product enhancement suggestion for LegacyFamilyTree to add this to the webpages that Legacy generates. (Crossing fingers that they at least consider.)

That’s about it for now. As I try out some of the software and concepts, I may post follow-ups!

My Struggle with Legacy Family Tree Sourcing – Part 2

In my previous post (link), I started the discussion of sources and citations and lumping and splitting as related to creating sources in Legacy Family Tree software. Part 2 will talk a little about the database structure and the trade-0ffs of lumping and splitting.

I made a very simplistic, high-level diagram of how things work in Legacy. It shows a source table with 5 sources. Next is the Citation Table which shows 5 citations all pointing back to source 1. Notice, however, the first three of these citation records contains identical data. This identical data is stored three times because each one points to a different event. The 4th and 5th Citation Data records are also identical.

This data model involves redundant storage of data and is very bad in terms of data maintainability. Now, in order to maintain data integrity, if any piece of the citation data needs to be changed it is necessary to find all copies and change each of them. Legacy shifts this onus of maintaining data integrity to the user, supplying only a Search and Replace tool. But there are several cases where Search and Replace cannot make the desired change easily and some cases where it cannot make the desired change at all. It then falls on the user to edit each copy of the citation data manually.

Diagram 2 illustrates the exact same relationships, but the citation data/event links are pulled out into a separate table. This allows for each unique citation record to be stored once, regardless of the number of events to which it is linked.

Had Legacy implemented a model similar to diagram 2, I would be a very happy camper. But they didn’t. So now it all comes down to trade-offs. On one hand become a splitter. This entails creating a multitude of very specific, repetitious sources and minimizing the citation data content. In many, but not all cases, it gets rid of the data integrity problem as described above. On the downside, since you have so many sources, you need to be very careful and vigilant when you create them so that all the repetitious data is consistent from one source to the next. (That is if you care about consistent wording and formatting.) Admittedly, the ability to create a new source by copying an existing one helps with this.

It is also extremely important to come up with an organization scheme that is built into the source name. All Legacy does is present you with an alphabetized list of sources – no filtering or classification on the list. Granted, this is also a problem for lumpers, but the problem is magnified for splitters because they have so many more sources! Over the past couple of years, I’ve tweaked my naming system a couple of times to force the sort order of the source list. I don’t want to even image how much more laborious and time-consuming this would have been were I an extreme splitter! And while I don’t know of a hard-limit on sources, if you have a large database of people you may find that extreme splitting creates just too many sources to be practical.

On the flip-side. lumpers are more likely to have a more manageable number of sources. This has the advantage of making it somewhat easier to tweak them. I have actually tweaked my naming convention to force sort order (as mentioned above) as well as tweaked wording and content of source fields for better consistency in how footnotes and endnotes appear in reports. I also feel that some degree of lumping is more in keeping with database and software design principles. The downside of lumping is, of course, the citation maintainability problem which is the focus of the article.

So where does all this leave me. Well, I’ve already characterized myself as a lumper – although I am sure there are some who are more extreme. Over the years I’ve done a lot of experimenting and tweaking and I like the system I have for deciding what to include in the source table vs what to include in the citation. What works best for me is to define a source for each dataset or data collection. So each database in Ancestry gets their own source. I also tend to create separate sources for each of the datasets stored on the USGenWeb county pages. On the splitter/lumper spectrum, I would say that I’m a moderate lumper. In terms of Source Writer, I have recently decided to primarily use just 2 templates  for online data – online database or online database with images. (But that’s starting to get into a whole other discussion — the multitude of source writer templates!)

My struggle with Legacy sourcing is nothing new. It’s an issue I’ve had to deal with from the time I first started using it back in early 2004. Based on what people say on the LUG email list, the database implementation has pushed some people toward extreme splitting. That never felt right to me, and by now I’m just too entrenched in the way I have been doing things to even consider changing. Why then did I bother writing this post? After creating the SAR source and citation and linking it to about 30 events (so 30 copies of the citation) it occurred to me I should have included something additional in the citation. I tried to fix it with search and replace and guess what — it didn’t work!!!! It said it found and made 30 changes, but when I looked at the data, it had NOT changed. So mostly out of frustration I wrote this post. I still have to go back and try to fix things up, but at least I had a chance to vent.

Maybe some day Legacy will fix this design. Maybe some day some other company will design and build genealogy software that does not have this issue. Maybe some company already has — sometimes it’s hard to tell from the marketing oriented data on their websites. Maybe somebody will see this post and let me know!!

My Struggle with Legacy Family Tree Sourcing – part 1

Yesterday afternoon I got an email from Ancestry touting their newly added US Sons of the American Revolution Application dataset. (By the way, you can access it FREE this weekend in celebration of the Fourth of July holiday.) So I naturally logged on to Ancestry, went to the new SAR dataset and entered one of the surnames that I research to see what would pop up. And sure enough, I got some hits! The third or fourth one on the list I recognized as being one of my 5x great-grandfathers. Clicking on his name sent me to a screen where I could access the actual scanned image of a SAR application. And in viewing the application I was able to see birth, death and marriage dates and places for the generations that separated the applicant from the patriot.

Now, for me, this is both a blessing and a curse! Why? Because now I have to decide how to structure this within the confines of the method Legacy Family Tree has implemented sources and citations. Basically, I need to decide what information from the SAR application I want to store in the source and what I want to store in the citation. This discussion comes up often on the Legacy Users Group email list and is generally referred to as “lumping and splitting.” (FYI: Legacy has chosen not to provide a forum/message board, and with their email archiving being fractured and possibly dropping messages, many questions are repeated periodically.)

I think the both the source/citation and so-called lumping/splitting concepts are best illustrated with examples. The most easily understood source example is a book. Most people (regardless of whether they are lumpers or splitters) would agree that the book information (title, author, publisher, date, etc) should be stored in the source table and the page (or chapter, page range, etc) should be stored in the citation. As this illustrates, the purpose of the citation is to link the source to the event, and as such it should refer to the specific subset of the source that contains the data that was extracted and inserted into the event or fact.

Another common source – census data – is much less straight forward in terms of what part is source and what part is citation. If you follow Legacy Source Writer templates for US Federal Censuses, your sources will be specific to year, state, county and online database. In other words:

• source 1 – 1880 Census, Pennsylvania, Berks, Ancestry.com
• source 2 – 1880 Census, Pennsylvania, Berks, HeritageQuest
• source 3 – 1880 Census, Pennsylvania, Chester, Ancestry.com
• source 4 – 1800 Census, Pennsylvania, Chester, HeritageQuest

Splitters may break this down further, with separate sources for each town or city. Some have even suggested each census sheet is a separate source! As you can see, splitters have a very large number of very specific sources. Very little, if any, additional data is stored in the citation and it becomes just a link between source and event.

On the other hand, I fall into the lumper category. I still use Source Writer, but I leave the state and county fields blank when I create the census source. Then, when I add a citation, I preface the municipality field with the state and county. Since the source writer citation form does not have a logical place to store the online database (i.e. Ancestry vs. HeritageQuest, etc), my sources are based on year and online database. I’d rather it just be year, but I want to know which online database I used, so I make this concession in order to use source writer. Thus my sources look something this:

• Source 1 – 1880 US Federal Census, Ancestry
• Source 2 – 1880 US Federal Census, HeritageQuest

In general, lumpers have fewer sources and those sources are (for the most part) not repetitious. My guess is that most Legacy users who have a background in software or database design will probably lean toward the lumper end of the spectrum because that more closely follows the design principles to which we are accustomed.

Getting back to the SAR application and how that fits into the source/citation structure. A splitter would most likely consider each application a separate source. On the other hand, I consider the Ancestry SAR Application Collection the source, thus the specific data on an individual application would be part of my citation. But for a document like a SAR application, where it will serve as a citation for many events or facts, the fact that Legacy stores multiple copies of the citations is trouble waiting to happen. — more on this later in part 2 of this article [link].