Skip to end of metadata
Go to start of metadata

The Services Team Home

The CollectionSpace Services Team is from the IST-Data Services group of UC Berkeley. The team is driving the SOA analysis, modeling and development for the CollectionSpace project. Patrick Schmitz is the Services lead

SOA Concepts and Background

Service Description Repository

For descriptions of our services, visit the Service Description Repository page.

Service Schema Model

The service contracts are built around the XML schemas that describe the data we are storing and manipulating. A basic premise is that we can not define a one-size-fits-all schema for all the museums, where each service contract is the union of all requirements. We discarded this notion very early on, and instead assume a model in which the service defines a core set of information that is common to many museums, and that represents the core semantics needed to use the entity in a CMS context. Each deployment will then extend this schema to include additional information that the service does not understand or manupilate, but that it can store and expose.

These extensions could be one big bag, but we will be encouraging the schema developers to consider which of their extensions are common across many institutions in their domain, and which are specific only to their particular deployment or collection. E.g., for a museum of zoology, many extensions will relate to the management of specimens, and the cataloging of life science information, while a few concepts may be more specific to how they manage their specimen collections. In this way, we hope to foster the emergence of communities around different domains (e.g., life sciences, art history, anthropology and archeology, architecture, etc.), and to facilitate the sharing and re-use of extension schemas and the association application UI templates.

Over time, we expect that the domain-specific schemas will standardize enough that some domain-specific services can be defined to serve the respective communities. For example, we would begin with generic services (and schemas) for CollectionObject, ConditionReport, Location, etc. Over time, communities will agree on schemas that enable the definition of LifeSciCollectionObject, AnthroCollectionObject, ArtHistConditionReport, PaleoLocation, etc. We could not hope to define these various domain-specific services a priori, but they can emerge over time, through discussion and sharing within the respective communities of interest, in a kind of organic process.

This figure captures the idea of multiple schemas contributing to the total service schema for a given deployment.

Full Size

Coincidentally, this idea is also somewhat broadly similar in concept to the Fedora Digital Object Model.

Services Design and Development

Services Layer cake


One of the core deployment requirements of CollectionSpace was that it should support multi-tenancy (see Tech Thinking for See Design notes for multi-tenancy in CollectionSpace for more details.

CollectionSpace Ecosystem - Big Picture

CollectionSpace Ecosystem