Description

Assumptions

Key Concepts

Dependencies

Background Documentation

The content of this page should be considered "work in progress" between June 8, 2009 and June 12, 2009.

Description - CollectionObjects and CollectionObject Service

The goal of this page is to give an overview the CollectionObject Service and to describe key concepts associated with the service. For detailed descriptions of specific CollectionObject Service operations, see the Contract Description page.

The purpose of the CollectionObject Service is to manage records of information called CollectionObjects. In CollectionSpace, a "CollectionObject" is a record of information about a collection item -e.g. a single artifact, a box of shards, a specimen, etc. A museum or other repository using CollectionSpace to manage their collections can create and maintain a CollectionObject record for each item in their collection. Again, an item can be a single something or a container of items. In the case of a container, the museum does not necessarily need to create CollectionObject records for each item in the container -see "Lots, Sets, and Parts" under the "Key Concepts" section below for more details.

The diagram below shows how a typical museum's collection might map to a set of corresponding CollectionObjects. In this diagram, there are three collection items: two paintings, and a box with paintings in it. In this example, the museum decided to create CollectionObject records for the two paintings and the box. They did not however create CollectionObject records for the paintings inside the box. If they later decide it is necessary to create CollectionObject records for these paintings, the CollectionObject service will easily allow this.

Unknown macro: {multi-excerpt-include}

CollectionObjects can be made up of parts. They can also be considered part of another CollectionObject. Suppose in our previous example, the museum decided to create CollectionObject records for the three paintings inside the box. The CollectionObject representing the box would now be the "whole" and the CollectionObjects representing the three paintings would be "parts". See the diagram below showing CollectionObjects created for the box of paintings from our previous example.

Unknown macro: {multi-excerpt-include}

Key Concepts

This section describes key concepts related to the CollectionObject Service. These key concepts are critical to a complete understand of the service and related services.

Schema
Lots, Sets, and Parts
Grouping

Schema

CollectionSpace supports an extremely extensible data model for the "CollectionObject" record. A CollectionObject consists of three primary parts:

CollectionObject Core - information fundamental to managing collection items in general -information like object number, and object name.
CollectionObject Domain - information related to specific types or categories of collections - like Fine Arts Museums or Anthropology museums for example.
CollectionObject Custom - information custom to a specific museum.

Unknown macro: {multi-excerpt-include}

Each of these CollectionObject parts is described in more detail in the following three sections.

1. CollectionObject Core

The CollectionObject Core is a set of fields that are considered to be common to all types of collections regardless of domain. This set of Core fields are considered to be the minimum necessary to properly manage a CollectionObject within CollectionSpace.

Lots, Sets, and Parts

In the CollectionSpace system, CollectionObjects can participate in a containment hierarchy. In other words, a CollectionObject can be a part of something and it can also have subparts. For example, a CollectionObject can represent a chess set with each peice of the set also being represented by a CollectionObject.
See the diagram below.

Unknown macro: {multi-excerpt-include}

Using the chess set again as an example, it possible that a museum may create a CollectionObject for only the set and not the individual pieces. In this case there would exist a single CollectionObject record for the chess set. See the diagram below.

Unknown macro: {multi-excerpt-include}

Grouping

Current thinking is that it would be useful to have two general grouping models:

1. Primary Grouping Mechanism - we're thinking it would be useful to have a primary grouping capability for all collection objects that is hierarchical in nature. This primary hierarchical grouping is meant to reflect (or help express or portray) collection objects that are either parts of a whole, a whole consisting of parts, etc.
  A collection object could by default have zero or more children (sub-parts) and zero or one parent. To support the idea of a "lot", we could provide a collection object "container" resource/entity. This container could act as a parent for a set of objects whose parent is either unknown or not inherently meaningful -e.g., a cardboard box.
2. Ad Hoc - named/typed groupings of collection objects. This flexible grouping capability is meant to provide an mechanism for creating arbitrary groupings of collection objects -flat or hierarchical. The groups could be typed and contain metadata descriptive of the group meaning.

Grouping (cont)
Patrick Schmitz's original thinking on grouping: Collection objects may be grouped or not. Grouping CollectionObject is not same as collection or exhibition, but is an object that has sub-objects. Must be able to convert from a simple CollectionObject to a grouping object (long) after creation, since cannot always predict the level at which will work with something (e.g., "box of stuff" that later is more carefully described as items). Implies that all CollectionObject can have grouping capabilities, but not all do in practice. Probably want to configure whether or not a system allows for conversion, as some people will want to enforce a flatter model.
Tracking - Need to model collection objects that are being tracked, and possibly managed, but that are not accessioned. These may be from another museum, may be pending evaluation, etc. Implies classes of objects: accessioned (and deaccessioned), borrowed, pre-entry, etc. This is some controlled vocabulary that has some explanation for each.
Deaccessioned - Issue: Need to model objects that have been deaccessioned, or that are otherwise in the process of object exit. Implies state (cf. "Classes" above), and state may be closely tied to events that occur for the object..

Schema
Lots, Sets, and Parts
Grouping

Assumptions

Unknown macro: {multi-excerpt} A brief summary of assumptions goes here

* When is a CollectionObject a CollectionObject?

At the service layer, any object that could potentially become part of a repository's (museum, life science collection, etc) collection is modelled as a CollectionObject. The current "state" of the CollectionObject dictates whether or not it has, for example, been aquired, accessioned, deaccessioned, etc.

Dependencies

CollectionObject entities can be related to many other entities in the system; e.g. Loans, Events, Movements, Resources, etc. The semantics of these different relationships will affect how dependent/independent the CollectionObject service is on the other entities and their corresponding services.

Related Services

Collection Service Home
Loan In Service Home
Intake Service Home
Movement Service Home

Related Entities

The CollectionObject service has a bidirectional dependency with the CollectionObject entity.

Background Documentation

/wiki/spaces/collectionspace/pages/666276170
SPECTRUM - contains procedures for documenting objects and the processes they undergo, as well as identifying and describing the information which needs to be recorded to support the procedures
Getty Objects

Browser not supported