Skip to end of metadata
Go to start of metadata

Definition

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

Requirements

  • Provide a level of description sufficient to identify an object or group of objects and its differences from other, similar objects;
  • Provide an historic archive relating to an object or cross-references to sources where information can be found;
  • Be held in a system that allows convenient access, e.g. using indexes or free-text retrieval.

Standards, Guidelines + Use Cases

Use Cases and Community Design Workshop Notes

Spectrum 3.1: Cataloging

CDWA: Recommended elements for a minimum catalog record

Wireframes

Wireframes - Object Cataloging Data Entry

Services

CollectionObject Service

ID Service

Fields

Cataloging Schema

User Story Summary

Object User Story Summary


Definition and requirements from:
Spectrum Version 3.1
Created and Maintained by CollectionsTrust
http://www.mda.org.uk/spectrum.htm

1 Comment

  1. In our work as implementers here at the SMK we found it necessary to make a revision check and comparison of the functional requirements, the schemas, the wireframes, and the current version 1.0 alpha. The purpose of this work was to establish any discrepancies and inconsistencies in the implementation of CollectionSpace programme regarding the eight core procedures of version 1.

    For Cataloguing we have the following comments:

    Regarding the schema:

    Object Collection Information appears in both the Object Entry schema and the Cataloguing schema. Is this not an inconsistency in comparison with the overall structure of CollectionSpace, to have the same fields appearing twice? Should it not be a separate element with relations to both core-procedures?

    Object Description Information – Dimensions. The main schema is satisfactory, but regarding the schema limited to release 1.0, as we see it, it does not make much sense to have the summery separated from the rest of the dimensions group (and non-repeatable).

    Reference Information. The relation between the Reference and the associated Catalogue number is missing.

    Regarding the wireframes:

    Object Identification Information. In the wireframe appears a Number of objects group with the sub-fields of sub-number and title. This group does not appear in the schema. Is it valid? And if so, how is the functionality meant to be?

    Object Identification Information – Responsible department should not be repeatable according to the schema.

    Object History and Association Information: Association type is missing in the wireframe and in version 1.0 alpha. In the current structure this field will only make sense if it is added to each association 'string'.

    Regarding CS version 1.0 alpha:

    As above: Object Identification Information – Responsible department should not be repeatable according to the schema.

    Object Identification Information – Title. The whole group should be repeatable.

    Object Description Information – Dimensions should, like in the wireframe, be group repeatable including summary. Similar issues regarding Object History and Association Information – Associated event, Ownership, and more. Generally there are too many discrepancies between the schema and release 1.0 alpha, especially regarding repeatability. It does not make much sense to separate the note form the association, i.e. should be 'group' repeatable (as in the wireframe) - long with the Association type.

    Reference Information should be row repeatable.

    Generally we find that the strong graphic design of the wireframes is lost in the present version 1.0 alpha.