Cataloging Functional Analysis

Owned by Megan Forbes
Last updated: Feb 21, 2011 by Mal Ahern (Unlicensed)Version comment
4 min read

Overview

Our current CMS supports a cataloging schema roughly based on the VRACore 3.0. Some changes and additions were made to that schema based on the vagaries of the collection. The cataloging section is divided into a number of tabs, each of which handles a separate area of description:

Basic

Contains core cataloging information, including object ID number, extent, description, and classification.

Use: Frequent

Notes:

  • Artifact class and work type are fed from a two-level controlled list or vocabulary. In the CMS, selecting an artifact class then populates the work type dropdown with available choices. An artifact class may be selected on its own, but a work type cannot.
  • Artifact class and work type were not migrated from the old Access database; therefore, only about 60% of the records in the database currently have this designation. Old "categories" and "sub-categories" from the Access database live in the Attributes tab.
  • The three checkboxes at the bottom are admin-defined fields used to facilitate search. Only one is currently in common use.
  • The status field is used by collections staff as a workflow tool. A status of "publish" makes the catalog record available for public viewing.
  • In instances where the accession number was not unique, the extents for all records with the same number was put into the "Administrative remarks" field. These have been cleaned up for the most part, but some remain.

Screenshots:
Cataloging basic (top)
Cataloging basic (bottom)

Numbering

Contains any alternate numbers for an object.

Use: Often

Notes:

  • The field is repeatable. Because of a glitch in the search function, any artifact record with two or more former numbers listed in this section will appear twice in search results.

Screenshots:
Numbering

Custodial

Contains core condition and conservation information.

Use: Frequent

Notes:

  • The custodial tab was incompletely migrated from Access. The condition field contains a controlled list dropdown, but the values from the Access database were placed into the "Artifact needs" field (which is contains legitimate information) and the condition field defaulted to the first item in the dropdown.
  • The tab also contains the migrated values from the "Deed date" field. There are about 3000 records with this information in the "Custodial notes" field (which is currently used for legitimate information).

Screenshots:
Custodial

Attributes

Contains core cataloging information, including date, materials, and components.

Use: Frequent

Notes:

  • The attribute fields available for any given object depend on the Artifact class chosen. A core or default set of attributes may be used, or the admin may select a specific set (e.g. the attribute "gauge" would be available for a motion picture camera and the attribute "technique" for a photograph, but not vice-versa).
  • Attributes may be entered one at a time (via a dropdown and free text field) or using a form entry. Only in the one-at-a-time format are the fields repeatable.
  • Clicking "More options" reveals several fields that are not in use (Language, Text Encoding, Source Notes, Effective Date)
  • The category and sub-category attributes contain migrated classification data from the Access database. Best case scenario would be create a map between these fields and the Artifact class and Work type and fix on migration to CSpace. Worst case would be what we're doing now, which is updating Artifact class and Work type by hand and then deleting category and sub-category.
  • Additional attributes fields that were migrated from Access but which are no longer useful are Display date and Subject.
  • We would like to convert many of these fields into controlled lists when we migrate to CSpace.

Screenshots:
One-at-a-time entry
Form entry

Vocab

Contains the AAT.

Use: Never

Screenshots:
Vocab

Representations

Contains all digital images, audio, and documents related to catalog records.

Use: Frequent

Notes:

  • Representations are tied to catalog records, if the same image shows two different objects it must be uploaded twice.
  • A catalog record may have more than one representation attached, one must be designated as primary (the first file attached will be automatically assigned this designation)
  • Representations may be public or hidden - if a record is published but a representation is hidden, it does not appear to the public.
  • Representations may be added by browse or via the filespace (see media handling functional analysis).
  • Zoomable images and derivatives are generated on the fly (ImageMagick, Tilepic, etc.).
  • Data about images is automatically generated from the file: Dimensions, Format, and Original File Name.

Screenshots:
Representations

Clips

Contains portions of uploaded media with distinct cataloging information.

Use: Never

Screenshots:
Clips

Synonyms

Contains alternate names or terms for an object.

Use: Never

Screenshots:
Synonyms

History

Contains things that include a date stamp, including location, use, and components.

Use: Frequent

Notes:

  • Storage location is currently tracked via a free-text field in history. We would like to move to a hierarchical storage location authority when we migrate. There are many typos in the current field, as well as additional notes about what is being tracked (e.g. an object that has two components may have locations MST:2:3:4 (Camera) and MST:3:4:5 (Lens).)

Screenshots:
History

Docs

Contains related documents that do not fall under the rubric of "representations."

Use: Never

Screenshots:
Docs

Storage

Contains hierarchical storage location authority.

Use: Never

Notes:

  • This functionality was added after our initial migration to the CMS, and we never had the time to create a hierarchical authority for our storage location data. We would like to adopt this functionality when we move to CSpace.

Screenshots:
Storage

Registrar

Contains information about the acquisition or loan record (called a LOT record by the CMS) related to the object.

Use: Frequent

Notes:

  • This tab may only be seen by those with access to the full registrar tab (aka Registrar/Lots).
  • There is no verification that the lot number match the object id number, so mismatches are possible.
  • Many objects are missing this information.

Screenshots:
Registrar

Relationships

Contains all links to the Name authority (persons and organizations), Production authority, Collections, Place authority, and Publication authority.

Use: Frequent

Notes:

  • With a few exceptions, vocabulary terms are not accessible in stream in the cataloging records. They are accessed via the relationships tab. A relationship type is selected via a dropdown.
  • We would like to migrate data in this tab to distinct fields in CSpace, based on relationship type.
  • New terms may be added to vocabularies via this interface; all terms added this way are given a status of "quick added, needs attention" until they are vetted by a user with appropriate permissions. There is no visual cue to this status.

Screenshots:
Relationships - Entities
Relationships - Collections
Relationships - Productions

Log

Contains a history of all actions performed on a record.

Use: Frequent

Notes:

  • This is the one place on the User Interface that the DB object id number appears (under "Item").

Screenshots:
Log

Rights

Contains links to any use licenses defined by an institution.

Use: Never

Screenshots:
Rights

Comments

Contains date-stamped comments about an artifact.

Use: Never

Screenshots:
Comments

Summary

Contains a visual representation of how the catalog record will appear via the publicly accessible browser.

Use: Frequent

Screenshots:
Summary