|
II. WHAT ARE YOU CATALOGING?
To catalog a work is to describe what it is, who made
it, where it was made, how it was made, the materials
of which it was made, and what it is about. Before beginning
the task of descriptive cataloging, a cataloger must
ask a basic but potentially complex question: What am
I cataloging? This question refers to the relationship
between a work and its parts, and between a work and
the images that represent it. To make a coherent record,
the cataloger must clearly understand the parameters
of the work in question. Is the catalog record about
a single painted canvas or an altarpiece made up of
many panels? Is it about a monolithic sculpture or an
installation of various works? Is it about a single
built structure or a building composed of various parts
that were constructed at significantly different times?
Works may be complex, consisting of multiple parts,
or they may be created in series. Are you cataloging
a part of a work that belongs to a larger whole? For
example, a museum may own only one panel of a triptych
or one page from a manuscript. Perhaps you are cataloging
images and the works represented in them. For example,
imagine a photograph intended to document an original
two-dimensional painting (that is, a photograph that
contains the entire work and nothing more). Such images
may take form in any number of media, be it a slide,
a digital image, or, in this case, a photograph. Now
imagine that the photographer had stepped back fifteen
feet, expanded the perspective, and instead of a photograph
of a painting, it becomes a photograph of a painting
on a wall of a building with a sculpture in the foreground.
The photograph is no longer a simple image of a single
work; the photograph now represents a complex layer
of information open to subjective interpretation. The
answer to the question "What am I cataloging?" sets
in motion the rest of the choices made in the cataloging
process and helps to distinguish data about the work
from data about the image.
The answer to the question "What am I cataloging?"
sets in motion the rest of the choices made in the cataloging
process and helps to distinguish data about the work
from data about the image.
III. WORKS AND IMAGES
CCO recommends making a clear distinction between the
work and the image. It is important to make this distinction
at the outset because many of the same types of data
elements used to document the work are also used to
document the image. If the distinction is not clearly
drawn, the results of a search can produce inaccuracies
and confusion for the end user.
What Is a Work?
In CCO, a work is a distinct intellectual or artistic
creation limited primarily to objects and structures
made by humans, including built works, visual art works,
and cultural artifacts.
What Is an Image?
An image is a visual representation of a work. It
typically exists in photomechanical, photographic, or
digital format. In a typical visual resources collection,
an image is a slide, photograph, or digital file. Images
do not include three-dimensional physical models, drawings,
paintings, or sculptures, which are works in their own
right.
Relationships between Work and
Image Records
In a relational database structure, a record for the
image would be linked to a record for the work and therefore
would be linked to information about the work. The work
may be linked to multiple images (for example, when
there is more than one image of the work), and the image
may be linked to multiple works (for example, when more
than one work appears in the same image). The relational
database model enables the cataloger to record work
and image information in the appropriate places and
clearly make the distinction between the work and the
image.
IV. MINIMAL DESCRIPTIONS
How much information should a catalog record contain?
The focus of cataloging should be twofold: promoting
good access to the works and images coupled with clear,
accurate descriptions that users will understand. This
can be achieved with either a full cataloging record
or a minimal cataloging record, so long as the cataloger
follows standards and the descriptive cataloging is
consistent from one record to another.
Cataloging Depth: Specificity
and Exhaustivity
Cataloging depth is often discussed in terms of specificity
and exhaustivity, generally referring to the precision
and quantity of terms applied to a particular element
in the record. Specificity refers to the degree of precision
or granularity used in description. Exhaustivity refers
to the degree of depth and breadth that the cataloger
uses in description, expressed by using a large number
of terms or a more detailed description.
CCO recommends institutions take into account the following
parameters when making decisions about minimal cataloging:
• Size and Requirements of the Collection
• Focus of the Collection
• Expertise of the Catalogers and Availability
of
• Information Expertise of the Users
• Technical Capabilities
Although the practice of employing both specificity
and exhaustivity in creating a record is encouraged,
consistency in the way the data is expressed is more
important than the amount of data in the record. CCO
recommends using standard descriptive elements as outlined
in the VRA Core Categories or the CDWA core categories
as a basis for constructing a minimal record. How these
core metadata elements are used in building a cataloging
database, and how the information is parsed for display
in public access interfaces or printed labels, may require
different local solutions than those presented in CCO.
CCO discusses a subset of elements from the VRA Core
Categories, which in turn are a subset of the CDWA metadata
elements. The core elements in CCO comprise the most
important descriptive information necessary to make
a record for a work and an image. CCO recommends that
a minimal record should include most if not all core
metadata elements; a minimal record should contain data
values for all of the required core elements whenever
possible.
Elements for a Work Record
Chapters 1 through 8 in Part 2 list the recommended
elements, and advise how to fill in values for those
elements and what to do when minimal information for
a given required core element is not known.
Elements for an Image Record
Chapter 9 discusses required and recommended descriptive
elements for the view represented in images: View Description,
View Type, View Subject, and View Date.
Elements for a Group, Collection,
or Series Record
The record for a group, collection, or series may
have the same fields as a Work or Image Record, but
a group, collection, or series record should be flagged
(like Work and Image Records) with Record Type so that
it is clear to the user that this is an aggregate record,
not a record for a single work. Records for individual
works or images can be hierarchically linked as part
of the group, collection, or series record.
V. RECORD TYPE
Record Type indicates the level of cataloging, based
on the physical form or intellectual content of the
material. As a preliminary step in cataloging the work,
determine the cataloging level that is appropriate to
both the work and the goals of the cataloging institution.
CCO recommends using a Record Type element, although
this is administrative rather than descriptive metadata
and therefore outside of the scope of this manual.
VI. RELATED WORKS
In the context of CCO, Related Works are those having
an important conceptual relationship with each other;
records for Related Works are linked to each other in
the database. CCO recommends that catalogers distinguish
between intrinsic and extrinsic relationships. An intrinsic
relationship is essential and must be recorded to enable
effective searches. An extrinsic relationship is not
essential; although recording it may be informative,
the cataloger need not identify the extrinsic relationship
during the cataloging process.
Intrinsic Relationships
An intrinsic relationship is a direct relationship
between two works. Intrinsic relationships exist in
the following circumstances:
Whole-Part Relationships between Works
In this type of relationship (also known as larger
entity-component or parent-child relationships), a part
cannot be fully understood without its whole; the part
inherits much of its information from the whole. Architectural
complexes, manuscripts, and triptychs are examples of
works requiring whole-part relationships.
Group and Collection Relationships
When separate records are made for a group of works
or a collection and its parts, the relationships between
a group and its parts are intrinsic relationships.
Series Relationships
A relationship between an individual work and its
series is intrinsic, because the work is best understood
in the context of the series. Works done in series may
require separate records for each part (the works) and
for the whole (the series). Works done in series may
include prints, photographs, paintings, sculptures,
or installation art.
Components and Architectural Works
If multiple parts of an architectural work or any
work with components are cataloged separately, the relationship
between the whole and the parts is intrinsic.
Extrinsic Relationships
An extrinsic relationship is defined as one in which
two or more works have a relationship that is informative,
but not essential. The described work and the referenced
work can stand independently. Such a relationship can
be equated with a see also reference in a bibliographic
record.
Extrinsic relationships are generally temporal, conceptual,
or spatial. Temporal relationships often include preparatory
works such as models, studies, or plans. Conceptual
relationships may have a temporal element, for example,
with works done after rather than before the original
work, such as works that clearly reference other works
while not necessarily being copies of them. An extrinsic
relationship can also be the result of a spatial association,
such as two or more works intended to be seen together.
Displaying Relationships between
Works
Relationships should be displayed in a way that is
clear to the end user. Two common methods for displaying
relationships are:
Hierarchical Display
A hierarchical display, using indentation, may be used
to display whole-part relationships.
Example of a hierarchical display for a Japanese tea
set:
Old Kutani Porcelain Tea Set
..... Jar with Strainer
..... Hot Water Coolant Boat
..... Tea Caddy
..... Tea Pot and Lid
..... Five Cups and Saucers
Display in a Work Record
In a Work Record, whole-part and other relationships
are described as Related Works. When records for works
are linked, data for these Related Works may be concatenated
from one record to form a display in the other.
Example for display in the record for Notre Dame, Paris:
Related Work:
Relationship
Type: larger context for
Related Work
[concatenated label]:
Transepts;
transepts; architects Jean de Chelles (French,
died ca. 1270) and Pierre de Montreuil (French,
ca. 1200-ca. 1264); ca. 1250-1267; Notre Dame
(Paris, France)
VII. DATABASE DESIGN AND RELATIONSHIPS
The CCO guidelines have been carefully crafted to
be useful in a variety of database settings and designs.
Database Design
Because of the complexity of cultural information
and the importance of Authority Records, CCO recommends
using a relational database. A relational database provides
a logical organization of interrelated information (for
example, data about works and images, authority files,
and so on) that is managed and stored as a single information
system.
Types of Relationships
Whenever a relationship (called a link in CCO)
is made between two Work Records, a Work and an Image
Record, or a field in a Work Record and a term in an
Authority Record, a relationship is being expressed.
Relational databases can be designed to accommodate
hierarchical and other relationships.
Building the Relationships
Hierarchical and other relationships can exist in
the same information system. Several distinctions need
to be made when building relationships into a database.
First are the distinctions in relationships between
works and images of those works; then are relationships
between works and other works; then come relationships
between works and authority file records; and last are
relationships between authority file records within
the same authority file.
Relationship Type and Reciprocity
CCO recommends that relationships between entities
be reciprocal so that a search on one entity can lead
to the other. Reciprocity is most easily accomplished
when reciprocal relationship capabilities have been
built into the information system. The relationships
between entities may be one-to-one, many-to-one, or
many-to-many.
CCO recommends that the type of relationship between
the work being cataloged and the related work be indicated.
Whole-part hierarchical relationships may be made apparent
by using indentation in displays. Other relationships
may require explanation by noting the type of relationship
between two entities.
Repeatable Fields
CCO recommends that certain fields be repeatable. These
refer, in the context of CCO, to categories of information
for which there may be multiple data values. For example,
there may be multiple media used to create a work, each
of which should be recorded in a separate instance of
the appropriate field, or related by multiple links
to the authority file that controls the terminology
for media. Related fields may be designated to repeat
as a set.
Display and Indexing
Display issues refer to how the data looks to the end
user in the database, on a Web site, on a wall or slide
label, or in a publication. Information for display
should be in a format that is easily read and understood
by end users. Indexing refers to how data is indexed
(that is, what indexing terms are assigned to it), sorted,
and retrieved. Such indexing should be a conscious activity
performed by knowledgeable catalogers who consider the
retrieval implications of their indexing terms.
Controlled Fields vs. Free-Text Fields
CCO recommends that the database accommodate both
controlled fields and free-text fields. Controlled fields
contain indexing terms-that is, key data values drawn
from standard vocabularies and formatted to allow for
successful retrieval. Free-text fields communicate nuance,
uncertainty, and ambiguity to end users.
The primary function of an indexed field is to facilitate
end-user access. Access is improved when controlled
vocabularies are used to populate database fields. Ideally,
the indexing terms will be linked to controlled vocabularies
stored in controlled lists or authority files.
Although free-text fields by definition contain uncontrolled
terminology, the use of terminology that is consistent
with the terms in controlled fields is recommended for
the sake of clarity. Using a consistent style, grammar,
and sentence structure is also recommended.
Display Issues
CCO recommends that data be recorded according to the
various requirements of display and indexing. Display
issues relate to the choice of fields or subfields appropriate
for display to different end users, and to how the data
looks to the end users. Information intended for display
should be in a format that is easy for the end user
to read and understand.
When planning a database design and rules for data
entry, do not allow immediate display demands to dictate
database structure or data entry practice. Doing so
may offer short-term solutions to some problems, but
will make migrating and sharing data more difficult
over the long term.
How to Decide on a Database Design
There are several key issues to keep in mind when designing
and constructing a database for cultural objects and
images: What is the purpose of the database? Who are
the users it is intended to serve? Will it allow you
to properly manage your data? It is important to design
a database to accommodate the descriptive data point
of view.
What Is the Purpose of the Database?
The term database is generic; a database can
be built to accommodate any type of information. Within
the context of cultural objects and images, databases
constitute the basis of cataloging tools, collection
management systems, presentation tools, and digital
asset management tools. Any one of these can be built
as a local or as a shared system. How these different
databases work together is referred to as interoperability.
In an ideal world, there would be one integrated database
that provided all users with all functionalities. In
reality, most organizations have several databases or
software products that are used to fulfill a variety
of needs, from collection management to digital asset
management to presentation of high-resolution images,
and so on.
VIII. AUTHORITY FILES AND CONTROLLED VOCABULARIES
Authority control is a system of procedures that ensures
the consistent use and maintenance of information in
database records. Its purpose is to ensure consistency
at the cataloging level, and to ensure that the user
searching a database can find material and relate it
to other material in the database efficiently.
Authority Files
Authority files contain the terminology used in cataloging
Work and Image Records. In the context of CCO, an authority
file contains records for persons, places, things, and
other concepts related to the works and images being
cataloged. The advantage of storing such ancillary (and
frequently repeated) information in an authority file
is that this information can be recorded only once,
and then linked to all appropriate Work and Image Records.
Another advantage is that changing or correcting a preferred
name or heading in the Authority Record will automatically
update the name or heading in the associated Work and
Image Records.
Controlled Vocabulary
A controlled vocabulary is an organized arrangement
of words and phrases used to index content and to retrieve
content by browsing or searching. It typically includes
preferred and variant terms and has a limited scope
or describes a specific domain. Controlled vocabulary
is a broader concept than authority file, encompassing
authority files as well as other controlled lists of
terminology. Various types of controlled vocabularies
are:
• Controlled List
• Synonym Ring File
• Taxonomy
• Subject Headings
• Thesaurus
Definitions for these types of controlled vocabularies
are found in the CCO Glossary.
Methodology for Creating a Controlled
Vocabulary
Each institution should develop a strategy for creating
controlled vocabularies customized for its specific
collection. However, if the collection is being queried
in a consortial or federated environment, controlled
vocabularies should be customized for retrieval across
different collections.
To create controlled vocabularies that meet your institution's
needs you need to ask what do you want your controlled
vocabulary to do? A vocabulary for cataloging will contain
expert terminology and will be designed to encourage
the greatest possible consistency among catalogers by
limiting choices of terminology according to the scope
of the collection and the focus of the field being indexed.
In contrast, a vocabulary for retrieval will typically
be broader and will contain more nonexpert, and even
"wrong," terminology, such as misspelled words or incorrect
but commonly used terms. Vocabularies that are intended
to help end users browse collections online should be
very simple and aimed at the nonexpert audience rather
than at specialists. For practical reasons, many institutions
will have to use the same vocabulary for both cataloging
and retrieval, thus requiring compromise approaches.
Granularity in the Terminology
The more similarity among items in your collection,
the more specific your vocabulary will need to be and
the more granularity should be used in indexing with
that vocabulary. Keep in mind how your items will be
retrieved in a consortial environment with other collections,
and therefore include basic indexing terms appropriate
to more general retrieval as well as specific terms
that work well in your local environment.
Maintaining the Vocabulary
Terminology for art and material culture may change
over time. Vocabularies need to be living, growing tools.
Technical Considerations
What technology will you use and how will authority
files, lists, and other controlled vocabularies be integrated
into the rest of your system? Answers to these questions
depend on local needs and resources.
How to Create Authority Records
Once you decide on the requirements and characteristics
of the authority files required by your institution,
the next step is to populate them with appropriate records.
CCO recommends using standard, published authority information
where possible, and then supplementing the authority
file to make it collection specific, as determined by
your institution's unique requirements. When it is necessary
to make new Authority Records, use standard, published
sources for the terms or names and other information.
Cataloging vs. Retrieval Issues
In building a database and in cataloging, you should
ideally follow the best design theory and the best editorial
practice. A few of the issues surrounding the use of
vocabularies in retrieval are discussed below.
Using Variant Terms and Names for Retrieval
Ideally, controlled fields in the Work Record will
be linked to authorities that include variant terms
and names for the person, place, or things described
in the Work Record, and you will also use the variants
for retrieval. If this is not true, you should explicitly
include the most important variants in the Work Record.
Using the Hierarchy for Retrieval
Ideally, your controlled fields will be linked to hierarchical
authority files, and the hierarchies will also be used
for retrieval. If this is not true, you should explicitly
include broader contexts for your terms in the Work
Record.
Case Insensitivity in Retrieval
Your retrieval system should accommodate end-user queries,
no matter what case they use. If your retrieval system
does not accommodate such variations, you should add
these variants to your Authority Record or to the Work
Record (if you do not have an authority file).
Diacritics in Retrieval
Your retrieval system should accommodate both the end
user's use of diacritics and punctuation and his or
her omission of diacritics and punctuation. If this
is not the case, you should add these variants to your
Authority Record, or to the Work Record if you do not
have an authority file.
Singular and Plural in Retrieval
Your retrieval system should accommodate either the
singular or plural form of the term or any other grammatical
variant and incorporate stemming, a feature that retrieves
the term and all its grammatical variants. If your system
does not accommodate such variations, you should add
the variants to your Authority Record or, if you do
not have an authority file, to the Work Record.
Compound Terms and Names in Retrieval
Your retrieval system should accommodate compound terms
and names spelled with or without a space. If your retrieval
system does not accommodate such variations, you should
add these variants to your Authority Record or to the
Work Record (if you do not have an authority file).
Inverted or Natural Order in Retrieval
Your retrieval system should accommodate end users'
use of terms and names in either natural or inverted
order. If your system does not accommodate such variations,
you should add the variants to your Authority Record
or to the Work Record (if you do not have an authority
file).
Source Authority
A Source Authority is a bibliographic authority file.
It is important to credit sources from which data in
the Work, Image, and Authority Records is obtained,
whether the source is a publication, a Web site, or
the unpublished opinion of an expert.
Elements for the Source Authority File
Elements in a Source Authority file could include title,
author, publisher, place of publication, year of publication,
and a variety of other fields for bibliographic information.
In addition, Source Authority records could point to
full bibliographic records in an online library catalog.
A simpler authority file for sources could include
fewer elements, such as a full citation combining author,
title, and publication information in a single field
and a brief citation to be used for concise displays.
Rules for the Source Authority
Record information in the Source Authority or in free-text
source notes consistently, using the rules in CDWA,
AACR, and the Chicago Manual of Style.
|
