I was recently shown an example page from a tithe book. As this is possibly going to become a collaborative transcription project I've been giving some thought to the sort of data structure needed to hold the data. I've got some ideas in the back of my head but although it looks simple it presents some interesting problems, especially if a relational solution and capability of indexing personal names are objectives. The pages are ruled vertically into a number of columns. These are: Landowner. To be thought of as a single entity but names are not necessarily unique and a "Landowner" may not even be a single person or even a natural person, e.g. one "Landowner" is a named person plus the executors of another. So a Landowner is to be structured as a list of sub-entities but even then the sub-entities aren't all of one type. Occupier. Again this is to be thought of as a single entity but an "Occupier" can consist of multiple non-unique names. In one instance there is a name followed by "and another". Although there were none in the example it wouldn't surprise me to see executors listed. The structural problems are similar to those of "Landowner" Plan reference. A single number. For each such number there are columns for: Name and Description which may describe one or more buildings; e.g "2 Houses" or "House, outbuildings and garden"; or land. State of cultivation - land only Quantities or statute measure Greater Tithe Lesser Tithe Several plan items may be listed against an "Occupier" and apart from the individual quantities & tithes for each item these are summed against the "Occupier". Neither the pages nor any other items are numbered except the plan entries. On the face of it this is a basic master/detail relationship extending to two levels of detail: One Landowner to one or more Occupier One Occupier to one or more Plan item However as both Landowner and Occupier are themselves potentially identified by multiple names or descriptions there is no existing content above Plan item which can be used as keys to hang this together. It would be possible to create artificial keys such as auto-incrementing numbers or UUIDs (preferable for a collaborative project) but, at least for a relational solution, this results in the schema including two tables with no content other then the artificial key. -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk