BCC2008/MSWG/1
Music Library Association
Bibliographic
Control Committee
Metadata Working Group
Final Report
Charge
1. To
examine the descriptive, structural, and administrative metadata elements
currently being used to control music materials, including, but not limited to,
those elements employed in the projects identified by the International Music
Metadata Projects Working Group.
2. Formulate
a schema of required elements for music metadata applications, along with
recommendations for their standardized use.
3. Develop
"best practices" with regard to the use of, extension of, and/or
transmission of data between the new schema and the other major metadata
schemas.
Membership
Joseph
Bartl, Library of Congress
Antonio Calvo,[1]
California State University, Northridge
Marcelyn D'Avis, University of Colorado, Boulder
Stephen Davison, University of California, Los Angeles, Chair
Brad Eden, University of California, Santa Barbara
Ralph Hartsock, University of North Texas
Renée McBride, Hollins University
Constance Mayer, University of Maryland, College Park
Clay Redding, Library of Congress
Jenn Riley, Indiana University
Lois Schultz, Duke University
CONTENTS
1. Introduction
2. Current Metadata Standards
3. Music Metadata Guidelines
Appendices
1.
Metadata Object Description Schema
2.
MODS and Music Materials
3.
4.
Encoded Archival Description
5.
METSRights
6.
CopyrightMD
1. Introduction
The charge
to the working group falls into three tasks: examination of existing metadata
schema; formulation of a new music schema; and creation of best practices for
its use. Much has been learned, however, in the metadata community since the
formulation of this charge in 2003 about the interaction between metadata
structure standards and various types of content standards (see illustration
below). This progression of thinking led the working group to interpret the
development of a “schema’ as format-specific content guidelines rather than a
formal metadata structure standard.
Types of
metadata standards
Several other
factors support our decision that music metadata guidelines are of more use to
the community at this time than a music-specific metadata structure standard in
the form of an XML Schema. “Music” is an almost impossibly diverse field,
reaching far beyond the notion of Western art music to jazz, endless genres of
“popular” music, and indigenous musics throughout the world that are
increasingly a focus of study. The data elements to support discovery for, and
even the fundamental way of thinking about these various types of music
differs, most notably in the relative importance of “composition” versus
“performance.” It is therefore unlikely that one single metadata structure
standard could adequately meet the needs of music in all of these traditions.
Practical considerations enter as well—the ability of libraries to choose the
appropriate metadata standard for a given set of materials has not developed as
far as anyone would have hoped. Few if any ILS packages provide a robust,
easy-to-use, and fully supported mechanism for usefully integrating non-MARC
metadata together with existing MARC records, and widely-used Digital Asset
Management systems such as CONTENTdm and DSpace provide only minimal metadata customization
capabilities beyond their default Qualified Dublin Core models.
Archivally-focused repositories generally have a strong need to treat music
materials in the same way they treat other collections, including personal
papers and photograph collections. Most repositories with music materials,
therefore, have very little hope of being able to implement an MLA-defined
music metadata structure standard in a production environment at this time.
A comparison with the Visual Resources Association’s VRA Core metadata
schema is illustrative. Among visual resource collections—primarily slide
libraries supporting instruction in the visual arts—there have historically
been a variety of descriptive practices. Slide libraries are typically not part
of the academic library system, and staff often are not trained librarians.
Slide libraries can be part of academic institutions, or museums of various
sorts. Therefore, with the advent of digitization there was a need for the
creation of standard practices for description and a schema to contain them.
VRA Core is widely known in the VR community, but still not widely adopted,
largely due to a lack of systems that effectively handle the distinction
between a Work and Images of that Work outlined by the VRA Core Schema and the
lack of technical support in slide libraries to support systems that do allow
for the use of VRA Core. The music library community should monitor
developments in the visual resources community to help determine if specialized
music metadata structure standards should be developed in the future.
The working group limited the scope of our investigations to the musical
nature of materials, leaving guidelines on non-musical aspects such as bindings
and visual elements to specialists in these areas. Similarly, our
recommendations only hold for works of music, not works about music. We were, on the other hand, able to keep a broad scope
with respect to different descriptive traditions. We believe our
recommendations will be useful across the library, archives, and museum
spheres, and will be compatible with metadata structure standards and general
content standards (such as AACR2[2],
DACS[3],
and CCO[4])
from each of these communities. Our guidelines, however, will be most useful
for item-level description of materials. For multi-level description in the
archival tradition, relevant archival standards will likely provide better
guidance.
2.
Review of Current Metadata Standards
Various
metadata element sets and schema were examined by the working group, including:
- Descriptive metadata
- Metadata Object Description
Schema (MODS)[5]
- The metadata component of
Variations 2: Indiana University Digital Music Library,[7]
- Archival finding aids markup
- Encoded Archival Description
(EAD)[8]
- Rights metadata
- Open Digital Rights Language
(ODRL)[9]
- MPEG Rights Expression
Language (MPEG-21/5)[10]
- METS Rights Extension Schema
(METSRights)[11]
- Metadata exchange
- Metadata Encoding and
Transmission Standard (METS)[12]
- Music notation and transmission
- Standard Music Description
Language (SMDL)[13]
(note: SMDL seems to have no current support or maintenance)
- Music Encoding Initiative
(MEI)[14]
- MusicXML[15]
- Other standards
There are
many additional metadata standards either specifically music-related, or which
are used for the control of music materials, but the working group felt that
these were the standards that are most important for us to track at the present
time.
A number of
these standards are supported by the Library of Congress, and are widely used
for the control of digital objects of all types. They are:
·
Metadata
Object Description Schema (MODS)
·
Metadata
Authority Description Schema (MADS)
·
Metadata
Encoding and Transmission Standard (METS)
·
Encoded
Archival Description (EAD)
·
Metadata
for Images in XML Schema (MIX)
Of these
MODS and EAD are standards that have been used extensively to describe music
materials. These two, along with Dublin Core, are the descriptive metadata
standards that we need to track and for which we should create best practices.
METS is a
standard for creating containers for the metadata, file inventories, and
digital object structure and behavior that make up digital objects. Usage of METS
for object storage and exchange is growing, and METS profiles for musical
objects are beginning to be appear.[19]
This area should be monitored but it does not seem necessary for us to make any
specific recommendations for its use with musical materials at this time. The
descriptive portions of a METS file however, will typically be coded using MODS
or DC, for which we will provide recommendations.
Encoded
Archival Description is the standard encoding language for archival finding
aids. When used to describe musical materials at the item level it becomes
important to be able to map between the EAD encoding and other descriptive
element sets to enhance interoperability. Recommendations for EAD encoding or
music materials are included in the working group’s guidelines.
A number of
Rights Expression Languages (RELs) are currently under development. None of
them are fully deployed at this date. [20]
RELs have three principal goals: expression of copyright, expression of
contract or license agreements, and control over access and/or use. The various
RELs have been created to meet differing needs. For instance, METSRights is
intended to accompany digital library materials; ODRL is a general-purpose
language that allows for some actionable control over resource use; and
MPEG-21/5 is a general language for use within a trusted system environment and
is designed to provide protection from unauthorized use of resources. The
California Digital Library has performed an extensive analysis of rights
metadata standards, and has proposed an end-to-end Rights Management Framework.[21]
After
reviewing the listed standards, the working group concluded that
recommendations were needed only for descriptive metadata. Music notation
standards seem to operate in a different sphere, and can stand on their own,
and technical, structural, rights, and other types of administrative metadata
appeared to need to special guidelines for their application to musical
materials.
3. Music
Metadata Guidelines
The working
group presents guidelines for 14 descriptive attributes. These attributes
represent classes of metadata
elements that commonly appear in descriptive metadata structure standards. They
are intended to be used whenever an element in a structure standard falls into
the defined class, and in conjunction with appropriate general content
standards. While the attributes listed here are likely to be relevant to the description
of music materials, these guidelines do not go so far as to say they are required in description, as the presence
or absence of a metadata element is affected by the choice of both metadata
structure standards and general content standards. The guidelines do not
contain recommendations for every
descriptive element likely to be found in the metadata structure standard in
use at a given institution; rather, they represent only those attributes the
working group believed require special interpretation for music materials.
Descriptive data elements such as topical subjects, series, edition statements,
and relationships between entities are therefore absent from our
recommendations. The attributes listed in the working group’s guidelines are:
1.
Creator
2.
Culture
3.
Date
4.
Description
5.
Extent
6.
Format
7.
Genre/Form/Style
8.
Identifier
9.
Instrumentation
10.
Language
11.
Location
12.
Publisher
13.
Rights
14.
Title
Usage of
these attributes is presented for each of the following three entities:
1.
The
musical work
2.
Notated
music
3.
Recorded
performances
The “musical
work” is defined here as both an abstract concept (i.e., the canonical Work as
understood in the Western art music tradition) and the interpretation of that
work in a given representation, either in notation or performance. Guidelines
presented for the musical work therefore refer to the content present on a
given item. “Notated music” is defined here as the carrier, physical or
digital, in which the notated musical content is contained, and a “recorded
performance” is similarly defined as the carrier, physical or digital, in which
the performed musical content is contained. This separation of guidelines is
heavily influenced by recent work in the library community to clarify
description of content vs. carrier, and to some degree is influenced by the
Functional Requirements for Bibliographic Records (FRBR)[22]
conceptual model, although the working group’s guidelines do not follow the
FRBR model closely.
The
accompanying document lists the 14 selected attributes, along with:
1.
Definition:
brief explanation of the attribute, specifically for music materials
2.
Usage: general best practices, along with specific
recommendations for the application of the attribute to the description of a musical
work, notated music, and recorded performances
3.
Refinements:
suggested values
4.
Mappings
to common metadata formats (Dublin Core, MODS, EAD, MARC)
Note the
mappings to other metadata formats presented are rarely exact, precise mappings
as general-purpose metadata standards often lack elements in which music-specific
data can be unambiguously recorded.
APPENDICES
APPENDIX 1: Metadata Object Description Schema (MODS)
The Library
of Congress' Network Development and MARC Standards Office, with interested
experts, has developed a schema for a bibliographic element set that may be
used for a variety of purposes, and particularly for library applications. As
an XML schema, the Metadata Object Description Schema (MODS) is intended to be
able to carry selected data from existing MARC 21 records as well as to enable
the creation of original resource description records. It includes a subset of
MARC fields and uses language-based tags rather than numeric ones, in some
cases regrouping elements from the MARC 21 bibliographic format. MODS is
maintained by the Network Development and MARC Standards Office of the Library
of Congress with input from users.
MODS can carry the major data elements from a MARC record
but does not use the MARC tagging that one finds in the MARC XML schema.
Instead, MODS represents key bibliographic data with easily understood element
names such as "title," "name," and "subject."
This makes it more friendly to communities that are not accustomed to the MARC
numeric tagging. MODS can be used to translate MARC records into XML, but it is
also suitable for creating original metadata records. MODS exists in relation
to, but does not replace, MARC XML, and it supports, but is not identical to,
MARC-encoded metadata. It serves well as a bridge between traditional library
applications and bibliographic applications that do not make use of library
cataloging or metadata formats.
MODS was,
in part, a response to the need to have a metadata format that was not specific
to the library community and the MARC standard, but that would have a richer
data element set than Dublin Core. MODS can function as a crossover metadata
format for XML applications that may make use of traditional library cataloging
data together with metadata with other origins. It does not attempt to define
every data element that is found in the MARC record, but rather it has
distilled that record down to a selection of key elements that can serve a
fairly wide variety of metadata needs.
MODS will be modified as the MARC standard changes to maintain parallelism with
the MARC record so that translation from MARC to MODS will be possible. It can
also be modified in response to requests from the community that uses MODS, at
the discretion of the Library of Congress office that is shepherding the MODS
standard.
Advantages:
- MODS was developed with both
digital objects and MARC format firmly in mind, therefore MODS has a high
level of compatibility with MARC records.
- The MODS element set is richer
than Dublin Core and simpler than MARC, yet retains most of the rich
information in MARC. MODS’ language-based tags are easier to work with
than MARC’s numeric ones.
- MODS doesn’t assume the use of
any particular cataloging code. It accommodates record content that is
full AACR2 with authoritative name and subject headings, content
uncontrolled by cataloging rules, the use of alternative content standards
such as Describing Archives: A Content Standard or Cataloging Cultural
Objects, and anything in between. MODS accommodates metadata from a
variety of sources.
- LC offers a number of
stylesheet tools for converting data between Dublin Core, MARCXML and
MODS.
- MODS is able to represent
constituent parts, e.g. a CD with its constituent songs by different
artists on separate tracks, and express relationships among musical works.
- MODS allows for the various
dates associated with sound recordings.
Limitations:
- MODS has the potential to
develop in a number of different directions, depending on feedback from
users. It is not yet a widely used standard with time-tested
implementation, but use is growing.
·
MODS
does not support lossless round-tripability with MARC 21. In other words, an original MARC 21 record
converted to MODS will not convert back to MARC 21 in its entirety without some
loss of specificity in tagging or loss of data. In some cases if reconverted
into MARC 21, the data may not be placed in exactly the same field that it
started in because a MARC field may have been mapped to a more general one in
MODS. In some cases the element in MARC may not have an equivalent element in
MODS and then the specific data could be lost when converting to MODS.
Authority Control
MODS allows
for linking to authority records from elements likely to be under authority
control. In these cases, authority
attribute appears in which a user can enter the code for the authority from
which a term was taken. One could also use the xlink:href attribute to give a
URI that points to a full authority record.
Example:
In LC
authority file:
Rite of spring (Choreographic work)
LCCN: n 94024219
MODS
record:
<titleInfo authority="naf" xlink:href="info:lccn/n94024219"><title>Rite
of spring (Choreographic work)</title></titleInfo>
In
addition, the Library of Congress' Network Development and MARC Standards
Office has drafted the Metadata Authority Description Schema (MADS), an XML
schema for an authority element set that may be used to provide metadata about
agents (people, organizations), events, and terms (topics, geographics, genres,
etc.). MADS was created to serve as a companion to the Metadata Object
Description Schema (MODS). As such, MADS has a relationship to the MARC 21
Authority format, as MODS has to MARC 21 Bibliographic – both carry selected
data from MARC 21. In the future, one will be able to use the MODS xlink:href
attribute for a URI in the MADS namespace.
MODS Examples
I. Samples
from MODS site
For an
example of a score:
http://www.loc.gov/standards/mods/v3/mods85753651.html
(public version)
http://www.loc.gov/standards/mods/v3/mods85753651.xml
(coded)
For a list
of MODS records in a variety of formats:
http://www.loc.gov/standards/mods/mods-guidance.html
II. Sound
Recording (Library of Congress)
http://lcweb2.loc.gov/diglib/ihas/loc.natlib.ihas.200003802/mods.xml
III. Sheet
Music(
Resources
Digital
Library Federation/Aquifer Implementation Guidelines for Shareable MODS Records
<http://www.diglib.org/aquifer/dlfmodsimplementationguidelines_finalnov2006.pdf>
“Primers in
Standards.” Computers in Libraries 24/2
(Feb. 2004), 18+
MADS: Metadata Authority Description
Schema Official Web Site <http://www.loc.gov/standards/mads/>
MODS: Metadata Object Description
Schema Official Web Site <http://www.loc.gov/standards/mods/>
MODS User
Guidelines <http://www.loc.gov/standards/mods/v3/mods-userguide.html>
APPENDIX 2: MODS & Music
Materials
Scores: Important
Elements MODS
Element
024: Other Standard Identifier <identifier>
International Standard Music Number
(ISMN) type=”ismn”
028: Publisher Number <identifier>
Plate Number type=”music
plate”
Other Music Number type=”music
publisher”
041/546: Language of Sung/Spoken
Text <language><languageTerm>
and
<note>
type=”language”
130/240/730:Uniform Title <title><titleInfo>
type=”uniform” and
130/240/730 $n: Part Number <partNumber>
130/240/730 $p: Part Name <partName>
246: Varying Form of Title
(including <title><titleInfo>
type=”alternative”
First Line of Text/Chorus)
300: Physical Description (crucial
elements <physicalDescription>
<extent>
are presence of parts and
accompanying material)
306/500: Duration <note>
type=”duration”
4xx/8xx: Series <relatedItem>
type=”series”
505: Contents <note>
type=”contents”
6xx $t: Name/Title Subject <subject><name>
<titleInfo><title>
7xx $t/740 _2: Constituent Parts
(analytics) <relatedItem>
type=”constituent”
Roles of contributors <name><role><role
term> type=”text”
Cover illustration information could
include <note> about image and
illustrator,
<name><role> for illustrator,
<subject>
of image
Collection and manuscript attributes collection=”yes”
manuscript=”yes”
Sound Recordings:
Important Elements MODS
Element
024: Other Standard Identifier <identifier>
International Standard Recording
Code (ISRC) type=”isrc”
Universal Product Code (UPC) type=“upc”
028: Publisher Number <identifier>
Issue Number type=”issue
number”
Matrix Number type=”matrix
number”
Other Music Number type=”music publisher”
Videorecording Number type=”videorecording
identifier”
033/518: Date/Time & Place of
Event <originInfo><dateCaptured> and
(e.g. broadcast, recording) <note>
type=”venue”
041/546: Language of Sung/Spoken
Text <language><languageTerm>
and
<note>
type=”language”
045: Time Period of Content <originInfo><dateCreated>
(i.e., Date of Composition)
130/240/730:Uniform Title <title><titleInfo>
type=”uniform” and
130/240/730 $n: Part Number <partNumber>
130/240/730 $p: Part Name <partName>
246: Varying Form of Title <title><titleInfo>
type=”alternative”
300: Physical Description (crucial
element is <physicalDescription> <extent>
accompanying material)
306/500: Duration <note>
type=”duration”
4xx/8xx: Series <relatedItem>
type=”series”
505: Contents <note>
type=”contents”
511: Performer Note