CollectiveAccess is open-source collections management and presentation software designed for museums, archives, and special collections. As it is easily customized, it is also increasingly used by libraries, corporations and non-profits. At its core, CollectiveAccess is a relational database that enables powerful searching and browsing options and provides opportunities for nuanced web-based collection discovery. In this quick-start guide, we’ll discuss the intended uses of CollectiveAccess, its front and back-end components, set-up and configurability, and data migration. Throughout you will be directed to more in-depth guides on each major point, and you will gain a clearer understanding of how CollectiveAccess can work for your organization.
Who uses it?
The flexibility of CollectiveAccess makes it a great choice for a variety of organizations, particularly those wishing to illustrate relationships between different types of records. In addition to supporting different metadata standards, it also accommodates an array of external data sources and services such as The Library of Congress Subject Headings, the Getty Art and Architecture Thesaurus, Googlemaps, and other descriptive and geospatial services. It can also handle a broad spectrum of digital media formats. As a result, It can accommodate traditional library collections as well as more idiosyncratic collections.
The focus of a collection need not be objects - CollectiveAccess could center on exhibitions, collections, entities, etc. depending on your project’s needs. It also supports a wide variety of metadata standards (or a custom combination of your choosing). Examples of organizations that have benefitted from CollectiveAccess include art museums, historical societies and museums, institutional archives, mixed collections, film archives, natural history archives, fine art collections, and more. Because it is a web-based system, CollectiveAccess is also useful for projects that need to be accessed remotely by multiple users. Furthermore, because it includes an optional front-end application, CollectiveAccess is an excellent choice for organizations wishing to offer public access to collections.
Providence and Pawtucket
The two main components of CollectiveAccess are Providence, the core cataloguing and data management application, and Pawtucket, an optional "front-end" publication and discovery platform. If you are starting out with CollectiveAccess, your first download should be Providence, which provides all of the "back-end" cataloguing and data management functionality you'll need to manage a collection. To download both Providence and Pawtucket, visit here or find our code on Github here. Other aspects of CollectiveAccess will only operate if you have a working version of Providence installed.
Providence can be used to catalog almost anything. There are no hardcoded fields and all fields system-wide are customizable programmatically using an xml-based profile, or through the user interface. Once you have settled on a data model, you can configure Providence and import or hand-catalog your data. Users will be able to log in to the system from any location with internet access, and administrators can customize access privileges. If you don’t wish to publish any of your data to the web, you can create an archive using only Providence and you don’t need to worry about downloading Pawtucket.
The collection presentation component of CollectiveAccess, or front-end website software, is called Pawtucket. It’s designed to pull content from the Providence database into a public-access interface that’s entirely customizable. The default theme for Pawtucket is visually simple, but with a little modification of the site’s CSS and navigation files almost any design can be supported. The look and feel of a Pawtucket site is governed, as with many php-based websites, by a theme directory. To begin designing, simply copy the default theme folder, rename it to match your project, and set the theme in the setup.php file. You can download Pawtucket here.
How it Runs
Before you get started with Providence, you'll need to choose and set up a server. The basic requirements include at least 1gig of memory for typical uses and small media, adequate data storage to accommodate your media, and any modern CPU. Linux, Windows (Server 2003, Server 2008, Windows XP and Windows 7 verified to work), Solaris 9+, and Mac OS X 10.5+ are all acceptable operating systems. See here for additional information on specific operating systems, and here for more on basic installation requirements. Providence also requires the installation of three core open-source software packages: Apache (1.3, 2.0 or 2.2), MySQL (5.0, 5.1 or 5.5) and PHP (5.3.6+). You may also need to install various supporting software libraries and tools, such as ImageMagick, if you wish to handle certain types of media. All of this is up to you to provide - CollectiveAccess does not automatically provide hosting. A full list of required and suggested support software and modules can be found here.
Once your server is set up, you can download Providence from our downloads page (where you will also find Pawtucket). You can also obtain CollectiveAccess from the project's GitHub repository. For a detailed guide to installation, from server requirements to the final moment, visit Installing Providence and Installing Pawtucket on our project wiki. If you wish to experiment with CollectiveAccess on your Mac or Windows PC without setting up a server try the QuickStart package. The package includes all of the basic prerequisites and a pre-configured DublinCore-based installation of CollectiveAccess. It includes both the Providence cataloguing application and Pawtucket publishing interface. Just download to your computer, unpack and click on the start button. However, be aware that this option isn’t ideal for long-term institutional work, so you should use it primarily for exploratory purposes.
Installation Profiles and Configurability
The key to customizing your copy of CollectiveAccess is the Installation_profile. This is an XML document that tells the software how to set up various aspects of Providence. Installation profiles generate and define controlled vocabularies, create standards-compliant setups, define and label metadata fields, define data entry screens and assign them to record types, delineate and describe relationships between record types, set logins for users, and configure display of search results and data exports. In other words, they allow you to make CollectiveAccess your own.
Unlike many cataloging platforms, CollectiveAccess does not restrict you to a certain set of fields or even a given set of data entry screens. This means that you can (and must) determine which fields you wish to use and how you wish to organize them. Adding, deleting, and even reorganizing fields in Providence can be done easily at any stage of a project. These configurable fields can be further customized; they can vary in size, be repeatable, collapsible, etc. They take a broad variety of data types such as text, date ranges, numbers and predefined lists, designated during the creation of the element. This means that the software recognizes and normalizes data values, facilitating data conversion and enhancing search and browse functions. It also means that there are many decisions to be made when choosing a data model. For example, you may want to determine the Object types into which your collection can be divided, so you can tailor specific metadata elements to each and keep your screens from appearing cluttered.
At the beginning of the process, when there are many such decisions to make, it is more efficient to work directly in the XML document, testing and reinstalling as you go along. However, once you have some data entered in your system, you will no longer be able to re-install without deleting your work. Fortunately, you can still make changes at that stage through the “Manage” menu in the graphical user interface. These changes will be somewhat more time consuming, but will allow you to achieve flexibility in your database well into the future. Users with “administrator” status can configure metadata elements, add them to user interfaces, create and delete screens, add relationship types, and update lists and vocabularies. All of this being said, CollectiveAccess is still built around certain rules. There are sixteen “Basic Tables,” primary record types which anchor the environment, that you can read about here. You do not need to work with each and every one of these types, and you can adjust the terminology when necessary, but understanding what they mean and how they function will allow you to manipulate them with greater dexterity.
All of these options can be overwhelming. Fortunately, when building an installation profile, there is little reason to work from scratch. If you’re looking for a place to begin with your configuration, you can start with the CA schema library, which includes many pre-configured standards such as PBCore, DublinCore, VRA, DarwinCore, CDWA Lite, SPECTRUM, MARC and others, as well as a variety of user-contributed custom installation profiles. The library offers profiles by organization type; you’ll find everything from institutional archives to natural history museums. You can use a configuration as-is, or as a starting point for a system molded to meet your needs. To use one of the profiles in the library with your copy of CollectiveAccess, download the desired profile and copy it into the profiles/xml directory of the installer. After reloading the installer start page the newly installed profile should appear in the profiles drop-down menu.
A beautifully configured profile is meaningless without content, and most users already have some form of data management in place when they turn to CollectiveAccess. As a result, the release of CollectiveAccess v1.4 has enabled users to create their own mappings and migrate their source data directly into a configuration of Providence. This is a detailed process that involves using a template to map each metadata element in the source data to its corresponding field in CollectiveAccess. This template can be used to import data in XLSX, XLS, MARC, MYSQL, Filemaker XML and Inmagic XML, and will soon be usable for tab delimited, CSV, and OAI-PMH/DC files. It can also be used to migrate data from one CollectiveAccess system to another. For a technical approach, with a downloadable version of the template, visit here. For a more user-friendly approach, try here. The process is most manageable when working with clean source data. There is only so much that one can do, in the mapping process, to account for inconsistencies in style, etc. For large data sets, you will need a reliable internet connection and you will probably want to run the import through the command line. For smaller batches, you can simply import through the Providence user interface.
Throughout the process, you can refer to the <a href="http://collectiveaccess.org/support/forum">CollectiveAccess forum</a> and our project <a href="http://docs.collectiveaccess.org/wiki/Main_Page">wiki</a> for support. The wiki includes information about installation and set-up, but it’s also a useful resource for cataloguers who are working with the software on a day-to-day basis. Embedded in the wiki there is a <a href="http://docs.collectiveaccess.org/wiki/Category:Users_Guide">users guide</a> that describes navigation through the user interface, and is a useful way to determine if the workflow of a standard CollectiveAccess project makes sense for you. There is also a topic-by-topic <a href="http://docs.collectiveaccess.org/wiki/CollectiveAccess_Cookbook">cookbook</a> that can be a handy resource for quick and easy troubleshooting. And finally, some users look to consultants for help with their ColllectiveAccess projects. Find more information about getting outside help from developers <a href="http://collectiveaccess.org/support/consulting">here</a>.