[Home Page]

COMPUTERIZED COLLECTION MANAGEMENT:
A PRIMER

Robert A. Baron
Museum Computer Consultant


 

For registrars of small museums and large, the prospect of using computerized collection management systems is becoming ever more attractive, particularly as resources become more scarce, and additional responsibilities draw upon their time. But, as many who have tried to use computers have found out, not all computerization projects fulfill their promise. This article discusses some of the benefits and limitations of computerized collection control, and surveys some of the techniques and programs accessible to registrars.

While computers have more readily served museum needs as diverse as membership, development and fund accounting, other tasks, such as collection management, including accession control and collection description, have not been so easily assigned to the computer.

Recent database management systems have become more responsive to the complex data types required by historical artifacts. Adequate collection management programs are now available, aided by advances in video-disk technology and digital imaging techniques.

SELECTED PROBLEMS

Object Tracking

The task of "Collection-Management" should be understood as a fusion of two separate, but overlapping functions: Object Description, and Object Tracking.

Although operationally complex, "Object Tracking" is but a particular implementation of what database managers call "inventory control." These programs record the status of objects, track loans, monitor acquisitions and exhibitions. They record object disposition, storage locations, keep tabs on lenders, borrowers, donors, and the expenses and activities associated with object management. Loan agreements, receipts, insurance lists, and tabulations of works to be prepared for shipment, and objects due for return, are generated by tracking modules.

Many object management systems developed from a need to establish an inventory. Even the simplest computer inventory, composed of little more than accession numbers and object classifications, may have incalculable value--indexing old filing schemes, comparing object lists to card lists, identifying missing cards and objects.

To facilitate monitoring object transactions, simple inventory databases may be augmented by files containing related data, such as borrowers and lenders. Were tracking functions the only components needed, almost any competent database developer would be able to construct an object management system--many have tried. But when standard accessioning forms, worksheets, lists of collection categories, sorted by artist, style, subject, material or culture, are added to make collection control more manageable, intelligible, and provide public access, inventory control systems must be enlarged by adding object classifications and descriptions. No longer an administrative machine, the database now must cope with the scholarly vocabulary of the humanities. This is why it been so difficult to create credible museum databases.

Object Description

The most severe obstacles to this endeavor lie in the process of describing man-made objects. To make a computer successfully sort and select data, one must obey conventions specified by the database program, while imposing standard vocabularies--these conventions do not necessarily correspond to the way historians and curators traditionally classify objects.

Therefore, in the past, successful object management has had to impose its own conventions. This required 1) defining the kinds of data to collect, 2) deciding how to control the nomenclature used, and 3) determining what to do with repeating and alternate values, including conflicting and former opinions--usually ignored in the face of the difficulty of the first two tasks. Furthermore, each of these issues has been made crucial by the limited database management systems available for use in small computer environments.

Because each museum, collection, period, culture and object type, ideally requires its own unique set of data fields, it has been impossible to set uniform standards. To fit countless varieties of objects into one system, designers often must choose between establishing a set of common, but inadequate number of data fields, or placing diverse collections into disconnected databases.

The problem of turning an object's critical history into retrievable data is rarely considered. Although dedicated to the business of the day, the registrar certainly must have authentic records reflecting current, and even historical opinion. Information is dynamic--each object has its own history. Because current conceptions become past opinions, museum databases cannot ideally assume otherwise.

Authority Lists and Nomenclature

As all who are concerned with museum computerization projects are aware, success or failure of data entry will often depend upon establishing conventionalized terminologies. Unfortunately, the more each system strives for internal consistency, the more obvious becomes the difficulty of regulating systematic data elements within each institution. Intra-institutional vocabulary control is expensive, parochial, and rarely solves the problem of communicating with outsiders.

Moreover, although some museums develop style sheets and lexicons in preparation for current or future computer projects, the terms and practices defined therein are often determined by a mix of institutional traditions and personal preferences. Even so, not all museums have the resources to follow their own style sheets and conventions.

To attain cross-institutional consistency in geographical, cultural, material, biographical, historical, stylistic, and other terminologies, nomenclature projects such as Chenhall, Icon Class, the Getty Art and Architecture Thesaurus (AAT), and others were pursued. In spite of their undeniable value, these efforts do not fully address the workday problems of how extant, often old records are to be reconciled to the new conventions without extensive revision.

Determining Needs

Of course, for each institution considering adopting a computerized collection management system, the importance given to the above questions largely depends upon the nature and the size of each collection--upon those functions the database must serve, who is to use it and care for it, and upon how it might serve the public. Small specialized collections will need different types of systems than large diversified ones. New collections have different needs than old collections. The requirements of academic institutions differ from private and public galleries and museums.

Each need demands its own solution. For example, if object management databases are to be used to produce publishable lists of objects suitable for catalogues, copy for wall labels, and official credit lines, custom data fields may have to be fashioned to accommodate an official terminology which differs from the nomenclature used for queries.

Video systems merge object images with the database, but not all video linkages are the same. Some systems work well to document the collection and defend it against potentially harmful handling, while significantly reducing the need for staff to retrieve items for verification and identification, thereby saving time and personnel. Others serve these purposes less well, but offer high quality manipulatable images of great value to conservators and curators. Some query fast, some slow, some offer high quality, some low, some use vast data storage reserves, others do not interfere with normal data files.

Therefore, when selecting an imaging system, many questions must be answered: How are new images added; how much data storage will be used; will production be too costly? Is the system too advanced for the intended function (read too expensive)? Can the entire collection be recorded in reasonable time. Are images linked to the query apparatus? How swiftly can groups of images appear during queries? Will one user's call for images prevent other users from using the system effectively? Can query results be saved with images; can images be reproduced on paper?

SELECTED SOLUTIONS

Choosing a packaged computer system to manage a collection is a more complex endeavor than just locating a program which meets functional specifications and provides necessary forms and fields. One must be aware of the mechanism each system uses to achieve its ends; know whether the program and the equipment on which it runs can comfortably support the intended number of users without serious degradation; whether it is wiser for the machinery to be shared with other applications, or to remain independent of word-processing, membership, and financial management. One must determine if the machinery offers proper storage capacity, and how quickly it answers queries, among other technical matters.

Some systems use outdated operating systems or old technologies which offer little opportunity for enhancement, and others tie the user to specific brands of equipment. On occasion, municipal and collegiate collections have been urged to share time on the mother main-frame, where they may be placed in a chain of access priorities, and isolated from all developments in the field. Whether these solutions are workable or not is not always obvious.

One benchmark of a program's sophistication may be seen in the way it handles repeating data. For example, if a program supports two artists for each object, it is vital to know how it works. Can a query in the first artist field find that artist when listed in the second artist field? Whereas some programs are severely limited in these matters, others are more flexible, permitting all makers ascribed to an object to be entered--each conditioned by attribution parameters, e.g. "In the manner of Rosso Fiorentino". Sophisticated programs create master lists of authoritative field values (such as artist names), validating every new entry by searching these lists for approval. Others are even more efficient, and maintain a lexicon of valid entries, linking each to the object record, forcing approval of new values.

Obviously, any decision to use an object management system, simple or sophisticated, must be made with full knowledge of each package's limitations and capabilities. The correct system for one museum may be wrong for another. Some institutions may best be served by not computerizing.

Because choosing or developing a database system is always complex, it may be wise for any museum considering computerizing to experiment with simple solutions first. This process will help staff more fully understand and assess its needs and database requirements. Perhaps a low level of computerization will prove adequate. Impulsive overkill may be as inefficient as underkill, but a lot more expensive.

With the above in mind, surveyed below are the most popular methods of using computers to manage objects in the registrar's office.

Word-processor Lists

Many museums successfully rely solely upon word-processors for project and list management. The word-processor's ability to edit lists simplifies many management tasks--itemizing new acquisitions, enumerating objects in exhibitions, or sending "mail-merged" letters. As long as these assignments are finite in scope and duration, of defined purpose and limited size, and restricted to one person or one office, word-processor lists have value. Their disadvantages lie in their uncontrolled structure, and in their specialized nature. These lists are always difficult to query, impossible to sort by specified criteria, and offer no ability to tally classifications.

Rigorous conventions, strictly imposed, might make word-processing lists work; but in the end, the effort may not be useful for any project which must provide lasting data to be used for any other than its primary purpose.

Text-Bases

Text-bases index free-form word-processing documents, providing very quick access to masses of unstructured materials.

Typically, all words, or designated key-words are registered by these programs. When a document is needed, the user forms a query by stringing key words together, linking them with AND, OR, and NOT. For example, one may ask for all references to "Rembrandt," excluding all entries with "Peale". Even though conventionalized vocabulary is rarely imposed on text-bases, some of the problems associated with the lack of defined nomenclature may be averted with clever queries. Text-bases may be useful for research, but no administrative system should rely upon instinct and ingenuity as a means of finding data.

Still, text-bases are intriguing as quick means of turning chaotic curatorial and object files into machine readable form--as long as one is willing to accept the clutter found in these files. Text-scanning readers are recommended; today many can read common mono-spaced fonts.

The best text-base systems for the IBM PC family are ZyIndex, FYI-3000, and the academic word-processor Nota Bene. For refined applications Star, by Cuadra is well respected. Star allows field definitions and cross-field indexed queries, and accommodates dynamically changing data, unlike the others. None permit the kind of transactional programming registrars need to maintain object histories and record changing conditions. Star, however, does provide elaborate vocabulary checking and mimics some relational features of advanced database systems, but its forté lies in object description and bibliographic citation, not in object management.

Flat File Databases

Any user may appreciate the complexities of art historical and curatorial databases by trying to create one himself. Simple flat-file database management systems are the closest computer equivalent to the traditional index-card file. For the IBM PC and compatibles, PC-FILE is a popular favorite flat-file system. Reviews of others regularly appear in the pages of PC Magazine and PC World, and other journals.

Flat-file databases can be used to create computer lists of all kinds: names and addresses, telephone numbers, mailing labels, and simple inventory management utilities. Their querying, sorting and reporting functions are typically slow, however, and their file sizes may be limited.

The prime disadvantage of such systems, however, lies in their fragmented approach to database design. Data is not entered economically, repeating data elements must be entered into each record. Few controls are available to manage data. These programs waste valuable computer storage space, and tend to accept errors easily. Overlapping flat-file applications do not interact with each other, requiring time-consuming maintenance to keep them current.

Relational Databases

Most relational databases are composed of flat-file components linked by common data types. Joining files to each other fabricates powerful "one-to-many" or "many-to-many" relationships. Thus, a single borrower, cited once, may be tied to all works he borrowed, or one donor linked to all his gifts, or one artist record attached to all objects attributed to him.

To be most effective, relational database systems, such as Dbase III Plus, R:Base System V, and Informix, must usually be constructed and programmed by specialists in database design--but some allow knowledgeable users to create simple applications with relative ease. Unfortunately, most professional database programmers are not sufficiently familiar with the unique properties of object data and with scholarly issues to design respectable museum systems--and curators and registrars are not yet adequately versed in the intricacies of database management systems to insure that their needs are being provided for correctly and efficiently. For complex applications, museums would be best advised to turn to someone familiar with both museum practices and database systems.

In each database management program there are limitations which may affect the utility of complex applications. Some put severe restraints on the number of files which may be opened on a screen at once--limiting the number of definable relationships. When the limit is reached, complex needs soon turn fine relational databases into series of related flat-file systems. Some packages, R:Base, for example, keep all data in one file--prohibiting distribution and separation of data among storage devices. Some systems have inflexible sorting rules, others limit field size, and so on.

Most personal computer database applications suffer from two fundamental data limitations: fields cannot accept multiple values and must have fixed length. Fixed-length fields require strict economies of database design and exact countless compromises. Fixed-length fields demand their defined space, whether they are filled or not. Obviously, one must avoid defining specialized fields for object descriptions if they will rarely be used.

When fields are single-valued, meaning that they can be filled only once--to the limit of available space--the user must decide what to enter and what to omit, and must decide which of several elements is most important. Sorting and reporting act on the first value listed, searches are often slower. "Plaster and wood" is different than "wood and plaster." On the other hand, multi-valued fields, often defined for artist names, for stylistic or cultural groupings, or for media and/or supports, treat each entity equally.

Since the storage needed by variable-length fields depends upon the number of characters actually used, there may be no practical limit to the text entered. When citing the title of a work, correct use of multi-valued and variable-length fields permits one to record as many titles or subjects as required to identify an object--each may be independently queried and sorted.

Some database management systems designed for small computers (e.g. Oracle and Revelation) are beginning to offer multi-valued and variable-length fields. The Pick operating system (which Revelation copies) is well known for these features--now incorporated into the newest generation of commercial object management databases.

Dedicated Object Management Systems

Museum databases and their vendors are abundant at AAM meetings. The most visible of these are ARTIS, Willoughby Associates, and Questor Systems. Each provides respectable services, and has its own position regarding how to computerize collections.

When choosing a prepared package for object management over an expensive customized system, the consumer usually must learn to adapt his operations to the system provided, but obtains the benefits of collected experience. Some packages are fixed in shape, while others permit customizations. Some firms, such as Willoughby, have developed paper based report systems to simplify fixing erroneous data. Another, Questor, avoids paper reports, providing, instead, internal means of validating and structuring data elements.

Differences are apparent in approaches to vocabulary control. In the ARTIS package, the artist file employs a list of artist names which must be manually queried for validation. In its more advanced (promised) packages, Willoughby Associates expects to provide automatic referencing of predefined vocabulary lists for artists' biographies and other data fields, as well as hierarchic query structures for searching sub-terms automatically when parent or equivalent terms have been specified.

Hierarchically controlled lexicons were pioneered by Questor Systems of Los Angeles. Questor's, ARGUS, created for ethnographic collections, is being adapted to the needs of fine arts museums. Pick-based ARGUS contains multi-valued and variable-length fielding, supports multiple users, security levels, and offers an optional video-disk add-on.

Hierarchic querying may be the single most important achievement in museum database technology, resolving many of the authority control problems responsible for earlier failures. For example, a query for "Florentine Renaissance paintings," should find works listed as "Florentine," as well as those cited as made in "Florence" and "Fierenza." If "Florentine" proves too fine, the user may choose a more general term, perhaps "Tuscan," which may include works catalogued as made in Tuscany, Toscana, and the towns therein. Furthermore, now only one field is needed to identify the geographical origin of a work--fields labeled "country," "region," and "city" are unnecessary. Fewer fields serve where more had been required.

Although hierarchic fields offer distinct advantages over those defined for rigid nomenclatures, using such hierarchies confers its own complications. To invest these queries with power, terminology must be structured, though not at the field level, below it. Because, terms are input as found in extant records, little revision is necessary during data entry, but the relationships and authorities must still be supplied by structuring real records, and by inputting defined ordered vocabularies--no small task.

CONCLUSION

Choosing an object management system must not be taken lightly. The expenses incurred in purchasing a system, and entering data, may be small compared to the investment of will-power needed to maintain it. Good functional systems have been abandoned for little reason, save lack of resolve to service them. Museums beginning the process of computerization might determine their needs, consider the financial investment required, assay their determination by experimenting, and then choose a system of adequate sophistication to accomplish their goals.

* * *

For further reading:

1. Peter H. Welsh and Steven A. LeBlanc, "Computer Literacy and Collection Management," Museum News, June 1987, 42.

2. Richard B. Light, D. Andrew Roberts and Jennifer D. Stewart, eds., Museum Documentation Systems: Developments and Applications, London, 1986.

3. Lenore Sarasan, "Why Museum Computer Projects Fail," Museum News, Jan/Feb, 1981, 40.

[Go to Top]
[Home Page]