CollectionSpace is a collaboration that brings together a variety of cultural and academic institutions with the common goal of developing and deploying an open-source, web-based software application for the description, management, and dissemination of museum collections information. This report includes an update on the project team's activities for June and July. The next update will be released Friday, August 7th.
The CollectionSpace project team is pleased to announce the release of CollectionSpace 0.1, which allows users to create a new object record, view and edit existing records, and save any changes. The 0.1 release interface only allows for text entry; dates, controlled vocabularies, and pattern numbers (e.g. accession numbers) will be functional at a later date. The CollectionSpace project team is moving to a more active release schedule, and new functionality will be added on a regular basis.
The CollectionSpace project team welcomes any and all questions, comments, and critiques of the 0.1 Release. A feedback page has been created on the project wiki; users can also email firstname.lastname@example.org.
The user interface design seen in the release is based on wireframes developed and tested over the last six months. Wireframes are used to outline the structure of a user interface, and combined with graphic design, comprise the final "[look and feel]" of an application.
The CollectionSpace system architecture is comprised of three layers: services, application, and user interface. The 0.1 release represents the first integration across the user interface and application layers of the system. Full integration among the user interface, application, and services layers is currently undergoing testing.
The core service developed for Release 0.1 is CollectionObject. Its primary purpose is to provide operational support for the creation and management of information related to an object, artifact, or work of art. This service offers a REST-based Application Programming Interface (API) to create, retrieve, update, and delete information about collection objects. In this API, there is also an operation to retrieve a list with summary information about all collection objects. In Release 0.1, authentication credentials are not requested by the service.
All planned CollectionSpace services are documented in the services repository. In addition, the services developers have outlined a schema extension modelthat will facilitate institution-specific and domain-specific customizations of the services offered by CollectionSpace.
The services team created a series of presentations for the all-hands meeting in June that give an excellent overview of their methodology. These presentations are available on the project wiki.
CollectionSpace uses the Fluid Infusion framework as the basis for its user interface (UI) architecture. Built for creating applications that are highly usable and accessible, Infusion provides a set of APIs for creating loosely coupled models and views using a declarative and event-driven style. Infusion is built on top of jQuery, and embraces unobtrusive, functional techniques that promote less code and greater flexibility.
Each page in CollectionSpace is organized as a hierarchy of components, managed through a controller. The user interface is bound to the application layer through a UI Specification (or UI Spec), which provides the basis for generating the component tree. In the 0.1 Release, only the central data entry component is active.
The user interface development team put together a presentation for the June all-hands meeting that includes a very clear walkthrough of the user interface architecture, and its integration with the application layer. This presentation is available on the project wiki.
The application layer serves as the conduit between the user interface and services layers, and as the chief engine for configuration. It takes the form of a number of domain-neutral "engines" which either encapsulate application-level services directly, or delegates them to the core services layer after appropriate translation. For example, the Forms and Grids engine provides datafeeds in two directions (via JSON) to manage the representation of forms, differences in forms, and the handling of their contents. The Event engine determines when and how application-level events (e.g. "this object was accessioned") turn into service-level events (e.g. "create photograph accession event"), and vice versa.