metadata for music: issues and directions

METADATA FOR MUSIC: Issues and DirectionsAuthor(s): Sherry L. VellucciSource: Fontes Artis Musicae, Vol. 46, No. 3/4 (July-December 1999), pp. 205-217Published by: International Association of Music Libraries, Archives, and Documentation Centres(IAML)Stable URL: http://www.jstor.org/stable/23509267 .

Accessed: 15/06/2014 22:07

Your use of the JSTOR archive indicates your acceptance of the Terms & Conditions of Use, available at .http://www.jstor.org/page/info/about/policies/terms.jsp

.JSTOR is a not-for-profit service that helps scholars, researchers, and students discover, use, and build upon a wide range ofcontent in a trusted digital archive. We use information technology and tools to increase productivity and facilitate new formsof scholarship. For more information about JSTOR, please contact [email protected].

.

International Association of Music Libraries, Archives, and Documentation Centres (IAML) is collaboratingwith JSTOR to digitize, preserve and extend access to Fontes Artis Musicae.

http://www.jstor.org

This content downloaded from 185.2.32.121 on Sun, 15 Jun 2014 22:07:42 PMAll use subject to JSTOR Terms and Conditions

http://www.jstor.org/action/showPublisher?publisherCode=iaml

http://www.jstor.org/action/showPublisher?publisherCode=iaml

http://www.jstor.org/stable/23509267?origin=JSTOR-pdf

http://www.jstor.org/page/info/about/policies/terms.jsp


METADATA FOR MUSIC Issues and Directions

Sherry L. Vellucci (St. John's University, New York)

Metadata is data that describes the attributes of a resource, characterizes its relation

ships to other resources, supports the discovery, management, and use of a resource,

and exists in an electronic environment. Many different metadata sets exist, ranging

from general schemes to accommodate information in a wide variety of disciplines and formats, to highly specialized schemes designed for specific formats or subject communities. Common issues relating to all schemes include the lack of clear

descriptions for multiple "states" of a resource, conflict between discovery and

description functions, difficulty in describing aggregate resources, and lack of man dated standards for data content. The Dublin Core Element Set, fast becoming the

accepted metadata standard in the library community, must resolve these issues

before it can be the ideal metadata scheme to describe music resources. The Resource Description Framework (RDF), with its reference to linked authorities, may provide the optimal framework for implementing a variety of metadata to

describe music resources in a global network.

The term metadata has crept into the vocabulary of most librarians, music and

non-music, cataloguers and non-cataloguers. It has the power to enthrall

because it holds so much promise. Metadata will organize the Internet; it will

promote interdisciplinary research on a global scale; it will accommodate the

description of as yet unknown formats; it will provide unprecedented control

over electronic resources; and while doing all this, it will enhance the power and, therefore, the reputation of those who create it. Does the reality of meta

data live up to these promises? For now, at least, the answer is no. But move

ment in the metadata direction is fast indeed, and music librarians cannot afford

to be left behind in this brave new world of information organization. Unless we

take a leadership role in the development of music metadata, other less knowl

edgeable people will make the rules by which we must eventually play. Does this mean that all of the detail-laden MARC records will be converted

into simple Dublin Core metadata records? Probably not! But music librarians

will be creating and cataloguing more and more electronic resources, includ

ing digital facsimiles of music treatises, scanned images of music scores, sound files of archival recordings, and videos of staged productions. Along with these new digitized resources comes the ability to embed metadata with

in these digital objects, or link metadata descriptions directly to the files. The

205



206 FONTES ARTIS MUSICAE 46/3-4

MPEG-41 and the developing MPEG-72 ISO standards allow metadata to be embedded within multi-media objects using a synchronized metadata track.

Already libraries are migrating to integrated library systems (ILS) that can contain and simultaneously search several metadata databases. Thus, music librarians will not only need to understand a variety of metadata schemes in order to enable data interchange within their own systems, but will be respon sible for creating metadata records in formats other than MARC. A firm under

standing of the important issues in metadata development will assist in this transition.

The Current State of Affairs

The most common definition of metadata is "data about data." This is a simple and accurate definition, but it needs a bit more elaboration. The term "meta data" began to appear frequently in the literature on database management systems (DBMS) in the 1980s, and was used to describe the information that documented the characteristics of information contained within databases.3 In this DBMS domain the computer was the setting for both the information

being described and the descriptive data, and, therefore, metadata operated within a totally electronic environment.

The parallel world of library cataloguing traditionally used the terms "bibli

ographic data" or "cataloguing data" for this type of descriptive information, even when describing computer files. But when cataloguers began to describe networked electronic resources using the exact same type of bibliographic data, things changed. Suddenly the MARC record became "metadata." What happened to cause this transformation? The answer is: convergence with the broader world of information organization. The methods of organizing resources from the rather separate domains of library science, computer sci

ence, and information science all converged in this networked environment, and, for better or worse, the term "metadata" became the commonly accepted term in all three disciplines. On the plus side, metadata provides a common term to use when communicating with other information organizers in the computer and information science world. It allows everyone to interact

equally on the continuum of information organization. This equality is impor tant for the development of bibliographic systems that access, transfer, and

manipulate metadata information across multiple databases in a way that pro vides meaningful information to the user. On the down side, the term "meta data" allows information organizers in the computer and information science domains to continue to ignore not only the efficient and effective process of

"cataloguing" that developed over the last century but also the very large body

1. International Organisation for Standardisation. "MPEG-4: Overview (Melbourne Version)." Web page, October 1999 [accessed 4 January 2000]. Available at http://www.cselt.stet.it/mpeg/ standards/mpeg-4/mpeg-4.htm.

2. International Organisation for Standardisation. "MPEG-7: Context and Objectives (Version 10)." Web page, October 1998 [accessed 4 January 2000], Available at http://www.cselt.stet.it/

mpeg/standards/mpeg-7/mpeg-7.htm. 3. John T. Phillips, "Metadata: Information About Electronic Records," ARMA Records

Management Quarterly 29, no. 4 (1995): 52-57.



METADATA FOR MUSIC: ISSUES AND DIRECTIONS 207

of cataloguing literature that already exists on many of the so-called "metadata issues" under discussion today.

In order to place metadata within its proper context, the following expanded definition, which incorporates statements of functionality and environment, is used. Metadata, therefore, is data that:

• describes the attributes of a resource (name, title, publisher, dates, etc.)

• characterizes resource relationships (Is Based on, Is Version of, Contained in)

• supports resource discovery, management, and effective use (descriptive data, administrative data, terms and conditions data, intellectual property rights data, content ratings data, provenance data, structural data), and

• exists in an electronic environment.4

Although this definition reflects the metadata ideal, in reality most metada

ta schemes do not accomplish all of these functions equally well. Descriptive data come in a variety of levels and detail. Metadata schemes designed for use

by the general Internet-user public tend to concentrate on very basic data for

resource discovery and retrieval (e.g., HTML <META> Tags). libraries prefer more detailed descriptions that act as surrogates for the object (e.g., MARC

records). Only a few metadata sets express relationships adequately, although

implementation of the Resource Description Framework (RDF) as a formal

structural standard may change this in the future.5

Traditionally, metadata in library catalogues focused on the functions of

identification, description, and retrieval; but other metadata categories extend

into the areas of resource management and use. These include administrative

and structural data, terms and conditions data, content ratings data, and prove nance data. The extent to which any particular metadata set incorporates these

data categories varies depending on the needs of the community responsible for its development, and there are many such communities. Each group devel

oped its own metadata scheme to describe the resources most used by its

constituency. Some of these metadata schemes are general in nature—such

as the MARC format and the Dublin Core Metadata Element Set—and are

designed to accommodate information about electronic resources in a wide

variety of disciplines. Other metadata schemes are more specialized and apply to information in a specific format or within a specific discipline or domain.

What they all have in common is that they contain a set of defined data e

lements that describe the resource and help provide access to it in the elec

tronic environment. Beyond that, they all vary as to the number and content of

the data elements, and the standards used, if any, for that content.

4. Sherry L. Vellucci, "Metadata," m Annual Review of Information Science and Technology, ed.

by Martha E. Williams, 33 (1999): 187-222. (Medford, NJ: Information Today for the American

Society for Information Science, 1999.)

5. World Wide Web Consortium (W3C). "Resource Description Framework (RDF)." Web

page, December 1999 [accessed 5 January 2000]. Available at http://www.w3.org/RDF/ Over

view.html.




Metadata Characteristics

All metadata schemes have three basic characteristics: semantics (or content),

syntax, and structure. The semantics can vary from many complex data elements

with content prescribed by standards and rules, to schemes that have as little as two or three elements with no control at all over that content. The syntax

may range from a highly complex coding system like the SGML to a basically undefined record structure like the original Dublin Core. Finally, metadata can be contained in a variety of architectural structures, including library cata

logues, Microsoft Access databases, or the recently formalized RDF standard. In addition to these three characteristics, there are three other aspects of

metadata that are the new buzzwords in digital information organization: flexi

bility, interoperability, and extensibility. Flexibility allows the metadata creator to include as much or as little detail as desired in the metadata record, within the overall constraints of the metadata scheme, with or without adherence to

specific cataloguing rules or authoritative lists.

Interoperability refers to the ability of information systems to interact in a useful way on a real-time basis over communications networks.6 For the sake of interoperability, many believe that metadata records should contain a basic core set of data elements common to all schemes. This would facilitate the

exchange and use of metadata in a variety of systems, and is the basic premise of the Dublin Core. Crosswalks offer a way to map the data elements from one metadata scheme to another and are a major part of the interoperability factor. Several crosswalks currently exist to map the MARC format to and from other

popular metadata schemes such as the Dublin Core.7 On the surface, cross walks appear to provide a simple means of exchanging data, for example the

DC.Title element maps to the 245 field in USMARC; however, few things in the world of metadata are as simple as they seem. No metadata crosswalks work

equally well in both directions. Mapping fifteen data elements into MARC may not seem difficult, but mapping a standard MARC record into fifteen simple Dublin Core elements presents a real challenge.

The final buzzword, extensibility, means that the scheme should allow the addition (i.e., extension) of data elements and data qualifiers to accommodate

specific user needs (domain specific). The danger with extensible data is a

lessening of interoperability, because the more that general metadata elements are qualified or extended on an individual or domain specific basis, the less

compatible or interoperable the metadata becomes with other schemes.

Metadata and the Music Community

While many subject-specific communities have developed their own metadata

schemes, the music community has not chosen that route as yet. Instead, most efforts have focused on evaluating the effectiveness of one general scheme,

6. Christine L. Borgman, "From Acting Locally to Thinking Globally: A Brief History of

Library Automation," The Library Quarterly 67, no. 3 (1997): 215-49.

7. Michael Day, "Metadata: Mapping between Metadata Formats," Web page, February 1999

[accessed 5 January 2000]. Available at http://www.ukoln.ac.uk/metadata/interoperability/.




the Dublin Core Metadata Element Set, as a means for the description and retrieval of music resources.8 Taking the lead in this area was the Performing Arts Data Service (PADS), a division of the Arts and Humanities Data Service in Great Britain, with many IAML members active in the project.9 The PADS

project raised several practical and theoretical issues of importance to the music community, some of which are being addressed by the developers of Dublin Core. Many of these and other issues are, in fact, common to a wide range of metadata schemes; but since the Dublin Core seems to be the

"metadata-of-the-moment," I will use it as the context for this discussion. Fast becoming the metadata scheme of choice for general library use, the

Dublin Core (DC) was developed within an international and interdisciplinary environment through the collaboration of various Internet communities, includ

ing librarians, computer engineers, text scholars, and most recently, the intellec tual property rights community. The Dublin Core semantics (i.e., content) was

kept simple because it was designed for authors of Web-documents to generate their own metadata.10 The development goal was to define a basic level of descrip tive data for Web sites that provided more information than just the keywords that were common in Web document headers, but was less complex than MARC

bibliographic records. This basic data could then be imported into any more

complex metadata structure (like MARC), and be used as the basis for building a richer description of the resource. The fifteen elements, many of which corre

spond, or map, to data in traditional catalogue records, are divided among three information categories: Content (Title, Subject, Description, Source, Language, Relation, Coverage), Intellectual Property (Creator, Publisher, Contributor,

Rights), and Instantiation (Date, Type, Format Identifier). There are currently no mandatory rules governing the Dublin Core Element

Set, which was designed for simplicity and flexibility. All elements are optional; all elements are repeatable; the order of elements is optional; and all elements can be qualified. Initially, the Dublin Core was designed to be syntax indepen dent, that is, no rules of grammar were mandated for the data so that the ele ments could be used in many different environments; but implementation of DC

projects required a syntax that could be used consistently on the World Wide Web without changes to existing Web standards and software. HTML <META>

tags were adopted by many early projects as the preferred syntax, and are cur

rently in the process of becoming a formalked standard; however, since

approval of the Resource Description Framework (RDF) as a structural stan

dard by the World Wide Web Consortium (W3C), XML has become the rec

ommended syntax for use with the more sophisticated RDF architecture.11

8. "Dublin Core Metadata Initiative," Web page, January 2000 [accessed 4 January 2000].

Available at http://purl.org/DC/index.htm. 9. "The Performing Arts Data Service," Weh page, 1998 [accessed 4 January 2000]. Available

at http://www.pads.ahds.ac.uk/padsWebNet98.html. 10. Stuart L. Weibel, "The Dublin Core: A Simple Content Description Model for Electronic

Resources," Bulletin of the American Society for Information Science 24, no. 1 (1997): 9-11. Also

available at http//www.asis.org/Bulletin/Oct-97/weibel.htm. 11. Eric Miller, "An Introduction to the Resource Description Framework," D-Lib Magazine 4,

no. 5 (May 1998). Available at http//www.dlib.org/dlib/may98/miller/05miller.html.




Metadata Issues

While the fifteen basic elements of the Dublin Core have remained stable for three years now, virtually all applications of the Dublin Core elements have

adopted element qualifiers to accommodate more specific resource description than the basic model supports. This highlights the paradox that exists in the

DC community: on the one hand, the more elements and element qualifiers that are added, the less interoperable the data become; on the other hand, no one is really satisfied with the quality and level of description afforded by the basic element set. There are several important issues at the root of this prob lem, none of them new to the cataloguing community. These include:

• Lack of clear descriptions for multiple "states" of a resource, i.e., work,

expression, manifestation, and item. This issue involves the question: What state of the resource is being described?

Conflict between two different metadata functions, i.e., resource discov

ery and description. This issue involves the question: Can one core set of metadata serve two functions?

• Difficulty in describing aggregate resources. This issue involves the

question: At what level of granularity is the resource being described?

• Lack of mandated standards for data content. This issue involves the

question: Is authority control necessary for the description of Web-based resources?

As the PADS Workshop participants found, these issues present both theoret ical and practical problems that result in confusion when creating the metada ta record, and lack of precision in the description. Just when many specialized groups were beginning to despair of these issues being addressed adequately for their purposes, an unlikely ally appeared in the form of the Intellectual

Property Rights community.12 With this new and powerful group arguing for

many of the same descriptive details and standards as the library community, albeit for very different reasons, the Dublin Core developers began to sit up and take notice. The following discussion takes a closer look at the theoretical issues and some of the practical solutions that are being addressed by the Dublin Core metadata community.

State of the Resources Issues

Early on, those trying to apply the Dublin Core elements to the descriptions of actual resources had problems deciding on exactly what it was they were

describing. For example, the DC Date element seems straightforward enough, but exactly what date should be given? For a recording of the Mendelssohn

12. David Bearman, Eric Miller, Godfrey Rust, Jennifer Tränt, and Stuart Weibel, "A Common

Model to Support Interoperable Metadata," D-Lib Magazine 5, no. 1 (1999). Available at

http//www.dlib.org/dlib/january99/bearman/01bearman.html.




What is being Described?

Work

Expression

Manifestation

Abstract State

Tangible State Item

What is being Described?

Work

Expression

Manifestation

Abstract State

Tangible State Item

FIGURE 1

Octet, is this the date the Octet was composed? Or the date the performance was captured? Or the date the recording was originally issued? Or the date it

was digitized and mounted on the network? All of these dates represent valid

information that applies to different states of this resource's existence. The

IFLA (International Federation of Library Associations) model identified four

states of a resource as outlined in the Functional Requirements of the

Bibliographic Record,u These include the work, the expression, the manifesta

tion, and the item. Although there is still some confusion and perhaps dis

agreement over the model, it is generally agreed that the work and expression exist in an abstract state, while the manifestation and the item exist in a tangi ble state (see Figure 1). To give an example, if we choose a Mozart symphony as the work under consideration, its expression could occur either in sound or

in notation; a manifestation could be a performance or an edition, while the

item level could be represented by a specific CD or score.

In order for a resource description to be useful, it must be clear which state

of the resource is being described, and the descriptive data must be associated

with that appropriate state in some way. The current Anglo-American Cata

loguing Rules alleviate some of the ambiguity by requiring that the manifesta

tion be described in the body of the record, the work be described with access

points, and the specific item be described in notes.14 While reducing confusion

over what is being described, the end result is a single MARC record in which

some data elements describe the work, some data elements describe the par

ticular manifestation of an expression of that work, and some data elements

13. International Federation of Library Associations and Institutions. Study Group on the

Functional Requirements for Bibliographic Records. Functional Requirements for Bibliographic

Records. München: K. G. Saur, 1998. Also available at http//www.ifla.org/VII/sl3/ffbr/frbr.pdf.

14. Anglo-American Cataloguing Rules, Eds., Michael Gorman and Paul W. Winkler. 2nd edi

tion; 1998 revision. Chicago, IL: American Library Association, 1998.




Resource Discovery vs. Description

Work High Recall Resource Discovery

Expression

Manifestation

Item

Resource Description

High Precision

Resource Discovery vs. Description

Work

Expression

Manifestation

Item

High Recall Resource Discovery

Resource Description

High Precision

FIGURE 2

describe a specific copy of the manifestation, all without clear indications as to which data are describing which state of the resource. This data model, which worked well for flat files with linear access such as card catalogues, has hin dered the development of new database structures for computerized cata

logues. Surprisingly, the basic Dublin Core data model, designed in a hyper text environment without the constraints of flat file access, fell victim to similar

inadequacies in describing the state of a resource, without the benefit of the guidance afforded by the cataloguing code. This problem could be solved by a one-to-one relationship between the descriptive metadata and the particular state of the resource being described. On the positive side, because of its sim

plicity, flexibility, and the small amount of existing Dublin Core legacy data

compared to the vast number of MARC records, the Dublin Core developers are able to work much more rapidly to solve the problem.

Resource Discovery and Description Issues

A tension has always existed between the two catalogue functions of resource

discovery and description. In order to discover or retrieve all relevant

resources, i.e., to obtain high recall, we need to describe at a high state, usu

ally at the level of the work or the expression. But in order to find the exact resource required, i.e., to obtain high precision, we need to describe at a much lower state, usually the manifestation or item level (see Figure 2).

As a core element set, the Dublin Core is really designed for high-level resource discovery, i.e., high recall. It is becoming increasingly clear, however, that once retrieved, searchers need metadata that can provide accurate and de tailed descriptions of resources in order to select the desired object efficiently. Thus, there is one faction of the Dublin Core community arguing for few and simple data elements to obtain the best recall and maintain a high level of inter




FIGURE 3

operability, while another part of the community is calling for more detailed

descriptions to obtain the best precision, even though this may mean sacrificing some interoperability. A solution to this problem may be found with new inte

grated library systems containing a variety of metadata databases that might use basic Dublin Core elements for the resource discovery aspect of a search, then link to records that provide richer resource descriptions when needed.

Level of Granularity Issues

Another persistent issue that presents problems for the creation and use of

metadata is the level of analysis for the description (often referred to as gran ularity) . Traditionally, bibliographic descriptions focus on the physical object and describe the whole entity at the summarization level. Many of these items are unified entities meant for linear access and there is no need to describe each section independently. The cataloguing rules do provide the option to

analyze contents and create separate descriptions when desired, and this

option is frequently used to describe the individual works on a sound record

ing. On the other hand, cataloguers rarely deal with description at the collec

tion level; that is usually the domain of archivists.

Electronic resources, however, present additional difficulties for deciding on the level of analysis for description. Web sites often consist of many indi

vidual parts that can stand alone, be used separately, and, therefore, be

described separately. Many sites consist of aggregates of images, texts, jour nals, or sound files (see Figure 3).

These sites might be described as aggregate collections, as single entities, as parts of single entities, or in any other way that may be useful to a searcher.

Determining the appropriate level of description and distinguishing between levels of description to insure intelligible assessment of search results can be




problematic.15 Data models are needed that can represent both hierarchical and associative relationships with a fairly simple syntax and architectural structure. One solution to this problem is the fuller development of relation

ship metadata that can express clearly the associations and connections between separately described resources.

Authority Control Issues

Ultimately, the success or failure of the retrieval process for any metadata scheme rests on issues of authority control and data content standards, and these are certainly of great importance to music libraries. The ability of libraries to incorporate and use multiple metadata schemes in current library systems will depend on the compatibility of imported data with existing OPAC data. But even beyond the OPAC, authority control will play an important role in metadata interoperability.16 In order to perform a successful high-level search for music resources using Dublin Core elements, there must be some measure of authority control over titles and names. This raises the question: Are the overarching metadata principles of flexibility, interoperability, and

extensibility, which are so important to the metadata community at large, in conflict with the principles of authority control?

Flexibility has two aspects: flexibility in the amount of metadata and flexi

bility in the content. Flexibility in terms of the amount of metadata detail does not present problems for authority control. The varying levels of description prescribed by the AACR and the various Core Cataloguing Records already demonstrate this. Flexibility with regard to data content and form, however, does make authority control very difficult indeed. The descriptive rules, authority lists, and data registries used by different metadata schemes must be

identified, and options provided for metadata selection and mapping among dif ferent authorities.

In terms of interoperability, authority control becomes an issue when meta data from various sources and in various formats must be integrated and

manipulated for efficient use. While crosswalks allow data transfer from one metadata scheme to another, they focus on transfer architecture and syntax and do not address interoperability in terms of the standards used for data con tent and form. Thus, authority controlled data is not a requirement for the

physical transfer of the data, even though it would certainly improve the data

compatibility aspect of interoperability. Extensibility is not necessarily a problem for authority control, although, as

mentioned earlier, it does create other problems for interoperability. Some schemes are being augmented and refined to include more elements, more data qualifiers, and a more complex structure. In fact, many of the data quali fiers being added to metadata schemes such as the Dublin Core are designed

15. Willy Cromwell-Kessler, "Dublin Core Metadata in the RLG Information Landscape," D-Lib

Magazine 3, no. 12 (December 1997). Available at http//www.dlib.org/dlib/december97/ 12cromwell-kessler.html.

16. Sherry L. Vellucci, "Metadata and Authority Control," Library Resources and Technical

Services 44, no. 1 (2000), Forthcoming.




to support the use of authoritative data for names and subjects, and to indicate the authoritative sources for controlled information. Thus, extensibility can

actually enhance metadata authority control. Another factor for successful metadata authority control, and one that is an

integral part of the RDF structure, is reference to authoritative lists. In the RDF metadata model these authoritative lists, or data registries, provide meta metadata that may be used to 1) identify the metadata type from among vari ous schemes; 2) verify and validate a particular metadata's semantics and syn tax; 3) verify the agency that created the metadata; 4) verify specific standards used for data content and form; 5) identify specific resources; and 6) exchange data elements among metadata packages. These authority links are necessary not only because of the variety of metadata schemes, but also because of the

many different content standards and subject lists used in various disciplines. This data model, therefore, will require extensive building of authoritative data

registries and extensive relationship modeling.

Future Directions for Dublin Core and IAML

So, what are the developers of the Dublin Core doing to address these issues and problems? Four areas are currently under discussion for improvement, some of which will move the Dublin Core in the direction of a more stable metadata scheme.17 These include 1) formalization of the Dublin Core mainte nance process; 2) standardization of the element set; 3) development of a

mechanism for additions to data qualifiers; and 4) implementation of the Resource Description Framework.

Formalization and Standardization

Begun informally as a workshop on resource description, the Dublin Core

developers are moving towards providing an explicit process and organiza

tional structure for decision making. The new structure is headed by the

Dublin Core Directorate, which oversees the Dublin Core Policy Advisory Committee and the Technical Advisory Committee, and maintains the official

Dublin Core Web site. Working Groups may be formed to address particular

problems with elements (e.g., Date or Format), or clusters of problems (e.g.,

relationship modeling). The structure is similar to other agencies such as the World-Wide-Web Consortium (W3C) or the Internet Engineering Task Force

(IETF). Additionally, the Directorate created a formal process for ratifying

changes to the Dublin Core with input from various communities.

There will be some slight modifications to the Dublin Core prior to the next

stage of formalization, which is submission to both NISO (National Informa

tion Standards Organization) and CEN (Center for European Normalization) for status as an official standard. First, the data element definitions will be

reviewed to improve clarity and promote more consistent application. Second,

17. Stuart L. Weibel, "The State of the Dublin Core Metadata Initiative," D-Lib Magazine 5, no.

4 (1999). Available at http://www.dlib.org/dUb/april99/04weibel.html.




the Dublin Core will be formatted according to ISO 11179, a standard for for

mally expressing the semantics of data elements in a standard manner.

Qualification Mechanisms

Data element qualification is the second area in need of improvement. From the outset, the many specialized communities such as performing arts and music made it clear that a mechanism to refine, or qualify, the metadata ele ments was essential for precision in resource description. The ability to add

qualifiers to the Dublin Core elements would improve the metadata scheme in a number of ways. It would 1) increase semantic specificity by allowing con trolled vocabularies or classification schemes to be identified and used for either description or as a formal browsing structure; 2) allow authority con trolled data to identify a name or title (e.g., DOI, SICI, BICI, ISBN, ISSN, ISWC, etc.) uniquely; and 3) allow definition of a formal substructure so that

compound values can be assigned to one element, e.g., Creator Value Name can have subelements such as e-mail address, affiliation, etc. Thus, data ele ment qualifiers will allow improved precision. It is the database structure and record architecture, however, that provide another level of meaning to these data by allowing specific data values to be identified clearly and associated with

specific functions, roles, or actions. This is the area that will benefit from imple mentation of the Resource Description Framework.

Resource Description Framework

The Resource Description Framework became an Internet standard in

February 1999. RDF is a set of conventions for expressing metadata that uses extensible Markup Language (XML) as an encoding standard and provides a framework for exchanging metadata. Resources are identified by a Uniform Resource Identifier (URI) and each resource has properties that describe it. By using the XML-namespace facility, RDF associates each property with its asso ciated metadata schema that defines that property, thus allowing data elements from different metadata schemes to reside together without confusion or con flict. The ability to specify metadata schémas in RDF makes it possible for

applications to access a particular scheme from a publicly accessible registry on the Web and retrieve the parsing structure and semantics of the element set. These link authorities have the potential to allow the development of rela tional systems that are only dreamed of currently with MARC. Figure 4 shows a very simple example of a metadata record that uses the RDF structure.

IAML and Future Music Metadata

If the Dublin Core is moving in the direction of formalization, standardization, increased descriptive data, and authority controlled data elements, in other words toward cataloguing data as we know it, are we just reinventing the wheel? I think the answer is "no," because although the semantics and syntax of Dublin Core are becoming more stable, they are designed for use within a structural data model that will allow the computer to do what it is good at: com




RDF Example 1

"IAML Presentation"

"Sherry L. Vellucci"

<?XML version»'1.0'?> <rdf:RDF xmlns:rdf="http://www.w3.org/TR/REC-rdf-syntax#"

xmlns:dc»"http://purl.org/dc/elements/1.0"> <rdf:Description rdf:about="URI:P">

<dc:title>IAML Presentation</dc:title> <dc:creator>Sherry L. Vellucci</dc:creator>

</rdf:Description> </rdf:RDF>

RDF Example 1

"IAML Presentation"

"Sherry L. Vellucci"

<?XML version='1.0'?> <rdf:RDF xmlns:rdf="http://www.w3.org/TR/REC-rdf-syntax#"

xmlns:do"http://purl.org/dc/elements/1.0"> <rdf:Description rdf:about="URI:P">

<dc:title>IAML Presentation</dc:title> <dc:creator>Sherry L. Vellucci</dc:creator>

</rdf:Description> </rdf:RDF>

FIGURE 4

putation and connectivity. This, in turn, gives us the potential to develop inte

grated library systems containing multiple databases that use multiple meta data schemes, employ sophisticated relational linkages, and provide unified interfaces without beginning from scratch.

So, where does this leave the music library community? Since anyone can

develop metadata and register it as an RDF schema, IAML's Cataloguing Commission could develop the metadata extensions and qualifiers necessary to describe music resources adequately, as the PADS project has already done to some extent, and declare these as an official RDF schema. LAML could

actively participate in this project by being the organization that officially main tains the schema. In addition, IAML could act as the clearing house for music metadata projects worldwide, allowing music librarians who are new to the metadata arena to benefit from the work and experience of their colleagues around the world.



metadata for music: issues and directions

Documents