Planning a New Collection
Before creating a new collection, it is best to spend some time planning. Here are some questions to consider. Think about them and plan before creating your collection:
What sort of content do you have? What sort of metadata? Who will use the collection and how? How will the collection grow? How will images and media be contributed? Are they being scanned? Imported from a digital camera? Created digitally in Photoshop? Will they come in batches or one or two items at a time? Is there multimedia? How large will the images or multimedia be? How will the metadata be created? Will it come from text files, comma-delimited, tab-delimited, XML, or perhaps Excel-formatted files? Will metadata be entered by hand via Inscribe or will it come from a read-only database? Determine if the data is technical in nature, process-oriented, minimal, or complex. How is it created? What are the processes that it undergoes (is there a validation or data integrity process)? Do you use controlled vocabularies or external hierarchies? What types of fields do you use (numeric, text, date)?
The following sections will help you to think about these issues and plan your collection.
Designing a Metadata Structure
There are many metadata standards for cataloging visual and non-visual media, including the VRA Core, MARC, Dublin Core, CDWA, Object ID, CIMI, and EAD. Each of these standards has benefits and drawbacks; some are more suited for describing books, others for slides, others for complex objects or multimedia, etc.
Think about how the data is organized and what you want to do with it. Your specific needs will inform your choice of cataloging standards.
Below is a list of resources where you can learn more about data standards:
Introduction to Metadata - Metadata Standards Crosswalk http://www.getty.edu/research/conducting_research/standards/intrometadata/metadata_element_sets.html
Categories for the Description of Works of Art (CDWA) http://www.getty.edu/research/conducting_research/standards/cdwa/
The CIMI Profile http://www.loc.gov/z3950/agency/profiles/cimi2.html http://www.unt.edu/wmoen/projects/Z39.50/cimi/Profile/appendixc.htm
Dublin Core Metadata Element Set Version 1.1 http://dublincore.org/documents/1999/07/02/dces/
MARC 21 http://www.loc.gov/marc/
Object ID Project http://www.object-id.com/
VRA Core Categories, Version 3.0 http://www.vraweb.org/vracore3.htm
Components of a Catalog Template
A metadata schema or Catalog Template represents the way that data is organized within a collection. A Catalog Template consists of fields or groups of fields that represent one complete record. A Catalog Template represents the most complex data record that you plan to catalog.
More specifically, the components of a Catalog Template are:
Fields: Fields are the simplest units that can be cataloged, such as names, dates, or simply, text.
Records or Field Groups: Records are groups of fields and represent how data is organized either for display or logically grouped for cataloging.
Object Records: An object record represents a complete data record in Insight.
Fields
Fields are the lowest-level building blocks of a data structure. Each field represents one unique section of data. Fields can be Numeric, Short Text, Long Text, or IDs. Multiple Fields can be combined to create Field Groups and Records.
Field Validation
Depending on a field's use or content, it may be important to restrict input of certain types of information. Field Validation Rules enable the Insight administrator to require users to input valid data into a given field within Inscribe.
Insight Studio enables an administrator to add different types of validation rules, including checks for required fields, numeric and numeric range validation, verification against an external hierarchy such as the Getty's Art and Architecture Thesaurus, and date validation.
Special Validation – Controlling Access by User Rights
For more complex data input scenarios, administrators can control not only the validation of the content that is added via Inscribe, but also whether a given user can see, add, delete, or change data. This granularity of rights is often useful in managing controlled vocabularies, by allowing an administrator to only enable specific users to add new entries.
NOTE:To enable this feature, you will need to use the Administrator Tools.
Field Groups and Record Types
Field Groups and Record Types represent the substructures of a given record, with fields as the base components. Field Groups and Record Types enable you to organize common content for display and data entry. Record Types represent groupings of fields within your metadata schema. Field Groups represent groups of fields organized for display. In many cases, both Record Types and Field Groups contain the same fields; when building data models within Insight Studio, for example, creating a Record Type will create a corresponding Field Group. Some topics to consider:
What are the logical pieces of your metadata model? Think about how you organize your records. Are fields grouped? Do they repeat? What's special about them? Does a set of fields pertain to a creator? What do they do? How should they work?
Independent Records (an authority record)
Independent Records should be used when data fields are related more to each other than the main (object) record. For example, a single creator record may be created to describe an individual artist (eg. Pablo Picasso, 1881-1973), but it will be linked to multiple object records representing works by Picasso. The independent record enables catalogers to access and manage this information separately from the object record (accessible from the File | Open Record menu option in Inscribe).
Figure 1: Independent Record Diagram
Work 1 Les Demoiselles d'AvignonWork 2: Blue BoyCreator Name: Pablo Picasso
Creator Dates: 1881-1973
In the example above, both Work Records (Work 1 and Work 2) link to the same creator information (Creator 1). If the Creator Record is updated, both records will share the updated data.
Dependent Records
Dependent Records duplicate data and are merged into the parent record (in many cases, this is the base record). A metadata architect might use dependent records for something like a Work Title where a unique title needs to be created for each object instead of linking each record to a unique title record. Dependent Records can also be used to allow a field to repeat, by placing only that field within the record. Dependent records are not displayed in the form selection list in the File menu of Inscribe.
Figure 2: Dependent Record Diagram Main Work Record*Work Title:* Les Demoiselles d'Avignon
Work Title Type: Primary*Work Title:* Young ladies of Avignon
Work Title Type: Title Translation
Controlled Vocabularies
Controlled vocabularies are a special type of independent record. Like independent records, they maintain unique values, but can only contain one field. Like dependent records, within Inscribe, they do not show up in the File | Open Record menu.
Object Records
An Object Record represents one complete record in the data schema. If you were cataloging slides, it would describe the data for one slide. Object records are paired with images, or are associated to create Multi-Page Documents.
Search & Data Display Properties
By default, all fields in Insight are searchable and displayed within the data. However, some fields may not be useful for searching, and some data fields should be visible only to the catalogers. Sometimes data fields should be displayed, but not searched, or searched but not displayed.
Some examples might include:
Fields that shouldn't be seen or searched (a cataloging Notes field)
Fields that should be seen but not searched (a type qualifier such as a measurement unit)
Fields that should be searched but not seen (the numeric versions of dates or OCR text)
When creating your Catalog Template, you have the ability to specify whether a field is searchable or not.
NOTE:You can always change this at a later date, using the Administrator Tools.
Considering Common Search Fields (Quick-Search Fields)
Quick-Search fields are offered as an easy way to search a collection. They are intended to provide guidance to users about useful ways to search a collection for specific records (i.e. the who, what, where, why, and how of your collection). Some topics to consider:
How do you expect people to search for images or data within your collection? What are the common fields that people will want to search by? Users may not want to search on repository name—especially if the repository is always the name of your institution.