Posted: Dec. 8, 2014, 9:43 a.m. by Rachel Stone
Many charters include explicit information about agents (individuals, groups and institutions) that is of interest to record. For example, we may be told attributes of agents, such as their ethnic identity (Lombard), their legal status (unfree), their title (bishop of Bergamo) or even the fact that they are dead by the time a particular charter is written. We may also be told about the relationships between two agents: that Fulrad is abbot of Saint-Denis (monasteries and churches are regarded as agents) or that Pippin III is the father of Charlemagne.
The Prosopography of Anglo-Saxon England (PASE) database records such information in a number of different categories of factoids for status, occupation, personal information, relationship etc. The People of Medieval Scotland database similarly separates out “titles/occupations” from “relationship type”. The Charlemagne database, however, records all this information in a single “attribute/relationship factoid”. Looking at our data, however, we realised that a model that distinguished attributes from relationships would arbitrarily separate out very similar types of statement.
To see this, consider office titles, which frequently included some kind of qualifier. We knew we could expect to find examples like the following statements in our charters:
1) Alcuin, abbot of St Martin's abbey (Tours) (qualifier is institutional agent)
2) Abbot Alcuin (no qualifier)
3) Arno, bishop of Salzburg (qualifier is place)
4) Tassilo, dux of the Bavarians (qualifier is ethnic group)
5) Charlemagne, king of the Lombards and Franks and patrician of the Romans (2 separate offices with qualifiers of ethnic groups)
6) Our most glorious king Charlemagne (no qualifier)
In terms of pure logic 1 (and possibly 4 and 5) should be treated as relationship factoids and 2, 3 and 6 as attribute factoids, but in practice we wanted to keep references to Alcuin as an abbot or Charlemagne as a king together. The decision was therefore made to create a combination attribute/relationship factoid, which could record statements in which:
An agent (Agent 1) has an attribute/relationship. This attribute/relationship may in addition link Agent 1 to another agent (Agent 2) and/or a place.
Whenever possibly, we used English terms for the attribute/relationship term, but this was linked to a field allowing one or more Latin terms to be input, reflecting the actual wording of the charter. This allowed us to produce meaningful categories for non-specialist users (e.g. “mother”), while retaining the option for those with a particular interest to distinguish between the use of “genetrix” and “mater”. Some attribute/relationship terms, however, such as “missus” and “colonus” which cannot not easily and succinctly be translated were left in Latin.
The data structure of an attribute/relationship factoid is therefore of the form:
Data conventions
As usual with the type of data (early medieval charters) with which we’re working, the problem was less the data structures themselves than ensuring that data was entered consistently. This was especially the case because we had such flexible data structures. We needed to decide, for example, which statements should be taken as referring to one agent and which to two. We have treated statements such as “Opportunus is abbot of Mondsee” as concerning two agents. In contrast, we decided to record bishops as linked to a place (the city of the diocese) rather than to the episcopal church within such a city, even if that existed as an agent. Since a phrase such as “Giso per misericordiam Dei Mutinensis episcopus” (Giso by the grace of God bishop of Modena) tells us nothing about the relevant episcopal church, we chose a pattern that seemed likely to allow us to enter bishops’ diocese more consistently. When a bishop is acting on behalf of his episcopal church, however, that is recorded via agent roles.
We also decided that we would not record phrases such as “Tassilo is duke of the Bavarians” as indicating a relationship between Tassilo and some nebulous and anonymous group of Bavarians. That seemed to us to multiply agents unnecessarily. Instead “duke of the Bavarians” and similar titles for rulers are treated as a single attribute. However, in order to allow easier browsing and searching of titles we do split up a phrase such as “Charlemagne, king of the Franks and Lombards” into two separate statements: “Charlemagne is king of the Franks” and “Charlemagne is king of the Lombards”.
Another issue was deciding how or whether to record circumlocutions for attributes and honorifics. The charters from Wissembourg, for example, record abbots in different ways and may not even explicitly say that the current abbot is abbot. For example, Wissembourg 20 refers to “sacrosancto monasterio cuius uocabulum est Uuizeburg...ubi uir uenerabilis Iustolfus episcopus preesse uidetur” (the holy monastery which is called Wissembourg...where the venerable man bishop Justulf is seen to preside). Because our emphasis is on comparable socio-economic information rather than precise wording, the decision was made to record such a statement as “Justulf is abbot”, but not to record the Latin term “abbas” in such a case (allowing users to distinguish such cases implicitly).
For similar reasons, we did not record epithets that we considered to be rhetorical more than conveying specific information on status, office, title etc. Charlemagne may describe himself as "Karolus serenissimus augustus a deo coronatus magnus pacificus imperator Romanum gubernans imperium" (Charles the most serene emperor, crowned by God, great and peaceful emperor governing the Roman empire), but we cut him down to “Charlemagne is emperor of the Romans”, with Latin terms “imperator” and “augustus”. Similarly, we record people as “venerable” only if they have no other official title and we do not record people as being saints. We will, however, record people as “noble” if they are explicitly said to be so, since that may epithet may reflect a social status as well as a moral comment.
Complex relationships: neighbours and the unfree
The use of a data structure which allowed linking to both a second agent and a place allowed us to develop standardised methods for recording social relations created by adjacency. A number of charters include the statement that a particular piece of land being transacted bordered on land held by another named agent. Such information can allow us to build up a more detailed picture of how agents relate to each other spatially and socially and we were therefore keen to record such information. We decided to record such agents specifically as having the relationship of “neighbours”, so that if Agent X is transacting property in place Z which borders on the property of Agent Y, we record a statement of the form: “X is neighbour of Y” with Z as associated place. We also set up the input system, so that once we input this factoid, it would automatically generate the additional (transaction) factoid that “Y holds property at place Z”.
A more complex decision was how to deal with the relationships of the unfree and other dependents to their lords and masters. In theory the unfree always exist as part of such a relationship: A is a dependant/slave/serf of some agent X (whether a person or an institution, such as a monastery). In practice, this is rarely explicitly stated in charters. In the vast majority of cases X says that they give manicipia A, B, C to Y without stating that these people are actually theirs in the first place; it is simply assumed. Did we need to record this implicit assumption or would it be potentially misleading to do so?
We realised that there were likely to be very few charters where servi, mancipia etc were mentioned where they were not the object of a transaction. In the case of a transaction the relationship to other agents will already be indicated via the “granter” or “recipient” role. We therefore decided that the various categories of unfreedom and dependency should be regarded as an attribute of a particular agent, but that their relationship to their previous and future holders did not need to be recorded explicitly. For consistency, in the rare cases where the unfree or dependents of someone are not included (or explicitly excluded) from a transaction, they are recorded in a separate possession factoid (a sub-category of transaction factoids).
Dating attributes
The attributes and relationship factoid, like other factoids within the database structure, has the option to be assigned its own unique dating information. However, we decided that such factoids should always be given the date assigned to the charter from which they were derived. In some cases, this may produce paradoxical statements. For example, our record for Carloman’s charter no. 46 (DKAR 1:46) records a reference to “Pipini quondam regis” as the statements that “Pippin III is king” and “Pippin III is dead” and both factoids are dated to March 769.
Our reasoning was that we had a large number of such attribute and relationship factoids (an average of more than 8 per charter) and that using external information to date them was therefore unrealistic. It might be possible to date rulers’ reigns (and so identify when they died), but this became far more difficult and time-consuming when expanded to bishops, abbots etc. It was also not clear what external sources we could use, since such dates are often unsure or disputed. Sticking to the date at which the charter was produced (according to the editor) gave a more modest, but also more consistent and better documented statement of possible dates for an attribute or relationship.
Displaying attribute and relationship factoids
We developed data structures for recording attribute and relationship data that proved flexible enough to meet our on-going requirements. The down side to this is that it’s been more difficult to devise methods for displaying such information in the most useful ways for users. We have not yet been able to develop rules for the consistent natural language display of attributes and relationships that will cover all possible cases.
We already have more than 200 different attribute and relationship terms, so any rules for display cannot rely on the database “knowing” the individual significance of them. Instead we have to generate more general rules, which can successfully cope with variations in the number of agents, in whether or not a place is mentioned and the additional problems if a place has only “Unknown XXX” for its modern place name. Considering such questions gets down to the most basic details of grammar: should the attribute be “bishop” or “bishop of”? If the “of” is included in the attribute, bishops whose sees are not mentioned in the charter will appear as “X is bishop of”. If the “of” is to be generated by the system, under what circumstances must it be added? Such matters require further painstaking and systematic consideration if they are to be made 100% accurate. For now, our hope is that users will be able to cope with the current rough edges of repetitions and omissions and grasp the meaning of the underlying data.
Difficulties of natural language also lay at the heart of another issue we contemplated: should the database include semantic knowledge of reciprocal relationships? We record only specific statements made by the charter: if a charter of Charlemagne refers to “my father Pippin” that is entered as “Pippin III is father of Charlemagne”. We do not record the indirect corollary of this: Charlemagne is the son of Pippin III.
This means that those interested in kin relationships will typically have to explore a number of terms to find all the examples in the database. At an early stage, we were interested in the possibility that we might be able to generate automatically such “reverse” relationships, if we set up specific rules. However, after further discussion this was not implemented. Part of the difficulty is that such rules are hard to specify. If “X is the son of Y”, that does not necessarily imply that “Y is the father of X”. Instead, Y might be X’s mother. Such complex interactions between relationship terms and sex make providing accurate rules for a database difficult.
But there is also a more fundamental problem. The natural language of kin relationships is slippery and supposedly reciprocal or transitive relations may not in fact exist. I may call both my natural half-brother and my adoptive brother “brother”, but they do not necessarily have any relationship to one another, let alone a fraternal one. Did Lothar I and Charles the Bald necessarily regard themselves as brothers, because they shared the same father, Louis the Pious? We decided to stick to a conservative strategy, in which only explicit relationships were recorded, and thus avoid making assumptions about ties that may not have existed or been acknowledged. Our recording of attributes and relationships provides standardised data of many types to users. It is left up to them, however, to reconstruct more complex family structures from these basic factoids.
Share:(Comments)
Comments