CollectionObject Service Description and Assumptions

Schema

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

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

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.

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.

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..