Creating the Database

The core of the database consists, at present, of seven tables. These record information on houses, their occupants, the kin relations of occupants, notes and the location of houses in the town (see table descriptions below and diagram). The database is implemented using the Ingres relational database management system, a major commercial product. Entry, linkage, editing and retrieval employ a combination of special menu driven interfaces and raw SQL queries.

We entered data from the first (1731) register into a slightly different structure to that described below. This was because no record linkage had been performed at this time. As well as the relationship table, the database had a table of parents and non-resident spouses, recording names and places of origin in each case.

At the next stage, we gave all identical pairs of parents the same person identifiers. Then these unique sets of parents were linked to matching couples (resident or not). Where these matched resident persons (taking into account knowledge of the spouse) we gave each individual the identifier from the 'register person' table. The non-resident spouses and parents were added to the general person table with their own unique identifiers. All of the relationship information was added to the main relationship table. The intermediate 'relative table' was retained within the database for historical reasons but does not form part of the everyday working data.

We have added data from later registers interactively by means of an interface application consisting of several forms. The locations are the same for all registers apart from extra ones added to represent new districts in the growing town. Each register entry has, at present, a complete set of unique house records. It was decided that the identification of distinct houses between registers was more difficult than the matching of individuals. This was for two main reasons. First there was an earthquake in 1733 which caused damage to property and rebuilding. Secondly, house names do not appear to be fixed. Houses owned by a particular set of occupants across several registers, may appear as Casa 5 in one, Casa 7 in another and Casa 8 in a further.

Because the names of both parents are given for most individuals in each register, we can make positive identifications of persons between registers in most cases. The form used for this task allows the names (or the start of a name plus a wildcard character ) to be entered and information on all of the persons with similar names already in the database to be retrieved. The displayed data includes the names of parents and spouse(s). From this information, a clear identification can almost always be made. If no match is found, or there is some uncertainty about identification, a new person record can be created. With linkage, it is better to err on the side of caution. These principles also apply to creating links to parents, as a new person may be sibling to others already known. In order to allow flexibility in linkage, the wildcard facility needs to be used judiciously. A new record is added to the 'register person' table for each individual appearing in each register. There is a compound key on person identifier and date. Names and place of origin are recorded each time to allow for minor variations; for instance a person may be Giovanni in one register and Giovanni Niccolò in another but the same individual as can be seen from his set of relatives.

So far, we have entered three registers - 1731, 1736 and 1754. From these it is becoming possible to build up several generations of bilateral links. As well as a link through person identifiers, each relationship is given a further identifier. This is not unique but is shared by a set of parents and all of their offspring. It is technically redundant data, but is useful in providing a quick method of locating sibling sets. The method was suggested by the model used by Antonio Ciuffreda and Gérard Delille for the Libro Magno di Manduria database at the École Française de Rome.

Another, and currently separate, section of the database holds information from the 1753 Catasto Onciario - a detailed taxation, property and population register made for the Neapolitan regime. This is currently being worked on by Ms. Oona Wesley-Smith, and will soon be linked to the 1754 State of Souls data. Links will be made to individuals, to houses and to locations (which are more detailed in the Onciario ). We will need to use a fairly advanced form of interface, such as the Windows/4GL system, to be able to search and compare the two sets of data side by side. So far only information on persons, residence, location and taxation has been entered from the Onciario , but the system is designed so that property details (land, houses, animals) and credit relations can be added at a later date. The Onciario provides data on wealth, occupation tenancy and debt relations. The method in which this document classifies households provides an interesting contrast to that used in the State of Souls registers.

The database has been designed to allow other types of information to be linked into the system. These include baptism, marriage and burial data. Such records will need to be linked to the existing person data and will also supplement it. We will use this information to create a further set of links about spiritual kinship as it is intended that a study of sponsor choice will be made in the future.

References

Bagg, J. 1991: 'Modelling kinship and residence from State of Soul registers - experiments with advanced database systems and presentation methods'. in H.J. Marker (ed) Proc. of the International AHC Conference 1991 (forthcoming).

Delille, G. 1988: Famiglia e proprietà nel Regno di Napoli, XV - XIX secolo.

Marino, J.A. 1988: Pastoral economics in the Kingdom of Naples.

Description of tables in the Ascoli database with example records

(Excluding the Catasto Onciario tables)

Diagram of the relationships between tables

lnum

id number for location

lname

short name of location

note

note about location (1 sentance)

hnum

id number of house

hname

name of house eg. casa 1

type

type of ownership/tenancy: apiggione (rented), propria (owner-occupied), ecclesiastical, vacant, diruta (ruined), uncertain

folio

page number of register

lnum

id number of location

year

date of register

pid

id number of person

hnum

id number of house

hhdiv

division of house as in register. Numbered in sequence within house.

subdiv

sub-division of house in register. Numbered in sequence within division.

fname

first name (to record variation between registers)

sname

last name (to record variation between registers)

pl

place of origin (to record variation between registers)

yage

age (years)

mage

age (months)

mstat

marital status - m married, n unmarried, u uncertain

com

if communicant - c communicant (if C in margin by name in register), else n

conf

if confirmed - cr or - as in register else n

nat

nat if illegitimate, else x, may be stated as naturale or be di padre ignoto

year

date of register

pid

id number of person

fname

first name - may be two part eg. Gian Battista

sname

last name - may be two part eg. di Marsico

pl

place of origin - If not known and person is a child pA (perhaps Ascoli) is used otherwise nk.

sex

m male, f female, u uncertain

pnum

id number of person

rtype

type of relationship: M mother, F father, S spouse

rnum

id of related person

union number

number given to each set of parents and their offspring

hnum

id number of house

note

note about house (1 line). Used to expand on name and to record public buildings next to house

year

date of register

pid

id number of person

note

note about person (1 line). Use to mark occupations or titles, to note uncertainties and to record additional notes given in register

year

date of register