Skip to end of metadata
Go to start of metadata

Project Overview

The CollectionSpace project goal is to produce a suite of modules and services that will provide a stable, robust, authoritative, and flexible core of collections information from which interpretive materials and experiences - from printed catalogs to mobile gallery guides - may be efficiently developed, and that can serve as a cost-effective alternative to proprietary collections management systems for museums in need, regardless of size or scope. The openness of the software will allow it to be connected with other open-source applications already in-use by the cultural sector including those for archival management, online exhibition creation, and digital asset management.

We intend to develop a stand-alone, free, easy-to-use collection cataloging and presentation application that meets the needs of museums of all sizes, historical societies, and other collection-holding organizations worldwide. The usability of the CollectionSpace application will be defined through its user interface, which will be developed from the ground up using the Fluid Framework, with internationalization in mind, and that will provide an accessible user experience for all.

In addition, CollectionSpace will be designed and developed so that it can be used with a wide suite of flexible, interoperable, and modular open source enterprise applications that are being developed and deployed by larger organizations. For these users, CollectionSpace will serve as an all-purpose interface to repositories of digital and physical assets across an institution. These larger organizations will serve as use cases to test the scalability of CollectionSpace.

The CollectionSpace Development Plan will unfold in three phases. Phase One will focus on the physical artifact, object, or specimen and provide the means through which to manage them. Phase Two will focus on descriptive metadata and how it can be used by museum professionals to interpret, publish, display and create experiences based on scholarship and the needs of diverse audiences. Phase Three will focus on preservation and the technical requirements needed to provide access to collections information and to ensure its authenticity over an extended period of time. For all phases of development we will ensure that solutions are suitable for art, history, and science materials (i.e., fine arts, history, natural science, archaeology, anthropology, etc.).



We will use SPECTRUM as the basis for the core collections management functions and units of information. SPECTRUM was developed and continues to be maintained by Collections Trust (formerly the Museum Documentation Association or MDA) in the UK and is considered an international standard for collections management.

Development activities in phase one will center on a subset of eight SPECTRUM procedures (workflows): those that comprise the minimum procedures required for accreditation in the UK. These procedures include: Object Entry, Acquisition, Location and movement control, Cataloging, Object exit, Loans in, Loans out, and Retrospective documentation.

This subset has been selected for several reasons:

  1. It represents a minimum standard for service and accountability across museums in the UK (with no equivalent in the States);
  2. While there are requirements for accreditation in the U.S., collections management functions as related to software that supports it are not recognized;
  3. The accreditation subset provides a stable foundation upon which the other phases can be built;
  4. There is a strong possibility that several of the functions can be turned into SOA services.

By limiting our first phase to these key functions, we can accomplish several things:

  1. Create a workable system for our user community to comment on and test during the first phase, rather then a disjointed set of features.
  2. Develop a working methodology for collaboration among the functional, technical, and UI teams. The eight procedures listed above are both well-defined and well-documented. If the project team can streamline the development process while working on these "easier" elements, it increases the odds that collaboration will run smoothly when the teams begin the more difficult (and fun) design and development work.
  3. As mentioned above, this function set is the base on which many of our more innovative features rest. For example, without object cataloging, there can be no collections publishing online. Without object records, there can be no linkages to complementary systems, such as digital asset management systems or integrated library systems. Object entry lets us test workflow management and document generation, while Cataloging gives us vocabulary and authority control, and so on.


In the original project proposal, we committed to: the development of user interface and related accessibility components within current W3C guidelines; the use of the Fluid Framework for front-end and back end user interface design (this includes tool sets, features, element sets, customizations, configurations, etc.); producing a user interface that is developed and maintained as a separate entity from the underlying application code; and developing a user interface that supports language-specific formatting rules (i.e., one that can be displayed in any language and one that can take language display constraints into consideration).

With these commitments in mind, phase one activities should include:

  1. Determining which of the 'potential' components from the Fluid potential component matrix can be used in conjunction with the functions listed in the functionality section above.
  2. Testing and incorporating selected components into the application.
  3. Identifying core accessibility features, protocols, and approaches that will form the foundation for all interfaces used throughout the application.
  4. Defining, testing, and refining a library of templates that will be able to serve multiple facets of the application.

All of these activities will be iterative, and will be revisited throughout CollectionSpace's design and development life cycle. For example, as we design new screens for the application, we'll identify and build new components and accessibility strategies along the way.


The technical team will focus on establishing a high-level architecture and shape for the CollectionSpace services and application, before moving on to active development.

  1. High-level system architecture: This architecture will sketch out the rough shape of our service and application design, showing the various modules and dependency boundaries within the system.
  2. High-level map of CollectionSpace services: Provides a landscape of the potential services we will build, based on:
    • the feedback and recommendations from the community workshops
    • comparative analysis of existing systems
    • input and direction from the functional/design tea
  3. Code repository and standards for development in the CollectionSpace community:
    • Set up a source code repository along with the associated set of processes for handling commit access, code quality, etc. within our community.
    • Define the technical architecture and tools for the development process.


All of the functions and associated units of information are available from the electronic version of SPECTRUM, a copy of which has been made available to all project partners. In addition, the following documentation will be developed:

  1. Complete list of procedures and associated units of information;
  2. A set of visualizations that illustrate the relationships between the procedures and the units of information, fluid components, and code analysis;
  3. List of extant Fluid components that relate to these functions;
  4. List of components from existing code analysis that are candidates to be used to develop these functions;
  5. SOA analysis of procedures to determine which might be developed as services;
  6. Preliminary documentation, including an administrator's guide, a "getting started" guide, a developer's manual, and an interactive user tutorial.

The project's support wiki will also be frequently updated to include the most current information.

Elements from the CollectionSpace Core Functionality covered during the first phase:

We will develop the functionality below following SOA methodology, first modeling the services involved, then developing the services, and then building a simple test application that ties these together. Parallel to the SOA work is user experience work and user interface tools development, that are used to build applications.

Collections Management


Collections Management


Collections Management

Location and movement control

Collections Management

Object entry

Collections Management

Object exit

Collections Management

Retrospective documentation

Collections Management / Publishing

Media handling

Collections Management / Publishing

Authority control

Collections Management / Publishing


Data management

Import / Export

Loans and Dispatch

Loans in

Loans and Dispatch

Loans out

System Administration


System Administration


System Administration


System Administration


System Administration


Accessibility / User Interface

Fluid Framework components identification

Accessibility / User Interface

UI requirements

Accessibility / User Interface

UI documentation

  • No labels