VRA Core 4

03/09/2007 How to convert from v3-v4 Page 1 of 12

VRA Core 4.0

Introduction

The Visual Resources Association Data Standards Committee has updated the Core Categories in

order to conform to ongoing developments in data standards, data sharing, and data storage

technology. This new version is known as Core 4.0.

VRA Core and data standards

The VRA Core is a data standard for the cultural heritage community. It consists of a metadata

element set (units of information such as title, location, date, etc.), as well as an initial blueprint for

how those elements can be hierarchically structured. The element set provides a categorical

organization for the description of works of visual culture as well as the images that document them.

Establishing an official encoding of the data elements into a data format (such as XML) is a logical

next step in the development of efficient systems for cataloging, retrieval, and record sharing. To this

end, the VRA Data Standards Committee has developed an XML Schema for the VRA Core 4.0

metadata element set to be used primarily for record sharing and exchange purposes.

It is important to realize that standardizing data elements and establishing a common data format will,

in and of themselves, achieve neither a high rate of descriptive consistency on the part of catalogers,

nor a high rate of retrieval on the part of end-users. Standards which specify how to fill the units of

information with data are necessary to guide the choice of terms or words (data values) as well as the

selection, organization, and formatting of those words (data content).

Some examples of data value standards that are used in the cultural heritage community include the

Thesaurus for Graphic Materials (TGM), Art & Architecture Thesaurus (AAT), Union List of Artist

Names (ULAN), and the Thesaurus of Geographic Names (TGN). An example of a data content

standard and one which is directly relevant to the VRA Core 4.0 is the Cataloging Cultural Objects

(CCO) guidelines. Data value and content standards will not be discussed in detail in this document,

but it is highly recommended that users of Core 4.0 refer to them in the development of their own data

standards guidelines. A full list of data standards and their URLs is displayed in Appendix 1.

Why a new version of the Core?

This latest edition of the Core contains significant changes from the previous version, Core 3.0. The

changes have been made in order to make an XML expression of the Core possible. These changes

primarily concern the redefinition of what were known as element qualifiers in 3.0. Qualifiers have

been converted to sub-elements and attributes following XML encoding syntax (see more on XML

below).

Other changes reflect practices elaborated in CCO. Core 4.0 and CCO have effected a symbiotic

relationship: Core 3.0 provided the groundwork upon which the CCO editors developed data content

guidelines and CCO, in turn, has informed the methodology of Core 4.0, specifically in the

differentiation of data values for display and indexing.

In Core 4.0, the VRA Data Standards Committee has continued to follow the "1:1 principle,"

developed by the Dublin Core community, i.e., only one object or resource may be described within a

single metadata element record. However, images often show more than one work, or only a portion

of a complex work made up of many parts. The Core RELATION element allows these complex

“one-to-many" relationships to unambiguously co-exist within one metadata record. How database

records are linked is a local implementation issue, but this introduction will give a general overview of

relationships between database records and refer to other resources that can advise in this area.

03/09/2007 How to convert from v3-v4 Page 2 of 12

Changes to elements between 3.0 and 4.0

Some element names have been modified from 3.0 to 4.0. In certain cases, the elements themselves

are still used for the same types of information as in Core 3.0. In other cases, there have been

structural changes, many of which were necessary for XML encoding. The changes are as follows:

Core 3.0

Core 4.0

Nature of change

RECORD

TYPE

WORK, COLLECTION,

or IMAGE

Name change and structural change (see below under

discussion of XML)

TYPE

WORK TYPE

Name change only

CREATOR

AGENT

Name change and structural change

ID NUMBER

LOCATION.REFID

Sub-element under LOCATION for IDs associated

with repository

TEXTREF

IDs not associated with repository

CULTURE

AGENT.CULTURE

Sub-element under AGENT to denote agent culture or

nationality

CULTURAL CONTEXT

Describes cultural context

INSCRIPTION

New element

STATE EDITION

New element

A significant change was made to the CREATOR element. Encoding of this element was problematic

in Core 3.0 because the term “creator" implied a particular role for the person or corporate body

affiliated with the object or image. A person or corporation might be affiliated with the object or image

in another role, such as a donor, commissioner, builder, etc. Therefore 4.0 created separate but

repeateable data placeholders for the name and role. CREATOR has been renamed AGENT and

sub-elements were created for name, role, culture, dates, and attribution.

CULTURE, which existed as a single, free-standing element in 3.0, is now recorded in two different

places. As a sub-element under AGENT, culture may be associated with a named individual or

corporate body to denote the nationality or cultural background of the agent of creation. That is, the

cultural background of Edouard Manet or the anonymous architect(s) of the Great Pyramid of

Tenochtitlan would be indicated by the values “French" and “Aztec" respectively in the

AGENT.CULTURE sub-element. On the other hand, the free-standing element CULTURAL

CONTEXT is meant to denote the cultural context in which the work was created. In this regard, the

cultural context of Manet’s “Olympia" or the Great Pyramid of Tenochtitlan could also take the values

“French" and “Aztec" respectively. However, in the case of the Wilton Diptych, which was almost

certainly created by a French artist in an English milieu, or “The Child’s Bath" by Mary Cassatt, which

was created by an American artist in a French milieu, the element CULTURAL CONTEXT would take

the values “English" and “French" respectively (see table below).

Work

Agent

AGENT.CULTURE

CULTURAL

CONTEXT

Olympia

Edouard Manet

French

Great Pyramid of Tenochtitlan

Anonymous Aztec

architect

Aztec

Wilton Diptych

Anonymous French

artist

French

English

The Child’s Bath

Mary Cassatt

American

French

03/09/2007 How to convert from v3-v4 Page 3 of 12

In 3.0, it was possible to define whole/part relationships by referring to a LargerEntity qualifier in the

TITLE element. While this was convenient, it created potential ambiguities among records. The Data

Standards Committee decided it was more efficient and “cleaner", from a data integrity standpoint, to

define whole/part relationships in 4.0 by creating record-to-record linkages using the RELATION

element. The LargerEntity qualifier has thus been eliminated from the TITLE element.

Another noticeable change from Core 3.0 is the restructuring of the ID NUMBER element. IDs

associated with a repository are now recorded in a sub-element (refid) of LOCATION. For example,

an object belonging to the Louvre with an accession number 680 would be described as follows:

Display: Musée du Louvre (Paris, FR) 680

VRA

element

XML

element

XML

attribute

XML

sub-element

XML

attribute

Data example

LOCATION

location

type

repository

name

Musée du Louvre

type

corporate

name

Paris

type

geographic

refid

680

type

accession

On the other hand, ID values derived from related textual references not associated with a particular

location, such as a catalog number, are recorded in what is now called the TEXTREF element. For

example:

Display: ARV2 5 (6)

VRA Element

XML element

XML sub-element

XML Attribute

Data example

TEXTREF

textref

name

Beazley, Attic

Red-figure Vase

Painters (2

Edition)

type

corpus

refid

p. 5, no. 6

type

citation

Two new elements have been introduced in Core 4.0: INSCRIPTION and STATE EDITION.

INSCRIPTION records all marks or written words added to the object at the time of production or in its

subsequent history, including signatures, dates, dedications, texts, and colophons, as well as marks,

such as the stamps of silversmiths, publishers, or printers. STATE EDITION records the identifying

number and/or name of a state, edition, or impression of a work that exists in more than one form and

the placement of that work in the context of prior or later issuances of multiples of the same work.

Works, Images, and Collections

In version 3.0, Core elements could be used to describe two types of records: works and images. In

version 4.0, a third record type has been added for collections. These three record types have been

defined in Core 4.0 as follows:

03/09/2007 How to convert from v3-v4 Page 4 of 12

A work is a unique entity such as an object or event. Examples include a painting, sculpture, or

photograph; a building or other construction in the built environment; an object of material culture, or

a performance. Works may be simple or complex. Works may have component parts that are

cataloged as works themselves but related to the larger work in a whole/part or hierarchical fashion

via the RELATION element.

An image is a visual representation of a work in either whole or part. The representation serves to

provide access to the work when the work itself cannot be experienced firsthand. In image

collections, such representations typically are found in the form of slides, photographs, and/or digital

files.

A collection is an aggregate of work or image records. In 4.0, it was necessary to add an additional

record type (other than work and image) in order to allow for collection-level cataloging, where a

single record may be made for a group or collection of items when it is impractical to make separate

records for a number of related works. While the term collection may have varying meanings in

different communities, a collection in Core 4.0 may be comprised of multiple items that are

conceptually or physically arranged together for the purpose of cataloguing or retrieval. This record

type can also be used to record an archival group that share a common provenance or a series that

encompasses multiple individual titles.

For more guidance see the CCO: Part I: Section II. What are you Cataloging?; Part I: Section III.

Works and Images; and Part I: Section VI. Related Works.

Relationships between records

In the context of Core 4.0 there are three primary types of relationships between records: 1) work to

work, 2) image to work, 3) image or work to collection

Work to Work relationships

According to CCO, there are two types of work to work relationships: intrinsic and extrinsic,

and it is important to make this distinction at the beginning of the cataloging process. An

intrinsic relationship is one that is essential to the cataloging process and needs to be

recognized in order to fully identify a given work. On the other hand, an extrinsic relationship,

while informative, is not essential in order to fully identify or locate the work.

An intrinsic relationship exists where the described work is dependent on the referenced work,

either physically or logically, for its identity. This dependency is typically part-to-whole, such

as a component of an architectural complex, a panel of an altarpiece, a page of a manuscript,

or an individual work in a series. The cataloger should use the RELATION element to

establish a virtual link between the two works. The data values should include at minimum the

identity of the related work (e.g. unique id at a minimum, title if needed) and a description of

the type of relationship.

An extrinsic relationship between two works exists when the described and referenced works

could stand independently and the relationship is informative but not essential either physically

or logically in identifying either of the works. Some institutions may find it unnecessary to

identify extrinsic relationships other than by adding a note in the DESCRIPTION element. But

if an institution wants to record a virtual link in its system between the two works using the

RELATION element, the link between the works should be reciprocal and the data values

should include at minimum the identity of the related work (e.g. unique id at a minimum, title if

needed) and a description of the type of relationship. Examples include: pendant works, a

preparatory sketch for a later work, a work copied after another work, or a work referenced

within another work.

03/09/2007 How to convert from v3-v4 Page 5 of 12

Image to Work relationships

In order to give meaning to an Image Record, it is necessary to create a virtual link between

one or more Work Records and the Image Record. This link is also made via the RELATION

element, and the nature of the relationship is defined by the type attribute.

Typically, a given work record will have more than one image associated with it (e.g. several

views of a work). In some cases an image may represent more than one work (e.g. image of

several pieces of jewelry in a display) and needs to be related to multiple work records. The

data values should include at minimum the identity of the related work (e.g. unique id at a

minimum, title if needed) and a description of the type of relationship.

Image to Collection or Work to Collection relationships

Depending upon circumstance, an image or a work record can be associated with a given

collection record (see above definition of collection), using the RELATION element. The data

values should include at minimum the identity of the related work (e.g. unique id at a minimum,

title if needed) and a description of the type of relationship.

For more guidance on relationships see CCO Part I: VI. Related Works; Part I: VII. Database

Design and Relationships.

Required/Minimal elements

From a strictly technical standpoint, the only required element in a Core 4.0 record is that which

contains information that uniquely identifies the record. In non-XML implementations, this is the

WORK, COLLECTION, or IMAGE element; in XML implementations, this is the Work, Collection, or

Image “wrapper" that contains the other elements (see XML and the Work, Collection, or Image

Element below).

However, as a principle of good practice, there are certain descriptive elements that are deemed

essential for meaningful retrieval. These are elements that provide information answering basic

questions about an object: what, who, where, when. To this end, a minimum-level work record

should contain the following elements:

WORK TYPE (what)

TITLE (what)

AGENT (who)

LOCATION (where)

DATE (when)

The cataloger is encouraged to record more than the minimal descriptive elements listed here

when the information is available and would be useful to the end user. For more guidance on

minimal elements see CCO Part I, Section IV, Minimal Descriptions.

By the same token, a minimal-level image record should contain the following descriptive

elements to ensure proper identification:

WORK TYPE

TITLE (CCO View Description)

03/09/2007 How to convert from v3-v4 Page 6 of 12

Repeatable elements

A repeatable element means that there can be more than one data value assigned to that

element within a single record. For example, SUBJECT is an element that is repeatable in

order to store the many subject terms that may be needed to describe a work or image. For

better storage, retrieval, and sharing of data, it is recommended that catalogers store multiple

terms in separate, repeatable instances of an element rather than storing multiple terms within

a single, non-repeated element. The data may still be concatenated for display or labeling if

needed.

Example:

Not recommended: Multiple terms within a single, non-repeated element

SUBJECT = woman with child, boat, dog

Recommended: Multiple terms assigned to separate, repeated elements

SUBJECT = woman with child

SUBJECT = boat

SUBJECT = dog

Why XML?

XML provides a stable, non-proprietary data storage and/or exchange environment from which

data can easily be transferred to other software environments as necessary. XML stands for

Extensible Markup Language. XML is a markup language much like HTML, but, unlike HTML,

which is about displaying information, XML is about describing information’s structure and

meaning. Basic components in an XML data file include elements, sub-elements, attributes

and data values.

Elements and sub-elements are analogous to field names in a database. They are also

referred to as tags because they are used to tag or markup the data they describe. Tags are

always easy to recognize because they are enclosed in <angle brackets>

Example of an element:

<description>back of panel in triptych</description>

Sub-elements are used to nest elements hierarchically within other elements.

Example of sub-elements:

<agent>

<name>Rubens, Peter Paul</name>

<culture>Flemish</culture>

<role>painter</role>

</agent>

Attributes contain data that qualify the element data or sub-element data in some way. For

example, the attribute unit modifies the element MEASUREMENT.

Example of an attribute:

Data values are the actual data that is enclosed within the XML tags. Unlike HTML, each data

value must be surrounded by an opening and closing tag to be valid.

Example of a data value:

<technique>etching</technique>

03/09/2007 How to convert from v3-v4 Page 7 of 12

This document provides only a very basic introduction to XML because it is presumed the

cataloger will be working in conjunction with a programmer, database administrator, or

technical support staff in setting up one’s system. While this is only an introduction, it is highly

recommended that the cataloger familiarize him/herself further with XML in order to

understand its capabilities and limitations and to communicate more effectively with technical

support staff in setting up a system. Additional XML resources are recommended in Appendix

Display, Indexing, and Annotation

CCO recommends that data be recorded according to the requirements of both display and indexing.

That is, data values for a given element should be formatted as they will be displayed to an end user

of a database, whether in a slide label, text in a publication, or web page. At the same time, data

values should be separately formatted and linked to controlled vocabularies as a set of indexing

terms to facilitate successful retrieval. Furthermore, each element should retain a place for additional

annotation, if it is needed.

To this end, the VRA Core XML schema provides each element with two separate sub-elements,

display and notes, for display and annotation purposes respectively. These sub-elements, along with

one or more index values contained within the element tags, are nested within an outer “wrapper"

known as a set that contains the display, notes, and one or more sub-element values. For example,

the MATERIAL element would be expressed as follows:

<display>oil on canvas</display>

<notes source="Art Bulletin, v.87, no. 1 (March 2005)">Medium originally thought to

be tempera. Oil medium discovered in tests at Uffizi in 2003</notes>

<material type="medium" vocab="AAT" refid="300015050">oil paint</material>

<material type="support" vocab="AAT" refid="300014078">canvas</material>

</materialSet>

The display value of the element is “oil on canvas", while the values “oil paint" and “canvas", derived

as controlled vocabulary from AAT, are recorded as indexing terms in repeating instances of the

<material> sub-element. Each set must contain at least one instance of the element name (in this

case, <material>) as a sub-element, whereas the display sub-element, which is used for a formatted

version of the index data, is optional.

An optional notes sub-element within the set wrapper enables free-text annotation of element-specific

information not already covered in the other attributes. If, however, the annotation refers to the entire

record rather than to a specific element, it should be recorded in the DESCRIPTION element instead.

Keep in mind that some systems will allow you to create the display data automatically from the

indexed data. In other cases, the displayed data will need to be entered manually.

XML and the WORK, COLLECTION, or IMAGE element

What was formerly known in Core 3.0 as the RECORD TYPE element has been reconfigured

into an element called WORK, COLLECTION, or IMAGE. The data contained within the

record (work, collection, or image data) determines the name of the element itself.

This element is a crucial storehouse of administrative data that provides context within a given

record-keeping environment. The attributes of the WORK, COLLECTION, or IMAGE element

provide this information as follows:

 id contains a unique identifier for the XML record

 the global refid attribute may be used to record a local number, code, or address that

uniquely identifies the record within the local context identified in the source attribute

03/09/2007 How to convert from v3-v4 Page 8 of 12

 the global source attribute records the set or environment to which the record belongs, such

as a visual resources collection or museum

In the XML schema, Work, Image, or Collection functions as an upper-level “wrapper" within

which the other elements, each packaged in sets, are contained. The global id, refid, and

source attributes of the Work, Image, or Collection wrapper serve as unique identifiers in

different contexts. The id attribute uniquely identifies an individual XML record within a file

consisting of many XML records, and the refid + source uniquely identifies the XML record in

the system from which it came. The hierarchy of tags, with a Work record used as an example

and the first element, Agent, elaborated, is as follows:

</agentSet>

etc…

</work>

Global attributes

Some attributes in the VRA Core 4.0 are considered global or “floating" because they can be

used to modify any element or sub-element rather than being tied to any specific one. The

VRA Core 4.0 attributes extent, dataDate, href, pref, refid, rules, vocab, source, and xml:lang,

have been designated as global attributes. These attributes are optional and may be applied

as needed.

 extent refers to the part of the work, image or collection being described by the element or

sub-element that it modifies.

 dataDate refers to the date and/or time a particular piece of data was captured

 href refers to a hypertext reference that provides a link to another electronic resource

 pref indicates that a particular data value is the preferred value when multiple data values for

the same element or sub-element exist

 refid refers to id numbers or codes coming from the local institution or resource named in the

source attribute

 rules refers to any data content standards used to construct the value recorded in the

element (e.g. AACR2, CCO)

 source refers to the local, print, or electronic source from which information is derived for a

specific element (e.g. Grove Dictionary of Art). Please note: SOURCE is also used as an

element and should be used when you want to record a single print or electronic source for

information pertaining to the entire record rather than pertaining to individual elements.

 vocab refers to the controlled vocabulary source from which the term or phrase is derived

(e.g. AAT, LCSH).

03/09/2007 How to convert from v3-v4 Page 9 of 12

 xml:lang refers to the language in which the information is recorded in the system (e.g.

English, French).

XML ID attributes

Besides the global attribute refid, which may refer to id numbers or codes associated with external

sources of information, such as AAT, ICONCLASS, or a local contributing collection, there are two

specialized identification attributes in Core 4.0.

 id is used in the WORK, COLLECTION, or IMAGE element. The value of this attribute is a

unique identifier for the XML record. It is analogous to a primary key in a relational database.

The value must begin with a letter or underscore. As a matter of best practice, it is

recommended that the value begin with a "w_" for works, "c_" for collections and "i_" for

images (e.g. w_123456, c_345678, and i_983247). This prefix may be added in the XML

export process, and need not be part of the database record.

 relids is used in the RELATION element. The value of this attribute is the id of the Work,

Collection, or Image to which the specified Relation is pointing. It is analogous to a foreign

key or relational key in a relational database.

XML Schemas

An encoding schema is needed in order for everyone implementing a common metadata

element set to do so in a consistent way. A schema is simply an XML file that contains the

rules for what can and cannot reside in an XML data file. Schema files typically use the .xsd

file name extension, while XML data files use the .xml extension. Schemas play several roles,

including specifying the valid elements, sub-elements, and attributes as well as the values

they can contain (either by data type or by providing a list of values). Schemas specify which

elements are required and/or are repeatable. Furthermore, they control the structure by

specifying which elements can be nested. When the data in an XML file conforms to the rules

provided by a schema, that data is said to be valid.

At present, there are two versions of the VRA Core 4.0 XML schema, one unrestricted and

one restricted. The unrestricted version imposes no restrictions on the values entered into any

of the elements, sub-elements, or attributes, and may be useful for those who want to

exchange legacy data that does not conform to the data value requirements in the restricted

schema. It should be understood, though, that data exchanged in this manner may not

interoperate well with data that meets the requirements of the restricted schema. The

restricted version imposes restrictions on the data values entered into the type attributes (see

VRA_Core4_Restricted_schema_type_values.pdf for a list of allowed values and their

definitions.) This version may be more appropriate for those wishing to aggregate VRA Core

data from multiple sources into a common repository or shared cataloging environment. As

time passes and practice warrants, even more restrictive or community-profile-specific

versions may evolve. Keep in mind that the restricted version of the schema is an extension

of the unrestricted version and should be used in addition to rather than in place of it.

Purpose of the VRA Core 4.0 XML Schema

Many institutions store their data in relational or proprietary databases. Most will not have the

capability or desire to store their data in XML. Even if your institution has the ability to store

data in XML, the VRA Core 4.0 XML Schema would probably not be sufficient for this purpose

because it does not support fully-enabled authority files and it is likely institutions would need

to add additional elements, sub-elements and attributes for local needs.

03/09/2007 How to convert from v3-v4 Page 10 of 12

The primary function of the VRA Core 4.0 XML Schema is to enable you to export information

from your relational or proprietary database to XML for the purposes of sharing that data

beyond your local system. Most commercial relational database software applications, such

as Access and FileMaker Pro, now provide this export option either by writing export routines

or by XSLT Stylesheet transformations.

Core 4.0 and CCO

As mentioned earlier, VRA Core 4.0 and CCO have affected a symbiotic relationship – a result

of informing one another and working very well together as data element and data content

standards. It should be noted, though, that they are not meant to mirror one another exactly.

They were designed for different purposes, CCO for record creation and VRA Core 4.0 for

record sharing. Therefore there are some differences that users should be made aware of.

CCO focuses on descriptive metadata only. VRA Core, on the other hand, includes some

administrative elements necessary for data aggregation and record sharing. Below is a chart

identifying the correlations and differences between them.

Core 4.0 work record

CCO work record

WORK, COLLECTION, or IMAGE

(administrative)

WORK TYPE

TITLE

MEASUREMENTS

MATERIAL

TECHNIQUE

AGENT

CREATOR

DATE

LOCATION

TEXTREF

STYLE PERIOD

STYLE

CULTURAL CONTEXT

CULTURE

SUBJECT

INSCRIPTION

STATE EDITION

STATE AND EDITION

RELATION (administrative)

DESCRIPTION

SOURCE (administrative)

RIGHTS (administrative)

CLASS

The CCO category CLASS is not included as an element in Core 4.0 because CLASS pertains to the

local organizational context of a given collection or institution and is not necessarily meaningful in a

shared environment. Some data values ordinarily found under CLASS are easily accommodated by

Core elements such as WORK TYPE or STYLE PERIOD. Other class terms may be recorded in a

local XML schema that uses a VRA XML record as it's "core."

Administrative elements found in the Core, but not in CCO, are important for record sharing. Explicitly

identifying a record as being one of WORK, COLLECTION or IMAGE type and using the RELATION

element will make it easier to maintain links between those records and to relate them to other

records outside the local environment.

In CCO, work records are distinguished from image records implicitly through element naming. For

example, CCO uses View Description, View Type, View Subject, and View Date as the descriptive

elements for Image Records. VRA Core 4.0, on the other hand, maintains the same set of element

03/09/2007 How to convert from v3-v4 Page 11 of 12

names regardless of record type (Collection, Work, or Image). However, the meanings of these

elements are equivalent. See the chart below.

VRA Core 4.0 image record

CCO image record

TITLE

VIEW DESCRIPTION

TITLE type="generalView" or “partialView"

VIEW TYPE

SUBJECT

VIEW SUBJECT

DATE type="view"

VIEW DATE

Other administrative elements in VRA Core 4.0, such as SOURCE and RIGHTS, are important in

an aggregated environment to help identify the original source for data and images and to clarify

how those images can be used. In a Work Record, SOURCE identifies the source of information,

usually a publication or web site, upon which cataloging information is based; in an Image

Record, it identifies the publication, vendor, or photographer from which an image is derived.

RIGHTS, on the other hand, identifies the copyright status and the rights holder, if known, for a

given work or image. Sometimes the cited source and the rights holder will be one and the same,

but this will often not be the case. If the copyright status or rights holder is unknown, then the

information contained in SOURCE may be a useful starting point to an end user in initiating a

As digital assets are shared outside of the local environment in which they were created, rights

metadata becomes important for supporting their effective management and re-use. Many

institutions will have their own intellectual rights metadata strategies and the RIGHTS element, in

and of itself, is not meant to replace those strategies. Rather, it can help inform institutions what

rights information will need to be extracted from the local record and accompany a digital asset

when it is shared.

Some institutions provide intellectual rights metadata at the collection level while others provide it

at the level of the individual asset. Ideally, institutions should record and provide this information

at the item level for the efficiency of the end user. But if this is not possible, a blanket rights

statement can be applied to all items upon export.

03/09/2007 How to convert from v3-v4 Page 12 of 12

Appendix 1: Related Data Standards (when online versions are available they are listed

below)

Data element sets:

Categories for the Description of Works of Art

http://www.getty.edu/research/conducting_research/standards/cdwa/

Data content:

Cataloging Cultural Objects: A Guide to Describing Cultural Works and Their Images/

editors, Murtha Baca…[et al.]. on behalf of the Visual Resources Association. Chicago :

American Library Association, 2006. See also http://vraweb.org/ccoweb/cco/index.html

Anglo-American cataloguing rules / prepared under the direction of the Joint Steering

Committee for Revision of AACR, a committee of the American Library Association ... [et

al.]. 2nd ed., 2002 revision. Ottawa : Canadian Library Association ; Chicago : American

Library Association, 2002- (AACR2)

Data values:

Library of Congress Subject Headings (LCSH)

Library of Congress Thesaurus for Graphic Materials (LCTGM - Parts I and II)

http://www.loc.gov/rr/print/tgm1/

http://www.loc.gov/rr/print/tgm2/

Getty Art and Architecture Thesaurus (AAT)

http://www.getty.edu/research/conducting_research/vocabularies/aat/index.html

Getty Thesaurus of Geographic Names (TGN)

http://www.getty.edu/research/conducting_research/vocabularies/tgn/index.html

Getty Union List of Artist Names (ULAN)

http://www.getty.edu/research/conducting_research/vocabularies/ulan/index.html

Getty Editorial Guidelines for ULAN: Appendix G: Nationalities and Places

http://www.getty.edu/research/conducting_research/vocabularies/guidelines/ulan_4_7_ap

pendix_g_nationality_place.pdf

Appendix 2: Recommended XML introductory resources

XML tutorial put out by w3Schools

http://www.w3schools.com/xml/default.asp

Eric Lease Morgan’s Getting Started with XML

http://www.infomotions.com/musings/getting-started/

Help files within software programs– For example, in Access search for “XML for the uninitiated"

Gilmour, Rom. XML: a Guide for Librarians. LITA Guide #11. American Library

Association, 2003.