This document identifies the broad range of capabilities that a fully functioning collection management system might be expected to perform. The CollectionSpace project team is evaluating this list and talking with the broader community to identify what capabilities can be developed and by when. The basic functional capabilities are identified first. System and technological requirements are identified in the second part of the document. It is important to note that this is a living document! More details and ideas are being added all the time, and certainly more detail about each of these capabilities is needed. The project team looks forward to working with the community on this effort.
Object Entry: The management and documentation of the receipt of objects and associated information which are not currently part of the collections. Any object which does not currently have an object number assigned by the receiving organization must be dealt with within this procedure.
Acquisition: The management and documentation of the addition of objects and associated information to the collections of the organization and their possible accession to the permanent collection.
Inventory Control: The maintenance of up-to-date information accounting for and locating all objects for which the organization has a legal responsibility. This may include objects on loan, unaccessioned or previously undocumented items, temporarily deposited objects and support collections.
Location + Movement Control: The management and documentation of information concerning the current and past locations of all objects or groups of objects in the organization's care to ensure the organization can locate any object at any time. A location is a specific place where an object or group of objects is stored or displayed.
Cataloging: The compilation and maintenance of key information, formally identifying and describing objects. It may include information concerning the provenance of objects and also collections management documentation e.g. details of acquisition, conservation, exhibition and loan history, and location history. It need not bring together in one location everything known about an object, but should provide cross-references to any other relevant information source known to the organization.
Structured object management: For at least some applications, it must be possible to relate objects in a structured manner, and to add cataloging annotations to each/any level of the structure. The structure must be definable/configurable per application instance, if not by the user.
Retrospective Documentation: The improvement of the standard of information about objects and collections to meet SPECTRUM Minimum Standards (or other) by the documentation of new information for existing objects and collections.
Batch Cataloging: The system should allow the user to perform action on defined groups of items, for the purpose of systemic error correction, updating legacy data, etc.
Time-Based Cataloging Tools: The system should allow the user to perform time-based cataloging, describing sections of time-based media in the same way one would describe a part of a whole traditional artifact.
Collections Publishing Module: The system should allow the user to publish collections information contained in the system on the web, either for public or password-protected use.
Community Cataloging and Curating: The collections publishing module should include the following features: (a) a user registration and account management module; (b) tagging (keyword-based); (c) ability to create custom collections/playlists; (d) ability to fully annotate at the item or list level; (e) assignment of rights for others - individuals, defined groups, or all registered users - to add to, alter, or view the contents of user-created lists/collections.
Object Condition Checking + Technical Assessment: The management and documentation of information about the make-up and condition of an object, and recommendations for its use, treatment and surrounding environment.
Conservation + Collections Care: The management and documentation of information about interventive and preventive conservation activities.
Conservation Management: The system should allow the user to record the need for conservation work; the process of technical examinations including reference to archival material and paper files; any remedial treatment; the history of the conditions and treatments of an object; notification about treatment call-backs; and conservation information via the objects' unique local number.
Import / Export Functions: The software should allow the user to import and export files and data using user-defined or standard formats (CDWALite, SPECTRUM, MARC, etc.).
Search: The software should allow the user to search across all fields, sort search results, save searches, and provide for basic and advanced (faceted) searching.
Metadata Configuration: The system should include metadata configuration tools that will the user to assign metadata standards to each field in the database. The tool will allow for the incorporation of emerging and future standards.
Reporting: The system should include a robust reporting module that allows users to: create pre-defined and user-defined reports, schedule automatic reports, save custom reports, generate forms and labels, export report data, recall past searches, etc.
Machine-Readable Labeling: The system should support the creation, management, and integration of machine-readable labeling systems, including but not limited to bar codes and radio-frequency identification (RFID).
Exhibition Planning: The management and documentation of temporary exhibitions and permanent displays, including the processes of developing, coordinating, and implementing an exhibition and display program.
Loans + Dispatch
Incoming Loans: The management and documentation of the borrowing of objects for which the organization is responsible for a specific period of time and for a specified purpose, normally exhibition/display, but including research, conservation, education or photography/publication.
Outgoing Loans: The management and documentation of the loan of objects to other organizations or individuals for a specific period of time and for a specific purpose, normally exhibition/display, but including research, conservation, photography and education.
Transport: The management and documentation of the transport of objects for which the organization is partially or fully responsible.
Rights Management: The management and documentation of the rights associated with the objects and information for which the organization is responsible for, in order to benefit the organization and to respect the rights of others.
Risk Management: The management and documentation of information relating to potential threats to an organization's collections and the objects for which it is temporarily responsible. It includes the provision of information enabling preventative measures to be taken as well as documentation supporting disaster planning.
Insurance and Indemnity Management: The management and documentation of the insurance needs of objects both in an organization's permanent collection and those for which it is temporarily responsible.
Loss + Damage: The management and documentation of an efficient response to the discover of, or damage to object)s) whilst in the care of the organization.
Deaccession + Disposal: The management of disposal (the transfer, or destruction of objects) and of deaccession (the formal sanctioning and documenting of the disposal).
Audit: The examination of objects or object information, in order to verify their location, authenticity, accuracy, and relationships.
Media Handling: The management and documentation of digital media files. The system should allow the user to upload/download, view, and catalog media objects.
Non-Collection Materials Management: The management and documentation of information related to artifacts in the collection. The system should allow the user to track the information's location, content, format, and relationship to an artifact or group of artifacts.
Use of Collections: The management and documentation of all uses of and services based on collections and objects in the organization. These include exhibition and display, education handling collections and the operation of objects, research and enquiries, reproduction and the commercial use of objects and associated documentary archives. User include staff (and volunteers) or the public, whether in person, by letter, telephone or any other means of communication.
Bibliographic Data Management: The system should allow the user to record bibliographic information related to objects and authority items, based upon the Functional Requirement for Bibliographic Records (FRBR) (http://www.loc.gov/cds/FRBR.html).
Customization & Personalization
Front-end user: The system should allow the user a degree of control over his/her environment, including placement of modules and menus, start-up screens, and visual elements.
System administrator: The system will provide administrators with a degree of control over such elements as logins, roles, and permissions; adding items to term lists not controlled by the authorities and vocabularies module; and changing field names.
System technician: The system will provide technicians, developers, or IT staff with the ability to make structural changes to the software.
Audit Trail:The system should create audit trails for activities in the system, including but not limited to record creation and deletion, all changes in a record, user ID login/logout activity, and queries performed.
Dashboard:The system should allow users to create a personalized workspace, or "dashboard," that provides immediate access to notifications, workflow tasks, scheduled reports, etc.
Document Generation: The system should allow users to create formatted documents (e.g. artifact receipts, deeds of gift, loan documentation) populated with collections data.
Documentation: The system should be documented for front-end users and back-end administrators/developers.
Help: The system should provide a complete set of help functions, including tutorials, context-specific help), and both system-supplied and user-defined help.
Notifications: The system should allow users to create notifications (manually or automatically) based on actions taken in the system. Notifications may be sent through the system itself (e.g. by appearing in another user's dashboard), by email, SMS text, or other means.
Permissions: The system should allow an administrator to define access to the system at the field level. These permissions should combine to form a function level (e.g. curator, registrar, etc.).
Security: The system should provide security features such as password protection, and data security features (permission-based record deletion, etc.).
Workflow Management: The system should allow users to create a managed sequence of operations based on task, role, etc.
Vocabulary + Authority Control
Authority Control: The documentation and management of information about persons, places, things, and other concepts related to the collection being described. The system should allow users to capture authority information separate from item-level records, and then link the information to appropriate records.
Vocabulary Control: The documentation and management of controlled lists of terms used to describe a collection. The system should allow the use of both standard and user-defined vocabularies.
System and Technological Capabilities
Under development and in no particular order
The following system and technological capabilities include both broad characteristics that the system must have as well as some specific technological and design requirements.
Design for museums, small and large
The project team has identified a range of institution types that need to be able to use CollectionSpace. At one end are small museums who might want a) the ability to install CollectionSpace as a "turnkey" application on a relatively small server (in-house or hosted) or b) outsource the maintenance of their collection management system to another institution or provider. At the other end are larger institutions housing multiple collections and having professional IT staff and a need to integrate the collection management system with other systems (for identity management, for instance). One code base for CollectionSpace should be able to be deployed or installed for these different kinds of institutions.
User Interface design standards
CollectionSpace will be designed according to user-centered design principles, both for the primary museum-based audience (the "back end") as well as any general public or collections publishing interfaces (the "front end"). A set of personas and scenarios representing a wide range of users will be developed. This process will be informed by the Fluid Project's UX Toolkit, in addition to direct participation from members of the Fluid team in Toronto and Berkeley. Fluid design patterns and components will be incorporated into the software's back-end interface. In addition, Fluid frameworks will be utilized to enable institutions to customize interface components based on the roles and responsibilities of specific users or user groups, and to pass on, if they choose, some customization options to the users themselves.
Service Oriented Architecture
The overall architecture for CollectionSpace is broadly based on Service Oriented Architecture principles for design and development. [Characterize the benefits briefly.] [Describe our agile hybrid approach to SOA analysis, design and development.]
A key requirement of CollectionSpace is that it support interoperability with other systems and services. This requirement goes hand in hand with the Service Oriented Architecture direction outline above but is driven by a number of specific needs identified by the community. The interoperability required can happen at different levels: at the data level (e.g., where CollectionSpace needs to share data with other data providers in a more or less programmatic way), at the system-to-system level (e.g., where CollectionSpace needs to be able to be integrated with another system used by the institution such as an identify management system or an archives management system), and even within the CollectionSpace system itself.
The lines between these kinds of interoperability can quickly blur! However, a set of techniques and technologies will be employed that both meet the particular interoperability requirement identified and that provide the most flexible and sustainable platform for reuse. In particular, Web Services and Plug-in Application Programming Interfaces (APIs) will provide interoperability to data, functionality, and services. Web Services and APIs will also make it easier for a community of developers and institutions to develop functionality that meets their particular needs and that can be provided back to the CollectionSpace community.
The following set of system requirements will benefit from an emphasis on interoperability:
Digital Asset Management: CollectionSpace should provide a built-in system for storing uploaded media. A file storage service would allow developers to easily integrate alternative storage options, such as the Fedora digital object repository.
Identity Management: CollectionSpace should have built-in user authentication and authorization functions. However, some institutions will want to use credentials from another identity management system (e.g., LDAP).
Geospatial Information Processing and Visualization: CollectionSpace should use services such as the Google Maps API for geospatial operations. As other visualization capabilities become available throughout the internet, CollectionSpace should be able to take advantage of them.
Query Service: Service exposing all basic and advanced search interface options as a web service.
Media Retrieval Service: Service providing access to all versions of a given media item. This service would allow external applications to retrieve and display media directly.
Data Submission Service: Service accepting submission of object and authority data and upload of media will allow external applications to add data to the system.
Interoperability with other systems (e.g., Archives and Library Systems; Conservation Management and Documentation; Exhibition Planning): In the second CollectionSpace community design workshop, several community members identified interoperability with other systems as a desired feature and a significant opportunity for CollectionSpace.
CollectionSpace should have some significant capacity for customization to meet the needs of a particular institution. This capability is broader than allowing for different graphical elements. For instance, the process of accessioning can vary significantly from institution to institution. CollectionSpace should allow for from local customization. There will be limits in what can be done and will depend heavily on priorities. Ideally, we will identify the degree and kind of customization needed or desired for each functional area (above), and that should be driven by process analysis (e.g., discussions with museum experts).
Other system and technology requirements
Internationalization and localization
Standards support and metadata management
Metadata ingestion and export tools