Article rating: Technology, Intermediate
Senior Research Analyst
Forum for Digital Culture, University of Chicago
The Florentine Catasto of 1427
To drum up wartime funds, the city of Florence in 1427 conducted a thorough tax census of residents, religious institutions, and guilds. In this census, known as the Catasto of 1427, residents of the city declared the occupants and income of their households, their professions and religious affiliations, their tenants or landlords, and the physical locations of thousands of their residential and commercial structures. However, the Catasto uses an idiosyncratic system of describing location that is almost entirely relative. Lacking a fixed system of addresses in the modern sense—or standardized street names—respondents in the census located themselves by reporting the names of their immediate neighbors. Following such a method, Person A would declare their property as having the neighbors—known as ‘confini’ (sing. ‘confine’)—Person B and Person C. Person C, in turn, lists Person A and Person D as confini. Person B and Person D in turn list their confini, allowing us to theorize the arrangement of the four properties.
These confine relationships (along with owners, renters, home parish, and a description of the structures on the property as given in each declaration) are stored in OCHRE. However, we still lack enough information to pinpoint the location of this set of four properties in geographic space. Further declarations of nearby properties must be reviewed, and street names and landmarks must be identified; however, as the list of confine relationships grows, it becomes increasingly difficult to track the tangle of neighbors without a visual aide. Fortunately, for this analysis, we can turn to a network graph. Because OCHRE offers built-in visualization tools, including a network graph feature, there is no need for us to export and reformat our confini to another program; the full workflow can be accomplished within OCHRE.
When managed in OCHRE, every declaration is stored as a Concept object and assigned an alphanumeric project label. In declaration S126, owner Iacopo di Piero Deti describes his property as 5/8 of a row of houses, known the Albergo (an inn) di Cammello. This property’s front street—functionally, the first confine—is via Porta Rossa (an extant street, still known by this name in the present day). Its second neighbor is via delle Terme, another extant street. Its third confine refers to ‘Michele del Bene’.
Michele del Bene makes a declaration of his own, assigned the label U185. This property, described as his own house, additionally declares via Porta Rossa as a first confine, as well as via delle Terme (as the third). Crucially, however, he declares as a fourth confine ‘the Albergo di Cammello, owned in part by Papi Deti’. This confirms the properties described in S126 and U185 as neighbors.
Tracking this relationship in OCHRE requires two link variables. In the example above, the link ‘Has declared confine …’ is added to declaration object S126, with the Person object ‘Michele del Bene’ as a target. This variable additionally creates the inverse link ‘Is declared confine of …’. However, this link is coupled with a second (with no inverse relationship) link variable, ‘Confine refers to …’, with the declaration object ‘U185’ as a target. A similar link is created in declaration U185 itself, marking S126 as the target of the link ‘Confine refers to …’.
After reviewing and analyzing other referenced individuals in these (and related) declarations, additional ‘confine’ links are identified, and their declarations are loaded into a single discreet OCHRE Set for visualization.
Creating the graph
With the Set selected, we navigate first to the View pane. In the View menu, select the View items collectively in Chart View icon, which will present several chart options.
To visualize the links we have established between declarations, select Network Graph. Then, switch to the Content tab. Under Source, select Given item. This will add each declaration in the Set to the graph as a node (an individual unit).
Switch to the Target tab. The Target node must be the object to which a given node is related; in this case, the declaration identified as a confine of the source (‘U185’ is a Target of ‘S126’). Thus, Value of the selected relational property(s) must be selected as the Target, and ‘Confine refers to …’ selected from the list of Relational properties, as it is this variable that holds the confini data. This will generate connective lines between the nodes—known as ‘edges’—representing the identified neighbor relationships.
In addition, selecting the Labels tab in the Format specifications pane to the right will allow us to use either the object’s Name or Abbreviation as a label for the node.
Click Draw Graph. By default, the graph will use the Hierarchical Layout; however, Organic Layout will allow us to freely manipulate the positions of the nodes. The chevron to the left of the Draw Graph button will enlarge the graph area.
Now, it is possible to first click and drag the ‘Street’ nodes to correspond roughly to actual positions in geographic space (also added to this Set is ‘piazza Santa Trinita’, another extant street and plaza). The ‘declaration’ nodes can then be arranged within the street nodes, with—ideally—no overlapping edges. From this model, the approximate positioning of all these theoretical properties begins to emerge.
Enriching the graph
Additional dimensions of data can make this analysis easier. As noted, no official street naming system existed in Florence at this time. While some major streets were popularly referred to by names which survived to the present day—and some residents appear to have developed monikers to refer to shared alleyways—it is extremely common for declarers to describe their first confine as merely ‘via’ (street). This vagueness, however, can make orientation within the block difficult. Consider the following network graph, illustrating the known confine relationships among several declarations.
With the aid of the network graph, the described properties appear between via della Vigna Vecchia and via della Burella (note that declarations which do not name a specific street do not have edges linking them with either street node). This allows us to place the properties on the block the project has codenamed 254, but not enough street information is available to determine the east-west orientation of this line of structures within the block. However, many declarations do hold other useful location information, which will augment the graph.
At this point in time, parish boundaries defined which church a resident would be expected to attend for regular worship. These boundaries have certainly fluctuated over the decades as new parish churches were consecrated and aging parishes were closed or integrated, and the exact boundaries of 1427 are not currently known. However, many declarations do state within which parish the property falls, and because the locations of the churches are known, parish information offers a clue to the proximity of a property to a given church.
To color-code each declaration node by parish, we can create a Project Style. Under the Sets & Specifications category in the main navigation side pane is the Styles hierarchy, containing Master project styles. Select the Create new item command on the far right of the Symbologies pane. In this example, the new Style is labeled ‘Declaration view’.
Here, it is possible to assign colors to nodes based on specific variables from the taxonomy, in the same manner as a user adds variables to an object. As each node in the graph represents a single declaration, variables from the declaration taxonomy can be assigned as features for color-coding (in this case, ‘Declares parish’).
Once a ‘Declares parish’ value is selected, click the Symbology field, then select the Define style features button.
This will open the Symbology editing window, with several formatting options. To color-code the property nodes by type, select Background/Fill color under Polygon format/Text highlight; a number of different color selectors are offered.
In this example, four different parishes in the vicinity of block 254 are selected.
Now, we return to the set. After creating a new network graph, with Source selected under the Content pane, select Override from the Source: Format specification section on the right. Under the Select style dropdown, choose the Style that we have just created (note that the ‘Edit project styles’ button will also bring up the styling editor; users do not need to navigate back to the Master project styles list to make changes to existing Styles).
Then, select Target from the Source section, and once again select Override from the Source: Format specification section and choose the new Style from the Select style dropdown. Click the Draw graph button once more to ensure that the changes take effect. If a node item does not contain any values defined in the Style (in this case, if a declaration does not have any parish information), that node will retain the default styling.
In this graph, the parish of San Simone is represented in blue, and Sant’Apollinare in chartreuse. In actual space, the church of Sant’Apollinare lies to the west of block 254, with San Simone immediately to the east. Thus, it would seem likely that properties declaring San Simone as a parish would align to the east, with the Sant’Apollinare parishes to the west, and the network graph as arranged is likely accurate.
In the early stages of the CATASTO project, three separate tools were necessary to perform all steps—logging confine relationships, collating the data into lists of nodes and edges, and importing the data into a program for network visualization—of this type of analysis. However, with our workflow entirely in OCHRE, labor time as well as the risk of errors and data loss are reduced.