# Presentation: 073758

## 2. Specific metadata standards: descriptive

- Metadata Standards and Applications Workshop

## Session 2 Objectives

- Understand the categories of descriptive metadata standards (e.g., data content standards vs. data value standards)
- Learn about the various descriptive metadata standards in terms of the community that developed them
- Evaluate the efficacy of the standard for a specific community, their strengths and weaknesses

## Outline of Session 2: descriptive metadata

- Types of descriptive metadata standards (e.g. element sets, content standards)
- Specific descriptive metadata standards (e.g. MARC, DC, MODS, EAD...)

## Descriptive metadata

- Most standardized and well understood type of metadata
- Major focus of library catalog
- Increased number of descriptive metadata standards for different needs and communities
- Importance for resource discovery
- May support various user tasks

## Aspects of descriptive metadata

- Data content standards (e.g., rules: AACR2R/RDA, CCO)
- Data value standards (e.g., values/controlled vocabularies: LCNAF, LCSH, MeSH, AAT)
- Data structure standards (e.g., formats/schemes: DC, MODS, MARC 21, VRA Core)
- Relationship models
- Data exchange/syntax standards (e.g. MARC 21 (ISO 2709), MARCXML, DC/RDF or DC/XML)

## Content Standards: Rules

**AACR2 **functions as the content standard for traditional cataloging
**RDA **(*Resource Description and Access*) is the successor to AACR2 that aspires to be independent of a particular syntax
**DACS** (*Describing Archives: a Content Standard*)
**CCO **(*Cataloging Cultural Objects*) new standard developed by visual arts and cultural heritage community
**CSDGM** (*Content Standards for Digital Geospatial Metadata)*
- Best practices, Guidelines, policies-- less formal content standards

**Notes:**
RDA is a work in progress which is more than AACR3 but its focus is still being debated

## Content Standards: Value Standards/Controlled Vocabularies

- Examples of thesauri
- Library of Congress Subject Headings
- Art and Architecture Thesaurus
- Thesaurus of Geographical Names
- Examples of value lists
- ISO 639-2 Language codes
- MARC Geographic Area codes
- Other enumerated lists (e.g. MARC/008 lists)
- Dublin Core Resource Types

## Data structure standards (element sets and formats)

- Facilitates database creation and record retrieval
- Flexibility because not tied to a particular syntax
-  May provide a minimum of agreed upon elements that facilitate record sharing and minimal consistency
- Different user communities develop their own standard data element sets
- May differ in complexity and granularity of fields
- Some data element sets become formats/schemes by adding rules such as repeatability, controlled vocabularies used, etc.

## Key descriptive metadata element sets/formats

- MARC 21
- MODS
- Dublin Core
- ONIX
- EAD
- Special resource types
- CDWA/VRA Core
- IEEE-LOM
- PBCore
- IPTC Core

**Notes:**
Allene– we need to give URLs for all of these, but no room on the slide. Maybe a references handout?
Not all these will be covered in this workshop.

## What is MARC 21?

- A syntax defined by an international standard and was developed in the late 60s
- As a syntax it has 2 expressions:
- Classic MARC (MARC 2709)
- MARCXML
- A data element set defined by content designation and semantics
- Institutions do not store “MARC 21”, as it is a communications format
- Many data elements are defined by external content rules; a common misperception is that it is tied to AACR2

## MARC 21 Scope

**Bibliographic Data**
- books, serials, computer files, maps, music, visual materials, mixed material
**Holdings Data**
- physical holdings, digital access, location
**Authority Data**
- names, titles, name/title combinations, subjects, series
**Classification Data**
- classification numbers, associated captions, hierarchies
**Community Information**
- events, programs, services, people, organizations

## MARC 21 implementation

- National formats were once common and there were different flavors of MARC
- Now most have harmonized with MARC 21 (e.g. CANMARC, UKMARC, MAB)
- Billions of records world wide
- Integrated library systems that support MARC bibliographic, authority and holdings format
- Wide sharing of records for 30+ years
- OCLC is a major source of MARC records

## Streamlining MARC 21 into the future

- Take advantage of XML
- Establish standard MARC 21 in an XML structure
- Take advantage of freely available XML tools
-  Develop simpler (but compatible) alternatives
- MODS
- Allow for interoperability with different  XML metadata schemas
- Assemble coordinated set of tools
- Provide continuity with current data
- Provide flexible transition options

## MARC 21 evolution to XML

- <date/time>

## MARC 21 in XML – MARCXML

- MARCXML record
- XML exact equivalent of MARC (2709) record
- Lossless/roundtrip conversion to/from MARC 21 record
- Simple flexible XML schema, no need to change when MARC 21 changes
- Presentations using XML stylesheets
- LC provides converters (open source)
- http://www.loc.gov/standards/marcxml

## Example: MARC and MARCXML

- _[Music record in MARC](http://catalog.loc.gov/cgi-bin/Pwebrecon.cgi?v4=1&DB=local&CMD=010a+85753651&CNT=10+records+per+page)_
- _[Music record in MARCXML](http://www.loc.gov/standards/mods/music-marcxml-record.xml)_

## What is MODS?

- Metadata Object Description Schema
- An XML descriptive metadata standard
- A derivative of MARC
- Uses language based tags
- Contains a subset of MARC data elements
- Repackages elements to eliminate redundancies
- MODS does not assume the use of any specific rules for description
- Element set is particularly applicable to digital resources

**Notes:**
Use of XML schema allows for flexibility and availability of freely available tools

## MODS high-level elements

- Title Info
- Name
- Type of resource
- Genre
- Origin Info
- Language
- Physical description
- Abstract
- Table of contents
- Target audience

- Note
- Subject
- Classification
- Related item
- Identifier
- Location
- Access conditions
- Part
- Extension
- Record Info

## Advantages of MODS

- Element set is compatible with existing descriptions in large library databases
- Element set is richer than Dublin Core but simpler than full MARC
- Language tags are more user-friendly than MARC numeric tags
- Hierarchy allows for rich description, especially of complex digital objects
- Rich description that works well with hierarchical METS objects

## Uses of MODS

- Extension schema to METS
- Rich description works well with hierarchical METS objects
- To represent metadata for harvesting (OAI)
- Language based tags are more user friendly
- As a specified XML format for SRU
- As a core element set for convergence between MARC and non-MARC XML descriptions
- For original resource description in XML syntax that is simpler than full MARC

## Example: MODS

- _[Music record in MODS](http://www.loc.gov/standards/mods/music-mods-record.xml)_

## Status of MODS

- Open listserv collaboration of possible implementers, LC coordinated (1st half 2002)
- First comment and use period: 2nd half 2002
- Now in MODS version 3.3
- Registration approved by National Information Standards Organization (NISO)
- Companion for authority metadata (MADS) in version 1.0
- Endorsed as METS extension schema for descMD
- Many expose records as MODS in OAI

## A selection of MODS projects

- LC uses of  MODS
- LC web archives
- Digital library METS projects
- University of Chicago Library
- _[Chopin early editions](http://chopin.lib.uchicago.edu/)_
- Finding aid discovery
-  Digital Library Federation Aquifer initiative
- National Library of Australia
- MusicAustralia: MODS as exchange format between National Library of Australia and ScreenSoundAustralia
- Australian national bibliographic database metadata project
- See: _[MODS Implementation registry](http://www.loc.gov/standards/mods/registry.php)_ http://www.loc.gov/mods/registry.php

## What is MADS?

- Metadata Authority Description Schema
- A companion to MODS for authority data using XML
- Defines a subset of MARC authority elements using language-based tags
- Elements have same definitions as equivalent MODS
- Metadata about people, organizations, events, subjects, time periods, genres, geographics, occupations

## MADS elements

**authority**
- name
- titleInfo
- topic
- temporal
- genre
- geographic
- hierarchicalGeographic
- occupation
**related**
- same subelements
**variant**
- same subelements

**note**
**affiliation**
**url**
**identifier**
**fieldOfActivity**
**extension**
**recordInfo**

## Uses of MADS

- As an XML format for information about people, organizations, titles, events, places, concepts
- To expose library metadata in authority files
- To allow for linking to an authoritative form and fuller description of the entity from a MODS record
- For a simpler authority record than full MARC 21 authorities
- To integrate bibliographic/authority information for presentation

## Examples

- _[person](http://www.loc.gov/standards/mads/mads-name.xml)_
- _[organization](http://www.loc.gov/standards/mads/mads-corporate.xml)_
- title
- topic
- genre
- geographic

## Some MADS implementations

- Irish Virtual Research Library and Archive Repository Prototype
- Perseus Digital Library (Tufts)
- Mark Twain Papers (University of California)
- Library of Congress/National Library of Egypt

## Dublin Core: Simple

- Fifteen elements; one namespace
- Controlled vocabulary _values_ may be expressed, but not the sources of the values
- Minimal standard for OAI-PMH
- Used also as:
- core element set in some other schemas
- switching vocabulary for more complex schemas

**Notes:**
The namespace is where machine (and usually human) readable information can be found.
May use controlled vocabulary but can’t say where the terms come from
(MARC allows different classification and allows the cataloger to say where that classification scheme came from.)
Qualified DC allows the metadata creator to say what kind of controlled vocabulary is used, but not extensively
IEEE-LOM uses simple DC as its core element list
DC is the “lingua franca” for many digital projects.  It doesn’t “map out” (to richer schemas) as well as it “maps in.”

## Dublin Core Metadata Element Set (DCMES) 1996

**Notes:**
By 1996, the 15 elements had been established

kind of extensibility is what I refer to as the LegoTM metaphor–modular extensibility. Let’s say you want additional elements to support local or disciplinary specific requirements. In addition, you want them to be complementary–that is to say, you want them to be able to fit together. So, you might have a block of metadata that we call description metadata, such as the Dublin Core, but you also want species distribution metadata. 

## International and cross-domain
Increase efficiency of the discovery/retrieval of digital objects
Provide a framework of elements which will aid the management of information
Promote collaboration of cultural/educational information

- International and cross-domain
- Increase efficiency of the discovery/retrieval of digital objects
- Provide a framework of elements which will aid the management of information
- Promote collaboration of cultural/educational information

## Simplicity
Supports resource discovery
All elements are optional/repeatable
No order of elements prescribed
Extensible
Interdisciplinary/International
Semantic interoperability

- Simplicity
- Supports resource discovery
- All elements are optional/repeatable
- No order of elements prescribed
- Extensible
- Interdisciplinary/International
- Semantic interoperability

**Notes:**
The ability to extend or refine the elements was a point of discussion at many meetings. Implementations that used the 15 elements wished to modify the elements for their special needs by using dot.syntax. By  1998 (DC6) it became clear that many projects were extending the meaning of the basic elements by using the dot.syntax structure. It was recognized that by extending the meaning, it meant that interoperability between databases would be reduced.

Simplicity: can be implemented by non-catalogers; not meant to replace richer description schema. Lower-cost alternative for describing materials

Semantic interoperability: on Internet Commons different schema for describing resources (based  on community/discipline needs: libraries, museums, archives, geospatial information systems. Core attributes, supports cross-file searching

semantic interoperability
Ability to search for digital information across heterogeneous distributed databases whose metadata schemas have been mapped to one another. It is achieved through agreements about content description standards; for example, Dublin Core, Anglo-American Cataloging Rules.
syntactic interoperability
Achieved by marking up our data in a similar fashion so we can share the data and so that our machines can understand and take the data apart in sensible ways; for example, XML, EAD and MARC.
Interoperability
The ability of different types of computers, networks, operating systems, and applications to work together effectively, without prior communication, in order to exchange information in a useful and meaningful manner. There are three aspects of interoperability: semantic, structural and syntactical. 

Issues of interoperability

Interpretation and Use of Elements
Use of Element Qualifiers (Encoding & 	Refinement)
Domain-Specific Elements & Qualifiers 
Registry
Search Engine Development
Authenticity

Interdisciplinary/International
Consensus about a simple standard for resource discovery

Mission of the DCMI 

     The mission of the Dublin Core Metadata Initiative (DCMI) is to make
     it easier to find resources using the Internet through the following
     activities: 

Developing metadata standards for resource discovery across domains           
Defining frameworks for the interoperation of metadata sets          
 Facilitating the development of community- or domain-specific metadata sets that work within these frameworks
The ability to extend or refine the elements was a point of discussion at many meetings. Implementations that used the 15 elements wished to modify the elements for their special needs by using dot.syntax. By  1998 (DC6) it became clear that many projects were extending the meaning of the basic elements by using the dot.syntax structure. It was recognized that by extending the meaning, it meant that interoperability between databases would be reduced.

Simplicity: can be implemented by non-catalogers; not meant to replace richer description schema. Lower-cost alternative for describing materials

Semantic interoperability: on Internet Commons different schema for describing resources (based  on community/discipline needs: libraries, museums, archives, geospatial information systems. Core attributes, supports cross-file searching

Interdisciplinary/International
Consensus about a simple standard for resource discovery

Mission of the DCMI 

     The mission of the Dublin Core Metadata Initiative (DCMI) is to make
     it easier to find resources using the Internet through the following
     activities: 

Developing metadata standards for resource discovery across domains           
Defining frameworks for the interoperation of metadata sets          
 Facilitating the development of community- or domain-specific metadata sets that work within these frameworks
The ability to extend or refine the elements was a point of discussion at many meetings. Implementations that used the 15 elements wished to modify the elements for their special needs by using dot.syntax. By  1998 (DC6) it became clear that many projects were extending the meaning of the basic elements by using the dot.syntax structure. It was recognized that by extending the meaning, it meant that interoperability between databases would be reduced.

Simplicity: can be implemented by non-catalogers; not meant to replace richer description schema. Lower-cost alternative for describing materials

Semantic interoperability: on Internet Commons different schema for describing resources (based  on community/discipline needs: libraries, museums, archives, geospatial information systems. Core attributes, supports cross-file searching

Interdisciplinary/International
Consensus about a simple standard for resource discovery

Mission of the DCMI 

     The mission of the Dublin Core Metadata Initiative (DCMI) is to make
     it easier to find resources using the Internet through the following
     activities: 

Developing metadata standards for resource discovery across domains           
Defining frameworks for the interoperation of metadata sets          
 Facilitating the development of community- or domain-specific metadata sets that work within these frameworks

## Dublin Core metadata

- Original 15 included in DC simple
- Elements defined subsequently and all refinements/encoding schemes under dcterms (qualified)
- DCMI Type values for high level resource types
- Simple DC widely implemented and required for metadata harvesting using OAIPMH (until current version)
- Application profiles developing to document usage and additional elements needed
- http://dublincore.org

## Dublin Core: Qualified

- ‘Qualified’ includes element refinements and encoding schemes
- More specific properties
- Two namespaces
- Explicit vocabularies
- Additional elements, including ‘Audience,’ ‘InstructionalMethod,’ ‘RightsHolder’ and ‘Provenance’

## Ex.: Simple Dublin Core

- <metadata>
-     <dc:title>**3 Viennese arias: for soprano, obbligato clarinet in B flat, and piano.**</dc:title>
-     <dc:contributor>**Lawson, Colin (Colin James)**</dc:contributor>
-     <dc:contributor>**Bononcini, Giovanni, 1670-1747.**</dc:contributor>
- <dc:contributor>**Joseph I, Holy Roman Emperor, 1678-1711.**</dc:contributor>
-     <dc:subject>**Operas****--****Excerpts, Arranged****--****Scores and parts**</dc:subject>
-     <dc:subject>**Songs (High voice) with instrumental ensemble--Scores and parts**</dc:subject>
-     <dc:subject**>****M1506 .A14 1984****</**dc:subject>
-     <dc:subject></dc:subject>
-     <dc:subject></dc:subject>
-     <dc:date>**1984**</dc:date>
-    ** **<dc:format>**1 score (12 p.) + 2 parts ; 31 cm.**</dc:format>
-     <dc:type>**Sound**</dc:type>
-   **  **<dc:identifier>**85753651**</dc:identifier>
-     <dc:language>**it**</dc:language>
-     <dc:language>**en**</dc:language>
-     <dc:publisher>**Nova Music**</dc:publisher></metadata>

**Notes:**
There is no prescribed order of elements in DC.  Everything is optional.  Notice that the <subject> element has a classification number in it (this is legal, the distinction between classification and topical subject is at the level of the vocabulary).  This record also has an identifier, the ISBN (this is a physical object, not a digital one)
DC does not specify a particular syntax.

## Ex.: Qualified Dublin Core

- <metadata>
-     <dc:title xml:lang="en">**3 Viennese arias: for soprano, obbligato clarinet in B flat, and piano.**</dc:title>
-     <dc:contributor>**Lawson, Colin (Colin James)**</dc:contributor>
-     <dc:contributor>**Bononcini, Giovanni, 1670-1747.**</dc:contributor>
- <dc:contributor>**Joseph I, Holy Roman Emperor, 1678-1711.**</dc:contributor>
-     <dc:subject xsitype="LCSH">**Operas****--****Excerpts, Arranged****--****Scores and parts**</dc:subject>
-     <dc:subject xsitype="LCSH">**Songs (High voice) with instrumental ensemble--Scores and parts**</dc:subject>
-     <dc:subject xsitype="LCC"**>****M1506 .A14 1984****</**dc:subject>
-     <dc:date xsitype="W3CDTF">**1984**</dc:date>
-  <dcterms:extent>**1 score (12 p.) + 2 parts ; 31 cm.**</dcterms:extent>
-  <dc:type xsitype="DCMIType">**Sound**</dc:type>
-   **  **<dc:identifier>**85753651**</dc:identifier>
-     <dc:language xsitype="RFC3066">**it**</dc:language>
-     <dc:language xsitype="RFC3066">**en**</dc:language>
-     <dc:publisher>**Nova Music**</dc:publisher>
- </metadata>

**Notes:**
There is no prescribed order of elements in DC.  Everything is optional.  Notice that the <subject> element has a classification number in it (this is legal, the distinction between classification and topical subject is at the level of the vocabulary).  This record also has an identifier, the ISBN (this is a physical object, not a digital one)
DC does not specify a particular syntax.

## ONIX for Books

- Originally devised to simplify the provision of book product information to online retailers (name stood for ONline Information eXchange)
- First version flat XML, second version included hierarchy and elements repeated within ‘composites’
- Maintained by Editeur, with the the Book Industry Study Group (New York) and Book Industry Communication (London)
- Includes marketing and shipping oriented information: book jacket blurb and photos, full size and weight info, etc.

**Notes:**
Briefly.
It’s hard to map a second hierarchical version.  ONIX includes a lot of marketing text and information helpful to shipping, e.g., taxes in different jurisdictions, height and weight.

## ONIX scheme

- Assigns textual element names as well as short alphanumeric tags
- Forms are identical in their functionality
- ONIX has extensive codelists
- Institutions could receive ONIX records from publishers and use an ONIX to MARC (or other metadata scheme) conversion

## Ex.: ONIX

- <Title>
- <TitleType>**01**</TitleType>
- <TitleText textcase = “02”>**British English, A to Zed**</TitleText>
- </Title>
- <Contributor>
- <SequenceNumber>**1**</SequenceNumber>
- <ContributorRole>**A01**</ContributorRole>
- <PersonNameInverted>**Schur, Norman W**</PersonNameInverted>
- <BiographicalNote>**A Harvard graduate in Latin and Italian literature, Norman Schur attended the University of Rome and the Sorbonne before returning to the United States to study law at Harvard and Columbia Law  Schools. Now retired from legal practise, Mr Schur is a fluent speaker and writer of both British and American English**</BiographicalNote>
-  </Contributor>

**Notes:**
Note the encoded values (TitleType, SequenceNumber, ContributorRole).  Hard to figure out the encoding without looking it up (same for MARC).  This information is all in one, big package.

## Ex.: ONIX

**<othertext>**
**<d102>**01**</d102>**
**<d104>**BRITISH ENGLISH, A TO ZED is the thoroughly updated, revised, and
- expanded third edition of Norman Schur’s highly acclaimed transatlantic dictionary
- for English speakers. First published as BRITISH SELF-TAUGHT and then as
- ENGLISH ENGLISH, this collection of Briticisms for Americans, and Americanisms
- for the British, is a scholarly yet witty lexicon, combining definitions with
- commentary on the most frequently used and some lesser known words and
- phrases. Highly readable, it’s a snip of a book, and one that sorts out – through
- comments in American – the “Queen’s English” – confounding as it may
- seem.**</d104>**
**</othertext>**
**<othertext>**
**<d102>**08**</d102>**
**<d104>**Norman Schur is without doubt the outstanding authority on the similarities
- and differences between British and American English. BRITISH ENGLISH, A TO
- ZED attests not only to his expertise, but also to his undiminished powers to inform, amuse and entertain. – Laurence Urdang, Editor, VERBATIM, The Language
- Quarterly, Spring 1988 **</d104>**
**</othertext>**

**Main Desc.**

**Review**

**Notes:**
Yellow bubbles tell you what the codes mean. Numeric tags get away from language limitations.

## Encoded Archival Description (EAD)

- Standard for electronic encoding of finding aids for archival and manuscript collections
- Expressed as an SGML/XML DTD
- Supports archival descriptive practices and standards
- Supports discovery, exchange and use of data
- Developed and maintained by Society of American Archivists; LC hosts the website

## EAD, continued

- Based on the needs of the archival community
- Good at describing blocks of information, poor at providing granular information
- Some uptake by museum community
- Not a content standard
- EAC is a companion for information about creators of archival material
- Example: http://purl.dlib.indiana.edu/iudl/findingaids/lilly/InU-Li-VAA1292

**Notes:**
EAC=Encoded Archival Context

## Benefits of an EAD finding aid

- Documents the interrelated descriptive information of an archival finding aid
- Preserves the hierarchical relationships existing between levels of description
- Represents descriptive information that is inherited by one hierarchical level from another
- Supports element-specific indexing and retrieval of descriptive information

## VRA Core

- Developed by the Visual Resources Association's Data Standards Committee
- Metadata element set for descriptions of work of visual culture
- Includes hierarchical structure
- Currently in version 4.0
- XML schema has been established for record sharing
- Data value standards may come from CCO (for content rules) and thesauri (e.g. TGM, AAT)

## Work, Collection or Image

- work, collection or image
- agent
- culturalContext
- date
- description
- inscription
- location
- Material
- Measurements

- relation
- rights
- source
- stateEdition
- stylePeriod
- subject
- technique
- textRef
- title
- workType

## Advantages of VRA

- Allows description of original and digital object
- Level of granularity greater than Dublin Core, less than MARC and supports specific discipline
- Now content rules have been developed (CCO)

## VRA examples

- Lindesfarne gospels (manuscript)
- Chanel coat (3-dimensional object)
- XML
- Display

## Learning Object Metadata 

- An array of related standards for description of ‘learning objects’ or ‘learning resources’
- Most based on efforts of the IEEE LTSC (Institute of Electrical and Electronics Engineers Learning Technology Standards Committee) and the IMS Global Learning Consortium, inc.
- Tends to be very complex with few implementations outside of government and industry
- One well-documented implementation is CanCore

**Notes:**
This standard was developed by IEEE.
The IMS Global Learning Consortium is a sort of spin-off.
Look at the CanCore implementation, which is really one of the few IEEE-LOM that we can examine.  Usage of IEEE-LOM tends to be in closed government sites, for example, Army training manuals.
IEEE-LOM is very rich in its way, but it’s a real commitment.

## Ex.: CanCore 

- <learningResourceType>
-   <source>**LOMv1.0**</source>
-   <value>**narrative text**</value>
- </learningResourceType>
- <learningResourceType>
-   <source>**GEM Resource Type Controlled Vocabulary**
- _http://www.geminfo.org/Workbench/Metadata/Vocab_Type.html_
-   </source>
-   <value>**educator's guide**</value>
- </learningResourceType>
- <learningResourceType>
-   <source>**LOMv1.0**</source>
-   <value>**narrative text**</value>
- </learningResourceType>
- <learningResourceType>
-   <source>**EdNA Curriculum**
-   _http://www.edna.edu.au/edna/go/cache/offonce/pid/621_
-   </source>
-   <value>**training package**</value>
- </learningResourceType>

- Note name & URL

- Note name & URL

**Notes:**
The metadata record is telling you where the value came from [urls].  Except when they give you a URL (not URI), and that page is not valid anymore.  [The GEM vocabulary link is broken.] But they’re on the right road.

## Metadata Standards in a Resource Grid

**Books**
**Journals**

**Special ****collections**

**Freely-accessible web resources**

- high

- low

- low

- high

**stewardship**

**Uniqueness**

**MARC, DC**
**ONIX, MPEG**

**MARC, METS, EAD, DC, TEI**

**DC**

**DC, DDI, IEEE/LOM, FGDC, EAD, TEI, SCORM**

**Institutional assets**

**Books**
**Journals**
**Newspapers**
**Government docs**
**Audiovisual**
**Maps**
**Scores**

**Freely-accessible web resources**
**Open source software**
**Newsgroup archives**

**Special collections**
**Rare books**
**Local/Historical Newspapers**
**Local history materials**
**Archives & manuscripts**
**Theses & dissertations**

**Institutional repositories **
**ePrints**
**Learning objects/materials**
**Research data**

- Lorcan Dempsey cited in Stuart Weibel. Presentation **State of the **
**Dublin Core Metadata Initiative **Göttingen August 11, 2003

## Modeling metadata: why use models?

- To understand what entities you are dealing with
- To understand what metadata are relevant to which entities
- To understand relationships between different entities
- To organize your metadata to make it more predictable (and be able to use automated tools)

**Notes:**
Modeling standards, like FRBR and FRAD, aim to facilitate the automated exchange of data and services between remote computer systems by defining a model for the data or the services. 

## Descriptive metadata models

- Conceptual models for bibliographic and authority data
- Functional Requirements for Bibliographic Records (FRBR)
- Functional Requirement for Authority Data (FRAD)
- Dublin Core Abstract Model (DCAM)
- Some other models:
- CIDOC Conceptual Reference Model (emerged from museum community)
- INDECS (for intellectual property rights)
- There are many conceptual models intended for different purposes

## Bibliographic relationships (pre-FRBR)

- Tillett’s Taxonomy (1987)
- Equivalence
- Derivative
- Descriptive
- Whole-part
- Accompanying
- Sequential
- Shared-characteristic

## Bibliographic relationships in MARC/MODS

- MARC Linking entry fields
- MARC relationships by specific encoding format
- Authority vs bibliographic vs holdings
- MODS relationships
- relatedItem types
- Relationship to METS document

**Notes:**
MARC linking entry fields (although developed initially for serials, but later made applicable to all types) are defined for many of the relationships in Tillett’s taxonomy.

## FRBR (1996)

- IFLA Study Group on the Functional Requirements for Bibliographic Records
- Focused on the bibliographic record rather than the catalog
- Used an entity relationship model, rather than descriptive analysis without a structural model
- Broader in scope than previous studies

**Notes:**
This is worth looking at carefully when considering broader implications.
FRBR is more than the bibliographic entities (work-expression-manifestation-item) that are usually discussed in the library world. It asks important questions:
What are the relationships between entities and people (agents)?
What are the implications for how a bibliographic system should work?

## FRBR Entities

- Bibliographic entities: *works, expressions, manifestations, items*
- Responsible parties: *persons, corporate bodies*
- Subject entities: *concepts, objects, events, places*

**Notes:**
Three classes
We are going to come back to events and the importance of temporality.

## Group 1 Entities and Relationships

**    ****A Work                   “Is realized through”**
**An Expression**

**An Expression **
**“****Is embodied in”**
**A Manifestation**

**A Manifestation**
**“****Is exemplified by”**
**An Item**

**An Expression**
**“****realizes”**
**A Work**

**A Manifestation**
**“****embodies”**
**An Expression**

**An Item **
**“****exemplifies”**
**A Manifestation**

**Notes:**
The Group 1 entities are the Work, the Expression, the Manifestation and the Item

The diagram shows the relationships between two adjacent entities

## DC Abstract Model

- Reaffirms the One-to-One Principle
- Defines ‘statement’ as the atomic level
- Distinguishes between “description” and “description set”:
**Description**: “A description is made up of one or more statements about one, and only one, resource.”
**Description Set**: “A description set is a set of one or more descriptions about one or more resources.”
- Work is being done to understand RDA in terms of the DCAM

**Notes:**
The model defines the metadata statement as the most granular level– the atomic level.
Groups metadata statements into description and description set.
The DC abstract model clusters related entities.

## A record consists of descriptions, 

- A *record* consists of *descriptions*,
- using *properties* and *values*.
- A *value* can be a *string* or a pointer
- to another *description.*

**Notes:**
The metadata statement is core.
Example of a metadata statement:  245 1_ Moby Dick
A value can be a string or something else (e.g., an image).  An image is a rich value.
The property of the statement in our example would be the title.
A statement in that description should describe one bibliographic entity (one-to-one-rule). 
A series of descriptions can be grouped into one or more description sets.
That description set gets grouped into a record.
One way to keep from violating the model is to understand the roles of (and not conflate) attributes and values.
“Leave yourself enough bread crumbs that you can back out.”

## Basic model: Resource with properties

- A Play has the title “Antony and Cleopatra,” was written in 1606
- by William Shakespeare, and is about “Roman history”

**... ****related to ****other**** Resources**

**Notes:**
Play has a title, an author.  The author has a name, birthplace, etc.

## An Exercise

*Each group will be given a printout of a digital object*
*Create a brief metadata record based on the standard assigned to your group*
*Take notes about the issues and decisions made*
*Appoint a spokesperson to present the metadata record created & the issues involved (5-10 minutes) *

**Notes:**
Choose an object and describe it.
This would work best as an individual or group exercise.  
What controlled vocabularies would you consider? Are all fields necessary? Are you creating metadata for the original, the digital surrogate, or both?