If two museums have used different terms to describe an object, how can they share information about it? What if two people in the same museum describe the object differently? How will they even recognize that it is the same object? What is the difference between a "dog" and a "canine" and a "German Shepard"? A "car and an "automobile"? A "forest" and "trees"? These are problems which must be addressed in order to create a useful, usable database accessible to outside users or other museums. It is widely agreed that the answer, or at least partial answer, is to use an agreed-upon set of terms when making the database; this is called a controlled vocabulary or lexicon.
An added dimension of utility is introduced when relationships between terms are created: that's when the database can suggest an alternative term to a user who has no idea what went into the lexicon. A controlled vocabulary limits what terms can be entered into a field (which eliminates the storing of typographical errors, etc., in the database). More sophisticated databases include thesauri or lexicons which index synonyms under a single representative term, or allow relationships other than just synonyms ( e.g., broader or more specific terms) to be indexed. Combining controlled vocabulary with a thesaurus gives a good chance at getting thorough answers to searches.
The Library of Congress subject headings have provided usable controlled vocabulary for libraries, and are a useful tool for building a vocabulary with relationships. Because this system is based on an extremely wide field of terms (i.e., those about which books have been written) it is very useful for generally known terms. Culturally specific or technically specific terms may be lacking.
Chenhall's lexicon is a controlled vocabulary created for artifacts; it is useful as a vocabulary with relationships. Generally speaking, if it is a man-made object, there is a way to classify it under Chenhall's system. In databases where relationships can be established, culturally or technically specific terms can be linked to Chenhall terms.
The Getty Information Institute (GII), previously known as the Art History Information Program (AHIP), an institution of the J. Paul Getty Trust, has developed three important vocabulary resources. The Art & Architecture Thesaurus (AAT) is a 90,000-term structured guide to vocabulary describing art and architecture. The
Creating a vocabulary or lexicon for a museum can become a little bit like trying to find the one supreme Truth; it is best not to turn it into this kind of eternal quest, however. Most museums either eventually settle on one of a few widely accepted standards (as mentioned above) or they forgo any effort at being accessible to outsiders and create their own individualized system.
To address the question of what is needed by a museum from a database: the more of the items listed in the previous table that a database can manage well, the more useful that database is!
There are always hardware questions with computerization, but software issues are quite important. In general, a database should be examined in terms of:
access - who will be able to utilize the information, and how difficult is it?
The Canadian Heritage Information Network (CHIN) collections management software review examined seven areas of several commercially available programs:
1) Collections management - accessioning, inventory control, location and movement control, cataloguing, conservation management, rights and reproductions, risk management, insurance management, exhibition management, dispatch, loans, deaccessions and disposal;
Specific users will find specific needs. A conservator might require an ability to see high resolution images of an object down to a scale of 1 micron. An art historian might require cross-references between literary citations and object records. An accountant might need to be able to sort records by value of donation, whereas a development officer might want to know who donated to the museum in a given time period. All of these are extensions of the questions listed above, and the way in which each can be answered will depend upon not only the needs of the particular museum and its visitors, but may also depend upon each object. A study or projection of use for any museum is needed before a good computerization plan can be implemented.
It is impossible to select database software for a museum without a deep understanding of that museu's needs, but one suggestion can be made: museums are strongly advised to consider the issue of standards when deciding whether they will use a commercially produced database or try to develop one independently.
It has been recommended that museums considering building their own collections database use "user-friendly" software that doesn't require much technical experience and can be easily modified in the future. Programs for museums from commercial vendors that utilize Windows, DOS, or Macintosh operating systems and based on common database systems are available; these products can provide a relational system that is relatively mainstream. Commercial packages like FileMaker Pro are frequently recommended for simpler projects, as they are easily adapted for use; more sophisticated database software, such as Microsoft's Access or Oracle are more often recommended to those with complex needs, with the warning that they require more complex programming to meet those needs.
Commercial museum databases have some advantages. The reality is that no one product can please all costumers, of course, but by trying the vendors often create a level of compatability between institutions - and vendors will usually try to optimize the life-span of a database in terms of utility and, of course, can provide technical support and warranties. Good vendors study the needs of museums and, enjoying a viewpoint removed from the actual work, can create a product flexible enough to successfully encompass a relativley full range of museum activities. Building an individualized collections management system is a resource-intensive project, and there are reasons for suggesting that a pruchased system will be more efficient and effective. An individual from within any department of a museum involved in developing a database will stress the functions of interest to that department - possibly at the expense of the interests of other departments. Further, if the experts in museology are busy creating a databse, there will be no one doing the regular museum work.
The more mainstream the database management system, the more likely the museum will be able to find people who know how to use it or program in it - and it will be easier to find books at the bookstore, help on the Internet, help from other museum users, etc. The problem of mainstream support or its lack is significant. Many institutions are conforming to the standards of Access, Oracle, or similar systems. Some systems on the market today use database management systems based on different commercial products or products that do not incorporate standard relational models, however. Some systems are based in other operating systems, such as UNIX or PICK, drawing on particular data-handling benefits of these systems. Standard relational databases require fields to be predefined in length and hold only a single value. Making a comples structure in a standard relational database requires very complex programming. The question of what system to choose for a museum is a decision between the popularity if the tools offered by the software industry against the demands of the data.
A perhaps unlooked-for occurrance has been the push by companies not formerly allied with or interested in the museum field to produce software to be used by museums. The G7 proposals and the normal market-seeking efforts of developers of technology, combined with the current inclination towards multimedia information storage, have brought new companies like Corbis and old companies like IBM into competition for museum clients. In these new industries, museums are content providers or content holders, and the information is seen as the content - not the real collections or objects. These companies tend to have tremendous resources, but they lack a detailed understanding of the purposes, processes, and procedures of museums, and there will no doubt be a learning curve.
capacity - can the database hold all of the information necessary and continue to grow?
transferability - as equipment ages and technology evolves, what will happen to the data?
security - museum data needs to be protected from both unauthorized alteration and unauthorized access to sensitive information.
updates - how will new information be incorporated, and how difficult is it?
tracking - does the databes include the history and movement of the object (physical location) and other relevant information?
images - is this important, relatively new aspect of record-keeping incorporated into the database?
2) Data management - field structure, data entry, validation, update, vocabulary control (including thesaurus and authoring control);
3) User interface - help features, date formats, customization, languages, record display, public access, and imaging;
4) Query - general requirements, range searches, wildcard searches, query results, and features;
5) Reports - pre-defined reports, reports on pre-printed forms, reports on labels, and user-defined reports;
6) Technical requirements - import/export functions (e.g. in CHIN Microtext format and from other software), documentation and support (and customization), training, and features;
7) System administration - security, database index/indices, backup, and audit reports.