Bar Codes
Home Up Bar Code Project Bar Codes e-Vouchers Field Computers GIS Integrating Collections Chornobyl Radioactive Collection Rapid Data Entry

 

Incorporation of Bar Code Capabilities
to Existing Museum Databases

 

INTRODUCTION

The ideas and theories of bar code installation and use in a museum collection are simple. However, the practice of installing a bar code system within a museum environment takes more time and energy than one might initially realize. The bar code is a series of bars and spaces that represent a number in a database with different combinations representing different characters (Worthington Data Solutions, 1998). This "visual Morse code of a number" (Percon, 1998) is nothing more than an actual number from the database. The bar code system can be designed to complement the collection database and to assist with cataloging, inventorying, accessioning, deaccessioning, and other tasks performed in a museum. It is used to enter and retrieve information faster and results in less human errors, thereby saving time and effort. The energy saved on data input and retrieval can be allocated to other areas of the collection.

The Data Enhancement Project has five phases. Phase I is designed to identify the collection needs for its database. Phase II reviews the database and database model. The bar code system, is addressed in Phase III, expands the capabilities of the database with views, queries, and reports. Finally, the information cards and reports designed during Phase IV are printed and installed into the collection(s) in Phase V. Phase I and II should be completed before the bar code system is installed because this maximizes the usefulness of the bar code system. Phase III requires a small amount of time compared to Phases I and II. Phases IV and V are ongoing processes that depend on the activity of the collection. The five Phases must be monitored by a database manager- a single person in charge of the entire project. The data enhancement project must be designed to be flexible to meet the future needs of each collection. This flexibility includes collection growth as it relates to collection size and human resources.

MATERIALS

The components of the bar code system include a unique number, a bar code symbology, a bar code translator, a bar code reader, a laser printer, and a systems operator. The database manager acts as an "overseer" who is in charge of coordinating the efforts of those involved with the project including programmers, data entry clerks, and database users. The database manager also programs the computer to link the bar code to an object's unique data. A unique number links the bar code to an individual record in the database. Many different types of codes exist; however, Code 128 and Code 39 are preferable for use in museums (Dawson et al., 1999). Code 128 is a high-density alphanumeric symbology producing highly compact bar codes if even number of digits are used (Percon, 1998). Code 39 produces larger bar codes than Code 128 (Fig. 1) and is a literal translation of the unique number with an asterisk (*) as its start and stop characters (Dee, 1999). The bar code is produced with a computer program called a bar code translator. It should have a range of point sizes in three densities (low, medium, and high). The bar code is scanned with a bar code reader that varies in type (wand/pen, gun, or omni-directional) and by their distance it can travel from the computer (1-300 feet). The type of bar code reader chosen depends on the needs of the collection. The bar codes are printed in-house with a laser printer on object labels (Figs. 2 and 3).

Figure 1. Comparison of size difference between bar code symbologies Code 128 and Code 39.

 

Figure 2. New information tags used at the Panhandle-Plains Historical Museum include a bar code.

 

Figure 3. Previous information tag at P-PHM.

 

METHODS

A bar code system can be installed into many of the PC, Macintosh, or older DOS-version databases currently employed by museums. Phases I and II are implemented on an institution-wide level to develop a database model for the museum. Phases III, IV, and V are conducted on a divisional level and are collection specific. The database manager oversees the entire project. 

Phase I requires every division to compare the information on the specimen's tag with its corresponding data in the computer. Correlating the inventory with the existing database validates the information in each data records and assists in eliminating typographic and erroneous data. The inventory also helps to determine ways for "the database [to] be expanded and supplemented" (Fishman et al., 2000) in Phase II. 

In Phase II, the database management system (DBMS) and the current institution-wide database model are reviewed. The database model is the blueprint from which the database is designed. Fields, information types, and rules for data entry are governed by the standards established by the database model. If the database is not in a relational format, this is an excellent opportunity to upgrade; relational databases manage data more efficiently, use less RAM, retrieve data faster, and have expanded search capabilities compared to flat databases (Fig. 4). In addition, since monotony of data entry is eliminated, transcription errors are reduced 

Figure 4. A relational database links or relates a single record in one table to several records in a separate table, saving space and reducing data redundancy.

 

More effort is required from each division's systems operator beginning with Phase III when the bar code hardware and software compatible with the needs of the collection(s) are selected and installed. Views and queries are designed in Phase IV and can contain any number of combinations of fields (including the bar code) from the database to reflect the needs of the collection. These views can be institutionally generic (loan forms) or collections specific (paleontology inventory form). Phase V is where the bar code is printed on archival quality "information labels" and cut to size. The labels are then attached to the specimen in accordance with the institution's collection management policies.

 

CONCLUSION

An effective data management program will save time, money, and effort because it increases accuracy, speed, and usefulness of the data management regime, and is easier to manage overall (Dawson et al., 1999). However, before bar codes are printed on information labels, the data need to be checked against the collection records to ensure its accuracy. To do this, we propose the use of the five phases outlined above. Phase I and II create, (or review) an institution-wide database model and the database is proof-read for erroneous data. The bar code is installed in Phase III. Phases IV and V are designed to maximize the usefulness of the collection's data (Fig. 5). The lasting effects from the project include updating all labels on archival paper, standardization of the labels and database, and automated generation of catalog cards. This new system also allows a more efficient way of identifying and correcting data errors and allows the museum to be better prepared for unforeseen collection uses in the future.

Figure 5. Scanning a Bar Code at the Panhandle-Plains Historical Museum.

 

LITERATURE CITED

Dawson, E.P., S.E. Fishman-Armstrong, and R.D. King. 1999. Collections Management in the 21st Century. American Association of Museums. Poster Presentation.

Dee, A. 1999. Personal communication

Fishman, S.E., H.J. Garner, and M.O. Houle. 2000. Museum of Texas Tech University Data Enhancement Project. In-house manual. 

Percon. 1998. www.percon.com 

Worthington Data Solutions. 1998. A bar code primer. An introduction to bar coding. Santa Cruz, California. 40 pp.

 

ACKNOWLEDGMENTS

We wish to thank the Panhandle-Plains Historical Museum, specifically Millie Vanover, Toni Davis, Monica Schaffer, Rolla Shaller, Becky Livingston, and Kathy Upshaw and the Museum of Texas Tech University, specifically Sankar Chatterjee, Kyle McQuilken, Matthew Houle, Susan Baxevanis, Emma Mae Dawson, David Dean, Amy Hooker, Kara Hurst, Eileen Johnson, Raegan King, and Amy Polley for support of this project. We also wish to thank Bill Vernon (Vernon Systems Ltd), Chris Callaghan (Vernon Systems Ltd), Avery Dee (Silicon Valley Bus Co.), FileMaker Pro, Tim Rothroch (Azalea Software), C.J. Weigland (Life $uccess), and the people at Worth Data Inc. (formerly Worthington Data Solutions).

by Susan E. Fishman-Armstrong, Heath J. Garner, R. Richard Monk, Jeff Indeck, Gary F. Edson, Nicola Ladkin, and Robert J. Baker; poster presented at the SPNHC annual conference in Halifax, Nova Scotia (July 8-14, 2000)