CIMI Consortium for the Interchange of Museum Information

CIMI: Consortium for the Interchange of Museum Information Dublin Core (DC) Metadata Testbed Lynn Ann Underwood July 1999 Museum Records Manager Solomon R. Guggenheim Museum

What is CIMI? z“A group of institutions and organizations that encourages an open standards-based approach to the management and delivery of digital museum information. ” z. Formed 1990. z. Recent Projects: y. Z 39. 50 y. IIM (Integrated Information Management) y. Dublin Core (DC) Metadata Testbed

Metadata? What Are We Talking About? z Metadata is a fashionable term. z Used to describe People, Places, & Objects (Resources). z Structured data about data. y Cataloguing, indexing, documentation is one type of Metadata. z Commonly associated with electronic and networked information. y Databases & Web Pages z CIMI’s definition acknowledges museums document objects/items, collections, programs, staff, etc. . z Purpose for CIMI is information retrieval.

How is Metadata Used? z. Information Retrieval y. Fielded searching facilitates resource discovery. z. Document Administration z. Rights Management z. Sales & Service z. Security & Authentication z. Archival Status

Metadata as part of a Resource Description Community z A resource description community is characterized by common semantic, structural and syntactic conventions used for the exchange of information. z Through the use of detailed standards MARC & AACR 2 the library community promotes interoperability. z While the art community formed the Art & Architecture Thesaurus (AAT) and the Categories for the Description of Works of Art (CDWA), specifically the art museum community can use these in addition to metadata to share resources.

Why Use Dublin Core? z A useful tool to refine web searching. z Repurpose information that already exists. z It is easier to adopt an interdisciplinary standard already in use. z Interoperability: Allows different communities (libraries, archives, businesses, museums, etc. ) to search for data using a common basis. z Establishes a basis for next-generation projects.

Interoperability z. Semantics y. The meaning of the elements z. Structure yhuman-readable ymachine-parseable z. Syntax ygrammars to convey semantics and structure Resource Description Communities (e. g. DC, AACR 2) HTML MARC RDF (XML)

The Dublin Core z Title z Creator z Subject z Description z Publisher z Contributor z Date z Type z Format z Identifier z Source z Language z Relation z Coverage z Rights

DC “Simple” z “Simple” or unqualified DC is comprised of the 15 elements with no further content definition. z Current “simple” definitions are based on IETF (Internet Engineering Task Force) RFC 2413 document. z The CIMI working group resisted the temptation to move directly to qualified DC. z Instead CIMI rigorously tested DC “Simple” and it is considered the primary application testing “Simple”. z This process heightened the group’s awareness for the need for qualifiers (element & value).

DC Qualified z Qualified adds descriptive precision in retrieving a resource. This is achieved through the development of a substructure. For instance “Role” is a desired term to further describe, or “qualify”, the CREATOR element. y Creator=Name. Creator Role=Artist z Qualified also allows for terms to be drawn from controlled vocabularies (LCSH, AAT) or classification schemes (DDC). The use of hierarchies provides further definition (semantic specificity). y Guggenheim family -- art patronage z Caution of using DC Qualified is that elements must degrade gracefully to preserve interoperability.

DC Qualified z DC Qualified is a currently under development by DC Working groups. z Working Groups: y DC- Agents (Creator, Contributor, Publisher) y DC-Coverage y DC-Date y DC-Format y DC-Relation (Source, Relation) y DC-Subdesc (Subject Description, Language) y DC-Title (Title, Identifier) y DC-Type y *no working group for rights

DC Requirements z. All 15 DC elements are optional. z. All 15 DC elements may be repeated. z. Proposed changes to the 15 core elements must be made through the framework of the DC working group.

DC Requirements 1: 1 Principal z “. . . one object (or collection), resource, or instantiation can only be described within a single metadata record. ” z 1: 1 is not formally adopted. z This principal, along with the DC Type field, assists with description of the resource. z RDF (Resource Description Framework) reinforces the 1: 1 rule.

XML: e. Xtensible Markup Language z. Based on SGML. z. Encoding syntax. z. Tools under development.

RDF: Resource Discovery Framework z. A scaleable or “extensible” data model. z. It provides a framework for exchanging different types of metadata. y. Types of Metadata (GLIS, INDECES, IMS) z. Intended to be machine generated and understandable. z. The Request for Comment (RFC) was announced in March 1999

The Dublin Core Serves as a Filter DC. title DC. creator DC. subject DC. . . A User Dublin Core ‘filter’ A Resource mapping/ crosswalk

Using DC “Simple”, we can map data from detailed records directly to the Dublin Core. Creator Artist’s Name Type of Work Period depicted Place depicted. . . Subject Coverage. . . Surname Forename Title. . .

Why DC for Museums z. Museum community requires a method to access databases with different underlying schemas because the community historically lacks content standards. z. Web provides museums with an opportunity to share with other museums, libraries, archives, individuals, through the use of commonly understood semantics.

What is Museum Specific? z. Emphasis on attributes of physical objects. z. Associate physical object with persons, places, and events. z. Need to describe items, collections, institutions, people, and events. z. Need to account for surrogates such as photographs.

Museum Metadata Model

CIMI Assumptions for Museums z DC is appropriate for use in describing both physical and digital resources. z DC is easy to learn and simple to use: Is it usable by non -cataloguers? z Information can be meaningfully and efficiently extracted from existing museum systems in order to populate DC records. z The creation of a DC record to describe a museum is cost -effective. z DC aids the discovery of resources more than access to the underlying Collection Management System might.

CIMI Identifies DC Challenges for Museums z. Tension: functionality and simplicity. z. Tension: extensibility and interoperability. z. Human and machine creation and use. z. Community-specific functionality, creation, administration, access.

Testbed Participants z. Involvement of over 18 participants both 1998 & 1999. y. Access Providers y. Software Vendors y. Technical Support Personnel y. Content Providers x. Cultural Heritage x. Art x. Natural History

Guggenheim Records z. The Guggenheim has approximately 5, 600 records in an Access database. z Of the 15 DC Elements only a handful could be mapped.

Guggenheim Records z Due to the fact that Guggenheim records scarcely populated the 15 DC elements, my methodology to test DC elements was to build 134 records from scratch. z This process of creating more robust records helped identify documentation projects, such as the addition of subject terms, etc. z It also helped address information integration issues within the museum.

Guggenheim Records z Creating Object, Collection, Institution, & Event records required information to be brought together from different departments. y For object records I combined information from the database with data from the curatorial and registrar files. y Data for collection records was drawn from electronic and paper files in addition to our web site. y Institution records were created using our web site and print catalogue information. y For event records I used exhibition publications, brochures, and our web site.

Guggenheim Contribution z The 134 full or “rich” records describe individual artworks, collections, the museum, and events. z Also contributed were over 5, 600+ collection records exported from the collection database. z Intended to be an exporting routine, most museums may find, as we did, that their DC records are not very robust. z By providing the testbed with both rich and sparse records further user testing will benefit.

Testbed Products z. Guide to Best Practice: Dublin Core z http: //www. cimi. org/documents/meta_bestprac>VO 31. html y. Drafted Winter 1998 y. Peer Review Spring 1999 y. Published Summer 1999 z. Over 300, 000 record repository y. Contains museums, collections, artifacts y. DC “Simple” records both created by hand or exported from legacy systems.

Outcomes z DC is (sort of) easy to use. z DC works for museum information. z DC is a machete, not a Scalpel. z Further evaluation is necessary. z Need to express more complexity. z Can be mapped to other standards. z Community will require guidance. z 15 “simple” elements will work for museum data. z Lose ability to express complexities (dates). z Non-intuitive fielding of information (materials, methods, techniques, and creators of surrogates. )

Outcomes: CIMI Institute z Responses included: y Need for more concrete examples, DC, XML, RDF. y Would like guidance on how to implement including storage strategies for archiving, retrievablity and architecture. y Fuller description of tools. y More discussion on cost. y Practical examples from the end user’s perspective. What does this look like to the user who is searching for the resource (delivery mechanism).

Summary z. DC is useful for museum information needs. z. Qualification of DC is developing. z. Web Infrastructure is developing (HTML, XML, RDF). z. Tools are beginning to appear and evolve. z. Interoperability testbeds are underway.

WWW Infrastructure Evolving z Resource Description Framework (RDF) ywill allow rich metadata semantics for documents yhttp: //www. w 3. org/RDF/ z Extensible Markup Language (XML) ywill allow highly structured documents and rich linking (relationship) capabilities yhttp: //www. w 3. org/XML/ z Uniform Resource Names (URNs) ywill allow for persistent, globally unique identifiers

Resources z. DC Home Page yhttp: //purl. org/dc z. Metadata Matters yhttp: //www. nla. gov. au/meta z. IFLA Metadata Resources page yhttp: //www. ifla. org/II/metadata. ht. z. Dlib Magazine (all DC workshop reports)

Resources z. Dublin Core Homepage yhttp: //purl. org/dc z. Proposed Recommendation of the DC Metadata Initiative yhttp: //purl. org/dc/elements/1: 1 y. Modifications to this document will replace RFC 2413 z. RFC 2413 yhttp: //www. ietf. org/rfc 2413. txt

Resources: Metadata Tools z. DC Dot (UKOLN) yhttp: //www. ukoln. ac. uk/metadata/dcdot z. Reggie (DSTC) yhttp: //metadata. net y The aim of the Reggie Metadata Editor is to enable the easy creation of various forms of y metadata with the one flexible program. As it stands, the Reggie applet can create metadata using the y HTML 3. 2 standard, the HTML 4. 0 standard, the RDF (Resource Description Framework) format y and the RDF Abbreviated format.

Resources: Metadata Tools z. Nordic DC Metadata Template yhttp: //www. lub. lu. se/cgi-bin/nmdc. pl z. CORC (OCLC) yhttp: //purl. oclc. org/corc

Resources: Metadata Tools z. SEED (Search Engine Evaluation & Development), University of Wolverhampton y. Researched the automatic classification of web pages, initial work focused on Dewey Decimal Classification yhttp: //scitsd. wlv. ac. uk: 8080/metadata. html

DC Example Record

DC Example Record

DC Dot Dublin Core Generator <link rel="schema. DC" href="http: //purl. org/dc"> <meta name="DC. Title" content="GUGGENHEIM MUSEUMS"> <meta name="DC. Publisher" content="CERFnet"> <meta name="DC. Type" content="Text"> <meta name="DC. Format" content="text/html"> <meta name="DC. Format" content="550 bytes"> <meta name="DC. Identifier" content="http: //www. guggenheim. org">

DC Dot Dublin Core Generator: RDF <rdf: RDF xmlns: rdf="http: //www. w 3. org/1999/02/22 -rdf-syntax-ns#" xmlns: dc="http: //purl. org/dc/elements/1. 0/"> <rdf: Description about="http: //www. guggenheim. org" dc: title="GUGGENHEIM MUSEUMS" dc: publisher="CERFnet" dc: type="Text" > <dc: format> <rdf: Bag rdf: _1="text/html" rdf: _2="550 bytes" /> </dc: format> </rdf: Description> </rdf: RDF>

DC Dot Guggenheim Enhanced (1 of 2) <rdf: RDF xmlns: rdf="http: //www. w 3. org/1999/02/22 -rdf-syntax-ns#" xmlns: dc="http: //purl. org/dc/elements/1. 0/"> <rdf: Description about="http: //www. guggenheim. org Solomon R. Guggenheim Museum" dc: title="Solomon R. Guggenheim Museum" dc: creator="Guggenheim, Solomon R. " dc: subject="Bilbao, Spain Berlin, Germany New York, USA Venice, Italy Guggenheim, Solomon R. artworks Krens, Thomas Kandinsky, Wassily Brancusi, Constantin Calder, Alexander Chagall, Marc Delaunay, Robert Klee, Paul Miro, Joan Picasso, Pablo Hilla von Rebay Foundation Museum of Nonobjective Painting Thannhauser, Justin K. Thannhauser, Hilde Guggenheim, Peggy Guggenheim Collection Panza di Biumo, Giuseppe Robert Mapplethorpe Foundation Mapplethorpe, Robert Conceptual art Twentieth Century post-1945 fine arts styles and movements nonobjective art organizations, nonprofit Art Museums Solomon R. Guggenheim Foundation Messer, Thomas M. Thannhauser collection"

DC Dot Guggenheim Enhanced (2 of 2) dc: description="The Solomon R. Guggenheim Museum is comprised of five related museums. In addition to the New York City Fifth Avenue location, there is also Guggenheim So. Ho, NYC, Guggenheim Bilbao, Spain, Deutsche Guggenheim, Berlin, and the Peggy Guggenheim Collection, Italy" dc: publisher="Solomon R. Guggenheim Museum" dc: contributor="Thannhauser, Justin K. Thannhauser, Hilde Guggenheim, Peggy Panza di Biumo, Giuseppe Messer, Thomas M. Krens, Thomas Rebay, Hilla Von Sweeney, James Johnson" dc: date="1920" dc: type="Text Image Sound Place Physical Object Original Collection Cultural" dc: relation="Is. Part. Of Solomon R. Guggenheim Foundation References http: //www. guggenheim. org" dc: rights="Solomon R. Guggenheim Museum" > <dc: format> <rdf: Bag rdf: _1="text/html" rdf: _2="550 bytes"/> </dc: format> </rdf: Description> </rdf: RDF>

Thank You! Lynn Ann Underwood Museum Records Manager Documentation & Records Solomon R. Guggenheim Museum 575 Broadway, 3 rd floor New York, NY 10012 -4233 lunderwood@guggenheim. org Telephone: (212) 423 -3871 Telefax: (212) 360 -4340