A Simple Universal Metadata Schema for the Preservation, Discovery, and Rights Management of Digital Audio (SUMS AUDIO)

For Dr. Tibbo

Butch Lazorchak
INLS 210
March 18, 2003

Introduction

	Coming to terms with various metadata schemas for audio can be a daunting task.  The number and variety of schemas is infinitely varied, ranging from the overwhelmingly complex schema of MPEG-7 (Moving Pictures Expert Group), a metadata standard for describing multimedia content data that is suited for rigorous applications, to schema created on the fly by casual audio producers which might include artist, title and little else. 
	Audio has been identified as one of the "killer aps" of the internet; the popularity of networked audio is now beyond question, and commercial opportunities abound.  However, one difficulty that has prevented commercial producers, amateur users and university researchers from coming together is the lack of a unified descriptive language for digital information that can be communicated across the networked environment. Additionally, this unified language needs to be simple enough for the home user to apply to files created on their own computers, but sophisticated enough for librarians, archivists and other information professionals to utilize for their important preservation, discovery, and rights management purposes. 
	Each domain of knowledge which calls audio its own has created a metadata schema to portray audio in its own image.  What has heretofore been missing is a simple schema which provides the appropriate level of complexity required to accurately describe the material, but which is also user-friendly in a way that provides for wide adaptation. 
	The many differing audio metadata schemas are designed for different purposes: support for preservation, discovery, music information retrieval, and digital authenticity are just a few of many possible support purposes. Are musical pieces organized and searchable by date, style, composer, melodic theme, performance, performers, length, genre, storage medium, or all of these? Before determining an appropriate audio metadata schema, the support purposes must first be defined. 
	The SUMS AUDIO metadata schema is designed to support many purposes, but is most appropriately applied to experimental work in digital libraries. It is in digital libraries that the issues of preservation, discovery and rights management find their sternest tests. Metadata designed to support preservation, discovery, and rights management is the range of metadata ideally suited to support the core descriptive, structural and administrative needs of common creators and user of digital audio. Thus, the relatively simple metadata schema proffered here could also have wide applicability in the consumer realm.   
	
Purposes Defined

	In order to determine the metadata elements necessary to support the core purposes introduced above, the concepts of preservation, discovery and rights management in our instance must first be defined. For preservation, it is helpful to examine the work of the Open Archival Information System (OAIS) model:

	Preservation metadata is the information infrastructure that supports the processes 	associated with digital preservation. More specifically, it is the information 	necessary to maintain the viability, renderability, and understandability of digital 	resources over the long-term. Viability requires that the archived digital object’s 	bit stream is intact and readable from the digital media upon which it is stored. 	Renderability refers to the translation of the bit stream into a form that can be 	viewed by human users, or processed by computers. Understandability involves 	providing enough information such that the rendered content can be interpreted 	and understood by its intended users. Preservation metadata can serve as input to 	preservation processes, and also record the output of these same processes.

For discovery, we can look to the work of Paul Conway for clarification:

	In the digital world, preservation is the action and access is the thing – the act of 	preserving access...Preserve access to what? The answer suggested in this chapter 	is: a high quality, high value, well-protected, and fully integrated digital product 	that is derived from but independent of original source documents. The content, 	structure, and integrity of the digital product assume center stage – and the ability 	of a machine to transport and display this product becomes an assumed end result 	of the preservation action rather than its primary goal.

For rights management, the issues are more complicated. On one side are the creators and originators of digital objects who have a strong economic interest in protecting their investment.  On the other side is the general public (including libraries and archives) with a strong interest in full access to digitized materials.   Duke law professor James Boyle writes often on the subject of intellectual property in cyberspace:

	Who is affected by the politics of intellectual property? Many groups are, though 	they might not see it that way. Some of the most innovative software engineers 	have objected to the extension of patent law to cover their products; they fear it 	will help create an oligopolistic software market and diminish 	inventiveness...Environmentalists wish that some of the profits on patented 	pharmaceuticals drawn from the rain forest could be returned to protect their 	source. Religious organizations protest the patenting of living organisms.  
	Each group is complaining about an intellectual property system that has 	expanded out of control. Yet they don't see those complaints, or their interests, as 	linked. Part of the problem is that we have not adapted our public debate to the 	realities of the information age. Censorship we understand. But the subtler forms 	of control imposed by ownership of information? These are harder to discuss.  

	While the broad purposes of preservation, discovery and rights management are the overriding goals of the SUMS schema, it is important to note that any complete schema will also have to address each of the three main categories of metadata: descriptive, administrative and structural metadata.  The SUMS schema includes metadata which applies to each of these subject areas. 

Survey of the Literature

	There are several high-level metadata schemas that must be considered at the outset.  One high-level schema, the emerging Metadata Encoding and Transmission Standard (METS) developed by the Digital Library Federation and supported by the Library of Congress AV Project, provides high-level metadata information. The METS schema proposes to define metadata elements for complex digital objects, including multiple instantiations of individual items.  Its focus on aggregate objects puts it outside our current scope of  inquiry, though its identification of the complex construction of digital items and their web of interrelationships (the idea that a record album in the digital world is a multi-part object which includes the audio file along with the digitized album cover image) is an important model worthy of further investigation. The SUMS purpose is to provide the metadata elements necessary to fully encapsulate a single digital item, while recognizing that there is greater complexity in the world. The METS schema successfully addresses this complexity.
	The METS standard can incorporate any other metadata schema desired, and one of the most widely disseminated is the Dublin Core (DC) metadata schema.  The DC is a standard for cross-domain information resource description, with an information resource defined to be anything that has identity. By definition it is designed to be broadly applicable, and this breadth is both a blessing and a curse. DC is useful for identify core elements common to all complete metadata schemas, but its failing is its inability to fully account for the core elements of individual domains of knowledge.
	In the realm of intellectual property rights, the <indecs> Metadata Framework, a project of Muze, Inc., the International DOI Federation and others, is working on metadata solutions to intellectual property rights issues. 
	In more audio-centric realms, the Library of Congress has devised an audio-visual metadata schema for the digital material housed in their new Culpepper, Virginia audio-visual repository. Even more detailed is the richly descriptive schema of MPEG-7, though its complexity makes it too unwieldy to stand on its own for our purposes. Other organizations have identified their own metadata schemas, or have suggested elements appropriate for consideration. Metadata schemas considered include those from the Michigan State University Digital and Multimedia Center; the Library of Congress' Digital Audio-Visual Preservation Prototyping Project; the Colorado Digitization Project; the Indiana University Digital Music Library Project; the Audio Engineering Society's Radio Traffic Audio Delivery Extension to the Broadcast-Wave-File Format; and the RLG Preservation Metadata Element set, in addition to those mentioned above.

Elements Defined

	Specific metadata elements were gathered from the sources enumerated above, and then were evaluated. It soon became clear that the Dublin Core metadata schema could be used as the basic container architecture for SUMS.  For the most part, it has been possible to fit the SUMS requirements into the Dublin Core (utilizing DC refinements in places), though further research in the SUMS schema may omit or alter this reliance on Dublin Core. All of the chosen elements reflect the Dublin Core namespace with the exception of the element ORIGINATOR.  This element is similar to the Dublin Core element of  PUBLISHER. However, the European Broadcast Union element of ORIGINATOR was chose because PUBLISHER is a somewhat conflicted term, especially in the realm of intellectual property rights.
	We introduce each element, define its purpose (utilizing the European Broadcasting Union's EBU Core Metadata Set for Radio Archives), note any refinements and suggest important information that should be included under each element. The elements are listed in lower case as prescribed by the XML standards. 
	In addition, while defining each individual field, we also place it within the broad conceptual metadata areas of description, administration and technical.  This information is found in the Table of the Elements in Appendix One.

The format is: <name of element>(Established metadata schema which provides the source of the element name).  [Determination as to whether the element can be repeated or not.] [Element required or optional?]

1. <title> (DC). A name given to the resource. [Single item] [Required]

2. <creator> (DC). An entity primarily responsible for making the content of the resource. This would be analogous to "artist," and includes one DC sub-element
	<creator.role> This would include a further refinement of the creator into terms such as artist, singer,  [Repeatable] [Required]

3. <subject> (DC). The topic of the content of the resource.  Typically, the subject will be expressed as keywords. Recommended best practice is to select a value from a controlled vocabulary or formal classification scheme. Due to the specialized requirements of audio description at the commercial level, one non-DC sub-element has been included:
	<subject.genre> (rock, jazz, classical, etc.) [Repeatable] [Optional]

4. <originator> (EBU). The ORIGINATOR is the entity that has made the resource available in digital form. ORIGINATOR encapsulates the OAIS concept of responsible agency, and could include anyone from a single individual to a large corporation. [Single item] [Optional]

5. <contributor> (DC). An entity responsible for making contributions to the content of the resource. This would include any other named persons who added value to the work, including the producer, fellow musicians, etc. Includes one DC sub-element
	<contributor.role> [Repeatable] [Optional]

6. <date> (DC)-A date associated with an event in the lifecycle of the resource. Typically, DATE will be associated with the creation or availability of the resource. This element includes two non-DC sub-elements [DC has the qualifiers ISSUE and CREATED in the DC-LIB application profile, but they don't seem to accurately represent what we're shooting for here.]
	<date.creation_date>-the original date an audio work was created [single item]
	<date.digitization_date>-the date that the item was digitized by its "originator" [Repeatable] [Required]

7. <format> (DC). The physical or digital manifestation of the resource, which would include MIME types. Many of the most important aspects of FORMAT come under the one DC sub-element 
	<format.extent> FORMAT.EXTENT represents the size or duration of the resource. It is highly recommended that FORMAT.EXTENT include values for these specific format options: file size, duration (in a time format), sampling_frequency (in kilohertz), bit rate (in bits per sample), channel_track_quantity (number of different audio channels), data_rate (in kilobits), and sound_field (indicates the aural space arrangement of the sound, i.e., mono, stereo, etc.), encryption [Repeatable] [Required]

8. <identifier> (DC). 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. We are mainly thinking of a Handle System URN here, but other unique identifiers could be included, including original company's label number. It is highly recommended that the IDENTIFIER element include a value for the checksum (or another error-correction value), as well as the checksum type and date. [Repeatable] [Required]

9. <language> (DC). A language of the intellectual content of the resource.  [Repeatable] [Optional]

10. <coverage> (DC). The extent or scope of the content of the resource, including spatial location (a place name or geographic coordinates), temporal period (a period label, date, or date range) or jurisdiction.  With two DC sub-elements
	<coverage.spatial> For geographic description.
	<coverage.temporal> For time period description [Repeatable] [Optional]

11. <rights> (DC). Information about rights held in and over the resource, including detailed copyright declarations. It is highly recommended that the RIGHTS element includes values for these specific options, including the appropriate date information:  Permissions (a relation which is allowed by an agreement, for example, a Creative Commons license which states explicitly how the digital item can be used); copyright_holder_composition; copyright_holder_sound_recording. [Repeatable] [Optional]

The following DC fields are not included in SUMS:
Description [covered fully by SUBJECT]
Publisher [this is being replaced by ORIGINATOR due to the imprecise usage of the term PUBLISHER in the world of intellectual property]
Type [covered fully by SUBJECT and FORMAT]
Source [the source identifier information will be included as part of the Identifier element]
Relation [we are considering individual items at this time and not fully considering them as part of more complex digital objects]
Appendix One: Table of the Elements

Element Name	Sub-Elements	Type of Metadata (Descriptive, Administrative or Structural)	Allowable information type (i.e., ASCII text, numeric, date with ISO number)	Possible Element Encoding Schemes	Is the field repeatable or Single item?	Item Required or Optional?	
		
title		Descriptive	ASCII text (ISO 646)		Single Item	Required	
creator	role	Administrative	ASCII text (ISO 646), numeric	MARC Relator Codes for ROLE found at http://www.music.indiana.edu/
tech_s/manuals/training/marc/relator.html
Also
Library of Congress Authorities found at
http://authorities.loc.gov/	Repeatable	Required	
subject	genre	Descriptive	ASCII text (ISO 646)	Any number of possible controlled vocabularies, including DCMI Type vocabulary	Repeatable	Optional	
originator		Administrative	ASCII text (ISO 646)	Library of Congress Authorities found at
http://authorities.loc.gov/	Single Item	Optional	
contributor	role	Administrative	ASCII text (ISO 646)	MARC Relator Codes for ROLE found at http://www.music.indiana.edu/
tech_s/manuals/training/marc/relator.html
also
Library of Congress Authorities found at
http://authorities.loc.gov/	Repeatable	Optional	
date	creation_date
digitization_date	Structural	Date information	Typically yyyy-mm-dd format (ISO 8601), but could also be DCMI Period Encoding Scheme or the W3C Date and Time format (DTF)	Repeatable 	Required	
format	extent	Structural	ASCII text (ISO 646), numeric	10 ASCII characters contain the time duration of the sound sequence in the format <<hh:mm:ss:d>>. Other standards for other aspects of FORMAT including Internet Media Types list found at 
http://www.isi.edu/in-notes/iana/assignments/media-types/media-types.	Repeatable	Required	
identifier		Administrative	numeric	Handle System URN, UMID, ISRN, ISAN	Repeatable	Required	
language		Structural	ASCII text (ISO 646)	Recommended best practice is defined by RFC 1766, which includes a two-letter Language Code (taken from the ISO standard 639), followed optionally by a two-letter Country Code (taken from ISO standard 3166).	Repeatable	Optional	
coverage	spatial
temporal	Descriptive	ASCII text (ISO 646), numeric	Spatial: ISO 3166, Getty Thesaurus of Geographic Names, DCMI Point Encoding scheme
Temporal: DCMI Period Encoding scheme, W3C Date and Time Format	Repeatable	Optional	
rights		Administrative	ASCII text (ISO 646), numeric		Repeatable	Optional	

Further Reading

1. Dublin Core Library Application Profile http://dublincore.org/documents/2002/04/16/library-application-profile/
2. Indiana University Variations2 Digital Music Library Project Data Dictionary: Metadata Elements for Version 1
http://variations2.indiana.edu/pdf/DML-metadata-elements-v1.pdf
3. California Digital Library Digital Object Standard: Metadata, Content and Encoding
http://www.cdlib.org/about/publications/CDLObjectStd-2001.pdf
4. <indecs> RDD White Paper: A Standard Rights Data Dictionary
http://www.doi.org/topics/indecs-rdd-white-paper-may02.pdf
5. Audio-Visual Prototyping Project Data Dictionary for Metadata-Capture Database: Logical View
http://lcweb.loc.gov/rr/mopic/avprot/datadict.html
6. Michigan State University Digital and Multimedia Center Digital Audio Specifications
http://www.lib.msu.edu/vincent/specifications.htm
7. MPEG-7 Overview
http://www.mpeg-industry.com/mp7a/w4980_mp7_Overview1.pdf
8. Metadata Encoding and Transmission Standard (METS): An Overview & Tutorial
http://www.loc.gov/standards/mets/METSOverview.html