Welcome back to our online classroom for Cataloguing Museum Collections: History, Trends, and Issues.
This week we are investigating cataloguing systems and tools. We will begin this presentation by briefly covering the history of cataloguing systems in museums. We will follow that with a look at the current state cataloguing systems, specifically collections management systems, in museums today. That will be followed by a discussion of the role of digital asset management and content management systems in providing different spaces for cataloguing. Finally we will look to the future of museum cataloguing systems and think a little about what might be in store for the next ten years.
As we have discussed before in this class, early cataloguing systems in museums were paper based catalogues that existed in ledger books or on catalogue cards. As with any system, the characteristics of the system place parameters on how the information in the system can be used. While ledgers and catalogue cards were an appropriate record of the collection for their time, they provided access in a quite limited way. First they were constrained by their physicality. A user of the cards had to be in a room with the cards in order to look at them. While museum staff would follow up on research request received by mail, the process of researching the collection was slow. Users also had to understand the cataloguing rules in order to find what they were looking for.
This changed in the late 1970s and early 1980s as early “computerized” systems made their way into museums. Although early incarnations were little more than the cards from the card catalogue transcribed into an electrical box, they signaled a fundamental change in how museum information was going to be managed. These early systems were mostly stand alone without network capabilities, but they did provide searching on all of the fields in the database. This was big! For the first time, museums could ask questions like, “How many paintings do we own that were created in the 1920s?”Often early systems were adaptations of generic database management systems for the museum space. This adaptation was primarily done in an ad hoc manner at a single museum. This led to highly specific systems that closely resembled the paper based systems they were replacing. While this eased the transition from one system to the next, replicating the paper system in a digital form placed limits on the digital systems that were no longer necessary. A good example of this was the continuation of the practice of using inverted word order for person names, “Smith, John” instead of “John Smith.” In a digital system, it makes far more sense to have a surname and given name field along with a display name field than it does to use inverted word order. Over time the designers of systems fixed these anachronistic features.
Some early digital cataloguing systems employed a relational database model. Relational databases were a significant step forward in information management because they allowed large amounts of data to be stored and interrogated in an efficient and quick way. Here is a good definition of a relational database that I found on the web: A relational database is a collection of data items organized as a set of formally described tables from which data can be accessed or reassembled in many different ways without having to reorganize the database tables. The relational database was invented by E. F. Codd at IBM in 1970.Here is an example of how relational databases work in a museum catalogue. Consider the “Hot Pot” krater from Hoving’s article of a few weeks ago. Euphronios was the painter and Euxitheos was the potter. In a relational database, the record for the crater could be in a table called “Objects” and catalogued with fields for Accession Number, Title, Object Name, etc. The two people involved in the creation of the krater would be catalogued in another table that we will call “Artist.” As the record for the krater is catalogued, a cross-reference relationship is created between the record in the Objects table and the two records in the Artist table to note Euphronios as painter and Euxitheos as potter. Both Euphronios and Euxitheos have only one record in the database and each time an object is catalogued that relates to them, another cross-reference record is written to a third table. In that way, if a user wants to search on everything painted by Euphronios, the system looks up the one record in the Artist table and then finds all of the cross-references. This is much more efficient from a processing standpoint than searching every record in a flat file to find the string “ Euphronios.”
The mid 1990s saw the creation of the early versions of the current crop of collections management systems that are in use today. Let’s take a look at some of the distinguishing features of these systems.
Almost all “modern” collections management systems rely on a rich graphical user interface to guide users through cataloguing and research. By the mid 1990s, the use of a mouse to control a computer was ubiquitous. Early web browsers like Mosaic were available and pointing the path toward the graphically rich information space that we have today. Digital photography was in its infancy, but Collections Management vendors saw a big win if they could supply a clear and useful identification image to the catalogue record. Museums were imagining public access with the new systems. A relatively easy to use and visually inviting interface was important in drawing the public in. For these reasons and more, a good user interface went a long way in selling collections management systems.
Modern collections management systems rely on the networked environment to provide access to the catalogue to multiple concurrent users. In doing this, most systems are configured in a client-server architecture where users access the catalogue on client machines that are connected to a server via a network. This architecture simplifies the maintenance tasks necessary to support the system because everything of consequence is being stored in a central location on the server. Only the server needs to be backed up or have a fast processor to manage the database. The networked system also anticipated the need to move collections catalogue information to other places on the network including public websites, in-gallery kiosks, etc.
Most modern collections management systems rely on a industry standard structured query language database to perform the backend database function of the system. Using SQL dbs separates the heavy lifting database function that need not be specific to museums from the business logic and graphical user interface that are tailored to museum needs. This also makes communication with other systems easier because they could use standard database calls to gather information as necessary.But let’s step back a moment, What is SQL?SQL stands for "Structured Query Language," and can be pronounced as either "sequel" or "S-Q-L." It is a query language used for accessing and modifying information in a database. Some common SQL commands include "insert," "update," and "delete." The language was first created by IBM in 1975 and was called SEQUEL for "Structured English Query Language." Since then, it has undergone a number of changes, many coming from Oracle products.Today, SQL is commonly used for Web database development and management. Though SQL is now considered to be a standard language, there are still a number of variations of it, such as MSSQL and mySQL.
Modern collections management systems have permissions systems in place that credential users and control what they can do within the system. As systems moved to multi-user environments, this became necessary in order to support the basic business functions of the museum. A museum wouldn’t want the same level of access to change records in the system for an intern as it would want for its chief registrar. In addition to providing security, credentialed login allows many of the systems to keep a thorough audit trail of changes in the database. This audit trail often includes the user the identity, the field that was changed and a date time stamp of the change.
Modern collections management systems reflect the relational data structure that underlies them. For this reason, we often see a number of different modules on the home screens of these systems. Records are segregated into these modules for organizational reasons, but records in one module can often be linked to related records in other modules.
It is hard to overstate the change brought about by the use of modern cataloguing systems in museums. In many institutions, virtually all of the administrative tasks related to the collection are managed with the cataloguing system. In addition to changing the way that administrative tasks are completed, cataloguing systems have changed exhibition planning. Whether it is creating an exhibition checklist or compiling government forms for immunity from seizure or indemnity, the collections management system is involved. Finally, cataloguing systems have opened up access to collections. This has primarily taken place online although it is also happening within institutions.
Museum websites have brought collections from across the globe into the homes and schools of our users. Collections management systems have been the source for much of the collections content that is available on our websites. However, as we worked to populate those websites with the content from our collections systems, we found deficiencies in the systems that we were using. Collections management systems weren’t great at managing longer contextual information that wasn’t about a specific object or artist, but rather was about a period or trend. They also didn’t do a good job managing large media files like images, videos, and sound files that related to the collection. For those reasons, museums began to employ more systems to help in the cataloguing of their collections.
Content management systems are widely used to publish websites. They allow non-technical users to collaborate to add rich content to a repository that can be published to the web. In the context of museum cataloguing, they often provide a place for longer-form writing related to objects or themes from the collection. They also allow museum to catalogue non-collections records such as events or educational programs that are organized by the museum.
Digital asset management systems are designed to perform the specific functions and tasks necessary to manage high-resolution digital images files, digital video files, and digital audio recordings. Museums are employing DAM systems to do just that. They are tying their DAM systems to their collections management systems in order to serve the highest quality assets possible to various target locations including the web and print publications.
The integration of all of these systems has not been easy. Many of the collections management systems in use are based on technology that is at least fifteen years old. Integration often required hard-coding one system into the next. By this I mean to say that the programmer of one system, say a museum’s website, had to be intimately familiar with the business logic of the collections management system in order to get object information out of that system. Hard-coding the systems together also meant that if there was a change or upgrade to one system, the integration of the two systems would have to be re-engineered. This is costly to museums. Newer technology offers a better way.
So what might the next generation collections management systems look like? We can say a couple of things with certainty. First, they will be browser based. Current collections management systems require users to install a workstation application on their machine and keep it up to date with the version of the system installed on the server. This takes time and effort to maintain. New systems will rely on commonly available web browsers (Internet Explorer, Firefox, Google Chrome) to serve as the front-end to users. Next, the new systems will be a series of loosely coupled services that can be easily joined together in novel ways. This follows a software architecture called Service Oriented Architecture. The systems will have published application programming interfaces that make it easy for their functions to be integrated into other systems like content management and digital asset management.
Watch the CollectionSpace Webinar that details the 1.0 release of a new open source tool for collections cataloguing. http://www.collectionspace.org/content/webinars/museum_and_cultural_heritage_professionals_am
Jhu Week 5
Cataloguing Museum Collections<br />History, Trends, and Issues<br />Michael Jenkins<br />JHU Museum Studies Spring 2010<br />
Week 5: Cataloguing Systems and Tools<br />History of cataloguing systems<br />Current state of collections management systems<br />Role of digital asset management and content management<br />Future of cataloguing systems<br />
Relational Database Model<br />A relational database is a collection of data items organized as a set of formally-described tables from which data can be accessed or reassembled in many different ways without having to reorganize the database tables. The relational database was invented by E. F. Codd at IBM in 1970.<br />Source: http://searchsqlserver.techtarget.com/sDefinition/0,,sid87_gci212885,00.html<br />
Structured Query Language Database Backends<br />SQL stands for "Structured Query Language," and can be pronounced as either "sequel" or "S-Q-L." It is a query language used for accessing and modifying information in a database. Some common SQL commands include "insert," "update," and "delete." The language was first created by IBM in 1975 and was called SEQUEL for "Structured English Query Language." Since then, it has undergone a number of changes, many coming from Oracle products.Today, SQL is commonly used for Web database development and management. Though SQL is now considered to be a standard language, there are still a number of variations of it, such as MSSQL and mySQL. Source: http://www.techterms.com/definition/sql<br />
Security Access and Control<br />Maintain permissions and security<br />Provide change audit<br />
Integration of Systems<br />Integration has been hard work<br />Hard-coding was required to integrate components of cataloguing and access systems<br />Upgrades or changes to one system required a reworking of the integration<br />
Watch the CollectionSpace Webinar<br />http://www.collectionspace.org/content/webinars/museum_and_cultural_heritage_professionals_am<br />
Reading<br />Read the Canadian Heritage Information Network's Collections Management Software Review, http://www.pro.rcip-chin.gc.ca/gestion_collections-collections_management/evaluation_logiciels-software_review/index-eng.jspAs you read consider how our notions of collections management may have changed since this report was issued in 2004. Do you think that a homegrown system is still a viable option for museums? How far should a collections management system go into the areas of digital asset management and content management? What role do you see for open source collections management systems? Evaluate the methodology employed by CHIN. Would you have structured the software review any differently?<br />
Written Assignment<br />Pick a Collections Management Vendor and review their product descriptions (either printed or online). Based on the product descriptions, describe their strength and weaknesses in the areas of collections documentation, digital asset management, and content management. Describe the type of organization that would be a good fit for the software and the limitations of the software that might make it unsuitable for other organizations. How easily does the product integrate with other systems? How difficult would it be to make records available online? Do you think the user interface looks intuitive? How well does the system handle reporting? Are there adequate security controls in place? Submissions should be approximately 500 words. <br />
Discussions<br />Monitor the Discussion area of Sakai for this week’s topics. New topics will be posted on Monday and Thursday. <br />