|
|
About
the Project
|
| |
The Sheet Music Consortium
is a group of libraries working toward the goal of
building an open collection of digitized sheet music
using the Open Archives Initiative:Protocol for Metadata
Harvesting (OAI:PMH).
Harvested
metadata about sheet music in participating collections
is hosted by UCLA Digital Library Program, which
provides an access service via this metadata to
sheet music records at the host libraries. For technical
details of the harvesting process and service, consult
the Project Timeline and
Technical Overview. Member
institutions and data providers have chosen to catalog
their sheet music in different ways, but a very
large proportion of the original sheets in participating
collections has been digitized, allowing users direct
access to the music itself and — in many cases
— covers and advertisements that offer evidence
of the cultural context in which the songs were
published.
For a definition of sheet music
and a review of other sheet music digitization projects,
consult the sheet music on
the web section.
The Sheet Music Consortium welcomes
participation from curators of collections of sheet
music, whether in the US or other countries. Inquiries
should be addressed to Stephen
Davison, chair of the project team. |
| |
|
| |
Project
Staff
|
| |
| Steering
Committee |
|
Stephen Davison,
Music Librarian for Special Collections,
UCLA (Chair) |
|
Stephen H. Schwartz, Head of Library Information
Systems Development, UCLA |
|
Kristine R. Brancolini,
Director, Digital Library Program, Indiana
University |
|
Cynthia Requardt,
Kurrelmeyer Curator of Special Collections,
Johns Hopkins University |
|
Lois Schultz, Head of Monographic Cataloging, Duke University |
| Programmers |
|
Curtis
Fornadley, Digital Library Lead Programmer,
UCLA
(OAI Service and Sheet Music Virtual Collections) |
|
David Reynolds, Metadata Librarian, Johns Hopkins
University |
|
Kurt
W. Whitsel, Programmer, Indiana University |
|
Will Sexton, Programmer,
Duke University |
| Darrow
Cole, Programmer, Library Information Systems,
UCLA |
| Technical
Support, Design, and Editing |
|
Teal Anderson, Usability
and Focus Group Consultant, Johns Hopkins
University |
|
Michelle Dalmau,
Interface and Usability Specialist, Indiana
University |
|
Jenn Riley, Digital Media Specialist,
Digital Library Program, Indiana University |
|
John Riemer, Head of Cataloging, Young
Research Library, UCLA |
|
Howard Batchelor,
Digital Library Coordinator, UCLA |
|
| |
|
| |
Data
Providers
|
| |
Collections
Indexed
| Library of Congress, Music Division |
47,528 records |
| Rare Book, Manuscript, and Special Collections
Library, Duke University |
20,157 records |
| Lilly Library, Indiana University |
17,937 records |
| Maine Music Box |
11,779 records |
| Lester Levy Collection, Johns Hopkins University |
11,590 records |
| National Library of Australia |
6,731 records |
| UCLA Music Library |
4,593 records |
|
| |
|
| |
Information
for Data Providers
|
| |
The
Consortium welcomes prospective data providers who
wish to make metadata for their sheet music collections
available for harvesting by the principles of the
Open Archives Initiative Metadata Harvesting Protocol
(OAI-PMH). These guidelines are merely recommendations:
we would be glad to discuss details via email. This
section addresses: Collection Policy, OAI Standard
Implementation, Planning Data Mapping, and Testing
Data Harvesting.
Collection Policy
We
are currently accepting collections of metadata
and/or images of sheet music, as opposed to musical
scores and audio collections. We encourage international
contributions, but currently require metadata in
English. Although we can accept sheet music collection
information consisting of metadata only, our goal
is to build an international collection of digitized
sheet music, and we prefer participation by collections
that are in the process of digitizing their sheet
music for online viewing.
OAI Standard Implementation
The technical standard, with
sample code and test sites for data providers, is
defined at the Open Archives Initiative
web site. There are several ways to become a data
provider:
1. Build your own software
according to the standard specifications for OAI-PMH
(version 2). This may be feasible even if your data
is not in a standard format if you have the programming
skills available.
2. Use available OAI software. Several open source
packages are available (see list at the OAI site)
into which you can port your data.
3. Find a collaborator. One of the existing Sheet
Music Consortium data providers may be willing to
host your data. Contact them and ask.
4. Wait for the new standard for encapsulating your
data into a large XML document for harvesting by
a special service (check the OAI site for news).
Planning Data Mapping
The mapping of your metadata
from its native format to Dublin Core will determine
how well it is discovered within the Sheet Music
Consortium OAI Service. Because OAI requires
at least Dublin Core, the project team has developed
guidelines for data mapping. The following is intended
as a guide for mapping existing sheet music data
to unqualified Dublin Core. It is not intended as
a guide for the creation of new metadata, but may
prove useful for planning purposes in conjunction
with other resources for the description of sheet
music. An important guide to sheet music description
is available from the Music Library Association:
Cataloging
Sheet Music: Guidelines for Use with AACR2 and
the MARC Format.
Edited by Lois Schultz and Sarah Shaw. Scarecrow
Press (2003).
(Music Library Association Technical Reports,
28) ISBN 0-8108-47507. |
The first version of the sheet
music harvester will harvest data in the 15 fields
of unqualified Dublin Core: Title, Creator, Subject,
Description, Publisher, Contributor, Date, Type, Format,
Identifier, Source, Language, Relation, Coverage,
Rights.
Each field is repeatable, however, the principal Title
field (as opposed to alternative and subsidiary titles,
first lines, etc.) should appear before other titles
in the record.
The order in which the fields appear is not important
as long as the information is tagged using standard
Dublin Core. For both ease of reading and machine
processing it is recommended that the fields appear
in the order above.
Information that appears in square brackets below
— indicating creator roles, sources of information
etc. — can be included but cannot necessarily
be used by the browsing software of the service application
at UCLA Digital Library.
Because there is a substantial body of sheet
music cataloging that follows the Anglo-American Cataloging
Rules, 2nd ed. (AACR2) the general formatting of data
should follow that standard where possible. Although
we anticipate that formatting will vary from institution
to institution, differences will be few if AACR2
is used as a general guide.
Examples of UCLA Dublin Core records can be found
at:
http://digital.library.ucla.edu/oai/
( 462 records: includes Title, Creator, Description,
Publisher, Date, Identifier, Source, Language, Rights)
http://unitdev.library.ucla.edu/mus_test/apamview/oai/index.cfm
( 970+ records, includes Subject, Type, Format fields
in addition) For advice
on application these standards to existing or new
data contact Stephen Davison at the UCLA Music Library:
sdavison@library.ucla.edu. |
| |
|
| |
Standards
for Mapping Sheet Music Cataloging to Dublin Core
|
| |
Dublin Core
Element Definitions and Guidelines:
Sheet Music Consortium Service, Phase 1
Questions and Examples
Note: Any bracketed descriptor terms should
follow the data.
Title |
A
name given to the resource.
Typically, a Title will be a name by which
the resource is formally known. |
| The
first occurrence of DC.Title must be the main
song title.
Title (and variants),
may also include: first line, first line of
refrain/chorus, and other forms by which the
work might be known.
Recommendation: Following AACR2 capitalization
rules. Omit the statement of responsibility.
April
fool [song title]
Martini [show title]
The Cornell Masque presents Martini [alternative
title]
Poets say, that an April day is much like
the ways of lovers [first line]
Gloomy season, without reason, makes our hearts
seem far apart [first line of chorus]
|
| Creator |
An entity
primarily responsible for making the content
of the resource.
Examples of a Creator include a person, an organization,
or a service. Typically, the name of a Creator
should be used to indicate the entity. |
Composer,
lyricist, arranger. Other contributors, including
illustrator, artist, photographer, etc. Recommend
last name first.
Recommendation: Invert name. Use the authorized
form of name where possible. If needed (e.g.
for an alias) repeat the field for the alternative
form.
Shaw, J. B., Jr. [lyricist]
Stanley, J. Selwyn [composer] |
| Subject |
The topic
of the content of the resource.
Typically, a Subject will be expressed as keywords,
key phrases or classification codes that describe
a topic of the resource. |
Recommended
best practice is to select a value from a controlled
vocabulary or formal classification scheme. Subject
headings, usually from controlled vocabularies
such as LCSH, LCTGM, AAT, etc. Also local vocabularies.
Recommendation: Attempt to map to existing vocabularies
wherever possible.
Songs with piano [LCSH]
Dance [TGM]
Music boxes [TGM] Musical revues & comedies
[TGM]
Women [TGM] |
| Description |
An account
of the content of the resource.
Description may include but is not limited to:
an abstract, table of contents, reference to
a graphical representation of content or a free-text
account of the content. |
Any
descriptive notes concerning the publication.
Includes quotes from the publication concerning
attributions, origins, format, associated performing
artists, etc. Include publisher's number and
plate numbers as notes with standards labels.
Use the labels "Plate number: " and "Publisher
number: " [placed in front] if possible. Persons
associated with the music that are not creators
(e.g. dedicatees, sponsors) can be included
in the description. Descriptive fields may include
a variety of information, with a variety of
labels ("Plate number", etc.). This field would
always be keyword searched, not browsed.
From Irving Berlin's
Music box revue
Lyrics: What a beautiful morning What a wonderful
day We can hear the birds singing As we go on
our way, Like a couple of children, We're so
happy and gay for we've been married two years
now And we're gonna be divorced to day. The
judge is waiting at the court around the corner
for the wife and me With the final decree You'll
see a happy groom and bride Standing side by
side Receiving congratulations When the knot
is untied a foxy lawyer at the court around
the corner will collect his fee the minute we're
free We'll be divorced and then We'll soon be
married again At the court around the corner
the little wife and me
Plate number:
6596-4
Publisher number: 7466 |
| Publisher |
An entity
responsible for making the resource available.
Examples of a Publisher include a person, an
organization, or a service. Typically, the name
of a Publisher should be used to indicate the
entity. |
Place
of publication and name of the publishing person
or corporate entity. Use AACR2 formatting if
possible.
Follow standard AACR2 formatting if possible
(Place followed by Publisher). It is likely
that the place will be split off into a separate
field in the DCQ phase.
New York : Cornell
Masque Ithaca
New York : M. Witmark & Sons |
| Contributor |
Not used.
Use Creator instead. |
An
entity responsible for making contributions
to the content of the resource.
Examples of a Contributor include a person,
an organization, or a service. Typically, the
name of a Contributor should be used to indicate
the entity. |
| Date |
A date
associated with an event in the life cycle of
the resource.
Typically, Date will be associated with the
creation or availability of the resource. Recommended
best practice for encoding the date value is
defined in a profile of ISO 8601 [W3CDTF] and
follows the YYYY-MM-DD format. |
Date
of publication. The most recent date to appear
on the music, or, the actual date of publication
if not present but known. Include other dates
(e.g. date of composition) if known. Codes "c"
for copyright and "ca." for circa in front of
the date is allowed for now.
Use repeated DC fields for each date if needed.1920
[date of publication]
2002-07-17 [date of digitization]
c1902
[ca. 1800]
18-- |
| Type |
The nature
or genre of the content of the resource.
Type includes terms describing general categories,
functions, genres, or aggregation levels for
content. Recommended best practice is to select
a value from a controlled vocabulary (for example,
the working draft list of Dublin Core Types
[DCT1]). To describe the physical or digital
manifestation of the resource, use the FORMAT
element. |
Standard
phrase for this format. Sheet music?
Sheet music
Image
Text data, music
[electronic resource]
Note: "Image" is from the Dublin Core type vocabulary
http://www.dublincore.org/documents/dcmi-type-vocabulary/;
"Text data, music" and "[electronic resource]"
are OCLC/CORC and AACR2 [gmd] terms respectively. |
| Format |
The physical
or digital manifestation of the resource.
Typically, Format may include the media-type
or dimensions of the resource. Format may be
used to determine the software, hardware or
other equipment needed to display or operate
the resource. Examples of dimensions include
size and duration. Recommended best practice
is to select a value from a controlled vocabulary
(for example, the list of Internet Media Types
[MIME] defining computer media formats). |
AACR2
format statement.
MIME type statement.
5 p. of music
1 score (5 p.)
image/tiff
image/jpeg
Note: "image/tiff", "image/jpeg", "application/pdf"
are standard internet media [MIME] types; see:
http://www.isi.edu/in-notes/iana/assignments/media-types/media-types. |
| Identifier |
An unambiguous
reference to the resource within a given context.
Recommended best practice is to identify the
resource by means of a string or number conforming
to a formal identification system. Example formal
identification systems include the Uniform Resource
Identifier (URI) (including the Uniform Resource
Locator (URL)), the Digital Object Identifier
(DOI) and the International Standard Book Number
(ISBN). |
| Supply
an Identifier only when the sheet music exists
in digital form.
URL
for the digital form of the music:
http://digital.library.ucla.edu/sheetmusic/servlet/sheetmusic.LibrarianServlet?ITEMID=IBATC
SOURCE
A reference to a resource from which the present
resource is derived.
The present resource may be derived from the
Source resource in whole or in part. Recommended
best practice is to reference the resource
by means of a string or number conforming
to a formal identification system.
Call number of the physical item.
UCLA. Music Library. Archive of Popular American
Music. SY118524 [call number]
|
| Language |
A language
of the intellectual content of the resource.
Recommended best practice for the values of
the Language element is defined by RFC 1766
[RFC1766] which includes a two-letter Language
Code (taken from the ISO 639 standard [ISO639]),
followed, optionally, by a two-letter Country
Code (taken from the ISO 3166 standard [ISO3166]).
For example, 'en' for English, 'fr' for French,
or 'en-uk' for English used in the United Kingdom. |
Language(s)
of the text of the song and accompanying material.
Use either full name or code. Repeated DC term/line
is recommended if needed.
English [en]
French [fr] |
| Relation |
Optional.
No recommendation. |
A
reference to a related resource.
Recommended best practice is to reference the
resource by means of a string or number conforming
to a formal identification system. |
| Coverage |
The extent
or scope of the content of the resource.
Coverage will typically include spatial location
(a place name or geographic coordinates), temporal
period (a period label, date, or date range)
or jurisdiction (such as a named administrative
entity). Recommended best practice is to select
a value from a controlled vocabulary (for example,
the Thesaurus of Geographic Names [TGN]) and
that, where appropriate, named places or time
periods be used in preference to numeric identifiers
such as sets of coordinates or date ranges. |
| Optional.
No recommendation. |
| Rights |
Information
about rights held in and over the resource.
Typically, a Rights element will contain a rights
management statement for the resource, or reference
a service providing such information. Rights
information often encompasses Intellectual Property
Rights (IPR), Copyright, and various Property
Rights. If the Rights element is absent, no
assumptions can be made about the status of
these and other rights with respect to the resource. |
| Wording
and format determined by copyright holder. e.g.,
(c) 2003. The Regents of the University of California.
All rights reserved. |
Testing Data Harvesting
Once you have tested your
software against the OAI site and have mapped your
data we will harvest it. Please contact UCLA Digital
Library Systems Architect Curtis Fornadley curtisf@library.ucla.edu.
|
| |
|
| |
Project
Timeline
|
| |
The first phase
of the project, which established the service
as a gateway to US collections, contained 78,708 records: 17,417
records from Indiana University, 11,590 from Johns
Hopkins University, 2,173 from UCLA Music Library's
Archive of Popular American Music, and 47,528 from
the Library of Congress. Subsequent harvests have raised
the total to 120,315 records from seven institutions,
as shown in the table above.
| Key Dates |
| Fall and Winter 2001:
Brainstormed the idea of a collaborative sheet
music project based on the Open Archive Initiative
Protocol at Coalition for Networked Information
and Digital Library Federation. Found partners
- UCLA, Johns Hopkins University, Indiana University,
and Library of Congress. A steering team was
formed. |
| March 2002: Held an
open meeting (12 institutions, 24 people) at
Indiana University, drafted a Dublin Core standard
for description of sheet music, and agreed to
proceed with harvesting data. |
| Summer 2002: Build
prototype harvester and harvested test data
from the four data providers. |
| Fall 2002: With support
from the Mellon Foundation, conducted usability
and focus groups at five institutions - Duke
University, Brown University, UCLA, Indiana
University, and Johns Hopkins University. |
| Spring 2003: Redesigned
interface based on study results. |
| July - August 2003:
Testing production release and re-harvesting
data, including new data from Indiana University,
UCLA, and Duke University. |
| September 2003: Version 1.0 release. |
|
| |
|
| |
Technical
Overview
|
| |
Presentation
given at Coalition for Networked Information, December,
2002 by Curtis Fornadley. |
| |
|
| |
Sheet
Music on the Web
|
| |
|
| Last Revised:
June 1, 2006 |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |