Robert A. Baron
In the beginning.
At this early stage database files may be used to list new acquisitions and to record incoming and/or outgoing loans. They are as often put to work as mailing list managers, helping to send out notices to museum members and prospective donors as they are used to create inventory records to establish object accountability.
Accordingly, the earliest stages of the evolution of automation are typically characterized by multiple, independently produced, electronic systems. The registrar might keep one or several databases to monitor his or her regular functions. For his own use, a curator may create an object and classification database. The membership and development officer may keep separate lists of museum members, activities and donors. Typically, some staff members who may be in constant need of information will not have practical unrestricted access to the data collected by another staff member. The director of a small museum may have to go through the registrar to find out where a certain object is located, whether it is on loan, in conservation, etc. In short, these computer systems are much like the paper systems they support. Their primary advantage is to provide faster access to and more versatile reporting of the information they contain.
The highly compartmentalized aspect of immature systems replicate the traditional working environment: each officer develops and managers his or her own data. Each user develops individualized procedures which make use of the data created and stored in his own system. Usually no one single person has personal access to the data developed by another or has intimate knowledge of how another's data is supposed to be used. Indeed, each database may be developed on separate platforms -- meaning different computers and/or different out-of-the-box database products. The net complex of such systems closely resembles the proverbial Tower of Babel. Without aid from the staff member that created each system, it would be impossible or certainly difficult to translate any particular procedure or database into the common museum parlance. If the promise of creating electronic storage databases was to establish a kind of common "institutional memory," in these situations, such promises cannot be kept.n1 Even in the unlikely event that the creator of a database has gone to the trouble to document the rules, uses, and procedures that governed his product, history has shown that continued use of current systems are rare due to the difficulty encountered in trying to continue a project that has been terminated or abandoned. Undocumented home-brewed systems pose the greatest danger for loss of data in the small museum environment.
Databases develop during this opening stage as occasion and opportunity permit. An exhibit or an impending catalogue raisonné may oblige the creation of a database, which ultimately may be expanded to include other objects. The most common reason used to establish an electronic inventory is an upcoming collection move, but the need for financial or summary audits is also sufficient reason to start the process going.
emerge at an early stage. [Go to Outline.]
For example, the collections database maintained by the registrar will undoubtedly hold some or part of the information on donors that is also recorded in one form or another by the development officer. The registrar may even keep duplicate information on the same object, as may be discovered by inspecting the loans file, the exhibits file, the acquisitions file, the inventory file, and the artists file. The curator may be keeping his own notes on objects that are described in lesser detail in the registrar's inventory file.
When databases are islands unto themselves they tend to diverge, to lose their coherence and to become different from one another. Additions, changes and corrections made in one database are not necessarily reflected in the others. Common variations may include data maintained on object names, on maker names, on attributions, on locations. Almost any kind of data can be transmuted and translated from one correct to an alternately correct form as it is recorded. There are at least four types of errors that plague compartmentalized data management systems: typographical, syntactical, those concerning usage, and those concerning validity.
Syntactical errors occur when no standard has been applied to control how the information is to appear in the database. One institution can easily have databases in which the maker's name, for instance, appears inverted (Last Name, First Name), separated into distinct fields (Last Name) (First Name), and in natural order (First Name Last Name).
Usage errors occur when different forms are used to describe the same entity. One database may track one form of an artists name and another may use a variant. In such situations, without knowledge of the conventions applied to each system, use of the system may become entirely impossible.
Other usage errors may be found in the breadth of specificity of terminology applied to objects. Where one database may identify an object as having been made in France, another may indicate that it was made in Paris.
Validity errors occur when a factual change entered into one system is not carried through in all systems that maintain the same data. A database created to follow the procedures pursuant to the acquisition of an object may not be made to indicate that the object was in fact accessioned. A change of attribution introduced in one database may not find its way into others.
Another kind of validity error concerns the user misunderstanding the nature of the field into which data is to be entered. One database may contain a field in which to record the location of the source of an object, meaning that "this object comes from:" France. Another field in another database may request that the location of manufacture of an object be specified. Without proper control over the data added, careless users may not always distinguish between the types of information requested in each.
As the number of applications a museum runs begins to increase, museums soon realize that the process of tracking multiple versions of the same data produces multifarious problems in continuity and consistency of data: The development officer may not obtain regular updates of new acquisitions; he must add these changes manually. The curator has made some attribution changes in his database, or has added qualified descriptions that are never passed down to the registrar. The curator does not know the loan schedule for items in his keep or does not have direct access to the conservator's condition reports. In sum, changes made to one set of data will not necessarily get passed around to staff who keep databases. Even when strict procedures are established and employed to keep multiple databases current, small changes, such as changes of status, or corrected typographical errors, will not be made all around.
It is in the face of the overwhelming complexity and endless efforts at data maintenance that museums that have learned to rely on their electronic databases soon come to realize that the individualized databases, heretofore kept separately, must be merged into a unified system in which all users share data from a common authoritative pool. The rule to be followed is simple: "Don't duplicate data."
your system. [Go to Outline.]
Accordingly, the systems analysis collects the information types maintained in paper and electronic records, including reports and correspondence and creates a unified list (the data dictionary) out of them. Data is created by people, used for certain purposes and is sent to people or to specific locations. For larger institutions where the division of responsibility and functionality is well established, the systems analysis may also list each museum job and relate it to the data required to accomplish the tasks germane to that job. The forms in which data is transmitted (the reports) are also cross-referenced to the data dictionary.
Related to, and often part of the "systems analysis" is the "needs assessment." The needs assessment may identify (1) the functions that should be served by an information system, (2) the informational requirements of the system and (3) the technical performance standards by which it should be judged.
When a museum decides that it must acquire or enhance its collection management software, it is often prudent to commission or undertake a "systems-analysis" and/or "needs-assessment" of its activities and information use. Large museums know that their needs cannot be met unless their information usage and data structures are studied, but small and medium sized museums may not realize how vital a systematic understanding of their procedures may be to their quest for an automation system suitable to their functions.
Large museums may devote considerable time to the process of defining and building an information system appropriate to their own uses. They customarily create committees of users, programmers and systems people who map out the uses and the forms in which information is to be presented and addressed. Large museums typically commission a wide ranging information study, and will test, through prototyping, various solutions, until all concerned are satisfied.
While small and medium sized museums usually cannot afford the luxury of an in depth analysis, they should be comforted in the knowledge that the lack of specialization inherent in their job descriptions may indicate that only the most general form of study is warranted. More often than not small museums should be served well by either building a system in pieces, ad hoc, or by choosing among the several commercial systems on the market.
What function does the systems analysis serve for small museums? Put broadly, for small museum and large the systems analysis serves only a single purpose: it acts as a gauge to insure that those staff members who depend upon museum information are served efficiently and accurately by the system built or selected. If a museum builds its own collection management system, commissions one or buys one pre-built from a vendor, having a systems analysis in hand will prove prerequisite to success.
If home-grown and commissioned databases are created and distributed in accord with a master plan, the chances for errors of veracity and syntax will be greatly diminished, especially if the appearance of duplicated data can be avoided through careful design or the introduction of networked applications.
Having in hand a formal list of required fields, functions, reports and other requirements transforms the sometimes awesome job of selecting among vendors into a structured logical enterprise. The systems analysis can be used to determine how well the vendor's product fulfills a museum's needs; it can be used to establish criteria that must be met before a vendor's system can be acquired, and conversely; it can be used to indicate when a vendor's solution to a certain data problem is in fact superior to the one in place.
Accordingly, during the preliminary stages of investigation every effort should be taken to see that the studies are widely focused to include as many departments and users as possible -- even if their operations are not slated for immediate inclusion within the system. This advice is especially true if data and information is to be shared, but less true when departments are generally independent of each other. If the registrar's office records and activities are analyzed, but the administration for development and collection curators are not consulted, then the information system adopted will most likely best benefit the operations and views of information used by the registrar's office. Since only the registrar's functions and object definitions are accommodated -- other departments might well find that their specific requirements are met only inasmuch as they coincide with those of the registrar. It is important, therefore, that all potential users be heard and that they make their needs and data requirements known.
of the species. [Go to Outline.]
Early efforts to widen the focus of data collection eventually pay off in simpler paths of expansion later. Data systems for small and medium sized museums are often planned and built from "the bottom up." Successful small systems have a way of growing into larger ones. Data originally structured for limited usages tends to find additional applicability for additional tasks. This means that the needs of a single office are implemented first, often in stages, beginning with the object catalogue, and subsequently expanded to include other activities and the functions of other offices. If the data elements are defined to suit only initial users, they may be found unusable or unsuitable by others. A simple real-life example will illustrate the problems with this procedure:
The registrar's office of a small museum has established a database file to keep track of works loaned to other museums and to exhibits. As each work leaves the premises, the object is recorded in a database defined to use data elements derived from the label script that accompanies the object. The Artist's Name is given in natural order; the Object Title is listed as it is usually displayed; the accession number is recorded in an alphanumeric field; dimensions and materials (when cited) are recorded as text strings. Additionally, the name of the borrowing institution and/or exhibit is recorded, the date of departure, the date of expected return, and perhaps the name of the shipper or courier is recorded, too.
The registrar finds the data useful for creating lists of works currently out of the museum. These objects may be listed by borrower, by date due back, etc. He may create a list of objects due in the current month or objects that have not been returned in a timely fashion. As each work is returned to the museum, the record for that loan is deleted from the list.
Is should be obvious that this small database is very well suited to the specific needs of the registrar who created it. Because works brought back are deleted, the database never grows disproportionately large and is easy to handle. To execute an unindexed query for the work of a single artist by his surname is not the time-consuming task it might be in a large database. Yet, from the systems point of view the problem with this database is that it contains a lot of information that may be useful to others, but the information it contains is not rendered in a usable form and, what is worse, it is eventually thrown out -- eliminating the possibility of deriving additional benefits from the labor expended in creating the database.
If the registrar had included a field in which to cite the status of the object (requested for loan, loan permission granted, object out the door, object received by borrower, object in transit back, and object returned, for example) there would be no need to delete the record from the database.n2 The same information could be obtained, but now the registrar can produce lists of all works lent during any given period and could even begin to develop a rudimentary exhibit history for the museum's objects. Additional information could be developed on the borrowers. Has this or that museum returned all its borrowed works on time? in good condition?
The "Loans Out" database duplicated much of the information in the museum's computerized inventory of objects, but recorded some of it in varying formats. If the loans database had been made into a constituent file of a relational system, joined to the inventory file by a common field (the accession number), the registrar would not have had to enter duplicating data (artist name, title, dimensions, media, etc.). The variations that tend to creep into redundantly held data would be avoided.
In its simplest form, the resulting study should certainly list the most important fields or types of information that must be accommodated. As the analysis becomes more complete, the report will undoubtedly cite the activities that must be accommodated, 1) a list of the procedures invoked to perform them, 2) the data required by each procedure, and 3) the forms used to transmit data vital to each activity. Additionally, the analysis may include the persons who use the data, the data they specifically require, and the reports that access or store their information. The data elements, themselves must undergo analysis. This will include notation of accepted or conventional syntax, terminology usages and limitations, representation of data length and other structural elements germane to automated database systems.
advised. [Go to Outline.]
This self-analytical procedure discussed here -- the so-called "systems analysis" -- is recommended because successful automation of collection management functions should start with a concise understanding of existing procedures and record keeping systems. Often, to achieve significant benefit, the analysis must be free to draw its conclusions from multiple perspectives at once, including some not generally enjoyed by the individual makers and keepers of the museum's current electronic and paper documentation resources. By integrating and synthesizing the requirements of many users into a uniform model, the analyst can suggest data architectures that reduce redundancy and secure a higher degree of veracity than was possible in the paper storage systems.n3
The integrated goal at which such an analysis aims must not be achieved at the expense of overlooking the diverse, sometimes conflicting requirements of the users. The cataloguing practices of curators with disparate vocabularies and nomenclatures, of departments with diametric classification procedures, and of administrative staff who require less complexly phrased object data must not be overlooked.n4
As museums carry out the tasks and procedures required of their activities, they create and alter data. Some of this information is routinely entered into the museum's records (Acquisitions, Loans, Exhibitions, Conservation, etc.) while other kinds of information may be thought of as documenting transient situations, and kept only briefly (Shipping, Lectures, Exhibit openings, etc.). Other kinds of information may be gathered and stored but not made universally available to all persons. Among such non-confidential data may be included requests for permission to publish photographs, and bibliographical citations.
If the museum's essential activities and procedures can be defined as repeatable sequences or sets of changes and additions to its stores of data, much of the more important information that is lost or put aside during acquisition, loan, conservation and other activities can be collected, maintained and made more universally available. Furthermore, when its procedures are adequately documented, the museum will find it easier to adhere to their stipulated procedural guidelines and will find fewer reasons to side-step them -- as nearly every museum does from time to time. The systems analysis can also help define the difference between data of historical and data of ephemeral significance so that the latter can be routinely deleted from the information stores.
As noted earlier, when computers are first introduced to institutions that have depended upon manual record keeping, the procedures employed usually attempt to replicate the form of paper systems electronically. This methodology -- so logical a first step -- in the long run, typically creates more, not less work for the records management staff who now must maintain both paper documents and their electronic surrogates. In fairness, creating electronic carbons of current paper files will increase access to data and simplify many burdensome reporting tasks -- a sufficiently seductive reason for establishing a database, no matter how simple it may be. However, this tactic notwithstanding, long-term successful computerization is rarely achieved when computers are used to iterate the record-keeping architecture of card indices and vertical files. To succeed, the process frequently demands a comprehensive rethinking of a museum's record-keeping methods. Effective translation to the new technology mandates that the registration operations of the museum be studied and recast in a form both suitable to the ways of electronic storage and comprehensible to native intelligence. In short, the resulting system must maintain commensurate logic with the current filing system while making adjustments for the logic of automated data.
does the system analysis produce?
The documents that form the by-products of the analysis: the compendia of files and fields, the charts of procedures and lists of activities and responsibilities in some cases may be even more important to the museum than the report's conclusions and suggestions. Typically, the analytical procedure documents each kind of data the museum requires and uses; it records the functions served by the data and identifies pre-established and ad hoc forms invoked to transmit and record data. Further, it identifies who creates data and who receives it. The analysis links these data into comprehensible structures that may take the form of procedural flow charts or task lists.
For instance, for an object accession or information file, the report will note what kinds of information are required and collected for each artifact, i.e. the name(s) of makers, their sociological, historical and/or stylistic groups, the maker's production role, the object identifications, its markings, its title, subject, accession group, accession number, acquisition data, media, size and condition descriptions, its location, exhibit history, provenance, etc. It will also cite the forms designed to collect this data, and indicate any duplicate or index files kept. The process may also identify who is responsible for creating this information, the sources used to generate the entry, the procedure(s) by which the data is recorded and/or changed, who has permission to alter the data and who may view it but may not change it. The procedures and activities that refer to or develop this data will include, among others, acquisition and accession, research, loans, conservation, deaccession, changes in attribution and exhibit preparation. The process collects the forms required to activate and execute the above procedures. The analysis develops inventories of sources surveyed, collects specimens of forms analyzed, and gathers the procedural manuals and syntactical guides in current and past use.
Every museum employee, from the director through the guard, will recognize some or all of an accession file's data elements in the records he administers. Files of recent acquisitions, works on display, loans from the past year, research lists, lists of slides and photographs for sale, publication permissions, published citations, vault lists, display and wall lists, gallery surveys, vitrine content lists, packing case inventories, incident and damage reports and so forth all use at least some of the data elements found in the core accession file, while adding data specific to their own functions. In paper systems, as we have seen, these records typically constitute independent, duplicating, repeating and often inconsistent or incomplete filing systems.n5 On computer, each singular manifestation of these data elements can owe their form and substance to a unique authoritative source. Thus when a guard files an incident report on an object, he adds the data relevant to the report, but he does not repeat data already in the system; he does not describe the object affected -- he only has to locate its record. Change the source information or add data and all future citations of the object will be updated automatically. In this chain of dependencies lies one of the most important benefits of computerizing the accession catalogue -- consistent cataloguing and the availability of reliable up-to-date information.n6 Among its other functions, the system analysis ferrets out these dependencies and determines which information types are calculated or derived from other data, and therefore need not be stored. Discipline, order and efficiency are brought to the practice and content of collection documentation.
Because the process of collecting data for a systems analysis inevitably requires creating an inventory of the museum's important data sources and the forms in which data appear, another of the by-products of the exercise is a compendium of the museum's current paper documentation system. Here, each source document is cross-referenced to the function(s) it serves. Thus, by looking under "loans," a researcher will be able to discover which forms and documents are used (or have been used) for loan activity, which data sources are consulted and what procedures should be followed.
As the functional requirements of the museum grow, so may the demands placed on the automated data system. One museum may be satisfied with an automated authoritative collection catalogue to aid research and provide high level access to its data. Another may wish to include loan and exhibit control and planning. One advanced system might be able to track progress on every step required to assemble an exhibit -- from researching works to be borrowed to acquiring, insuring, shipping, conveying, unpacking, inspecting, conserving, displaying, circulating, and returning them. Another museum, with a heavy loan schedule, might wish to have a method of reserving works in its collection for future loans.
In today's museum world, where staff turnover sometimes reaches high frequencies, having the kind of structured study discussed here may prove invaluable during the process of transition from old to new personnel. The information system documentation will be useful even if the museum does not intend to procure an automated system.
analysis process. [Go to Outline.]
The analysis process applicable for a museum has more in common with how a suit of clothes is bought; for here, even after the fundamental decisions regarding features and suitability have been made (two-piece, three-piece, cuffs, suspender buttons; for business, for leisure; for occasion, etc.), the purchaser must be measured for fit. While most shoppers will be satisfied with store sizes, styles and materials and will need few or no alterations, others will find that only a custom made and fitted suit is acceptable. For museums, the systems analysis should consider and suggest the most appropriate type of program application: custom, prebuilt, a combination of the two, or none at all. It also records the measurements necessary to specify the custom system, or to choose among the prebuilt ones.
The best argument against commissioning a systems analysis, or against performing one oneself, is implicit in the above analogy. Since most museums will know intuitively that they will require either a simple or a full featured automation system, and since most of the programs that have been on the market for several years have a high chance of providing at least adequate, if not entirely acceptable functionality, why then should a museum commit itself to the extra expense and/or effort to undergo a detailed self-study? "After all, XYZ program works for the ABC museum which is similar to ours; why should it not work for us too?"
The obvious response to this line of reasoning is that, indeed, any well thought-out system might indeed prove itself entirely suitable; but there is always the not too remote possibility that a system purchased without proper consideration and study of its suitability to your needs may soon prove to be wholly inadequate or, worse, even destructive -- rather like borrowing prescriptive medications from a friend who claims similar symptoms. The costs associated with these kinds of errors generally far outweigh the expenses of the required preliminary studies.n7
your own. [Go to Outline.]
The pitfalls of acquiring an advanced dedicated collection management system without adequate preparation are many: Data collected to manage and document cultural and artistic collections are complex and follow multitudinous conventions created over may years by scholars of varying methodologies and viewpoints. Computers are rather new additions to collection documentation practices. There will certainly be areas in which the technology cannot accommodate itself to the demands of the cataloguer. The new software may not support the museum's traditional filing categories. The chosen system may be too complex for the museum's personnel or too expensive to maintain. It may not record donors and contributors in the accepted, traditional or most useful fashion. The accession records may contain multiple attributions or a history of criticism or other documentary details not supported by the acquired package. The museum may keep complex logs of object condition and conservation, with records of the names of the participating conservators. The museum may maintain records of sets and attribution groups, that the new software may not be able to record correctly. Some of these functions may not be served or may not be served well by any program chosen hastily -- or chosen on the basis of a rudimentary or partial list of needs. Maybe the data structure adequately works for prints and natural history objects, but the costume design collection or the tools and implements from 19th century New England farms cannot be adequately listed. Perhaps the museum should have purchased a program that allowed linkage between object records and items in the museum's library or that permitted exchange of data among other museums, or that had better system of nomenclature control and assignment of cataloguing terminology, or that could link its collection of historical photographs to the museum's artifacts. The museum's records may contain long text descriptions of iconography, style, condition, etc. that cannot be accommodated easily into the existing data structure.
These, and many other questions should be addressed in the systems analysis report. Because the analyst's report incorporates the results of discussions with the staff who have described their operations, their research patterns, the features they need, and the problems they have encountered, the more experience the staff has with the problems of using computers, the better equipped it will be to help compile a list of functional requirements.
As with buying clothing, the museum in search of object management software may probably well know whether it will be able to accommodate itself to a store-bought package, or whether it must commission a custom system. However, even when the "fit" is inexact, most museums should be able to adapt many of their procedures and data collection methods to one commercially available system or another. Many museums may find that at least one of the current commercial systems will prove adequate -- perhaps with some alteration -- while others will have to have their system built for them from the ground up. Each museum will have to weigh the benefits of dealing with a company whose primary business is the computerization of museum collections and who may have supplied other institutions with the same or similar package of programs but who may not be capable of fitting their system exactly to every museum, against the disadvantages of using a generic developer who might be able to meet specific needs, but who may not have had much experience with museum and collection systems.
Administration and Humanistic databases. [Go to Outline.]
For example, a museum collects prints, fine books, drawings and paintings. An analysis that considers just the current collection documentation practices and the paper records the museum generates, without general knowledge of object documentation systems, might recommend solutions that are correct in context, but that introduce conceptual problems. For example, fields are often set up to hold the name of the artist (for prints, drawings & paintings), the publisher (for prints & books) and the author (for books). Duplicate fields might be set aside to record a potential second example of each. This methodology, not unknown among museum databases, is derived literally from card file forms. Multiple fields are allocated for the makers and creators of objects. Using a database of this architecture makes it nearly impossible to find and list all the works by any single creator and limits the number of roles that can be assigned (editor, illustrator, engraver). More enlightened approaches place all maker names associated with an object in a single multi-valued field or define a completely separate file for names, and link the relevant records to the object list through an attribute that may be called, for instance, "role." The above methodology, though not unknown in manual card systems, is especially well suited for electronic record keeping. It simplifies access and permits better control over the names associated with the museum's objects. In addition, it promotes creating only one biographical record per person which then may be attached in multiple ways to multiple objects. This approach results in more simplified record keeping, increased access and better conservation of computer resources.
The analyst-consultant can also be useful in suggesting strategies for retroactively entering much of the museum's current data into the system. Some vendors of museum management software specialize in fast data entry of the museum's collected records. New technologies have saved some museums the expense of manually typing their data into the database. Consultants working for the Winterthur Museum, for example, were able to develop a process by which paper records were scanned and sent to the proper database fields without complex rekeying. Other services make use of fast intelligent typists and specialized input screens that may not be a part of the final database data entry forms. Still other techniques in use choose the most highly structured of the extant paper files, and use software to build the database in parts by entering data from these sorted repeating files automatically without the need for significant manual input.
Finding the most efficient method for retrospective data entry will depend upon the results of the systems analysis. If retrospective data entry seems to be a significant issue, the systems analysis can consider the current data sources and make recommendations accordingly. Some database systems may make the collection of manual data easy but are, themselves, not generally useful for the museum's daily business. In these cases, implementation might be conducted in stages: first acquiring data and then transferring it to the final software platform.
Even when the chances of choosing the wrong or an inappropriate system are slim, the consequences of erroneous judgment may prove too costly to bear. The acquisition and implementation expenses of most systems, even the more costly ones, are relatively small when compared to the long-term overhead in labor sustained during data entry and upkeep. If an automated system does not adequately document the museum's collection, the museum may be forced to keep duplicate sets of records -- one by computer and another by hand. In these cases, the acquisition of a computer system may not have reduced expenses, but, rather, may have increased them. Most people agree that paper and automated systems can (must) co-exist without unwarranted additional expense, but the paper generated should come out of the computer and should be used to document the contents of the automated system -- not the other way around. There is certainly ample reason not to rely too heavily upon the miracle of electronic records, so, aside from their regular backup procedures, most museums will want to produce regularly timed hard copies of their electronic data for documentation -- both for safety and for universal access. The process would not be unlike automated libraries publishing their catalogue every year, except that the museum can have the collection management software issue replacement records only for those items that have changed since a given date.
Products of the Systems Analysis: The Data Dictionary: [Go to Outline.]
Paper record systems, because they are bulky and become old and outdated, frequently are relegated to long term storage or to archives. This process, necessary for bulky paper, hides from accessible view those scholarly materials and other types of object information that have not been transferred into the succeeding database. If the system analysis is commissioned to include surveys of this data, there is a good chance that the acquired software can be designed to reference the archives. If the ultimate function of all automated museum data systems is to preserve and transmit the history of the collection and the collecting institution for use by current and future generations, a proper survey of past, inactive records can help prepare for the creation of a wonderfully useful and rare research tool.
Armed with the information developed by the systems analysis, presented and structured so that it serves as an accessible reference and resource, choosing a commercially available object management database or commissioning one from a programming consultant becomes considerably less daunting an ordeal. The data dictionary lists each type of information collected and indicates the rules of form and syntax to which each piece of information should adhere. At the same time the data dictionary is cross-referenced to its sources -- the files, forms, and information stores where they were found. Similarly, other analysis reports may list each such file or form, describe its function, who uses it, who generates it, who receives it, and list the data elements it contains -- both as they appear and as they are entered into the data dictionary.
When paper forms and files of museums are analyzed, one soon discovers that many of the collected documents use and define data inconsistently. The registration card might list makers by name in inverted order: Doughe, Johannas, adding additional descriptive data, introducing orthographic inconsistencies, and exhibiting usage variations: Doghe, Jan (R.A.). Some cards might provide a location for alternate names or for secondary artists. Acquisition summary reports frequently present names in uninverted order or use the popular form of names: John Doe, and might omit fine details, such as the contribution of secondary artists. Electronic databases typically define two or three fields for an artist's name. Additionally, on paper the name of a field may change from form to form, or, conversely, the expected content of a blank on a paper or electronic form may depend upon the context in which it appears: e.g. On paper, a field called "Name" may call for the name of an artist, donor, conservator, lender, etc.
The data dictionary that accompanies the systems analysis identifies structural and systemic ambiguities and defines a uniform format and syntax that synthesizes the unnecessary discrepancies and analyzes differences found in the museum's data. The data dictionary that accompanies a systems analysis should be composed of several discrete sections: The first part (the dictionary) gives each data entity a name, assigns it to a category of functional field groups (e.g. description, loan, provenance), offers syntactical guidelines, defines it, assigns it to a nomenclature classification or source, and generally comments on its usage and its significance. Another part (the concordance) lists the documents in which each data element is found and provides the name given to it in those documents, which may differ from its official data dictionary name. A third part of the data dictionary, reverses the order and lists each document and names the fields it contains -- both as named in the document and as assigned in the data dictionary. When the number of fields and forms are small, these two last reports may be summarized in a cross-tabulated chart with the names of fields on one axis and the names of forms on another.
The Data Dictionary, and other reports provide objective standards and prerequisites for defining an information system -- standards against which such systems may be judged and measured. Since the analysis uses as its sources whatever current and past paper and electronic files have been created by and have been used by the museum, the documents produced by the analysis serve as a vital index that joins the new system to the old documents.
much to do? A full systems analysis, or just part. [Go to Outline.]
The analysis is most useful and revealing when its range extends beyond the scope of the duties of a single person or office, where no single individual can be fully aware of the operations of the information system as a whole. Those museums that find that they require little more than a simple automated inventory of objects, without including specified functions, may undertake the process of advance planning themselves. Other museums, such as those who may wish to provide access to a wide range of research materials concerning their objects and exhibition activity, will want to hire a professional to assess their needs.
Because computerized cataloguing and collection management is a "hot" topic, it is easy to be led on by promises and visions of automation. It is just as important to know how to define or create an information system for computerization as it is to know when computerization will be an excessive hindrance. While some museums may have an extensive loan and borrowing program that can only be administered efficiently by computer, others may make so few loans that computerization of the process would introduce excessive administrative duties, would be an intrusion upon its daily operations and would require a level of expertise beyond the museum's need. The computer becomes a valuable tool only when humans discover they cannot manage their own activities and when the unavoidable automation overhead has worthwhile benefits.
Needs should drive the application. One museum may require an immediate computerized inventory of objects to administer the movement of collections and will not have the time or patience to install and choose an elaborate systems package, while others may wish to take the time necessary to find an all inclusive solution.
vs. Bottom-up analysis. [Go to Outline.]
Smaller museums may not be able to afford the time-consuming introspective idealistic analysis required by the "top-down" method. These museums, and some larger institutions, too, may be served best by adapting a task list created for other institutions, and developing their systems specifications out of their extant data stores: the accession files, loan records, conservation data files, etc. The methodology of this "bottom-up" procedure lies in the assumption that the data stores adequately, or nearly so, already contain the kinds of data necessary to fulfill the museum mission. One role of the data analysis in these cases is to identify superfluous data and those redundancies that must needs creep into any manual information system. Another task is to create uniform systematic data structures that permit the data to be understood unambiguously.
Systems vs. Business Systems. [Go to Outline.]
More difficult however -- not anticipated by systems made for most business uses -- is the capacity to answer questions that are entirely unexpected. A scholar may wish to find 19th century portraits of men and women wearing glasses, and compare the percentage of female sitters wearing glasses to the percentage of male sitters in the sample. To answer this query, objects would have to be identified as belonging to the 19th century (even if undated); they would have to be classified and identifiable as portraits, typed by sex of the sitter, and by the attributes contained within each image. Sitters may have to be classified by their social position, function or standing. Few museums will have the resources or wish to dedicate staff to set up the proper descriptive fields that would produce the answer to such queries. Indeed, the answers to these queries are not based upon hard data, but upon judgment calls. It is the very essence of scholarly inquiry that the managers of humanistic data can rarely guess the criteria to collect to answer its queries. The above problem strikes at the heart of the intended function of museum databases. Certainly these databases exist to enable the museum to conduct its normal business and to track the legal status of objects, but at what point one must ask where the mandate to collect and preserve scholarly data begins and ends. The museum must determine the boundaries of scholarly access for each object. Will classification by historical and stylistic indicators suffice? Or should the museum include the scholarly materials developed by the academic community and its own curators? Should methods be developed to provide access by subject, theme and iconography? How much of the typography currently used to classify images are culturally and historically based? Should museums attempt to see beyond culturally determined criteria, or are they mandated to embrace the values of the moment -- even in their cataloguing and classification systems?
In a word, should the researcher be able to use the database to facilitate his or her research? While the necessary data may not be available in structured form, the researcher may find the database useful for narrowing his search. He might be able to obtain a list of portraits attributed to the nineteenth century, or by artists working within the stipulated time frame, but it will be more difficult to test the database against the name of the sitter or by the subject's sex. The presence of eyeglasses and other optic aids might be gleaned from a text search of descriptive fields, but without any guarantee of systematic success. (The researcher may have to query for glasses, for eyeglasses, for spectacles, for pince-nez, and for lorgnette, wary of the fact that some of the requested terms have alternate or inappropriate meanings, and equally wary of the fact that the presence of glasses may not have been noted in the description of the work.)n9 A museum dedicated to collecting portraits might need to devote fields with which to name sitters, and even fields in which to render the sitter's title: "The Marquis du ...," but most museums would find this level of specificity excessive. The scholarly researcher must know that while a museum's database may offer him unparalleled access to museum data, in some fundamental ways any system will eventually fail, elude or delude him.
One finds that descriptive and analytical data often reveals the periphery of the value of a systems analysis. Even among fielding requirement that are more traditionally included in object databases, such as culture group or country of origin, museum databases can easily confound researchers. Variations in the nomenclature used to designate similar entities, alternate levels of specificity used to attribute geographical and historical periods, designation of opinions of past curators and current historians, all tend to undo efforts at creating consistent databases. Databases created for business cannot allow irregularities to spoil their effectiveness: parts are assigned inventory numbers, people and corporations are given account numbers. Yet, while giving praise to all noble efforts to introduce consistency in terminology and in the designation of fields, ultimately humanistic databases cannot afford the luxury of such limitations of their specifications. Other methods have to be employed if the system is to be allowed to record the contents of records developed by scholars.n10
But when a museum has elected to collect information meant to be disposed into highly specialized fields, such as attributes, accoutrements, rank or occupation of sitters, a careful systems analysis offers special benefits. With shopping list in hand, the museum can query the vendors of museum software and discover who among them may accommodate his special needs. It is not sufficient to determine that specialized needs can be accommodated; rather, potential users should investigate how these features are implemented. Anything can be written in a note field.
No database system is perfect; each database will compromise data in its own unique way. The above illustration may be taken as an extreme example of the difficulties database systems impose, but there are simpler ones as well. Many of the most common problems derive from the relative simplicity of the controlling database architecture and the relative complexity of the data it must support.
For example, some systems will limit the number of characters that can be entered into its fields, or will permit only a single instance of data in a field. Some will require arcane illogical abbreviations. The systems analysis procedure looks at the data requirements of the museum, not only in terms of what is stored, but in terms of how data is stored, and determines what degree of limitation is acceptable. Must the museum be able to enter accented characters, will the standard IBM ascii set be suitable, or will it need other alphabets such as Hebrew or Cyrillic or Arabic. How should the query system work? Can the museum manage with just a single maker per object, should the number be limited or unlimited? Will the museum need to attribute makers to objects with degrees of uncertainty or degrees of proximity: "Probably by a student of Raphael." Can the exhibit history of an object be placed in a text field or should it be incorporated into the database architecture? Will the museum be forced to divide its collection among several databases or will one master list suffice? Should controlled nomenclatures be adopted other than the ones currently employed? Can licensed nomenclatures be edited?
Museums that have traditionally depended heavily upon the information stored in their paper files to administer and research their objects eventually come to suffer under the weight and disorder of redundant indexing and out-dated information stores. These systems are extremely difficult to maintain efficiently and become increasingly difficult to pass on to new staff. In addition, paperbound records management systems tend to inhibit, rather than promote access to their data. At the same time paper systems record complex data types and comments that are very difficult to render -- even in words. A good systems analysis will provide the tools that enable the museum to reduce the occurrence of repetitive data it manages and will facilitate the use of these common data sources for multiple purposes. When paper records and archives must be kept, the information system can keep track of their whereabouts, their contents and their indices.
While only the rare museum will wish to abandon its paper files altogether, using the computer to index the paper systems or to serve as a surrogate for paper systems may seem to enhance collection management by introducing additional points of access and providing additional useful tools, especially in the area of collection reporting. Looking at these operations from the vantage of the role each activity plays within the scope of museum operations as a whole will undoubtedly reveal the duplications of effort such systems employ. Accepting the primacy of the electronic record does not negate the value of paper documentation; what it does is to shift the process of information management into systems crafted for efficiency. Using the ability of the computer to map and control essential procedures introduces margins of safety and levels of consistency to museum activities heretofore possible with only the best of trained staffs. Paper records produced from computer originals may be strategically important, but they will no longer enjoy their archival status; they will merely be temporary replaceable documentation.
Introducing museum systems that guide staff through acquisition and loan procedures, through exhibit planning and deaccessioning, can only be accomplished after the systems analysis has revealed the methods, tasks and procedures employed for these processes. It is the function of the systems analysis to render this technology in a comprehensible and articulate form.
Conclusion. [Go to Outline.]
NOTES: [Go to Top.]
1 When reviewing a museum's databases it is not uncommon to meet staff who have no idea what an existing database documents, how it was used, who created it, and whether it is or was part of an ongoing process. [Return to text]
2 Large systems might use the status flag to signal records to be deleted after copying the records into a large loan history database. [Return to text.]
1) The first type of redundancy develops from the varying needs of users. It occurrs when the same data may be kept in different databases, as when the development officer keeps one database of museum donors and the registrar keeps the same information in the object database. The danger here manifests itself when one user changes or adds to the database, but another does not. The informations resources lose their agreement.
2) Redundancy from multiple occurrance of same data in the database. As when each object record contains the name of the maker or makers.
3) Redundancy from different syntactical requirements, as when information is used for display that cannot be stored in a form suitable for queries. See Fabing article cited below. [Return to text.]
4 For a discussion of the role curators and museum scholars should play in systems analysis procedures, see Suzannah Fabing, "Facts on File," in Museum News, Vol. 70. No. 2 (March/April 1991), p. 56 ff. [Return to text.]
5 In one museum the Security division identified rooms and galleries with a coding system not used or known by the Registration department. One night, when Security called Registration to report a flood, the exact location of the damage could not be communicated to the Registrar. [Return to text.]
6 In museums and history collections certain kinds of data can be updated, but other information, for example, attribution, must be kept, even as it is changed. [Return to text.]
7 For an opposing view, see Barbara Bormuth Witt, "How to Choose a Computer System: Advice from a Vendor," in Spectra, Vol. 16, No. 4 (Winter 1989), p. 11 ff. [Return to text.]
8 See Patricia Ann Reed and Jane Sledge, "Thinking About Museum Information," in Library Trends, Vol. 37, No. 2 (Fall 1988), pp. 220 ff. [Return to text.]
9 Note that the Getty Art and Architecture Thesaurus places eyeglasses, spectacles and pince-nez under the category, "eyewear," lorgnettes, however, are classified as "costume accessories carried." [Return to text.]
10 [Since this article was written much progress has been achieved in creating systematic lists of fields. Readers are recommended to consult the following URL where information can be obtained on the projects listed below it:
In the beginning.