Rupert Shepherd
Ashmolean Museum, Oxford, UK (formerly University of Sussex, UK) ¹

Databases and Art History. The Material Renaissance Project: Costs and Consumption in Italy, 1300–1650

Keywords: material culture, Italian Renaissance, currency, exchange rate, database

Introduction

Unlike the other contributions to this conference, this paper describes a project which saw the adoption of what was basically a low-tech, off-the-shelf solution to the problems which it set itself and which, whilst functioning satisfactorily, has not been as successful as it might have been. However, it is for precisely these reasons that our experiences on the project raise some interesting issues about the more mundane kind of computerised research project which many of our colleagues may be embarking upon, or at least considering.

The Material Renaissance Project

Before discussing the Material Renaissance project's database, it is worth outlining the project itself. ² It is a collaborative three-year research project, funded by the Art and Humanities Research Board (AHRB) and the Getty Grant Program, involving 16 academics and postgraduate students, divided over 6 universities in the United Kingdom and Italy. The principal investigator is Dr Evelyn Welch, an art historian at the University of Sussex. Having started on 1 October 2000, the project has another year to run before it formally closes on 30 September 2003.

A fundamental part of the project is the creation of a database of prices, wages and exchange rates for Italy during the period under consideration. As with all AHRB-funded projects, this will be deposited with the Arts and Humanities Data Service for use by the wider scholarly community at the end of the project.

The project's subtitle, Costs and Consumption in Italy, 1300–1650, summarises its concerns. It aims to investigate a series of issues centred around:

• the comparative prices of different types of goods in Renaissance Italy;
• the market for domestic goods such as food and clothing;
• the market for objects now considered 'art';
• changes in the relationship between the marketplace and individual or institutional artistic patronage over time;
• whether art objects were bought and sold in ways that distinguished them from other commodities;
• the gendered nature of Renaissance consumption;
• how social communities of buyers and sellers were formed;
• the different means by which objects were acquired in courts and republican communities.

The project's database aims to record prices because, in order to explore issues of cost and valuation, we need to know what things cost (and what factors may have influenced those costs and values). It will include wage-rates because they provide some sort of context in which to place different prices. And the complexities of the Italian monetary systems at this date mean that a good series of exchange rates are vital if these various data are to be compared in any potentially meaningful way.

However, that project is not intended to create meaningful statistical series of data. Rather, we hope to be able to produce a range of prices for a particular kind of good at any one time and/or place; to be able to suggest what a particular sum might have been able to purchase at any particular time and/or place; and to be able to show how the values attached to particular kinds of good may have varied according to various factors. Consequently, the Material Renaissance database is not a grand multimedia production: it is a database of text and figures, not of images. Rather than hold information about works of art, it aims to provide a much broader context within which issues of the reception, marketing, valuation and consumption of works of fine and decorative art can be assessed.

Problems and Solutions

But such apparently straightforward aims in fact mask a series of quite complex problems.

The argument for the euro: moneys

The first of these is the overwhelming complexity of Italian moneys during the Renaissance. First, there is the sheer quantity of different moneys. Nearly every town seems to have had its own money: not just every state (of which there were enough), but every town within that state.³ And within any one town, there were usually a variety of different moneys with which one might reckon a price or a value. These can be differentiated by the metal on which they were based – gold, silver, or various alloys of precious and base metals – and by whether they were represented by real coin, or were simply notional currencies – so-called 'moneys of account'. Thus, a large city like Rome, Venice or Florence, might use up to five different types of money:

• gold coin,
• gold money of account,
• silver coin,
• silver money of account
• base coin

and each of these types could itself contain several different moneys.

To add to the confusion, these moneys only seldom bore any straightforward or fixed relationship with each other. The continual problems of changing relationships between metals, devaluation and debasement facing the vast majority of early-modern moneys meant that the frequent attempts by the authorities to fix exchange rates usually came to nothing very rapidly, and exchange rates within a town (never mind from town to town) would quickly vary once more – usually on a daily basis (if not more frequently). One feels that Renaissance Italians would have welcomed the introduction of the Euro with open arms.

Clearly, then, the database would have to deal with valuations expressed in a plethora of different moneys, none of them in any fixed or stable relationship to each other. The result was that extensive sets of exchange rates between moneys are vital if the project is to make any practical, comparative use of the data expressed in these various moneys.

But this is not all. As some readers may recall, decimal moneys are a comparatively recent introduction. Many Italian Renaissance moneys were based upon the Carolingian system of a libra of 20 solidi each comprising 12 denarii – otherwise known as £.s.d, the old British pounds, shillings and pence – so that one libra was made up of 240 denarii. But, Italy being Italy, things are not that simple. There were in fact at least three different ways of subdividing a libra (or, in Italian, lira); these are laid out in table 1.

Table 1. Variations on the lira, soldo and denaro.

And, of course, lire, soldi and denari are only one convention for the sub-division of moneys in Renaissance Italy. At the moment, the database is set up to handle five different forms of money, and these are outlined in Table 2. I should note that I have made no attempt to include the much more complicated Neapolitan system of sub-dividing some of their moneys – I took one look at this and turned away in horror.

Table 2. Some possible ways of sub-dividing Italian moneys.

Rather than try and do sums in various combinations of pounds, shillings and pence, I decided that all moneys would have to be converted into a decimal for the purpose of calculations; they would then need to be converted back from decimals to the different forms in which they were each expressed, as shown in Table 3.

Table 3. The shift from Renaissance moneys to decimals and back again.

This means that each sum stored in the database must be capable of expression in five different forms of money, plus the decimal used for calculations. Once account is taken of the sub-divisions of each money, then each sum stored requires thirteen different fields:

1. lire
2. soldi
3. denari
4. lire affiorini
5. soldi affiorini
6. denari affiorini
7. lire manca
8. soldi manca
9. denari manca
10. decimal units
11. decimal hundredths
12. units
13. decimal for calculations

For all this to work, each time a sum is entered into the database, the database would have to perform the following tasks:

1. look up the way the money being entered broke down;
2. using this information, select the calculation required to convert it into a decimal;
3. convert the sum into a decimal.

Then, when the time came to performing a calculation using this data, the database would have to take the newly-calculated decimal, and:

1. perform the calculation;
2. look up the way the money being used broke down;
3. convert the result back into the original form of money.

The net result was that I had to learn how to write a great deal of code in order to perform the necessary calculations.

Three kinds of ounce: units of measurement

Just as each Italian town had its own moneys, so each town had its own units of measurement.⁴ Needless to say, these were not identical, nor – in many cases – even close to one another. To take just one example, the Roman boccale which was used to measure oil was, at just over 2 l, a little under twice the size of the Florentine boccale, which came in at a little over 1 l. But this is not the only problem – different measures, often with the same name, were used to measure different goods: both Florence and Rome used different-sized boccali when they were measuring wine from when they were measuring oil. So, in Venice, there were two kinds of ounce: the oncia grossa and the oncia sottile, the full ounce and the short ounce. The short ounce weighed only 63 per cent of a full ounce. They were used to measure different kinds of good – but it is very difficult to find a clear and comprehensive list of which goods were measured using which ounce. (And, just to help matters, there is a third type of Venetian oncia, more akin to an Imperial inch – a unit of length, 29 mm long.)

Of course, it is not impossible to determine what many of these obscure units of measurement meant, or even what they equated to in metric terms (though some of them remain resolutely obscure); but, if we were to use the database to make comparisons between values of goods sold in different towns, then we had to be able to convert each unit of measurement into a metric equivalent. Beyond the work involved in finding this information, this meant that the database would have to perform another set of calculations if it were to be a useful research tool.

For units of measurement, I resolved simply to hold the data in the original units specified in the documents – expressed as a decimal – and then convert them to a metric equivalent for the purposes of comparison. This greatly reduced the number of fields and the calculations required in the database – but it did mean that the metric equivalent of each unit of measurement would have to be established before any meaningful calculations and comparisons could be performed using the data.

The Devil is in the detail: interdisciplinarity and its problems

The Material Renaissance project currently involves sixteen different researchers, who are economic historians, social historians, art historians, or combination of all three. Whilst I think we would agree that interdisciplinarity is, in general, to be encouraged, diverse approaches lead to the asking of diverse questions; and the more questions that are asked of a database, the more complicated it usually becomes.

Thus, in addition to recording the economic data that I have already outlined – exchange rates, wages and prices and valuations – several project members were interested in the ways in which buyers and sellers might form interdependent networks. As a result, they wanted to be able to track specific individuals through the database as they were involved in different transactions. This meant that an additional, prosopographical section had to be created in the database. But names in Renaissance Italy are notoriously inconsistent: the painter Perugino might variously be called Il Perugino, Pietro di Cristoforo, Pietro Vannucci or Pietro da Perugia. It would be impossible to expect the database to be able to identify automatically the same individual when referred to by so many different names, and so the task of identifying the same individual under different names falls to those who enter the data. They use the 'people management' form to enter the details of an identified person to the database, and then connect each individual record that refers to that person in any of the exchanges, wages or valuations tables back to the central record for that person (Fig. 1). Using the 'people management' form, they can then scroll through summary information that shows how that particular person was involved in all the transactions to which they have been related.

Fig. 1. The 'People Management' data-entry form of the Material Renaissance database.

In addition, initial discussions within the project focused upon the many different ways in which objects might be valued and paid for. Two problems, in particular, emerged: payments in multiple moneys, and payments in kind.

The first was a comparatively straightforward problem: quite often, payments would be made in gold coin, but the sum due could not be expressed precisely in gold coin – there was some small sum left over still to pay. This would be paid in silver coin – a second money. Say an annual salary of 25 ducats (gold coins) was to be paid quarterly; the payment due each quarter would be 6¼ ducats. But there were no quarter-ducat coins, so the equivalent – say 1 lira 12 soldi – would be paid in silver coin. As a result of this possibility, it was felt that the database should be able to record values expressed in two moneys at the same time.

As far as payments in kind were concerned, the problem was similar – a sum might be settled using money (as cash, promissory note or bank transfer) or with other goods – a payment in kind. In account books, such payments are usually listed with an equivalent monetary value, which means that they can be entered into the database as a meaningful form of valuation. Clearly, if goods were being offered in place of money, this might affect the price that was being sought for a particular good – perhaps higher to compensate for the inconvenience of converting a payment in kind into cash, perhaps lower because the payment in kind was made in some particularly desirable commodity. Either way, it would be useful to see if, and to what extent, payments in kind might affect values. Consequently, the database had to be able to record valuations made in kind, and to distinguish them from valuations made using moneys.

As a result of these two problems, rather than record a price as one possible unit of information, the database would have to be able to record it as up to four possible units of information: a valuation in cash in one or two moneys, and/or a valuation in kind in one or two moneys. If we remember that a sum in one money can be expressed using two or more out of 13 possible different fields, we can see how this decision meant that one valuation could be recorded using two or more of 52 different fields, as shown in Table 4.

Table 4. The different fields used to record one valuation.

Thus, it probably comes as no surprise to read that, given the need to calculate values such as total unit prices in original and decimal units, the database now contains, between its various tables, around 780 fields.

Standardisation

Another factor which had to be taken into consideration was less connected to the complexities of the initial data, and more down to human fallibility. In order to avoid the introduction of typos and inconsistencies into the data, some means had to be found of controlling the vocabulary used when entering data into the database – a means which could be dealt with by the most technically-illiterate art historian. The use of drop-down lists seemed the most straightforward solution for entering the names of moneys and units of measurement, places, types of good being valued or wage being paid, and various other data which served to standardise the vagaries of the original documents. These lists were based upon a series of authority tables – 13 in all. Failure to select a term in the list produces a form giving a list of authorised entries from which to select, as well as the option of adding a new term into the relevant authority list – which is only permitted after the data-enterer confirms that there really is no other suitable term (Fig. 2). As the same authority table can serve several data-entry forms, there are far more than 13 opportunities for these procedures to be triggered – and, therefore, a great deal of code to be written to make it all work.

Fig. 2. Forms for ensuring only authorised terms are entered into the Material Renaissance database.

The joys of Microsoft Access 97

Finally, there were the constraints imposed upon the database by the environment in which it was being created. Initial consultations with the University of Sussex Computing Service at the bid-writing stage meant that the bid was written, and funding secured, on the assumption that Microsoft Access 97, the University's preferred desktop database system, would be sufficient for the project's needs. As the University already had a site licence, and as Access was considered a fairly user-friendly program, there was very little allowance made for buying in additional software or technical expertise.

It should, by now, be clear that the database required by the project was actually quite complex, and it might be worth considering briefly why Access was chosen so readily, and why it was assumed that it would not require any very complex development to get the project's database up and running. Whilst I was not present at these discussions, which took place long before I was appointed to the project, it seems to me that there was a certain breakdown in understanding between those writing the bid and their advisers. I suspect that we are faced with an example of two sets of experts talking to each other and neither understanding the implications of what the other is saying. Consequently, the computing staff did not appreciate the huge number of variables involved in defining anything so simple as a valuation in Renaissance Italy, or the complexities of the many different monetary systems. Likewise, the art historians did not understand the extent to which a program like Access needs to be tailored to suit an individual set of data – particularly the fact that automatic calculations all have to be programmed into the database. To be fair, there is no reason why they should have done: what is taken for granted by one expert may not even enter the consciousness of an expert in a different field.

In fact, the adoption of Access 97 caused further problems. First of all, although it was still standard software at Sussex, being only three years old, by the time the project began Microsoft had already issued Access 2000, which meant that copies of Access 97 were very difficult to obtain commercially – a potential problem for the students on the project, who were not covered by the University's site licence, but were still expected to contribute to the database.

This would have been less of a problem if migrating the database from Access 97 to Access 2000 was at all straightforward; but by the time Sussex decided to change to Access 2000, I had already written substantial amounts of code – which did not compile properly in Access 2000. By this stage, I had neither the time nor the inclination to plough through Microsoft's documentation and debug the code I had just written once again. The database is therefore still running in Access 97 – which at least has the advantage of being a tried, tested and relatively stable program.

Networking and updating

There was also the problem of how to enter data into a single database when project members were spread across two countries, often working in archives where an Internet connection was out of the question. Thus, an individual copy of the database had to be capable of being used to enter data remotely, and then periodically reconciled with a central database held on the University of Sussex's servers. The obvious solution was to use Microsoft's own Replication Manager to carry out the task; but this simply would not run over the network connections in place at Sussex between the PC holding the central database and the FTP server which acted as a drop box. Any straightforward implementation of Access directly onto the web, or automated use of the Replication Manager, required that the web servers being used ran Microsoft's Internet Information Server on a Microsoft operating system; the Sussex web servers all ran Apache and Unix.

The net result was that synchronizing the remote and central versions of the database would have to rely upon code written by hand, from scratch, which used key fields and date-stamped records to check for new or modified records and update the central database accordingly.

The current position

Despite these difficulties, the Material Renaissance Database does exist. It currently comprises about 780 fields in 28 tables, and uses 50 different forms and subforms for navigation, querying and data entry. The whole application is rendered functional by about 20,000 lines of code.

The database needs this number of tables because of the number of different kinds of information which it is used to record, and the fact that Access can only hold repeating fields in a linked table. The basic structure of the database is shown in Fig. 3, which depicts the relationships between the main tables and the 'sub-tables' which hold the repeating fields. The additional tables, which do not appear in this figure, are used to hold the 13 different authority lists mentioned earlier.

Fig. 3. The main tables in the Material Renaissance database.

As well as existing, the database also seems to work: a reasonable quantity of data has been entered successfully, both through the data entry forms and as imports from spreadsheets. Several sets of records have successfully been updated using the FTP drop-box and the various updating procedures. The main data-entry phase is just beginning, and the quantity of records held within the database should increase significantly over the next few months. However, it has taken about 21 months out of a 36-month project to get the database to a functioning state, and this means that valuable time for entering data has been lost.

Although the full searching and reporting facilities have still to be developed, a basic search for each main table has already been implemented; and, with a little knowledge of Access's query functions, it has been possible to start extracting some useful data. For example, Fig. 4 is a graph which indicates the range of prices paid for a staio of wheat (about 39 litres) in Ferrara over the years 1535 to 1539; this also gives an idea of what one Ferrarese lira could buy at the time – a fair amount of wheat, between about 25 and 50 litres. (The data comes from Mary Hollingsworth's examination of the accounts of Cardinal Ippolito d'Este.)

Fig. 4. Data from the Material Renaissance database: Wheat prices in Ferrara, 1535–9, from the dataset 'Cardinal Ippolito II d'Este's accounts'. Data © Mary Hollingsworth.

Fig. 5 shows the fluctuating exchange rate between the Florentine florin and the Venetian ducat over the 28 years from 1383 to 1411, compiled from 1,990 exchange rates extracted from the correspondence of Francesco di Marco Datini, the 'Merchant of Prato', by Reinhold Mueller.

Fig. 5. Data from the Material Renaissance database: The value of the ducat in florins, 1383–1411, from the dataset 'Foreign exchange in Venice during the Datini years'. Data © Reinhold C. Mueller.

However, there is still more work to be done, particularly in determining precisely how the data will be deposited with the History Data Service at the end of the project, and whether a web-based version of the database is at all feasible. I am also very aware that although it works, most of the solutions I have adopted are neither elegant nor sophisticated. In particular, the code I have written is bloated, and aspects such as error handling and the incorporation of standard procedures to handle frequently-used tasks could be used much more extensively.

Lessons to be learned

Were I to go back to the beginning and start the project again, what would I do differently? First, I would work towards a much more compact database: many of the fields recording prices in a myriad different forms of currency are unnecessary, and the conversions back from decimal values could instead be performed at the query or report stage. This would make the database much leaner, although it would still require a similar amount of programming.

I would also be more realistic about the kinds of data which could be recorded: despite the interest of valuations in multiple moneys or in cash and kind, they also make the database much larger, and add a couple of tiers of calculations it could happily do without. I would have to be firmer about losing some of the subtlety for the sake of getting the database written and working much sooner – which would allow more time for data capture.

I would also be less optimistic about my own ability to learn how to program and deliver a working database in a reasonable time. Instead, I think I would be much more insistent about biting the bullet and hiring an experienced developer to get the database working in a month or two, rather than rely on me to cobble it together through trial and error over the best part of a year. If this required money to be transferred from other sections of the budget, then I think this is something that we would have had to face – the advantages to the project would have been significant.

But the Material Renaissance project's experience with the development of its database also raises broader questions, about how funding bids are prepared, and about the nature of computing support in some universities. I suspect that many of the problems we encountered could have been foreseen before the bid was written, if the computing staff at Sussex and the academics writing the bid had had a clearer idea of the implications of what each other was saying. Part of the problem is that, unlike some other universities, Sussex has very limited facilities devoted to the development of humanities computing, and a small central computing service. Consequently, there is little support readily available to help inexperienced humanities researchers to develop applications to further their research. This means that such staff will always be more vulnerable to problems caused by their lack of knowledge of technical matters.

A potential solution to this would be for academics to buy in external expertise at the bid-writing stage. Ideally, this would take the form of someone with a decent background in humanities computing, able to understand both the complexities of the initial data, and the ways in which it would need to be processed by the computer. The skills required of these individuals are quite specific: they must combine a significant expertise in the subject of the research with sufficient technical knowledge to specify how this might be fitted into a computerised system. Thus, if a project anticipated using a database, they would be able to produce a draft entity relationship diagram and list of fields, which, coupled with the technical consultant's expertise, should enable them to make much more informed choices about the viability of their proposed use of computers. But this would cost time and money, and these are of course at a premium. I know that some funding bodies make small sums available to assist in the preparation of a funding bid, and it seems to me that this would be a straightforward way for a body such as the AHRB to ensure that the best possible use was made of computer technology by projects such as the Material Renaissance.

November 2002

Notes

1. Having worked on the Material Renaissance project for two years, Rupert Shepherd has taken up a post at the Ashmolean Museum; his position on the project has been occupied by Philippa Woodcock, also based at the University of Sussex.

2. Further information on the project's aims and members can be found online at the project's homepage, www.sussex.ac.uk/Units/arthist/matren/, which will be current for the life of the project.

3. Some notion of the plethora of different moneys used in medieval Europe can be gleaned from Spufford, P. (1986), Handbook of Medieval Exchange, London: Royal Historical Society (Royal Historical Society Guides and Handbooks, No. 13), which covers the period to 1500 – but even this is a poor reflection of the sheer quantities of moneys in use in Italy at this time. Goldthwaite, R.A. (1994), 'Il sistema della moneta fiorentina', in Goldthwaite, R.A. & Mandich, O. (1994) (Eds.), Studi sulla moneta fiorentina (secoli XIII–XVI), Florence, 1994, provides a useful list of moneys used in late-medieval and early-modern Florence – a total of some 27 different moneys.

4. For this and what follows, see, for example, Zupko, R.E. (1981), Italian Weights and Measures from the Middle Ages to the Nineteenth Century, Philadelphia: American Philosophical Society (Memoirs of the American Philosophical Society, Vol. 145), which contains numerous further references.