CollectionSpace Show-and-Tell presentation for BNHM-IST Partnership April 3, 2009

What is CollectionSpace? 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. CollectionSpace is supported by The Andrew W. Mellon Foundation

Community Source The Community Source Model is a hybrid model that blends elements of directed development, in the classic sense of an organization employing staff and resources to work on a project, and the openness of traditional open-source projects like Apache. The resulting software is available under an Open Source Initiative (OSI) approved license. The code can be examined, changed, redistributed, sold, or incorporated into other products without fee. Anyone can make changes, and subject to quality review, those changes can be incorporated back into an open-source application for the benefit of all. The distinguishing feature of the Community Source Model is that many of the investments of developers' time, design, and project governance come from institutional contributions … rather than from individuals. These contributions may be tendered as the first phase of a project, and then additional work may be contributed on an ongoing, voluntary basis by those institutions with a continuing interest in the project. The project often establishes a software framework and baseline functionality, and then the community develops additional features as needed over time. Wheeler, Bradley. "Open Source 2010: Reflections on 2007 | EDUCAUSE CONNECT."

Community Design In March and May of 2008, the project team held two Community Design Workshops that focused on the functional, technical, and accessibility needs of the user community with regard to the development of a modular, service-oriented solution to manage and publish collections information. Key stakeholders from the international museum field as well as representatives from special collections libraries and archival institutions took part in these coordinated sessions. Participants shared their experiences working with collections management systems; interpreted terms, workflows, roles and responsibilities; and described in detail their current working environments, from technical, functional, and usability perspectives. The project remains in close contact with workshop attendees, who continue to participate through user testing and the contribution of use cases. A third design workshop will be held at Berkeley in the fall.

Where are we now? Our first release is due in April, and will serve as the integration test among the service, application, and user interface layers. By June, the team will have a working demonstration version of the software, focusing on basic collections management functionality such as Acquisition, Cataloging, and Vocabulary management. By the design workshop in September, additional functionality such as Location and movement control and Media handling will be added. For December, all core collections management functionality – Object Entry, Acquisition, Location and movement control, Cataloging, Object exit, Loans in, Loans out, and Retrospective documentation - will be in place.

Development through May 2010 Collections Management Object Entry Acquisition Inventory Control Location and Movement Control Cataloging Object Exit Structure Object Management Retrospective Documentation Batch Processing Conservation Object Condition Checking and Technical Assessment Conservation and Collections Care Customization + Personalization End User Personalization System Administrator Customization System Technician Customization Dashboard Data Management Collections Exposure Data Import and Export Search Metadata Configuration Reporting Loans and Dispatch Loans In Loans Out Transport Policy / Legal / Insurance Rights Risk Insurance and Indemnity Loss and Damage Deaccession and Disposal Audit Resource Management Media Handling Time-based Media Cataloging Non-collection Materials Management Use of Collections Bibliographic Data Management System Administration Audit Trail Notifications Workflow Management Help Roles and Permissions Security Documentation Vocabulary + Authority Control Name Place Concept Subject

Colleges + Universities Libraries + Archives Vendors Software Developers MUSEUMS Professional Organizations Funders Sustainability

Why is CollectionSpace so important to UC Berkeley? Driving goals and major requirements –Flexibility and customizability - power to the museum; different kinds of museums –Community design and sustainability –Deployable to single server or data center –Services/SOA model - aligned with campus projects and trends, interoperability –User-centered design - intuitive, helpful systems Given campus context, a good fit and excellent opportunity

UCB activities around CollectionSpace General approach (CCMSR) –Coordinate around customers and communities –Keep the campus-wide needs in the foreground (CTC/IT Bank; CIO & VCR) –Track many moving targets -- flexibility required –Recognize timeline -- some museums involved earlier; others later

UCB activities around CollectionSpace Add use case and requirements (ensure it works for UCB!) Test new versions as they come out Evaluate claims it can do what we need it to do –Customize collection object to natural history domain –Interoperability with e.g., CalPhotos

UCB activities around CollectionSpace Plan for migrations and deployments at specific museums, how and when to migrate to recommended framework in an agreeable manner Perform local design and development work to track gaps and address them –Wrap functionality from current systems –Do local work that is coordinated with CSpace team –Find other workarounds Two deployments of some kind by June 2010

CollectionSpace and Sustainability For CollectionSpace itself For UCB collection management systems Budget planning and hard decisions needed Our campus goals –Drive down costs of managing individual collections –Allow more collections to be managed in systems that are stable and professionally managed –Build a platform that facilitates innovations in research, teaching, and outreach

CollectionSpace Architecture and Deployment Model Patrick Schmitz U.C. Berkeley IST/Data Services Co-Technical Lead, CollectionSpace

Talk overview, goals Describe our stack and project approach –Project teams, division of labor –What SOA means in our context Describe our schema model, its implications Explain customization and adaptation model Review project skills inventory, opportunities

Project overview 3 teams, 3 pieces –UCB: Services and deployment stack –Cambridge (UK): App/Customization layer –U. Toronto/Fluid: UI tools, UX/UI design Community design approach Development roadmap: –Get stack working top to bottom (big step) –Knock off services in small steps (agile)

Technology stack U. Toronto/Fluid Cambridge/CARET Berkeley/IST-DS Nuxeo (Apache, etc.)

Schema Extension Model Schema model for a customized service deployment

Service Contracts and Schema Contracts, SPIs, APIs –Note: SOA != SOAP. We like ROA/REST. –Main services expose entities (most of the work) Also a fair number of utilities Some task-level services –Most of contract is in the schema (XSD) Entity schemas roughly correspond to data model –But: not fixed for application – custom per museum –Follow something like an implements interface model

Configuration and Customization Configuration of existing services, schemas –Which services are of interest for this deployment –Which fields in schemas to use, how to label them –Validation rules, patterns, for field values –Roles, access policies, for pages, fields, etc. –Vocabularies, name authorities, etc. Customization of schemas, application –Pageflow, graphics, look and feel of application –Local schema extensions –Application extensions to integrate other services, etc.

Services stack C-Space Services Nuxeo Platform Services

Skills inventory for C-Space Customization and Extension –XML/XSD, for schema and for app. Definition –Javascript, jQuery, Fluid/Infusion for app code –HTML/CSS and Infusion templates for presentation Service definition and development –Domain expertise, experience –XML/XSD, Java, eventing/messaging, workflow, etc. Core framework coding –Java, SOA, Nuxeo (JBoss, Drools, JMS,.), ROA/REST –PM/Dev tools: Maven, Wiki/Jira, SVN, etc.

Thanks! Questions and discussion…