thePeerage.com
FAQ
Objective
My initial objective in creating this database of the European nobility was to fully explore the capabilities of the genealogy package(s) I have been using. The European nobility is fascinating for a number of reasons: long periods of records available with information going back more than 1000 years, a high level of inter-marriage, making the resulting family tress very complex and inter-woven, and extremely interesting families with every possible event occurring (murders, battles, coronations, overthrows, attainders, multiple titles, etc).
In particular, I am fascinated with the tight intermarriage which has existed within the royal families of Europe, with the result an individual may have the same person shown up in their family tree many different times. As an example, each person should have a total of 1,024,000 different direct ancestors within the previous 20 generations. So far, my database lists 222 million ancestors for Charles Windsor, Prince of Wales (over the previous 60 generations), but out of this total only 3910 are unique individuals (i.e. he has a 99.99% overlap of ancestors). Ultimately, I would like to be able to illustrate using my database the blood relationship between every married couple in the European royalty.
Software History
I first started building a royalty database in 1988, using PAF v1.0. I quickly switched to Roots II, upgrading to Roots III in 1990 then Roots IV in 1993. This transformed into Ultimate Family Tree in 1996, and with the demise of support for UFT, I switched to The Master Genealogist v4 (TMG) in 2000. Five years later, and I am now running the latest version of TMG, v6.0. Through all of these migrations, various elements of the database had to be completely re-edited to take advantage of the latest features of each package (the migrations from TMG v4 to v5 and then v6 have definitely been the most painless).
In addition, I have also switched from Ged2Web to the recently released John Cardinal’s Second Site to convert the TMG database into webpages – this conversion is largely automatic, using the defaults built into Second Site. I have been slowly adding to my web skills, and have used Perl to customise the HTML pages output by Second Site (such as customising the surname indices, into separate pages for each letter of the alphabet, instead of one big page, and by adding custom indices to the various peerages).
One other piece of software I have recently adopted is FSpeed Pro for calculating the degree of inter-relationship between individuals (the coefficient of inbreeding). I had originally written my own code (in Pascal) to compute this coefficient, but my attempt had a few limitations, including only being to look back about ten generations to find common ancestors for an individual, and taking about 2 days on a 3GHz PIV to run! FSpeed Pro is actually designed for use by animal breeders, but works just as well for humans.
Links for the providers of this software:
The Master Genealogist, v6: http://www.whollygenes.com
John Cardinal’s Second Site: http://www.johncardinal.com/ss/index.htm
Fspeed Pro: http://www.tenset.co.uk/fspeed/fspeedpro.html
Perl: http://www.perl.org
My website is currently hosted by www.jaguarpc.com for only US$10 per month. Unfortunately, being based in New Zealand, all ISPs in this country charge users per MB of data transferred, so uploading a zipped 35MB database to the website currently costs me about US$4 each time. With one upload per week or so, my operating budget is about US$25 per month (not counting new books and software purchases!). It was previously costing me about US$100 per month, before I switched to a host which supports uploading zipped files.
Sources
My first book on European nobility with some useful genealogical information was a very tattered copy of Debrett’s Peerage, 1949. In 1992 I downloaded a copy of Donald Reid’s Royal92.ged database, and integrated this into my own efforts. I then acquired and (slowly) input the relevant contents of a number of the standard royalty books (some good, and some not so good), including Eilers’s Queen Victoria’s Descendants, Weir’s Britain’s Royal Families, McNaughton’s Book of Kings and Louda’s Lines of Succession.
With this basic high-level background to European royalty and some descendants captured in my database, I have then focused on inputting as much information as possible about the British Peerage, entering information one family and title at a time. This process currently relies mainly on Cokayne’s The Complete Peerage and Burke’s Burke’s Peerage and Baronetage, with the assistance of various single family books. For example, compiling the Spencer family genealogy consisted of entering the detailed entries in Cokayne for the Earls of Spencer, and Barons Spencer of Wormleighton, expanding this from Burkes to include all the descendants of these peers, and then using Pearson’s Spencer Family and Spencer’s Blood Royal to round out the descriptions of the families.
About half way through this exercise, I acquired a copy of S&N’s Royalty database, and merged this with my own database. Given I already had around 20,000 quite detailed records at this point, and the S&N was around 106,6000 separate records (with little detail given and absolutely no sources), this merging process took me a considerable period of time. Any people in the database with no source information and cryptic notes are still a residue of this merge process.
For a complete list of the bibliography for my database, see http://www.thepeerage.com/s1.htm.
I have purchased most of these books through either Amazon (for the more recent new books), or through Abebooks (older used books), and highly recommend both of these websites for the dedicated book buyer.
Issues
In compiling this database, a number of issues need to be addressed as a result of the complexity of the underlying data, and the limitations of the genealogy software used. The main issues which arise are listed below, along with a discussion and rationale for my current chosen approach to addressing the issue. Any contrasting opinions on my treatment are welcomed (along with ideas on how to implement your suggestion in TMG!)
1. Language
The languages of Europe are many and varied (and actually have changed over time). Some books consulted translate names, places and titles into English, and others leave things in the original language. I haven’t consulted any books in languages other than English (except for the outstanding volumes of Europäische Stammtafeln), but assume that the same tendency to translate names into the author’s language occurs to a greater or lesser extent.
1.1 Alphabet
Indeed, even different alphabets are used by different languages. I have decided to show all names, places, etc. in the Western alphabet (translating Cyrllic or Hebrew characters into the equivalent Western characters where possible). However, I have tried to retain all the unusual symbols of each European language where supported by the Microsoft Basic Latin character set (e.g. à, á, â, ã, ä, å, but unfortunately not ā or ă). TMG still does not support Unicode, which would allow a complete set of all Western and Eastern European characters to be used, but presumably this will be addressed in the software eventually. In the meantime, I may trying to edit the HTML pages for the website to include all of the required characters.
1.2 First names
In some cases the first names of an individual are quite commonly expressed and more familiar in the English version (Tsar Nicholas of Russia, instead of Nikolai), in other cases the native language first name is quite familiar to English-speaking people (e.g. Kaiser Wilhelm II of Germany, rather than William II). I have decided to show all first names in the native language of the individual, wherever possible, translating back from English to the relevant language. The standard translations of first names from English into other languages I have used are shown in http://www.thepeerage.com/foreignnames.htm).
Where an individual was based in several different countries, and more than one language could logically be applied to him, I have used English if this is one of the languages, and otherwise have attempted to use the language I believe to dominate his life (e.g. Elector Georg I of Hanover is also King George of England, and so I have used English).
1.3 Titles
I have tried to show titles in their native language version (e.g. Herzog for a German Duke, Marchese for an Italian Marquis). However, there are a few languages where I am not very confident of the native language system of titles, and so just use the English versions as shown in my sources (e.g. Danish titles, Polish titles).
1.4 Places
I have decided to show all place names in the language of the appropriate country (e.g. Köln rather than Cologne), except, perversely, I have decided to retain the country name in English (so Germany rather than Deutschland, and therefore Cologne becomes Köln, Hannover, Germany ).
2. Changing Place Names and Countries
Of course, over the last 1000 years place names keep changing, country names keep changing, and the country which each place is in also changes. So somebody born in Strasbourg, France in 1865 may have died in Strasburg, Germany in 1942.
I have elected to translate all place names into the latest version which one would find by looking up a contemporary atlas, unless the original source showed a particularly unusual or difficult to translate into modern usage place. For example, numerous knights are indicated as having died in ‘the Holy Land’ – not clear if this in Israel, Syria, Lebanon or Turkey, so best to just stick with ‘the Holy Land’.
However, once I can figure out the best approach to do this in TMG, I would like to show the history of names for a given place and over what dates they applied (e.g. to show that Strasburg was Strasbourg, France before 1871, Strasburg, Germany for 1871-1918, Strasbourg, France for 1918-1940, Strasburg, Germany for 1940-1945, and has been Strasbourg, France since 1945)
3. Place Name Format
The standard place name template available in TMG v5 is Detail, City, Latitude/Longitude, Temple, Province/County/Region, State, Country. For European countries, I have not used the Latitude/Longitude, Temple or State fields (although I have used State for U.S., Canada and Australia locations). I have now begun to use the Temple field and a custom place style to show the common English name for cities with a different native language name (so for Rome I have City: Roma, Country: Italy, Temple: Rome, and a style which displays this as 'Roma, Italy (or Rome in English)'.