Association for Library Collections and Technical Services

ID NUMBER

This category would record numbers which are within range of AACR. Some of these numbers will be universal (e.g. repository numbers) and some would be local (e.g. image classification numbers).

Numbers would most likely be coded in 035 with appropriate identification of source of number.

STYLE/PERIOD

This category is out of scope of AACR.

CULTURE

This category is out of scope of AACR.

No current MARC bibliographic fields are defined to differentiate data in this category from that in STYLE/PERIOD, TYPE or MATERIAL though in many cases each would be relevant to the description of a work of art. The data are somewhat self-differentiating. That is, each of the terms in "Flemish Renaissance panel painting in oils on oak" would fit in a category and one would not look for "Renaissance" under MATERIAL. There may, of course, be differences of categorization for some of this data.

SUBJECT

This category is out of scope of AACR though there is significant overlap with title in many cases. For example, "Madonna and Child" may be the subject but also the only known title.

While this category would likely be recorded in 65X, it does not fit entirely comfortably in either 650 or 655. That is, a sculpture of Saint Sebastian is not about Saint Sebastian nor is it a genre of sculpture.

RELATION

Most relationship information would be recorded by AACR in notes fields.

In MARC, notes may either be in descriptive 5XX fields or in such combined access/descriptive fields as 76X-78X.

DESCRIPTION

AACR notes includes ample provision for additional description of the item in Area 7.

MARC also provides ample provision in 5XX fields for additional description.

SOURCE

This category is not often needed in descriptions of printed items. While source of title may be indicated in an AACR description, it is usually because the title is taken from a source on the item but beyond the chief source. For works of art, the source of the title information is more likely to be from a source beyond the item, e.g. museum catalog, artist catalogue raisonnée, vendor catalog.

RIGHTS

This category is not explicitly covered in AACR though the information could clearly be covered by a note. In an archival description, this information would often be covered.

MARC field 540 provides for the recording of rights information. Records for images are more likely to have RIGHTS information.

VRA Core Categories and Library Standards

Robin Wendler

This section contrasts the nature of the Visual Resources Association Core Categories with that of the primary pair of library standards, AACR2 and MARC21. The release of version 3 of the VRA Core Categories has changed this review from what it would have been based on version 2. The thinking of the VR community has been evolving very rapidly, and in ways that are both similar to and different from the evolution of library standards.

The VRA CC is a fundamentally different kind of standard than AACR2 or MARC21. It is first and foremost a list of data elements with definitions, that is, a data dictionary. Unlike MARC21, it has not yet adopted any particular encoding syntax, nor is there a fixed record structure. In comparison to the short, simple list of VRA core categories, MARC21 has historically been seen by the visual resources community as overly elaborate and complex in ways that provide no benefit to VR collections, while at the same time lacking or obscuring some concepts which are important to them. To some extent this perception is true, of course, due to several factors:

• 
  The maturity of MARC21 compared to the VRA CC
  
• 
  The fact that MARC21 consciously addresses many formats of material in many different institutional contexts
  
• 
  MARC21's combined function as a data dictionary, an encoding syntax, and in some elements such as fixed fields, a content value standard.
  

• 
  The inclusion in MARC21 of elements which characterize the metadata itself (e.g., record ID and source, record creation date, cataloging level, descriptive form, and so on), which are important for managing metadata records but are missing from the VRA categories.
  

In earlier versions of the Core Categories, the elements were narrowly defined in terms of either a Work or a Surrogate (v.1) or Visual Document (v.2). While there was no direction about how these units were to be associated with each other, the obvious implication was that a single description of a Work could be logically associated with descriptions of many Surrogates, that is, a two tier hierarchy. While this kind of hierarchical relationship can be expressed in MARC21 through the use of linking fields, I know of no systems that take such linkage into account to provide the kind of searching, result displays, and record displays desired for visual resource research.

Version 3 discards the distinction between Work and what is now called "Image" and generalizes the definitions, allowing any element to be applied to either, as appropriate. (Sort of like Format Integration.) This change made many new and much needed elements available to describe Images. More importantly, however, the VRA CC now explicitly recognizes that these packages of description for Works and for Images may have many relationships instead of only a (relatively) simple one–Work–to–many–Surrogate structure. For example, one Work description for a building might be linked to another Work description for an elevation drawing, and Image descriptions could be linked to each Work record, as appropriate.

The VRA CC differs from AACR in that it is not a cataloging code. For example, it does not specify a "chief source" from which the content of each element should be taken, nor does it speak to how that content should be formulated. Superficially, then, it might appear that it would be logical for catalogers to use AACR2 to construct the values in VRA CC elements. After all, the visual resources community recognizes a need to standardize the choice and form of their metadata, and AACR2 serves this purpose.

However, the visual resource and museum communities have largely rejected AACR2, specifically the rules in chapter 8 and to a lesser extent the guidance on forming access points.¹ AACR2 "feels" wrong to these communities in a number of ways. Most significant, as Sherman noted, is AACR2's reliance on and privileging of so called received metadata, e.g., information on title pages, containers, etc., which is far less relevant for visual materials. Official dialogue with the VRA could yield rule revision proposals that would increase the applicability of AACR in visual resource organizations.

Functional Requirements for Bibliographic Records

Anne Champagne

The Functional Requirements for Bibliographic Records proposes four basic user tasks:

• 
  “to find entities that correspond to the user's stated search criteria (i.e., to locate an entity in a file or database as the result of a search using an attribute or relationship of the entity);
  
• 
  “to identify an entity (i.e., to confirm that the entity described corresponds to the entity sought, or to distinguish between two or more entities with similar characteristics;
  
• 
  “to select an entity that is appropriate to the user's needs (i.e., to choose an entity that meets the user's requirements with respect to content, physical format, etc., or to reject an entity as being inappropriate to the user's needs);
  
• 
  “to acquire or obtain access to the entity described (i.e., to acquire an entity through purchase, loan, etc., or to access an entity electronically through an on line connection to a remove computer).”
  

The design of the VRA Core 3.0 can support these four tasks.

FIND. The Core's Title element, which not only includes the title or identifying phrase given to a work or image but also title variants, translations, series and larger entity titles, is the most important element for allowing the user to find an entity. What is commonly referred to as authorship in traditional cataloging rules is referred to here as Creator and includes both personal and corporate names and can be qualified by role and attribution. Other organizing elements that aid the user include Style/Period, Culture, and Subject. The Core recommends that all of these elements, except Title, use controlled vocabularies.

IDENTIFY. With an artistic work or image, there is often not the opportunity to construct its description based on transcribing data contained in the work or image. Consequently, the Core relies on other technical elements to aid the user in identifying the entity. Record Type, Type, Title, Measurements, Material, Technique, Date, Location, Relation, and Description all provide information that can help the user to determine whether a work or image is the one desired and distinguish among works or images with similar characteristics.

SELECT. All the data elements in the Core can be used to aid the user in selecting an entity.

OBTAIN. The Core provides custodial information for both a work and an image, although in most cases it is not possible for a user to obtain a copy of a work. However, almost any image may be borrowed, purchased, reproduced or remotely accessed and the Core elements Location, ID Number, Source and Rights give the user the necessary information to do so.

Although the VRA Core can in practice support the four user tasks set forth by FRBR, the VRA standard itself does not guarantee a user will find, identify, select and obtain the desired work or image. Data creation and sharing models can be developed to fulfill FRBR requirements using the VRA Core Categories, but VRA CC by itself is not sufficient.

Although the VRA Core has the potential to support the four user tasks set forth by FRBR, it is not clear that actual implementation of the Core guarantee a user will find, identify, select and obtain the desired work or image. The introduction to the Core states that "only those elements which are relevant for specific record should contain data. ... There is not requirement to include a minimum number of elements in order to create a valid record." Without designating a set of elements as mandatory it is not clear that every implementation of the Core will result in support of the FRBR user tasks.

Further, Core has not mandated a method for linking datasets for works to datasets for images of those works. Although it suggests that the Relation element may be used as the linking mechanism, it is not clear that every local solution for linking will be successful. This may having a damaging impact on the user tasks of Find and Identify.

VRA Core Categories and the Dublin Core Metadata Element Set

Sherry Kelley

If the FRBR provides the common logical model for the content of metadata records, then the Dublin Core Metadata Element Set might be said to be the most likely to provide a shared data structure. This section of the report will concentrate briefly on comparisons between the Dublin Core Metadata Element Set and the VRA Core Categories, Version 3.0 to test this assertion. Comparisons to AACR2 and MARC are made in a separate section.

We choose Dublin Core because it is emerging as the de facto data structure standard for non library databases and because the VRA Core standard includes Dublin Core mapping for each of its elements. In addition, the Dublin Core has been called the lingua franca, or switching vocabulary for other metadata element sets. Thus, achievement of our goal to create a virtual union database of structured metadata, which relies on the creation of reliable maps or crosswalks, may be served best by comparing the two standards with the most in common and where the mapping is codified (at least in one direction).

To begin with, the Dublin Core is both a simple metadata element set of 15 elements (DCMES) which can stand alone, and a set of qualifiers, the Dublin Core Qualifiers (DCQ). The VRA Core Categories is a qualified metadata element set of 17 categories. Thus, the following comparison will be between VRA Core, 3.0 and DCMES/DCQ. General properties are the same for each: optional use of any of the elements, no mandatory element or set of elements, no prescribed order for elements, and occurrence of each element is unlimited.

Elements and Their Equivalents (in no particular order):

DCMES	VRA Core
Title	Title
Creator	Creator
Subject	Subject
Description	Description
Publisher	–––––
Contributor	–––––
Date	Date
Type	Type
Format	Record Type Measurement Material Technique

DCMES	VRA Core
Identifier	ID Number
Source	–––––
Language	–––––
Relation	Relation Source
Coverage	Style/Period Location Culture
Rights	Rights

DCMES, Version. 1.1 (http://purl.org/DC/documents/rec-dces-19990702.htm) provides element definitions including name, identifier, definition and comment. The comment attribute may include “recommended best practice.” For example, the Comment attribute for the Subject Element states: “Recommended best practice is to select a value from a controlled vocabulary or formal classification scheme.” The DCQ standard (http://purl.org/dc/documents/rec/dcmes-qualifiers-20000711.htm) provides for further qualification of Subject through the inclusion of the standard used for the data value, the “Element Encoding Scheme(s)” or through “Element Refinements.” In the case of the Subject Element, no Element Refinements qualifiers are possible, but Element Encoding Schemes are, and possible standards are listed including LCSH, MeSH, DDC, LCC, and UDC.

The VRA Core Categories, Version 3.0 (http://www.gsd.harvard.edu/~staffaw3/vra/ vracore3.htm) provides element definitions which include the category term, followed by a set list of attributes: Qualifiers (list of labels if qualified); Definition or Description; Data Values; the term “(controlled)” for selected categories; VRA Core 2.0 mapping; CDWA mapping; Dublin Core mapping; and, optionally, Comment. The Data Value attribute indicates the standard(s) that is to be used (recommended or prescribed). Certain of the uncontrolled Data Value attributes contain statements specifying that the information is formulated according to appropriate standards for data contents and lists examples of these.

Looking at the Subject category in the VRA Core as an example, we see that like DCMES, there are no Qualifiers. The Data Values sources recommended for these are AAT, TGM, ICONCLASS, and Sears Subject Headings. It is interesting to note that this attribute is not listed as “controlled” and that there is no overlap with the DCMES list of standards. In neither scheme are the lists of standards prescriptive. The correspondence between supplied information for this element in each standard should be close. For example, controlled vocabulary standards are recommended and the appropriate standards identified. (The VRA Core does contain a list of recommended standards in its introduction which do overlap with DCMES.)

The VRA provides qualifiers for nine of its categories: Title, Measurements, Material, Creator, Date, Location, ID Number, Style/Period, and Relation. The DCQ qualifies six elements: Title, Description, Date, Format, Relation and Coverage. Several of these overlap and are closely equivalent: Title, Measurements Material (VRA)/Format (DC), Date, and Relation.

Both standards follow the “1:1 principle” developed by the Dublin Core community. This is a long standing, hotly debated issue in the library community and is best known as the multiple versions problem. The current U.S. cataloging practice of describing more than one version of a resource in a single record may, however, work against the successful interchange of records amongst different databases. The requirement that one object or resource be represented by one metadata package, the 1:1 principle, might best support interoperability goals.

In this cursory linguistic analysis of two well developed data content standards, several points emerge that suggest possible models for future element/category set development that will best facilitate semantic and content interoperability in the library catalog environment:

• 
  A common set of terminology is recommended. (For example, the VRA metadata set consists of “categories,” DC of “elements”; VRA definition of Source = a reference to the source of the information recorded about the work or image, DC definition of Source = a reference to a resource from which the present work is derived.)
  
• 
  The term definitions must be precise and well defined. (VRA is closer to meeting this test than DC, by the design of each.)
  
• 
  There should be consistency in an element=s defined sets of attributes, following ISO 11179. (For example, DC includes Name and Identifier attributes in its element definition. VRA does not.)
  
• 
  Similiar metadata properties should be shared across all metadata standards. These should be expressed and used in a similar fashion within each standard. (Both VRA and DC articulate these similar properties and use them consistently. For example, order, optionality, and repeatability of elements are addressed in both.)
  
• 
  Standards should be organized in a similar manner. This would facilitate finding analogous sections across standards. (Both VRA and DC begin with an introduction followed by element definitions. DC complicates the ability to make cross comparisons by listing its qualifiers in a separate document.)
  
• 
  Content rules must be specified, either as recommendations or prescriptions. (VRA is closer to meeting this test. ) Resolution rules are needed for differences.
  
• 
  Controlled vocabularies should be promulgated and specified. (This is true for both names and subjects. Both attempt to meet this test for subjects. The VRA meets this test for names.)
  
• 
  Standards used should be referenced in the metadata record. (DC meets this test.)
  
• 
  Principle of 1:1 should be supported.
  

We have focused on the DCMES/DCQ in this section, trying to note similarities or their lack. We conclude that mapping from VRA Core to DCMES/DCQ will result in reasonably close correspondence for most elements thus achieving reliable interoperability for resource description with little loss of data. There will be loss of precision in those instances of many to one and one to many mappings. A more detailed mapping for VRA Core, Dublin Core and other standards is available at http://www.getty.edu/gri/standard/intrometadata/ 3_crosswalks/index.htm (Introduction to Metadata : Pathways to Digital Information edited by Murtha Baca. 2000.)