Using Dublin Core in Museums Introduction to the

Using Dublin Core in Museums Introduction to the CIMI Guide to Best Practice: Dublin Core Dr. Paul Miller Thomas Hofmann UK Office for Library & Information Networking Australian Museums On-Line p. miller@ukoln. ac. uk thomash@amol. org. au

Overview Ø What is metadata? Ø Introducing the Dublin Core Ø Introducing the CIMI testbed project Ø CIMI DC Guidelines - Guide to Best Practice: Dublin Core Ø Break Ø Practical session Ø Implementation Ø Discussion.

What is Metadata? Ø Meaningless jargon Ø or a fashionable term for what we’ve always done Ø or “a means of turning data into information” Ø and “data about data” Ø and the name of a film director (‘Luc Besson’) Ø and the title of a book (‘The Lord of the Flies’).

What is Metadata? Ø Metadata exists for almost anything Ø people Ø places Ø periods Ø objects Ø concepts Ø The trick lies in making descriptions suitably generic to be meaningful to the majority, whilst suitably controlled to aid location.

What is Metadata? Ø Metadata fulfils three main functions: Ø description of resource content Ø “What is it? ” Ø description of resource form Ø “How is it constructed? ” Ø description of issues behind resource use Ø “Can I afford it? ”.

What is Metadata? Ø A resource description community is characterised by agreed semantic, structural and syntactic conventions for exchange of descriptive information Libraries MARC AACR 2 Based on a slide by Stu Weibel

What is Metadata? Home Pages Scientific Databases Libraries Geo Commerce ‘Internet Commons’ Museums Whatever. . . Based on a slide by Stu Weibel

What is Metadata? Ø Many structures have evolved at different levels, and to meet different requirements. . .

What is Metadata? Semantic Interoperability Standardisation of content “Let’s talk English” Structural Interoperability Standardisation of form “Here’s how to make a sentence” Syntactic Interoperability Standardisation of expression “cat sat on mat drank milk” “Cat sat on mat. Drank milk. ” “These are the rules “The cat sat on the mat. of grammar” It drank some milk. ”

Approaches to Metadata (I) Ø Search Engines üEasy to build üCheap üCover large areas of the Internet. ûPretty stupid, really ûMinimal contextualisation of data is ‘Miller’ the person who made this, the person whom it is about, the profession of a differently named individual, or something else entirely? E. g. Alta Vista, Lycos, Meta. Crawler, Hot. Bot, Excite, Info. Seek, Look. Smart, UK Max. . .

Approaches to Metadata (II) Ø Specialist Resource Description üExtremely detailed üAccurate finding aids üComprehensive. ûExpensive ûDomain specific ûOnly likely to be worthwhile for ‘valuable’ resources. E. g. MARC, FGDC CSDGM, EAD, SPECTRUM. . .

Approaches to Metadata (III) Ø Resource Discovery üRelatively easy to build üRelatively cheap? üContextualises information üEnable semantic mapping across community boundaries. ûInsufficient to meet specialist requirements within a community? E. g. Dublin Core. . .

Opportunities Challenges Ø Many flavours of metadata Ø which one do I use? Ø Managing change Ø new varieties, and evolution of existing forms Ø Tension between functionality and simplicity, extensibility and interoperability Functions, features, and cool stuff Simplicity and interoperability

Introducing the Dublin Core Ø An attempt to improve resource discovery on the Web Ø now adopted more broadly Ø Building an interdisciplinary consensus about a core element set for resource discovery Ø simple and intuitive Ø cross–disciplinary Ø international Ø flexible.

Introducing the Dublin Core Ø 15 elements of descriptive metadata Ø All elements optional Ø All elements repeatable Ø The whole is extensible Ø offering a starting point for semantically richer descriptions Ø Interdisciplinary Ø libraries, museums, government, education. . . Ø International Ø available in 20 languages, with more on the way.

Introducing the Dublin Core u Title u Format u Creator u Identifier u Subject u Source u Description u Language u Publisher u Relation u Contributor u Coverage u Date u Rights u Type http: //purl. org/dc/

Extending DC (semantic refinement) Improve descriptive precision by adding sub–structure (subelements and schemes) Element qualifier Value qualifier Greater precision = lesser interoperability Should ‘dumb down’ gracefully Creator First Name Affiliation Surname Contact Info Based on a slide by Stu Weibel

Extending DC (a modular approach) Ø Modular extensibility. . . Ø additional elements to support local needs Ø complementary packages of metadata Ø …but only if we get the building blocks right Terms & Conditions Description Archival Management Based on a slide by Stu Weibel

Extending DC? Ø DC offers a semantic framework Ø through use of further substructure, meaning can often be clarified <Creator> “Paul” <fore name> “Paul” Paul Inc. ? Paul xyz ? xyz Paul ? ûPaul Inc. üPaul xyz ûxyz Paul.

Extending DC? Ø DC offers a semantic framework Ø Use of domain–specific schemes greatly increases precision <Coverage> “Washington” <TGN> “Washington” Washington State ? Washington DC ? Washington monument ? üWashington State ûWashington DC ûWashington monument “North and Central America, United States, Washington” http: //gii. getty. edu/tgn_browser/

Dublin Core in 1999 Ø Formalise the process Ø TAC, PAC, Directorate and Working Groups Ø Refinement of definitions Ø DC 1. 1 Ø Qualification semantics Ø consensus and streamlining Ø RDF Ø Common understandings Ø INDECS/DOI Ø IMS ?

Formalisation Dublin Core Directorate Dublin Core Web Site purl. org/dc/ DC Policy Advisory Committee Stakeholder Communities DC Technical Advisory Committee Working Groups DC-General Dublin Core Mail Server www. mailbase. ac. uk/lists/dc–general/ Based on a slide by Stu Weibel

Introducing the CIMI testbed project (I) Ø Testbed Phase I Ø Goals Ø Evaluate feasibility of DC for museum community Ø Identifying and resolving operational, technical and intellectual issues Ø Promote international consensus on DC practices in museum community Ø Milestones Ø Involvement of over 18 participants (Software vendors, Museums, Consultants, Cultural Heritage Gateways) Ø Over 300, 000 record repository (museums, collections, artefacts) using DC Simple, both created from scratch and exported from legacy systems Ø Guide to Best Practice: Dublin Core Ø Outcomes Ø DC is easy to use Ø DC simple is a machete, not a scalpel Ø All Elements depend on Resource Type Ø DC can be applied to both physical and electronic resources Ø Further user evaluation necessary

Introducing the CIMI testbed project (II) Ø Testbed Phase II Ø Goals Ø Ø Ø Finalisation and publication of “Guide to Best Practice: Dublin Core” Identification of proposed qualified elements (sub–structure) Examination of RDF Initial effort in mapping DC elements to CIMI Access Points User evaluation Ø Milestones Ø There are four meetings scheduled for 1999. Please see http: //www. cimi. org/ for updates on the testbed phase II Ø Outcomes Ø The schedule for 1999 for sees the following deadlines: Guide publication (April) DC recommendation (December) DC to CIMI Access Points mapping (November) RDF examination (July) Choreographed demonstration/ user evaluation (October) Final report and recommendations (December) Ø For updates please see http: //www. cimi. org/

Dublin Core and the museum community Ø Challenges for museums Ø Emphasis on attributes of the physical object (artefact) Ø Need to associate the physical object with persons, places and events Ø Need to account for collections Ø Need to account for surrogates such as photographs Ø Historical lack of content standards Ø Assumptions regarding DC Ø DC is useful to describe artefacts and associated information resources in the museum community Ø DC is simple to use and learn Ø Adequate technical infrastructure exists to support use of resource discovery

The ‘ 1: 1 Principle’ - What does it mean? Ø Definition: Only one object, resource or instantiation described with one single record Ø Interpretation: object DC records surrogate Ø Conclusion: Makes describing original and surrogates easier

DC record relationships DC record institution DC record artefact DC record collection DC record story DC record artefact slide

Reality Check: Criteria for DC creation Ask yourself: Ø Is the record itself (and each element within that record) useful for resource discovery? Ø Is the value of the element known with certainty? Is it readily available from existing databases or information sources? Ø Have you selected values from enumerated lists recommended to assist in cross domain searching? If not, leave it out If not, interoperability degraded and records harder to maintain

About the Guide to Best Practice: Dublin Core Ø Basis for the Guide: Ø Based on Dublin Core 1. 0 (RFC 2413) Ø Recommendations based on testbed experience, not large scale production efforts Ø Syntax used in examples and testbed based on XML Ø Document structure: Ø 15 DC simple elements starting with TYPE to assist in following the 1: 1 rule (original vs. surrogate) Ø Each element: - Introduced with standard DC Definition (RFC 2413) - Explained with CIMI Interpretation - Manifested with CIMI Guideline - Illustrated through Examples Ø Appendices contain sample records for different types of museum describing a variety of resource types

Element: Type Ø Interpretation: The nature of the resource, including such aspects as originality, aggregation and manifestation. Ø Guideline: â Helps to decide the values of other elements â To aid in searching across collections and across different disciplines among museums, specify TYPE from: 1. List of controlled values maintained by the DC community: text, image, sound, dataset, software, interactive, physical object, event and the following list of museum-related values: 2. original or surrogate 3. item or collection 4. natural or cultural â list elements in the order as above for consistency reason (Note: element order is irrelevant in Dublin Core)

Element: Format Ø Interpretation: The properties of the resource that impose the use of tools for access, display, or operation; not the tools themselves. Do not use FORMAT if no tools are required. Ø Guideline Ø Use to populate element - with MIME type information for digital resources - with details of technique, material and media for analogue resources Ø Don’t use to describe: - limitations to access or restrictions against usage RIGHTS - dimensions DESCRIPTION

Element: Title Ø Interpretation: Name(s) given to the resource, regardless of whose they are — so long as they are useful for resource discovery. Ø Guideline Repeat TITLE element as required Ø Untitled works of fine art: : use whatever value you would use on the wall label copy, exhibition catalog, or other promotional material—i. e. , if the work is known as “Untitled, ” specify this in TITLE Ø Cultural items and collections: with no known title or name, use a term or phrase that is sufficiently descriptive to permit a user to judge relevancy. If your existing database does not contain title information, concatenate other descriptive field values as appropriate to “name” the resource Ø Natural specimens: use Latin binomial name of the animal, plant, or mineral, should contain the name that is given to the object in hand by the person identified in CREATOR. These two elements plus the DC. DATE thus give a full citation for the specimen, and allow for the possibility that the same specimen can have different names allocated by the same, or different, taxonomists at different times.

Element: Description Ø Interpretation: A textual, narrative description of the resource, including abstracts for documents or content characterizations in the case of visual resources Ø Guideline Ø Use this element whenever possible, as it is a rich source of indexable vocabulary. Emphasize the contextual information and popular associations (people, places, and events) of the resource Ø If a single “description” field does not exist in your current database, values from other fields or wall label copy, exhibition catalogs, didactic copy, etc. may be concatenated to populate DESCRIPTION Ø DESCRIPTION is likely a display field with the resource in the search result set, we recommend brevity but not so as to sacrifice richness.

Element: Subject Ø Interpretation: Keywords about theme and/or concept of the resource, as well as terms signifying significant associations of people, places, and events or other contextual information. Ø Guideline Do not strictly interpret the element name “Subject, ” which tends to lock our thinking into formal “subject terms” such as those used in bibliographic metadata. “Keywords” is a more appropriate interpretation of the kind of values that are useful for this element— index terms, or descriptors, rather than specific-to-broad categorizations of intellectual content.

Element: Creator Ø Interpretation: The person(s) or organization that conceived or initiated the resource. For example, author of written document; artist, photographer, or illustrator of visual resource; or founder of an institution. For natural specimens, CREATOR specifies the determiner; the person who created the name that is present in the TITLE element.

Element: Contributor Ø Interpretation: A person or organization not specified in a Creator element because their contributions to the resource are less direct or conceptual (for example, editor or translator). Also used for patrons, benefactors, and sponsors. For natural specimens, the collector and preparator are example values.

Element: Publisher Ø Interpretation: The person(s) or organizations responsible for making the resource available or for presenting it, such as a repository, an archive, or a museum. Also includes major financial supporters and legislative entities without whose support the resource would not be continuously available, such as a municipal historical council or a board of trustees. (Note: benefactors of the actual resources are listed under CONTRIBUTOR. ) In addition, list distributors and other important agents of delivery in PUBLISHER.

Element: Date Ø Interpretation: The date associated with the creation or availability of the resource. This is not necessarily the same as the date in the Coverage element, which refers to the date or period of the resource’s intellectual content. For natural specimens, the value should be the date that the name in TITLE was given by CREATOR. Ø Guideline Repeat DATE to express both the circa value and the range it represents according to your organization’s policy Repeat DATE to express both the time period during which the resource was brought into being and the specific date when it was [thought to be] first cataloged or collected

Element: Identifier Ø Interpretation: A text and/or number string used to effectively identify the resource. Ø Guideline Use URLs, or URNs, or DOIs (when implemented) for internet resources. For realia, use widely recognized means of identifying items and collections such as accession numbers, International Standard Book Numbers (ISBN), raisonne catalog numbers, and Kochel numbers

Element: Source Ø Interpretation: Information about a resource from which the present resource is directly derived. Ø Guideline SOURCE is distinguished from a RELATION value of Is. Based. On by degree or strength of the connection. The CIMI testbed group used SOURCE as a “kludge” element pending clarification of the “Is. Based. On” definition by the DC Directorate.

Element: Relation Ø Interpretation: Used to describe significant points in the hierarchy of surrogacy, including the immediate parent and the original item. Recommended values are CREATOR, TITLE, IDENTIFIER and any and all progenitors/children including (repeating) SOURCE value(s).

Element: Language Ø Interpretation: The language of the intellectual content of the resource, not the language of the DC record nor necessarily the language of the TITLE value. “Intellectual content” may be represented as text or as vocal sound. CIMI’s interpretation of this element reflects a potential application of “scheme” in DC Qualified. Ø Guideline Re-use terms from list of language abbreviations defined in RFC 1766 at ftp: //ds. internic. net/rfc 1766. txt If the language is not included in that reference, spell it out completely Use repeated elements to express multiple values LANGUAGE is not applicable to natural objects or those lacking words

Element: Coverage Ø Interpretation: Requires no interpretation. Ø Guideline Repeat DC. COVERAGE values as appropriate in DC. SUBJECT—e. g. , “colonial America” or “ ‘Baroque’ dance” as an intellectual access point or keyword. Ø Ø Temporal characteristics: Recommended best practice for dates is defined in a profile of ISO 8601 [Date and Time Formats (based on ISO 8601), W 3 C Technical Note http: //www. w 3. org/TR/NOTEdatetime, which specifies the format YYYY-MM-DD. If the full date is unknown, month and year (YYYY-MM) or just year (YYYY) may be used. Repeat DC. COVERAGE to express both the time period during which the resource was brought into being and the specific date when it was [thought to be] first cataloged or collected. Spatial characteristics: Where possible, use Getty’s Thesaurus of Geographic Names at http: //www. gii. getty. edu/vocabulary/tgn. html, specifying at a sufficient granularity to unambiguously identify the location. Concatenate place names as one string of values separated by semicolons. Start with broadest term and work down to narrowest. Do not use latitude and longitude unless your audience is accustomed to associating resources to places in this manner (e. g. , maritime items or events).

Element: Rights Ø Interpretation: A rights management or a usage statement, an identifier that links to a rights management or usage statement, or an identifier that links to a service providing information about rights management for and/or usage of the resource. A statement concerning accessibility, reproduction constraints, copyright holder, and/or inclusion of credit lines. Absence of RIGHTS in a record does not imply that the resource is not protected. Ø Guideline Use a pointer to Terms and Conditions or copyright statements for Internet resources. Ensure proper agreement between the RIGHTS value and the resource in hand—do not, for example, link reproduction notices for digital surrogates to analog objects.

Exercises And now… …over to you. . .

CIMI LOGOS