Jamel Ostwald's
Gateway to the Early Modern World



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).

Personalities.jpg (87032 bytes)

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:

PersonalitiesID Autonumber primary key. This is the foreign key for all the other tables.
Person Common name person goes by - I try to keep the name as short as possible unless there is more than one person by the same last name (see Austrian generals for an example). As this table expands, I'll probably have to switch over to full names.
I've also made the combo boxes on these tables' forms display the YroB-YroD for each person as an aid to figuring out which person a document is referring to (I could include additional fields as well). You can even show what post or rank they held based off of the date of the document in the current record.
Last Name Surname
First Name Names other than surname or name of title.
Full Name Name as it is found in a reliable source, in case I missed something, or mistranslated a title or place name.
Title Title of person. Anglicized unless non-English equivalent is deemed important. Note that this is a subtable/form, so one person can have several titles (the Title button opens a pop-up form where you can enter more info on the titles).
YroB Year of Birth
POB Place of Birth (town if possible, which would elsewhere be linked to province and country)
YroD Year of Death
Age at Death Calculated from YroD-YroB, or from DoD-DoB if you have exact dates for everyone. I could also make a field in a form  (e.g. the Notes form) that might say how old the Person is at a given point in time, such as when a document is written, or when they are in command of X, although you would be more likely to do this in a query.
Family Subtable with fields for relatives' names.
Position Subtable/form for each position/rank a person holds. For lower ranks, you would link them to a specific regiment (from a separate Regiment table). See Position/Rank issues below.
Service Whose service was the person in?
At EventID These are subforms run off queries, which automatically looks up all the events this person was in. I haven't quite figured out the smoothest way to integrate this, since right now the relationships require each Person in however many Armies (you can see the numerical ArmyID code in the In Theater subform), each Army in however many Event's, each Event in a Theater. But the problem is that some civilians might not be associated with an Army at all, so I also need a Person is in NoArmy which is at EventID... I haven't figured this out yet, so suggestions are welcome.
In Theater These are subforms run off queries, which automatically look up which theater this person served in each year. I haven't quite figured out the smoothest way to integrate this, since right now the relationships require entering each Person in however many Armies (you can see the numerical ArmyID code in the In Theater subform), each Army in however many Event's, each Event in a Theater. But some civilians might not be associated with an Army at all (e.g. a neutral observer or a diplomat), so I also need to be able to have those events come up as well with Persons unconnected to a particular Army. I haven't figured this out yet, so suggestions are welcome.
CiteFullName I also created a CiteFullName button (not pictured) that concatenates the full name of a Person. This makes it easy to paste the full name directly into a Word document when I need to introduce the person for the first time. E.g.: the Duke of Burgundy being Louis Bourbon, Duke of Burgundy (or duc de Bourgogne).

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:

Additional features (to come):

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