Formatting and Populating the Places Table and the DocumentPlaces Join-Table
Filling the empty Places and its related join-table (a process comparable for Agents) was a daunting task. To begin, then, I identified three main tasks that I needed to accomplish:
- Create a list of places (each with a unique, serially generated Place ID) that are related to the documents. This would constitute the Places table.
- Determine the information that I would need for each place, independent of its relationships to the documents. I would need geocoordinates to locate it with cartographic software, for instance. I would also need to compile a list of alternate spellings for each place, a deceptively simple step which would require the choice of whether to prefer modern Polish or German spellings, medieval Polish or German spellings, or some combination.
- Determine the information that I would need to qualify each place’s relationship to a particular document. Whether the place was a city, institution (church, monastery), group (burghers), convent, and so on; complicating this step is that the same place name (Torun, for example) could refer to any number of these distinct locations, which could only be determined from context. Details such as these would go into the join-table.
The first two tasks would thus go into creating the Places table. The third task was associated with creating the DocumentPlaces join-table, which could only happen after the Places table was formed.
Populating the Places Table
The simplest way to assemble the list of places to populate the Places table would be to go through all 4,959 documents by hand and compile a concordance. Thankfully, Gabe showed me how to manipulate the value-list function in Filemaker instead.
Within Filemaker, I created a new, unrelated table into which I imported all the “places” from my Excel spreadsheet. I then created a value-list in Filemaker based on these imported values. In effect, the software automatically compiled a concordance that I could print into a field of the new table, then copy and paste into a text file.
The result was a list of roughly six hundred place-names. I then went through the list, manually eliminating duplicates and condensing the list into “standard” place-names complemented by alternate spellings. This process was not only time-consuming, but also required a good deal of research. Very similar place-names were often alternate spellings (or misspellings), but could also easily be completely different places.
On another level, this process required that I make the arbitrary (yet necessarily political) judgment of which spelling or name to designate as the “standard” one. For the most part I decided to designate the modern German spellings as “standard” since they usually corresponded best with the most frequent usage in the medieval sources. The outcomes of this decision, both in the resulting structure of the database (that is, each Place ID would be associated with the “standard” Place Name) and in its political ramifications (choosing “colonial” German spellings over Polish ones), is a good example of how the structure of a historical database like this one easily becomes saturated with the conscious and unconscious biases, constraints, and tastes of the historian who creates it. In sum, there is no such thing as raw data.
Once I had a clean list of place-names with alternate spellings neatly compiled in a spreadsheet, I simply imported the list into the Places table. Filemaker automatically generated a serial Place ID for each entry, and the Places table was born.
Populating the DocumentPlaces Join-Table
With a complete list of places and documents, the next step was to track their relationships through the DocumentPlaces join-table. Again with Gabe’s assistance, I learned how to write a script in Filemaker to complete this task. As with each step in the creation of the database, it helped to assemble a list of tasks that I needed the script to accomplish in order to populate the join-table. These included:
- Beginning with the first place (Place ID 1), record the Place ID and place-name.
- Run a search for the recorded place-name in the “temp_place” field of the Documents table to find all occurrences of that place.
- Create a new entry in the join-table for each result of the search, entering the relevant Document ID and Place ID.
- Create a field in the join-table for the relation to the document. If a place is indicated as an “Origin” in the Places table, record this in the join-table in this new field (and the same for “Destination”).
- Repeat the first four steps for each place in the Places table.
The script for populating the join-table essentially instructed the software, in minute detail, to run through these steps. The complete script is copied to the left.
As long as the tables are properly linked, other fields directly related to the Document ID and Place ID in their respective tables can be automatically filled in the new join-table. For instance, the “Place Name” field from the Places table can be added safely and conveniently to the join-table. Any changes made in the parent-table will automatically update in the join-table, but Filemaker will not allow accidental changes to the parent-table through the join-table.
As shown in the screenshot to the right, the join-table can track information about the relationship between documents and places through “local” fields, as well as fields from directly related Documents and Places tables, and even from indirectly related tables like Dates, which is related via the Documents table.