IN RESPONSE TO DATABASE ACCESS FOR CURATORS
In setting up "rules" for adding and editing information, the specific features of the specific cms being used are critical to what you can do to control errors and consistency. With MIMSY XG, for example, the db administrator is able to do the following while in other cms, these features will not be available: 1. Each curator can have his/her own set of screens -- each screen can be customized to the curator's individual needs such as which fields to include, which to exclude, what order the fields appear in, what the field is called on the screen, help messages for each field specific to the application or project, and vocabulary controls on any or all fields that give specific instructions relevant to what the curator is doing. Among other elements. So, a natural history curator may have a entry/edit/query screen that looks quite different than the screen used by her colleague in the paintings department and neither curators' screens may look anything like the screen needed by the conservator. The db administrator can set fields to be read-only or editable or not to appear at all. The db administrator can also limit what records in the database can be accessed by any staff member within his/her security profile. A single curator may have many sets of screens, each for a specific project. For example, if a survey is being taken on whether arsenic preservatives may be present in bird specimens, the ornithologist's screen for this project might contain read-only fields by which the specimens can be located in storage and their identities verified along with several fields that the ornithologist can record survey information. This same screen can be ported to a hand-held or tablet for ease-of-use in a survey such as this where the curator needs to move around and between storage areas. Who updates the record and when is of course recorded automatically based on the curator's security login. 2. Accession numbers can only be changed by the db administrator. 3. Numerous primary fields such as Other Number, Display Title, Maker, Description, Date Made, etc, retain all changes made to them, who made the changes and why, as part of an object's running history. For example, the decorative arts curator needs to change the attribution on a table from Thomas Sheraton to Duncan Phyfe. He has been assigned the ability to update the Maker field as part of his set of screens. He queries for the record by any field value, the record appears on his screen. When he starts typing "Duncan Phyfe" into the Maker field, MIMSY XG will prompt the curator for the reason why the change is being made. The previous value and the new value are both stored and each is separately accessible so that on reports, the curator may want only the current attribution to appear, or in other instances, the current attribution along with all previous ones. 4. If a record for "Duncan Phyfe" already exists in the People Master File, MIMSY will indicate this [regardless of whether "Duncan Phyfe" or "Phyfe, Duncan" is entered] and automatically attach the object to Phyfe's record. If "Duncan Phyfe" does not exist in the People Master File, MIMSY prompts the user to create a record for him asking only whether the name is an individual or a non-individual and then will automatically create a record in the People Master File. This is all done without the curator having to leave the Object Master screen. If a record is created in the People Master File, it will automatically contain the name of the curator and the date he added "Duncan Phyfe" into the file. Essentially the same process occurs for each of the mission-critical fields recorded about an Object as well as for activities such as Location, Value, Condition, and other key processes. 5. MIMSY is designed to record as many descriptions as desired, precisely so that important information isn't lost when staff members' tastes change, or an exhibition is in the works, or the education department needs a K-8 description. Each description is retained along with its source, its purpose (terms can be controlled through "closed" pop-up lists rather than open-ended ones), its author, and so on. So a single object may have one or a hundred and one separate descriptions along with related information about the description, each of which is separately recorded, and separately accessible. Educators can quickly find all of the "published catalogue" descriptions. This enables a museum to retain all of the original information on the handwritten source cards through each exhibit label, visitor's guide, exhibit catalogue, on-line web displays, physical descriptions, art historical descriptions, docent tour descriptions, etc. Sorry that's so long. There is no reason that information should be lost once it has gone from paper to electronic form yet I see this repeatedly. It goes against basic collection management principles that were in place and carefully followed until the time that computers started being used in museums. Dozens, probably hundreds, of museums threw away their original handwritten records that contained incredible amounts of information not transferred into a database and this was followed by implementing systems that take an approach of one value for one field which doesn't reflect the reality of collection data. IN RESPONSE TO RICHARD LIGHT: The reason why the UK handles these things more effectively is multi-fold. First, when you and Andrew Roberts were the MDA, you instituted nation-wide standards that resulted in a consistency of data recording that didn't exist elsewhere. Second, at the same time, UK museums were supported by local and national governments who had mainframe computers. Museums had to pay for access to these mainframes and therefore knew from the start that there were fairly high expenses related to automating their collections. Since the data was being keyed in remotely, UK museums also knew the resources required to create their collection databases. Third, at the same time, UK museums did not have a registrar position comparable to the long-established practice in the US. Curators did their own cataloguing and so were involved in the use of the databases right from the start whereas registrars in the US ran/run the show and so the systems in the UK started out as curator-oriented while in the US they started out and for the most part remain in the domain of the registrar whose needs and concerns are quite different than that of curators, conservators, etc. Therefore, the UK museums have a much broader range of users within the institution using the database than in the US or even Canada and Australia. Bottom line is that you and Andrew Roberts do not get the credit you deserve for what has resulted in a superior use of computers in museums in the UK compared to other parts of the world. So, in spite of the fact that systems in the US (particularly MIMSY XG) have features like repeatable comments and dozens and dozens of elements that control consistency and reduce the amount of entry required to create and edit records, these features are either unknown to the curators (who do not generally attend training sessions) and registrars and IT people but, since most of these features are unnecessary for the registrars who use the system routinely and the nature of whose work differs significantly from that of other museum staff, the features remain unused in the US but are widely used in the UK.
