The types of bibliographic objects we are dealing with in this project (albums, photographs, diaries, ledgers, etc) have been selected primarily because they pose interesting technical problems for display and navigation. From a database standpoint they also pose another interesting set of problems. How do we define them in such a way that we can reasonably deal with all the possibly forms these objects and their elements can take? And how do we design a relational database that will allow us to define and create such variable and complex objects, and manage the kinds of processing they might will require on their way to becoming digital objects?

We began with the observation that these objects are essentially hierarchical in nature:

And any element at any level in one of these hierarchies can be subject to some kind of processing, like imaging or transcription, or both.

So we have attempted to design a database that can deal with all this variability and complexity, that will allow us to define and manage these objects and their subobjects during production, and that in the end will allow the objects, all the attendant metadata, and digital files to be packaged up in coherent digital MOA2 objects. Each object defined in this system is represented as a hierarchical collection of subobjects, any one of which can be subject to some kind(s) of processing that result in a digital file(s).

The DataBase

This is a users overview of the data base. In addition, context specific information is available for nearly every feature of the database interface. If you hold your pointer over a field or button, the system should present you with a short description of that feature.

Main Menu Form

When you open the database, this is the first form you will see. It allows you to select the kind of processing you want to do.

Defaults Form

Defaults are used extensively throughout the database. Anytime you add new object, subobject, transcription, master image, or derivative image records, defaults are invoked that are relevant to the type of object that you are dealing with. Before creating any one of these types of records, it would be a very good idea check the appropriate defaults for that record type. In most cases, however, the defaulted fields can be changed in the new record, once it has been created.

You cannot create in the database a new object of a particular object type, unless there is already a default record for that object type. If you are creating an object of a type for which there isn't a default record, you will have to create a default record first.

If you open the Defaults Form from within the context of a particular object, the form will display the defaults for that object type only. If you open it from the Object Form, and the Object Type listbox is empty, the Defaults Form will display defaults records for all object types.

Object Form

This form is the starting point for locating existing objects, adding new ones, and deleting obsolete ones.

Subobject Form

This form allows you to construct and navigate the various levels of a complex hierarchical object. When you open it, it displays the root node of the object you selected on the Object Form. This node is the ancester of all subobjects that make up that object. The fields in the upper left of this form display information about only one subobject at a time, out of the hierarchy of subobjects. But the view represented by those fields can be made to display any subobject in the hierarchy. Every node in the hierarchy (except the root node) has a parent, and many nodes have children. So from any node (except root) you can move the view to its parent, or to any particular child. There is also a way to display the entire hierarchy, and select any node from it for display.

Process Images Form

This is the main form for image processing. When it opens, it displays the last object created in the database. If you want to display another object record, you can click the field you want to search in, then click the Find button. You will be prompted for search criteria. You can also apply this method to search for records in any of the three subforms.