Jamel Ostwald's Gateway to the Early Modern World Gateway Research

Personalities table

Below is a screen shot from the Personalities table in my Access database. It is still quite rough, but you get the idea. For datasets of Personalities that could be easily imported into such a table and its associated subtables, go to the EMWWeb, or click here for a specific example of Austrian generals (~300 k).

There are several issues that immensely complicate tracking personalities. Most of the complications come from imperfect knowledge of all the actors in the data entry process. If my experience is at all typical (and maybe it shouldn't be), you go into the archives and start taking notes on letters, where you might find correspondence from Marlborough to Lewis (or Ludwig) Baden, from J. Churchill to the markgrave of Baden, from M. to Baden-Durlach, etc. If you don't know immediately where to find out who these people are and (probably wisely) don't want to waste precious archive time looking through archival reference guides, how do you design your database so that you minimize the number of errors and amount of additional entry you'll have to do later? Below are some solutions. You may not think you need all of them when you first start, but it's usually better to be safe than sorry. Some of the pitfalls include:

1) Especially in the early modern period, personal names were often misspelled (occasionally spelled different ways within the same letter!). Therefore, unless the correspondents are close associates, their name might be spelled incorrectly, perhaps phonetically instead: Marlborough, Marlboro, Marlbruck... (place names are even worse). Spelling is further complicated when you are dealing with correspondents who had different native languages: the Dutch general Ouwerkerk (modern Dutch spelling) often signed his name Auverquerque (the French version) and was known to the English as Overkirk. With all these cases, you need to decide which form you will use and keep consistent (unless of course you want to keep track of these variations, which would require an additional field in notes, and probably a subtable in Personalities to keep track of the variations). I prefer to use their name as written in today's native tongue wherever possible, e.g. Ouwerkerk.

2) Family names can be used over-and-over (everything from "Duke of So-and-So" to "John Peter Wilson" across generations). I resolved this issue by making the primary key a single field (Person) with a unique combination of their names (or a commonly-used nickname), linked to all the other tables you'll want to use people in. You tie the combo box on other forms to the Person field of the Personalities table and then you see their entire name in all drop-down lists and choose the one name. Most business databases normalize a person's different names (first, middle, surname) by making three separate fields. You then can insert "Dear Mr. [LastName]" when needed and concatenate the names together; you use a numeric ID number for foreign keys (Customer#, SS#...). Having separate fields for first and last names can really slow down data entry however, so I use the single Person field for data entry: instead of selecting "Philip Frederick" in one field (or "Philip" in a first name field and "Frederick" in a 'middle' name field) and "Vegelin van Claerbergen" as the last name, you just select "Vegelin van Claerbergen." Where there are several people (e.g. relatives) active at the same time (there were at least three VvC's active c. 1710), the last name by itself is reserved for the most commonly used person in the Person field: e.g. the ubiquitous Philip Frederick's Person field would be "Vegelin van Claerbergen", while his younger brother Johan would be "Vegelin van Claerbergen, Johan." Then you need only type "veg" before autofill adds Philip Frederik's record - since it sorts alphabetically first among the three Vegelin van Claerbergens. If you need one of the other VvC's, you can simply down-arrow to the appropriate choice in the combo box. With this method, you can still alphabetize by the Last name field from the Personalities field when you need to (in a query or whatever, or you could even sort on that in your combo box and just not display the Last Name field), even as you keep the Person field your primary key.

3) As a person's rank changes, often times so too does their title. You need to keep track of these changes (John Churchill was Earl of Marlborough, made First Duke of Marlborough, and this title has been passed down ever since). A letter might be addressed to the Earl of York and there were several Earls of York (e.g. father and son), so you need to keep them all straight. Sometimes you can avoid this problem if you have code that checks each person's date of death and verifies that the author you've entered was not dead when the letter was written (the recipient could, however, be dead, e.g. the recipient died suddenly and the author didn't know about it before sending off the letter). You can further minimize errors by including in your drop-down list the positions each person held and when: either show the date range or else display only those positions they held at the date when the letter was written. Note also that careless authors might not even have the proper rank/title for their recipient - AAARRRGGHHH!!!

4) A person's name might change drastically. Switching from the Earl to Duke of Marlborough is easy to handle with the PersonTitle subtable (one Person can have more than one Title, held either sequentially or at the same time if you include fields for DateStart, DateEnd), but on occasion someone changes their commonly-known name completely: the chevalier de Luxembourg becomes the prince de Tingry, or Jennifer Smith marries and becomes Jennifer Henson.

4a) If you want to trace a person whose name changes dramatically over time (e.g. the chevalier de Luxembourg/prince de Tingry), you will have to search under every name, an annoyance at best and you might not even know off hand all the names a person went through in his life (you could include aliases in this as well). You could deal with this problem by making the Person value include both names (e.g. Luxembourg/Tingry) and then search with wildcards to find those names singly. This is a bit ugly, but at least it reminds you that the name did change. Or you could do a more complicated arrangement of keeping track of each, perhaps with a separate title field.

4b) But what if you want to compare a person's correspondence between two periods associated with name changes? To make up two examples, say you want to see if Luxembourg started writing to those with higher status once he became the prince de Tingry, or you want to see if the topics of letters between two people vary by whether they address each other by a nickname or a more formal address. With only a numeric PersonalitiesID field as Author/Recipient, you have aggregated your data upwards so that you can't distinguish from these fields which is which. You will therefore need to know when each person's name change occurred, so that you can use that date as the cut-off. If this information is not readily available, an alternative, admittedly more complicated, solution is to keep Luxembourg separate from Tingry, using both a PersonalitiesID and a Person field. When you enter the Person name in the Notes form, code will automatically enter the corresponding PersonalitiesID of that Person into a (hidden) PersonalitiesID field, so that you do not lose any data by aggregating upwards.

5) For the Notes form, you can also have a field that records exactly who the letter is addressed to, in case you are paranoid about confusing one Duke of Baden for another. Perhaps you don't even know whether the Johan Vegelin van Claerbergen letter sitting in front of you was sent by the same person as a previous letter in your notes from Vegelin van Claerbergen. Perhaps you aren't positive who the author/recipient is at the time of data entry, or you want to compare the different ways a person was addressed. With this additional field you would have both standardized and transcribed versions of the recipient. You could then choose to have either field appear in your citations: "Capt. Smith to Brig. Pulteney" or the more formal, informative name, "Captain John Smith to Brigadier Josiah Pulteney."

6) With historical documents, unfortunately, you don't always know the author's or recipient's full name. So I've included the ability to enter new names on the fly from the Author, Recipient, Person Mentioned fields - ideally as records for those people are created in the Personalities table they should be flagged so that you can later go back and fill out the full information on the person. It would also be nice to have a feature that searched all the names of everyone in your database to see if there are any matches.

Below is a list of some of the fields and their descriptions:

This form is still a work in progress, and since it has a low priority for me, don't be surprised if many things are missing and if the layout looks rough. In fact, I still don't know how best to keep track of the numerous positions a person held. One particular issue still bugs me:

• Each Person can have several different types of positions at the same time: military, political and/or religious. Should I display these separately (by type of position) or altogether in one form?

Additional features (to come):

• You can include images in your database (actually you'd want to just link them to your database in order to avoid bloating the database's size), so you could click on the Portrait button and a scanned image of the person would appear in a pop-up window.
• You could also keep track of the wounds suffered by individuals in specific combats. Don't ask me why I put that in there, I just noticed that older literary histories throw that kind of thing into their prose for flavor.
• I suppose this table could be expanded to do more genealogical functions, but that's very low on my list of things to do.

I would appreciate any suggestions on my Personalities database's organization, any fields that should be included, etc. There is a lot of genealogical software out there specifically dedicated to tracing genealogies and lineages. This database, however, is meant only to provide basic information on each individual (Author, Recipient, Person Mentioned in text), including basic biographical information, and particularly the various posts, positions and ranks held by them and their dates of service as well as who was at a particular event or place. With this information, you can not only find details on an individual quickly, but you can also quickly find what rank/position a person held at a specific time, and you could even do rudimentary prosopographical analysis on the people, as well as tying their personal data to other variables. I have just started looking into how it might be used to help explore social and interpersonal networks. See Sample Queries for examples. One of the most important part of this table, for my purposes at least, is the ability to link these people to the various military events (battles, sieges, etc.) that they participated in, and more generally, where they served each year. That way, I can run a query that will list who commanded where every year, what people were involved in what combats, etc.

Last Edited March 28, 2003