# Presentation: 937377

## Metadata Standards and Applications

- Introduction:
- Background, Goals,
- and Course Outline

**Notes:**
Suggested activities for getting started, before beginning slide content:
Introduce instructors.
Ask each participant to introduce him/herself, identifying his/her institution and position, and also, why they are there—saying a little about the connection between their job and interest in this course.
Go over with participants the contents of their manuals.
Point out the table of contents, and the presence of the examples, exercises, glossary, bibliography.

## Version 2.1, February 2009

- 2

## Cataloging for the 21st Century

- Background for this course:
- The first of five courses developed as part of:
- Bibliographic Control of Web Resources: A Library of Congress Action Plan
- Action Item 5.3: Continuing Education (CE)
- Continuing Education Implementation Group (CEIG)
- See course Bibliography for citations

- 3

## Cataloging for the 21st Century: The five CE course components

- 1. Rules and Tools for Cataloging Internet resources
- 2. Metadata Standards and Applications
- 3. Principles of Controlled Vocabulary and Thesaurus Design
- 4. Metadata and Digital Library Development
- 5. Digital Project Planning and Management Basics

- 4

## Cataloging for the 21st Century: CE Course Series Objectives

- To equip catalogers to deal with new types of resources and to recognize their unique characteristics
- To equip catalogers to evaluate competing approaches to and standards for providing access to resources
- To equip catalogers to think creatively and work collaboratively with others inside and outside their home institutions
- To ensure that catalogers have a broad enough understanding of the current environment to be able to make their local efforts compatible and interoperable with other efforts
- To prepare catalogers to be comfortable with ambiguity and being less than perfect
- To enable practicing catalogers to put themselves into the emerging digital information environment and to continue to play a significant role in shaping library services

- 5

## Goals for this Course

- Understand similarities and differences between traditional and digital libraries
- Explore different types and functions of metadata (administrative, descriptive, technical, etc.)
- Understand metadata standards: schemas, data content standards, and data value standards
- Learn how various metadata standards are applied in digital projects, including use of application profiles
- Understand how different controlled vocabularies are used in digital libraries
- Approaches to metadata creation, storage and retrieval
- Learn about metadata interoperability and quality issues

- 6

**Notes:**
Digital library design and development is a process, rather than a recipe that can be followed. 
Within that process, this workshop explores the role of metadata, and the roles and responsibilities of the metadata specialist.

Situate this course compared to:
Course 4: Metadata and Digital Library Development

Course 5: Digital Project Planning and Management Basics

## Course objectives

- Increase catalogers’ understanding of metadata for digital resources
- Evaluate competing approaches and standards for managing and providing access to resources
- Enable catalogers to think creatively and work collaboratively
- Increase understanding of current environment to allow for compatibility among applications
- Increase flexibility in utilizing different kinds of  metadata standards
- Allow catalogers to use expertise to contribute to the emerging digital information environment

- 7

## Outline of this course

- Session 1. Introduction to Digital Libraries and Metadata
- Session 2. Descriptive Metadata Standards
- Data content standards, data value standards, data structure standards
- Specific descriptive metadata** **formats
- Relationship models

- 8

## Outline of this course cont.

- Session 3. Technical and Administrative Metadata Standards
- Session 4. Metadata Syntaxes and Containers
- Session 5**. **Application Profiles and how they are used in digital libraries
** **

- 9

## Outline of this course cont.

- Session 6. Controlled Vocabularies
- Session 7. Metadata Creation, Storage and Retrieval
- Session 8. Metadata Interoperability and Quality Issues

- 10

##  1. Introduction to Digital Libraries and Metadata

- Metadata Standards and Applications Workshop

## Goals of Session

- Understand similarities and differences between traditional and digital libraries focusing on metadata
- Explore different types and functions of metadata (descriptive,
- 	administrative, structural, etc.)

- 2

## Traditional vs. Digital Libraries

- Traditional library characteristics
- Digital library characteristics?

- 3

**Notes:**
We are all quite familiar with the traditional library; brick and mortar (buildings) with books and information items of various formats. 
 But, what are our thoughts concerning digital libraries or as some may say “electronic libraries”  or  “virtual libraries?

## What is a digital library?

- a library in which collections are stored in digital formats and accessed by computers. The digital content may be stored locally, or accessed remotely via computer networks.
- a type of information retrieval system.

- 4

**Notes:**
Definitions from Wikipedia

## Digital Library Federation (DLF)

- “Digital libraries are organizations that provide the resources, including the specialized staff, to select, structure, offer intellectual access to, interpret, distribute, preserve the integrity of, and ensure the persistence over time of collections of digital works so that they are readily and economically available for use by a defined community or set of communities.”
- _[http://www.diglib.org/](http://www.diglib.org/)_

- 5

**Notes:**
A better definition could be...[as read above]
This is DLF’s “working” definition of a digital library.
DLF continues to state that “ the concept of digital library has multiple senses that one might invoke in various contexts. For example, the concept may refer simply to the notion of collection without reference to organization, intellectual accessibility or service attributes. This extended sense seems to be in play, for example, when we hear the World Wide Web described as a digital library. The concept might also refer to the organization underlying the collection, or even more specifically to the computer-based system in which the collection resides.”
DLF is a membership consortium of libraries and related agencies that are pioneering the use of electronic information technologies to extend collections and services. Your institution must join to participate in activities.
The digital library is not a single entity; 
The digital library requires technology to link the resources of many
 * The linkages between the many digital libraries and information services are transparent to the end users;
Universal access to digital libraries and information services is a goal; 
* Digital library collections are not limited to document surrogates: they extend to digital artifacts that cannot be represented or distributed in printed formats 

## Slide 16

**Notes:**
Wikipedia even claims that Project Gutenberg is the first digital library, established in 1971.

## http://www.worlddigitallibrary.org/project/english/index.html

- _[http://www.worlddigitallibrary.org/project/english/index.html](http://www.worlddigitallibrary.org/project/english/index.html)_

**Notes:**
LC is now in the process of developing the World Digital Library.
Google donated $3 million to LC to develop the specifications for a WDL.
This is just the homepage for the WDL prototype. To learn more about WDL prototype the URL is provided.
This is the prototype, the WDL does not yet exist. The point is, we are now very much in a digital environment.

- How does the environment affect the creation of metadata?

- 8

## Traditional Libraries

- Firm commitment to standards
- Specifications for metadata content (e.g., AACR2)
- Specifications for metadata encoding (e.g., MARC)
- A variety of syntaxes can be used
- Agreements on quality expectations
- Tradition of sharing, facilitated by bibliographic utilities
- Available documentation and training

- 9

**Notes:**
Note that RDA is developing to replace AACR2 for metadata content; it is significantly different than AACR2, and those differences will be discussed later in the program.
Syntaxes include “classic” MARC and MARCXML
Characteristics of commitment to principles of bibliographic control:
--Sense of quality that is commonly understood
--Notion of completeness for a bibliographic record
--Documentation is ubiquitous– a well-established body of knowledge (we pride ourselves on having a good handle on the documentation)

## Digital Libraries

- No dominant content standard
- A variety of “formats” (or “schemas” or “element sets”)
- Some emerging “federated” agreements, mostly in the world of digital libraries attached to traditional libraries
- Variable quality expectations
- Emerging basis for sharing (OAI-PMH)
- Some documentation and training is becoming available

- 10

**Notes:**
In our current environment, things are evolving.
A Digital Library is to some extent a virtual version of a physical.  The “content” is in digital formats and presumed to be available to more than one user at a time.  
Although we try our best to “port” our traditional library processing and understandings there are significant differences developing because of the additional challenges of digital content.
Does it revolve around information services, or the web platform?
There is a lot of locally-invented “stuff” involved in many digital libraries, but increasingly standards are being developed for digital libraries.

Some may say that we have so many standards now that they are competing. What may be more interesting is that we have evolving standards that allow the various metadata standards to interoperate.
[Note reference here to OAI-PMH; we’ll talk more about that later]

We have been in dire need of documentation and training for this crossover from catalogers to metadata specialists and that is why this training is taking place.

## Environmental Factors

- Differences:
*Players*: New world of metadata not necessarily led by librarians
*Goals*: Competition for users critical for sustainability
*Resources*: No real basis for understanding non-technical needs (including metadata creation and maintenance)
- Many levels of content responsibility (or none)

- 11

**Notes:**
People from libraries are trying to figure out how to operate in the the digital library world.
One thing that creates competition is scale.  Compared to published materials, the scale of digital stuff to manage is staggering.  As a result, the digital library world is trying to manage with as little human intervention as possible.  We want to facilitate people getting at their stuff without increasing the cost.  This involves a close examination of what we attempt to do that is based on traditional library practices.
“In the future, the people that are now known as ‘catalogers’ will become ‘ontology midwives.’” – John Unsworth (Dean, GSLIS, University of Illinois, Urbana-Champaign)
The skill set is similar, the management of the information is not.

Players: Unlike traditional libraries, metadata is not necessarily created by catalogers or librarians. In some instances technical specialists take the legacy records and convert them into the standard of their choice.
Goals: Libraries have lost many users to Google. Therefore, libraries and cultural institutions are collaborating with these search engines to sustain our existence and retain users.
Resources: Traditional cataloging is too expensive in this environment where we are overwhelmed with digital information. Funds are low and the demand for resources, be it people and/or money is high. Many understand the value of quality metadata, but in this competitive environment for funds, it depends on where the priorities are placed. We have to change with the times.
Traditionally, we cataloged a book, not the chapter. In this environment granularity issues are broad.

## Environmental Factors

- Similarities
- It’s about discovery (and access, and use and meeting user needs)
- Pressure for fast, cheap and “good enough” (also rich, scalable, and re-usable--is that a contradiction?)
- Wide variety of materials and services
- Maintenance needs often overlooked

- 12

**Notes:**
We’re still trying to find stuff, for example, using identifiers based on the physical world, such as ISBD, ISSN.
There is pressure to do more with less, given the assumption that we will be dealing soon with vast quantities of information.
A lot of early efforts were funded by grants, which did not fund continued support.  These days there are few general grants for initial steps in building a digital library, and most still do not support maintenance and ongoing effort.

## What IS Metadata?

- Some possibilities:
- Data about data (or data about resources)
- Structured information that describes, explains, locates, and otherwise makes it easier to retrieve and use an information resource.”
- A management tool
- Computer-processible, human-interpretable information about digital and non-digital objects

- 13

**Notes:**
“Data about Data” definition largely deprecated (though still seen in documentation). 
Second definition from OASIS: a non-profit consortium concerned with open standards

Cataloging is a subset of metadata.  Metadata goes beyond the bibliographic record.
Metadata can be used to manage or manipulate the resources.

Favorite definition of metadata: “Metadata is cataloging done by men”

**“****In moving from dispersed digital collections to interoperable digital libraries, the most important activity we need to focus on is standards... most important is the wide variety of metadata standards [including] descriptive metadata... administrative metadata..., structural metadata, and terms and conditions metadata...”**
- Howard Besser, NYU

- 14

## Metadata standards in digital libraries

- Interoperability and object exchange requires the use of established standards
- Many digital objects are complex and are comprised of multiple files
- XML is the de-facto standard syntax for metadata descriptions on the Internet
- Complex digital objects require many more forms of metadata than analog for their management and use
- Descriptive
- Administrative
- Technical
- Digital provenance/events
- Rights/Terms and conditions
- Structural

- 15

**Notes:**
XML is just the syntax for metadata descriptions. It needs a metadata element set  to be used for metadata.

## Functions of Metadata

- 16

**Notes:**
Here are some examples of the functions of metadata.

Different metadata elements are needed to perform different tasks.
Some examples: Author, title and subject support the function of discovery; 
Copyright information supports the control of intellectual property rights; geospatial coordinates support situating geospatially.

## Types of metadata 

**Descriptive**
**Administrative**
- Technical
- Digital provenance
- Rights/Access
- Preservation
**Structural**
- Meta-metadata
- Other?

- 17

**Notes:**
Metadata can take various forms. This categorization is consistent with the National Information Standard Organization’s (NISO) publication “Understanding Metadata”.
Descriptive: the metadata that is well established that we all know and love. It supports user tasks such as resource discovery, identification, acquisition, etc. Examples are author, subject.
Administrative metadata: Metadata to manage the object. It has subcategories of technical (technical characteristics about the object), digital provenance (actions that have been performed on the object and source and custody of the object), rights (information about access and use of the object)
Preservation metadata supports long-term preservation; may fall into one of the other 3 categories.
Structural: Information about an object’s physical structure; it ties the components of a complex or compound resource together and makes the whole usable (example is paging for digital books when each page is an image).
Meta-metadata is information about the metadata itself; who created it, when, where it came from, when it was updated.
Types of metadata will be covered in detail later in sessions 2, 3, and 4. 

## Cataloging and Metadata

- Cataloging early form of descriptive metadata
- Underlying models for cataloging based on AACR2 and MARC 21
- Some new metadata models are emerging (e.g, DC Abstract Model and RDA in development)
- Most metadata models roughly based on attribute/value pairs:
- <property> = <value>

- 18

**Notes:**
Although some people make a distinction between “cataloging” and “metadata”, cataloging is really just another term for metadata with a particular focus.  Its origins were for a library “catalog”, but the content of a catalog record really consists of multiple metadata fields for resource description.
The movement to create FRBR (Functional Requirements of Bibliographic Records) relationships helped to break down cataloging practice into fundamental principles.
Dublin Core Abstract Model:  to get at the underlying relationships that drive metadata description.

## Some differences between traditional and digital libraries

- Metadata only vs. actual object
- Need to understand Web technologies
- Types of media
- Granularity
- User needs
- Web services
- Digitized vs. born digital

- 	Slide by Brian Surratt

- 19

**Notes:**
Traditional library catalogs are only designed to hold the metadata, not the digital item. When you are working with digital libraries, you are working with the actual object (full-text, audio, video, data) and you have to think about the relationship of the two. 
When working with metadata one has to have a much greater understanding of basic web technologies: servers, TCP-IP, DNS, HTML, etc. 
The types of media that can be delivered over the web is exploding. Many OPACs primarily describe textual objects, but digital libraries contain all types of media: video, audio, images, text, and these can be integrated together 
Granularity – the internet is a good medium for storing and delivering smaller chunks of information: individual photos, articles, small audio and video files. The OPAC is built to describe monographs, journal titles, and collections. There is a lot more opportunity/pressure to describe things at a lower level of granularity in digital libraries. 
User needs – web design is influenced by user behavior. In libraries it has been the other way around, we have designed a complex, controlled system and then we try to teach people to use it. 
Web services. Digital libraries are not static things, they are like books with wings. Web services are the things you can do with the metadata. 
Born digital vs. digitized. The techniques for managing born-digital vs. retrospectively digitized collections are different. They are both challenging in different ways. 

## One BIG Difference ...

- Catalogers most often are attempting to fit new items into an already existing world of materials--
- The structure already exists, as do the rules for describing
- Metadata practitioners are generally working with aggregated “stuff,” attempting to find a way to make it accessible
- Involves broad understanding, ability to work with others to make decisions that work for whole projects or domains

- **Thanks to Marty Kurth for these insights*

- 20

**Notes:**
It is necessary to think about things at multiple levels.  There is an analogy with the archival process.

## Questions to ask when selecting metadata standards

- What type of material will be digitized?
- How rich does the metadata need to be?
- Is there information already available?
- Is there a Community of practice developed for this resource type(s)?
- What is the purpose of digital project?
- Who will be the audience and how will they use the content?
- Are there pre-existing digital projects with which this one needs to function? Is there a need to interact with any existing records?
- What tools or systems options are available?

- 21

**Notes:**
Think about this slide as we go through the course. These are questions to consider when selecting appropriate metadata standards.
Some things to keep in mind:
Type of material:
Format (photographs, documents, oral histories, raw data)
Complexity of relationships (is it archival in nature and do individual items make sense out of a broader context; is there a hierarchical relationship like photo albums)
Are there multiple versions that need to be displayed

Who is the intended audience and their expectations and usage
The availability of tools can be an issue and may affect the choice of standard. For instance it would be difficult to use METS as a container without the ability to generate a METS object from a tool, since it is not intended to be done by hand. Fortunately there are a number of open source tools available.

## Exercise

- Examine the digital library sites below, and be prepared to discuss differences in user approach and experience. Look for how metadata is used.
- Alsos: Digital Library for Nuclear Issues (_[http://](http://alsos.wlu.edu/default.aspx)__[alsos.wlu.edu/default.aspx](http://alsos.wlu.edu/default.aspx)_)
- CSUN Oviatt Library: Digital Collections (_[http://](http://library.csun.edu/Collections/SCA/digicoll.html)__[library.csun.edu/Collections/SCA/digicoll.html](http://library.csun.edu/Collections/SCA/digicoll.html)__)_
- Birdsource (_[http://](http://www.birdsource.org/)__[www.birdsource.org](http://www.birdsource.org/)_/)

- 22

**Notes:**
See instructor’s notes for details on this exercise.
Invite the audience to comment on how these sites are structured.
When you look at a digital site, look at how they categorize the materials.  For example:  “Search” under keyword, title, creator; “Media” is broken down into article, book, CD, chapter, film, website.  Look at these sites not only as a user but also as the developer.

## 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 and the community that developed and use them
- Learn about some relationship models used in descriptive metadata standards

- 2

## 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...)
- Relationship models

- 3

## 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

- 4

**Notes:**
Of course descriptive metadata has been around for a very long time, as we have been describing analog objects for centuries. The term descriptive metadata was coined about 20 years ago, but essentially refers to bibliographic descriptions. As more and more resources have become digital, its importance outside the library community has increased, and other communities have discovered its utility.
It is the most standardized...

## 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)
- Set of semantic properties, in this context used to describe resource
- Data exchange/syntax standards (e.g. MARC 21 (ISO 2709), MARCXML, DC/RDF or DC/XML)
- The structural wrapping around the semantics
- Relationship models

- 5

**Notes:**
It is important to understand the scope of different types of descriptive metadata and how the pieces fit together in creating descriptions of resources.
A distinction is made here between the rules for populating elements (data content standards) from controlled vocabularies used as values in specific fields in metadata (data value standards). What we are referring to as data structure standards may just be element sets with definitions, or may have more detailed instructions that indicate additional structure.  Relationship models are included here, since they inform the development of many of the other categories of descriptive metadata. Syntax standards are used for data exchange and should be considered as independent of the data structure standard, although some are associated together in practice.
Much of these categories also apply to technical metadata (which we will discuss in session 3), although descriptive is more well developed.

## 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

- 6

**Notes:**
RDA work is undergoing development, and its focus is still being debated to some extent. Best practices and guidelines may be formal or informal documents that are not standardized in the same way as other standards, but they may accompany standards  and provide useful information about implementation. They supplement formal content rules; examples are LCRIs and local policies or guidelines

## 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

- 7

**Notes:**
Controlled vocabularies may be machine readable or not, although for maintenance purposes  this would be desirable.
There are many other examples of controlled vocabularies developed by different groups and communities that may be used in descriptive metadata.
We will cover this area in more detail in session 5 on applying metadata standards.

## 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.

- 8

**Notes:**
People also refer to data structure standards as “schemas” or “schemes”. This is not the same as “XML schema”, which is tied to a particular syntax and is the structural “template” that allows XML data to be validated.

Syntax allows metadata to be shared, move around, and so forth
Schemas are essential for understanding “what it is” that the metadata is supposed to be doing.

## Data Structure Standards: Examples 

- MARC 21 (_[http://](http://www.loc.gov/marc/)__[www.loc.gov](http://www.loc.gov/marc/)__[/marc/](http://www.loc.gov/marc/)_)
- Dublin Core (_[http://](http://dublincore.org/)__[dublincore.org](http://dublincore.org/)_)
- MODS (_[www.loc.gov/standards/mods](http://www.loc.gov/standards/mods/)__[/](http://www.loc.gov/standards/mods/)_)
- IEEE-LOM (_[http://ltsc.ieee.org/wg12/](http://ltsc.ieee.org/wg12/)_)
- ONIX (_[http://](http://www.editeur.org/onix.html)__[www.editeur.org/onix.html](http://www.editeur.org/onix.html)_)
- EAD (_[http://](http://www.loc.gov/ead/)__[www.loc.gov/ead](http://www.loc.gov/ead/)__[/](http://www.loc.gov/ead/)_)

- 9

**Notes:**
Dublin Core was developed to apply to a wide variety of digital objects.
MODS= Metadata Object Description Schema; was developed by the Library of Congress as an alternative to MARC for the description of online resources.
IEEE-LOM (eye-triple-ee lahm) is a schema for educational materials.
ONIX=Online Information Exchange; ONIX for Books is what is used by Amazon, BN and other online bookstores.  There is an ONIX for Serials as well.
EAD=Encoded Archival Description, is used to describe archival collections.

## Data Structure Standards: Examples, cont.

-  VRA Core   (_[http://www.vraweb.org/projects/vracore4/](http://www.vraweb.org/projects/vracore4/)_)
-  PBCore (_[http://www.pbcore.org/](http://www.pbcore.org/)_)
-  TEI (_[http://www.tei-c.org/index.xml](http://www.tei-c.org/index.xml)_)

- 10

**Notes:**
CDWA/VRA Core=Categories for Description of Works of Art/Visual Resources Association Core elements; developed to describe digitized works of art
PBCore=Public Broadcasting Core; an element set built on Dublin Core, developed by the Corporation for Public Broadcasting to describe moving image objects
TEI (Text Encoding Initiative)  has been used since 1994 to encode texts, including parts of speech, important quotes, names, numbers and dates. The TEI Header typically includes standard descriptive metadata such as title, edition, extent, and so on.

## 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

- 11

**Notes:**
Many data elements are defined by external content rules; a common misperception is that it is tied to AACR2.

## 02158cam  2200349Ia 45000010013000000030006000130050017000190060019000360060019000550070015000740080041000890400020001300200015001500430021001650490009001862450119001952460025

- 00314260006500339538003000404506003800434536015300472520076400625505009401389500008601483600004901569650004001618651003901658651002301697700002601720856005001746994001201796_x001e_ocm56835268 _x001e_OCoLC_x001e_20060118051017.0_x001e_m        d        _x001e_szx w s     0    2_x001e_cr mn---------_x001e_041028m20049999vau     st    000 0 eng d_x001e_  _x001f_aVA@_x001f_cVA@_x001f_dOCLCQ_x001e_  _x001f_a0813922917_x001e_  _x001f_an-us---_x001f_an-us-va_x001e_  _x001f_aVA@@_x001e_04_x001f_aThe Dolley Madison digital edition_x001f_h[electronic resource] :_x001f_bletters 1788-June 1836 /_x001f_cedited by Holly C. Shulman._x001e_ 1_x001f_iAlso known as:_x001f_aDMDE_x001e_  _x001f_ aCharlottesville, Va. :_x001f_bUniversity of Virginia Press,_x001f_c2004-_x001e_  _x001f_aMode of access: Internet._x001e_  _x001f_aSubscription required for access._x001e_  _x001f_aRotunda editions are made possible by generous grants from the Andrew W. Mellon Foundation and the President's Office of the University of Virginia._x001e_  _x001f_aDolley Payne Madison was the most important First Lady of the nineteenth century. The DMDE will be the first-ever complete edition of all of her known correspondence, gathered in an XML-based archive. It will ultimately include close to 2,500 letters. From the scattered correspondence were gathered letters that have never been previously published. The range and scope of the collection makes this edition an important scholarly contribution to the literature of the early republic, women's history, and the institution of the First Lady. These letters present Dolley Madison's trials and triumphs and make it possible to gain admittance to her mind and her private emotions and to understand the importance of her role as the national capital's First Lady._x001e_0 _x001f_aGeneral introduction -- Biographical introduction -- Introduction to the digital edition._x001e_  _x001f_aTitle from the opening screen; description based on the display of Oct. 21, 2004._x001e_10_x001f_aMadison, Dolley,_x001f_d1768-1849_x001f_vCorrespondence._x001e_ 0_x001f_aPresidents' spouses_x001f_zUnited States._x001e_ 0_x001f_aUnited States_x001f_xHistory_x001f_y1801-1809._x001e_ 0_x001f_aVirginia_x001f_xHistory._x001e_1 _x001f_aShulman, Holly Cowan._x001e_40_x001f_uhttp://rotunda.upress.virginia.edu:8100/dmde/_x001e_  _x001f_aC0_x001f_bVA@_x001e__x001d_

- 12

**Notes:**
A raw MARC record -- this is how MARC systems exchange data. It shows both data elements and MARC syntax.
Animation (on click):
#1 -- Title will appear (Dolley Madision ...)
How does the computer find the place in the record for the title?
#2 -- identify the 245 tag 
#3 -- 119 -- that number of characters that tag contains (in this example, the title is 119 characters long)
#4 -- 195 -- from the start point, count 195 characters to reach the beginning of the 245 tag.
ask:  you can tell from looking, that if the title is 119 characters long, it can’t be placed 195 characters from the beginning.  There are too many characters between 02158 ... and the beginning of the title.  how do you know where to start counting
#5 -- 00349 -- start counting at position 349.  
#6 -- 5 (this is position 349.  A computer would start counting here).  Count 195 characters.  Reach the beginning of the 245.  Count 119 characters & reach the end of the title tag.
start over & show 260 example
clicks #7-10, will make the previous example disappear.
#11 -- identify 260 tag
#12 – 339 -- count 339 characters from the start position (step #6 above)
#13 -- 0065 -- go 65 characters & you will find:
#14 -- the start of the 260

## MARC 21 Scope

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

- 13

**Notes:**
MARC formats for Classification data and Community Information are not as widely used as the others.

## 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

- 14

**Notes:**
A brief review of MARC is important to understand where we’re coming from and where we might be going in the future.
Although there is some talk about MARC not surviving into the future, a number of countries have recently given up their national formats and replaced them with standard MARC 21.

## 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

- 15

**Notes:**
Although some have said that MARC must die and that it is not appropriate in today’s environment, it is important to keep in mind the large investment in systems and records based on MARC. LC is exploring streamlining MARC and evolving it into the future so that institutions don’t have to throw out all their data and start with something new.

We are introducing the use of XML with descriptive metadata. Details about the XML syntax itself will be given in session 4.

## MARC 21 evolution to XML

- 16

**Notes:**
MARCXML is a syntactical conversion from classic MARC; once in XML other tools can be applied for further transformations into different metadata schemes/formats. Here are some examples of transformations.
Note that ONIX is only going one way, but it is expected that most of its use in relation to MARC will be the exchange of an initial record that could be a basis for a library catalog record.

## 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

- 17

## 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)_

- 18

**Notes:**
The first link shows a record with MARC tags (from LC’s catalog).
The second shows how the syntax using the MARCXML schema. Note that there are a minimum of elements and the tag itself is contained as a value of an attribute. Thus, the schema does not need to be changed when new data elements are added to MARC and can be used for any of the five MARC 21 formats.
We will look at MARCXML again in session 4 on syntax.
Printouts are included in the manual.

## 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

- 19

**Notes:**
Use of XML schema allows for flexibility and availability of freely available tools
MODS is a simpler view of MARC using language tags rather than numeric tags, so is somewhat more user friendly. As with other metadata schemes, the tag names could be easily translated into other languages using common XML tools. In cases where there are redundancies in MARC (e.g. genre values in 008 in additional to in variable fields), the data has been brought together into one data element with an “authority” attribute used to specify the controlled vocabulary.

## 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

- 20

**Notes:**
All MODS elements allow for specifying a language, script, or transliteration at the element level.
In MARC you can only specify language at the record level. XML by definition uses Unicode.

## 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

- 21

## 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

- 22

**Notes:**
Originally MODS was developed because of the need for a richer description than Dublin Core but more user friendly and simple than full MARC 21, especially for the emerging initiatives that required XML output (METS, OAI, SRU)

## Example: MODS

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

- 23

**Notes:**
Click on the link to see the full record in MODS. The example is also available on the following page in the manual.
This is the same record that we saw in MARC and MARCXML.
Note the use of authority attributes to specify controlled vocabularies. Note also the use of relatedItem with a type=“constituent”. This allows for more detailed descriptions of constituent parts of the item, which are listed in the table of contents. We will see this flexibility to describe at any level of granularity again when we look at its application in digital libraries.

## 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
- Companion for authority metadata (MADS) in version 1.0
- Endorsed as METS extension schema for descMD
- Many expose records as MODS in OAI
- MODS Editorial Committee being formed

- 24

**Notes:**
MODS seems to have become widely used for digital library projects, especially when there is need to interact with other library records, particularly MARC. Using MODS, the richness of a MARC description is not sacrificed to a simple set of data elements. Some of the granular tagging may be lost in conversion to MODS from MARC, but not much data is.

## A selection of MODS projects

- LC uses of  MODS
- LC _[web archives](http://lcweb2.loc.gov/diglib/lcwa/html/lcwa-home.html)_
- 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

- 25

**Notes:**
LC is using a limited set of MODS elements to describe archived websites (click on LC web archives), including a search and browse interface.
The University of Chicago uses METS with MODS for various projects. We will look at Chopin early editions in session 7.
The DLF Aquifer Initiative uses MODS, which promotes distributed digital library content in the area of American social history.
The National Library of Australia uses MODS as a common format between the national bibliographic database and non-MARC metadata in ScreenSound Australia.
There are many more listed in the MODS implementation registry.

## 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

- 26

**Notes:**
MADS is a companion to MODS in that it has the same features: a subset of MARC authorities, compatibility with MARC definitions, language based tags in XML.

## MADS elements

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

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

- 27

**Notes:**
Some of the MADS data elements are not in MARC authority records in separate fields (although some of the data such as field of activity might be in the 670 Sources found note).

## 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

- 28

**Notes:**
LC is exploring exposing authority records as MADS.

## Example: MADS Name Record
<mads xsi:schemaLocation="http://www.loc.gov/mads/  http://www.loc.gov/mads/mads.xsd">
    <authority>
 	   <name type=“personal”> 
          <namePart>Smith,John</namePart>
          <namePart type="date">1995-</namePart>
       </name>
     </authority>
	   <variant type="other">
         <name>
           <namePart>Smith, J</namePart>
         </name>
       </variant>
       <variant type="other">
 	     <name>
           <namePart>Smith, John J</namePart>
         </name>
        </variant>
    <note type="history">Biographical note about John Smith.</note>
    <affiliation>
        <organization>Lawrence Livermore Laboratory</organization>
        <dateValid>1987</dateValid>
    </affiliation>
</mads>

- <mads xsi:schemaLocation="http://www.loc.gov/mads/  http://www.loc.gov/mads/mads.xsd">
-     <authority>
-  	   <name type=“personal”>
-           <namePart>Smith,John</namePart>
-           <namePart type="date">1995-</namePart>
-        </name>
-      </authority>
- 	   <variant type="other">
-          <name>
-            <namePart>Smith, J</namePart>
-          </name>
-        </variant>
-        <variant type="other">
-  	     <name>
-            <namePart>Smith, John J</namePart>
-          </name>
-         </variant>
-     <note type="history">Biographical note about John Smith.</note>
-     <affiliation>
-         <organization>Lawrence Livermore Laboratory</organization>
-         <dateValid>1987</dateValid>
-     </affiliation>
- </mads>

- 29

## Example: MADS Organization Record

<mads xsi:schemaLocation="http://www.loc.gov/mads/  http://www.loc.gov/mads/mads.xsd">
    <authority>
 	   <name type=“corporate”>
          <namePart>Unesco</namePart>
        </name>
     </authority>
	<related type="parentOrg">
	   <name>
          <namePart>United Nations</namePart>
        </name>
     </related>
	<variant type="expansion">
   	    <name>
	      <namePart>United Nations Educational, Cultural, and Scientific
           Organization</namePart>
        </name>
    </variant>
</mads>

- <mads xsi:schemaLocation="http://www.loc.gov/mads/  http://www.loc.gov/mads/mads.xsd">
-     <authority>
-  	   <name type=“corporate”>
-           <namePart>Unesco</namePart>
-         </name>
-      </authority>
- 	<related type="parentOrg">
- 	   <name>
-           <namePart>United Nations</namePart>
-         </name>
-      </related>
- 	<variant type="expansion">
-    	    <name>
- 	      <namePart>United Nations Educational, Cultural, and Scientific
-            Organization</namePart>
-         </name>
-     </variant>
- </mads>

- 30

## Some MADS implementations

- _[Irish Virtual Research Library and Archive Repository Prototype](http://www.ucd.ie/ivrla/main.html)_
- Perseus Digital Library (Tufts)
- Mark Twain Papers (University of California)
- Library of Congress/National Library of Egypt

- 31

**Notes:**
Some digital library projects are beginning to use MADS.

## Dublin Core: Simple

- Simple to use
- All elements are optional/repeatable
- No order of elements prescribed
- Interdisciplinary/International
- Promotes semantic interoperability
- Controlled vocabulary _values_ may be expressed, but not the sources of the values

- 32

**Notes:**
Simplicity: intended to be implemented by catalogers, non-catalogers alike; not meant to replace richer description schema
Interdisciplinary/International: governed by an international group, the Dublin Core Metadata Initiative; annual conferences 
Interoperability (general): 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.]
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 – MARC; DC-MODS; DC-VRACore. DC is arguably the most frequently “mapped” metadata standard
Controlled vocabulary: In Simple DC you may use controlled vocabulary terms but can’t provide information about where the terms come from, or how the values are  encoded (dates, for instance). Qualified DC allows different classification as does simple DC, but qualified DC also allows the cataloger to say where that classification scheme came from. There is more than one technique to use for that (making machine manipulation more difficult).
Qualified DC allows the metadata creator to say what kind of controlled vocabulary is used, and provides techniques to do so in XML.

## Dublin Core Elements

- 	**Fifteen elements in Simple DC**

| Title | Creator | Date |
| --- | --- | --- |
| Description | Contributor | Coverage |
| Subject | Publisher | Identifier |
| Relation | Rights  | Format |
| Source | Coverage | Type |

- 33

**Notes:**
By 1996, the 15 elements had been established.
The namespace is where machine (and usually human) readable information can be found.

## “Qualified” Dublin Core

- Includes 15 terms of the original DC Metadata Element Set, plus:
- Additional properties and sub-properties
- Examples: abstract, accessRights, audience, instructionalMethod, rightsHolder, provenance
- Provides:
- A fuller set of properties with specific requirements for content
- A namespace that includes all properties
- Explicit value vocabularies can be specified

- 34

## DC Structure

- Property/element refinements are used at the element level in DC/XML
- Relationships between properties and sub-properties explicit in the formal representation
- Does not use XML “nesting” to express those relationships
- Encoding schemes (Syntax & Vocabulary)
- Syntax ES: Essentially a datatype that communicates the format or structure of a string
- Vocabulary ES: Includes values from an identified controlled vocabulary or list

- 35

**Notes:**
Element refinements (sub-properties) must be related to a “parent” element but the relationship is expressed in the element set declaration, and is not “nested” in XML (for example).
Encoding schemes include syntax encoding schemes and vocabulary encoding schemes used with DC. 
Syntax encoding scheme examples include ISO 3166 (codes for names of countries), RFC4646 (codes for languages), W3CDTF (W3C Date and Time Formats Specification).
Vocabulary encoding schemes include DCMI Type Vocabulary, DDC, LCC, LCH, MeSH, etc.

## Advantages: Dublin Core

- International and cross-domain
- Developed via an open review process
- Increased efficiency of the discovery/retrieval of digital objects
- Rich element set (qualified DC) provides a framework of elements which will aid the management of information
- Ease of mapping to other metadata standards promotes collaboration of cultural/educational information

- 36

**Notes:**
DC is useful especially when disparate metadata formats are used together.
The Dublin Core Metadata Initiative’s stated mission is to make it easier to find resources using the Internet through developing metadata standards for resource discovery across domains, defining frameworks for the interoperation of metadata sets, and facilitating the development of community- or domain-specific metadata sets that work within these frameworks.
Use of Qualified DC overcomes many of the limitations of Simple DC, while retaining the same accessible structure. Because DC is non-proprietary and undergoes an open, formal review process, additional refinements are compatible with earlier versions.
DC is also known to be well documented, which makes it easily accessible.

## Uses of Dublin Core

- Minimal standard for OAI-PMH
- Core element set in some other schemas
- Switching vocabulary for more complex schemas

- 37

**Notes:**
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) requires at least simple DC in XML; other XML formats may be used in addition to simple DC (e.g. qualified DC, MARCXML, VRA Core). 
DC is the “lingua franca” for metadata from diverse communities.  It doesn’t “map out” (to richer schemas) as well as it “maps in.”
IEEE-LOM uses simple DC as its core element list
PBCore used simple DC as the basis for its element set

## 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>**text**</dc:type>
-   **  **<dc:identifier>**85753651**</dc:identifier>
-     <dc:language>**it**</dc:language>
-     <dc:language>**en**</dc:language>
-     <dc:publisher>**Nova Music**</dc:publisher></metadata>

- 38

**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>

- 39

**Notes:**
Note the addition of encoding schemes (authorities) for the values in various elements.

## Status of DC

- Dublin Core Metadata Element Set version 1.1
- ISO Standard 15836-2003; ANSI/NISO Standard Z39.85-2007; IETF RFC 5013
- Updated encoding guidelines
- Proposed recommendation for expressing DC description sets using XML (Sept. 2008)
- Final recommendation for expressing DC metadata using HTML/XHTML (Aug. 2008)

- 40

**Notes:**
Revised ISO 15836 is expected to replace the current 2003 version in 2008. No big changes but improved definitions for many elements
ISO=International Organization for Standards (Geneva), international standards-setting body for business, government and society
ANSI/NISO=NISO, the National Information Standards Organization, is accredited by ANSI, the American National Standards Institute.
IETF=Internet Engineering Task Force, founded 1992, is an open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. RFCs are Requests for Comment. They are the basic publication series for the IETF. Once and RFC is “published” by the RFC editor, it is not modified.

## A selection of DC projects

- National Science Digital Library _[http://nsdl.org/](http://nsdl.org/)_
- Aggregates a wide variety of source collections using Dublin Core
- Kentuckiana Digital Library _[http://kdl.kyvl.org/](http://kdl.kyvl.org/)_
- For item level metadata, on DLXS software
- Gathering the Jewels _[http://www.gtj.org.uk/](http://www.gtj.org.uk/)_
- Website for Welsh cultural history using DC standards
- MusicBrainz _[http://musicbrainz.org/](http://musicbrainz.org/)_
- User-maintained community music recording database; extension of DC

- 41

## 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

- 42

## 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](http://purl.dlib.indiana.edu/iudl/findingaids/lilly/InU-Li-VAA1292)_

- 43

**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

- 44

**Notes:**
Widely used in the archival community. EAD Finding Aids themselves may be described using other metadata schemes (LC has many in its library catalog). There also can be links to other descriptions.

## Text Encoding Initiative (TEI) 

- Consortium of institutions and research projects which collectively maintains and develops guidelines for the representation of texts in digital form.
- Includes representation of title pages, chapter breaks, tables of contents, as well as poetry, plays, charts, etc.
- The TEI file contains a “header” that holds metadata about the digital file & about the original source.

- 45

## TEI

- <fileDesc>
- <titleStmt>
- <title type="main">A chronicle of the conquest of Granada</title>
- <author>
-      <name type="last">Irving</name>
-      <name type="first">Washington</name>
-      <dateRange from="1783" to="1859">1783-1859</dateRange>
- </author>
- </titleStmt>
- <extent>455 kilobytes</extent>
- <publicationStmt>
- <publisher>University of Virginia Library</publisher>
- <pubPlace>Charlottesville, Virginia</pubPlace>
- <date value="2006">2006</date>
- </publicationStmt>
- <availability status="public">
- <p n="copyright">Copyright &copy; 2006 by the Rector and Visitors of the University of Virginia</p>
- <p n="access">Publicly accessible</p>
- </availability>

- 46

**Notes:**
<fileDesc> is about the electronic publication (see extent & publicationStmt)

## MORE TEI

- <sourceDesc>
- <titleStmt>
- <title type="main”>A chronicle of the conquest of Granada</title>
- <author>
- <name type="last">Irving</name>
- <name type="first">Washington</name>
- <dateRange from="1783" to="1859">1783-1859</dateRange>
- </author>
- </titleStmt>
- <extent>345 p. ; 21 cm.</extent>
- <publicationStmt>
- <publisher>Carey, Lea &amp; Carey</publisher>
- <pubPlace>Philadelphia</pubPlace>
- <date value="1829">1829</date>
- <idno type="LC call number">DP122 .I7 1829a</idno>
- <idno type="UVa Title Control Number">a1599744</idno>
- </publicationStmt>
- </sourceDesc>

- 47

**Notes:**
<sourceDesc> is about the source publication (see extent & publicationStmt).  Violates the DC one-to-one rule, but coded explicitly

## Selection of TEI projects

- American Memory (uses a TEI-conformant DTD
-  _[http://](http://memory.loc.gov/ammem/index.html)__[memory.loc.gov/ammem/index.html](http://memory.loc.gov/ammem/index.html)_
- Early Canada Online
-  _[http://](http://www.canadiana.org/)__[www.canadiana.org](http://www.canadiana.org/)__[/](http://www.canadiana.org/)_
- Victorian Women Writers Project
- _[http://](http://www.indiana.edu/~letrs/vwwp/index.html)__[www.indiana.edu/~letrs/vwwp/index.html](http://www.indiana.edu/~letrs/vwwp/index.html)_
- Oxford Text Archive
-  _[http://](http://ota.ahds.ac.uk/)__[ota.ahds.ac.uk](http://ota.ahds.ac.uk/)__[/](http://ota.ahds.ac.uk/)_

- 48

**Notes:**
The TEI web site lists many more projects that use TEI.

## VRA Core 

- Maintained by the Visual Resources Association.  Version 4 is currently in beta release.
- A categorical organization for the description of works of visual culture as well as the images that document them.
- Consists of a metadata element set and an initial blueprint for how those elements can be hierarchically structured.

- 49

## 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

- 50

## 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)

- 51

## VRA Core

- <titleSet>
- <title pref="true” source=“LC NAF”>Rotunda</title>
- </titleSet>
- <agentSet><agent>
- <name type="personal“ vocab=“LC NAF” refid= “n 79089957”>
- Jefferson, Thomas</name>
- <dates type="life">
-           <earliestDate>1743</earliestDate><latestDate>1826</latestDate>
- </dates>
- <role>architect</role>
- <culture>American</culture>
- </agent></agentSet>
- <agentSet><agent>
- <name type="personal“ vocab=“LC NAF” refid= “n 50020242”>
- White, Stanford</name>
- <dates type="life">
- <earliestDate>1853</earliestDate><latestDate>1906</latestDate>
- </dates>
- <role>architect</role>
- <culture>American</culture>
- <notes>Architect of 1896-1897 renovation</notes>
- </agent></agentSet>

- 52

**Notes:**
about the BUILDING (architects)

## More VRA Core

- <dateSet>
-       <date type="construction">
- <earliestDate>1822</earliestDate><latestDate>1826</latestDate>
-       </date>
- <notes>Construction begun October, 1822, completed September, 1826.<notes>
- </dateSet>
- <dateSet>
-       <date type=“destruction">
-             <earliestDate>1895</earliestDate>      </date>
- <notes>Burned October 27, 1895.</notes>
- </dateSet>
- <dateSet>
-       <date type=“renovation">
-       <earliestDate>1896</earliestDate><latestDate>1897</latestDate>      </date>
- <notes>Rebuilt to designs of Stanford White, 1896-1897.</notes>
- </dateSet>
- <locationSet><location type="site">
- <name type="geographic" vocab="TGN" refid="2002201">Charlottesville, Virginia</name>
- </location></locationSet></work>

- 53

**Notes:**
about the BUILDING (dates)

## More VRA Core

- <image>
- <titleSet>
- <title type="descriptive">general view</title>
- </titleSet>
- <agentSet><agent>
- <name type="personal“ vocab=“LC NAF”
- refid=“n 82111472”>Lay, K. Edward</name>
- <culture>American</culture>
- <role>photographer</role>
- </agent></agentSet>
- <dateSet><date type=“creation">
- <earliestDate>1990</earliestDate>
- <latestDate>2000</latestDate>
- </date></dateSet>
- <locationSet><location type="repository">
- <name type="corporate">University of Virginia Library</name>
- <name type="geographic" vocab="TGN" refid="2002201">
- Charlottesville</name>
- </location></locationSet>
- <rightsSet>
-       <rights type=“credit”>K. Edward Lay</rights>
-       <rights type=“access”>Publicly accessible</rights>
- </rightsSet>
- </image>

- 54

**Notes:**
about the IMAGE (this one is a general view)

## More VRA Core

- <image>
- <titleSet>
- <title type="descriptive">View from gymnasia</title>
- </titleSet>
- <agentSet><agent>
- <name type="personal“ vocab=“LC NAF”
- refid=“n 82111472”>Lay, K. Edward</name>
- <culture>American</culture>
- <role>photographer</role>
- </agent></agentSet>
- <dateSet><date type=“creation">
- <earliestDate>1995</earliestDate>
- <latestDate>2000</latestDate>
- </date></dateSet>
- <locationSet><location type="repository">
- <name type="corporate">University of Virginia Library</name>
- <name type="geographic" vocab="TGN" refid="2002201">
- Charlottesville</name>
- </location></locationSet>
- <rightsSet>
-       <rights type=“credit”>K. Edward Lay</rights>
-       <rights type=“access”>Publicly accessible</rights>
- </rightsSet>
- </image>

*credit: K. Edward Lay*

- 55

## A Selection of VRA Core Projects

- Luna Imaging
- _[http://](http://www.lunaimaging.com/index.html)__[www.lunaimaging.com/index.html](http://www.lunaimaging.com/index.html)_
- ARTstor
- _[http://](http://www.artstor.org/)__[www.artstor.org](http://www.artstor.org/)__[/](http://www.artstor.org/)_
- Visual Information Access (VIA), Harvard University Libraries
- _[http://](http://via.lib.harvard.edu/via/)__[via.lib.harvard.edu](http://via.lib.harvard.edu/via/)__[/via/](http://via.lib.harvard.edu/via/)_

- 56

**Notes:**
VIA (Visual Image Access), a union catalog of visual resources at Harvard, draws on early versions of the VRA Core and CDWA. 

## Learning Object Metadata (LOM) 

- 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

- 57

**Notes:**
This standard was developed by IEEE; the IMS Global Learning Consortium is a sort of spin-off (note that neither organization makes their standard or documentary material openly available).
IEEE-LOM uses simple DC as its core element list. 
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.

## Uses of IEEE-LOM

- Describe and share information about learning objects individually or as a group
- Export as LOM in XML or RDF
- Most descriptive elements mapped to Dublin Core
- Can be used with the IMS VDEX (Vocabulary Definition Exchange)

- 58

**Notes:**
The VDEX specification is a grammar for controlled vocabularies; a mark-up language for CVs.

## A Selection of IEEE-LOM Projects

- CanCore
- _[http://www.cancore.ca/](http://www.cancore.ca/)_
- LearnAlberta.ca
- _[http://www.learnalberta.ca/](http://www.learnalberta.ca/)_
- Grades K-12
- Learning Object Repository Network
- _[http://lorn.flexiblelearning.net.au/Home.aspx](http://lorn.flexiblelearning.net.au/Home.aspx)_

- 59

## What is 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.

- 60

**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.  Some information is very useful to libraries: book jacket images, for instance.

## Advantages of ONIX

- Provides publisher information in a widely used standard format
- Promotes exchange of information with publishers, vendors, book sellers, libraries
- “Value-added” information (ex., book jacket images, reviews) benefits book sellers (online commercial sites) and libraries (online catalogs)
- More [information], faster [transmission], cheaper? better?

- 61

**Notes:**
ONIX has streamlined ordering, allowing faster and more reliable electronic transmissions. It also allows the exchange of bibliographic information from the publisher-vendor to libraries, though sometimes the content does not conform to the grammatical format traditionally used by libraries. (Capitalization, punctuation vary)

## A selection of ONIX projects

- _[http://](http://www.editeur.org/onix.html)__[www.editeur.org/onix.html](http://www.editeur.org/onix.html)_
- ONIX Administrators
- EDItEUR (European & international)
- Book Industry Communication (BIC) (European and international)
- Book Industry Study Group, Inc. (BISG) (U.S.)
- Amazon.com
- Association of American Publishers
- Baker & Taylor
- Barnes & Noble
- Google
- McGraw-Hill Companies

- 62

## PBCore

- Public Broadcasting Core element set
- _[http://](http://www.pbcore.org/)__[www.pbcore.org](http://www.pbcore.org/)__[/](http://www.pbcore.org/)_
- Built on Dublin Core (but does not comply with the Abstract Model)
- Provides a shared descriptive language for public broadcasters
- Used for television, radio, Web activities

- 63

## PBCore Elements

- 53 elements arranged in 15 containers and 3 sub-containers
- Four classes:
- Intellectual Content (title, subject, description, audienceLevel ...)
- Intellectual Property (creator, contributor, publisher, rightsSummary)
- Instantiation (dateCreated, formatFileSize, formatDuration, formatTracks, language)
- Extensions

- 64

**Notes:**
Note that the first four classes similar to those DC used until recently to categorize its elements.

## Uses of PBCore

- Shared descriptive language for public broadcasters
- Useful for both public search and viewing, and internal asset management
- Facilitates production collaborations
- Ability to parse programs into short segments for Web distribution, niche community needs

- 65

**Notes:**
Granular manipulation and interoperability of content are required in order to allow re-use of media content.

## Selection of PBCore projects

- Wisconsin Public Television (WPT) Media Library Online  _[http://wptmedialibrary.wpt.org/](http://wptmedialibrary.wpt.org/)_
- Kentucky Educational Television (KET)  _[http://www.ket.org/](http://www.ket.org/)_
- New Jersey Network (NJN)  _[http://www.njn.net/](http://www.njn.net/)_

- 66

**Notes:**
Most public television stations/networks do not have the infrastructure to support a public, online library of moving images. WPT was the first metadata management system to use the PBCore metadata dictionary. 
PBCore is commonly used as the internal standard to describe and track a station’s or network’s moving image assets. NJN is beginning to make some of its moving images available through the New Jersey Digital Highway (a statewide repository of cultural and historical objects) and NJVid (a statewide video commons for the state’s K-20 institutions, museums and libraries).

## 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)

- 67

**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. 
Here are some reasons why models might be important in developing metadata standards.

## 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

- 68

**Notes:**
Models may be widely variant in granularity and in use. Some may model information, while others functionality.   Some may be for specific kinds of metadata, others for specific kinds of resources. Very often models are developed after the development of the standard itself.

## Bibliographic relationships (pre-FRBR)

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

- 69

**Notes:**
Although dated, this taxonomy is useful for detailing types of relationships between bibliographic resources.

## 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

- 70

**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.
There are also relationships between entities described in the different MARC formats (somewhat related to FRBR entities).
MODS relationships are rich and detailed in related item types. They have a close relationship with the structural metadata detailed in a METS document (we will cover this in session 4).

## 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

- 71

**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*

- 72

**Notes:**
Three classes of FRBR entities.

## 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**

*[Thanks to Sherry Vellucci for this slide.]*

- 73

**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.”
- RDA vocabularies being developed to use the DC Abstract Model

- 74

**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.*

- 75

**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.

## 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”

- 76

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

- 77

**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) *

- 78

**Notes:**
LC is providing 2 objects with information for trainees and answer sheets for instructors to hand out after the exercise is completed.
This may be done as an individual or group exercise. 
What controlled vocabularies would you consider? Are all fields necessary? What are some differences in approach between the different descriptive metadata standards?

More information is in the Instructors’ Notes.

## 3. Technical and administrative metadata standards

- Metadata Standards and Applications Workshop

## Goals of session

- To understand the different types of administrative metadata standards
- To learn what types of metadata are needed for digital preservation
- To learn the importance of technical, structural and rights metadata in digital libraries

- 2

## Types of administrative metadata

- Provides information to help manage a resource
- Preservation metadata
- Technical characteristics
- Information about actions on an object
- Structural metadata may be considered administrative; indicates how compound objects are put together
- Rights metadata
- Access rights and restrictions
- Preservation rights and restrictions

- 3

**Notes:**
Administrative metadata gives information about managing the object such as how and why it was created, file format information, actions performed on objects, and information about who can access it. These are sometimes divided into subsets, such as “preservation metadata”, “structural metadata” and “rights metadata” There can be some overlap with elements in descriptive metadata. For instance something like extent or file size is important for the descriptive task of identifying the resource appropriate for the intended use, while it is also important for managing the file as a physical object.

## PREMIS: introduction

- Preservation metadata that includes subcategories:
- Technical metadata
- Relationships (structural and derivative)
- Digital provenance (what actions performed on objects)
- Rights

- 4

**Notes:**
PREMIS stands for PREservation Metadata: Implementation Strategies Working Group, which developed a data dictionary of elements needed to support the preservation of digital objects. Preservation metadata falls into various categories, each of which also support other uses (such as access). 

## Preservation metadata includes:

- Provenance:
*Who has had custody/ownership of the **digital object?*
- Authenticity:
*Is the digital object what it purports to be?*
- Preservation Activity:
*What has been done to preserve it?*
- Technical Environment:
*What is needed to render and use it?*
- Rights Management:
*What IPR must be observed?*
**Makes digital objects self-documenting across time**

**Content**

**Preservation**
**Metadata**

**10 years on**

**50 years on**

**Forever!**

- 5

**Notes:**
There are a number of questions that need to be answered to ensure preservation of digital objects over time. We all know that files can get corrupted and unreadable and it is important to be able to track who has had custody of an object and all actions performed on an object. What preservation strategies have been applied needs to be recorded as well as what software or hardware is needed to use it and whether there are any restrictions on preservation activities (in addition to access). If metadata is associated with an object it can become self-documenting over time.

## PREMIS Data Dictionary

**May 2005: ***Data Dictionary for Preservation **	**Metadata: **Final Report of the PREMIS Working Group*
- 237-page report includes:
- PREMIS Data Dictionary 1.0
- Accompanying report
- Special topics, glossary, usage examples
**Data Dictionary: **comprehensive, practical resource for implementing preservation metadata in digital archiving systems
- Used *Framework* as starting point
- Detailed description of metadata elements
- Guidelines to support implementation, use, management
- Based on deep pool of institutional experiences in setting up and managing operational capacity for digital preservation
- Set of **XML schema** developed to support use of Data Dictionary

- 6

**Notes:**
The PREMIS Data Dictionary has become the standard for core metadata needed for preservation activities.

## Scope of data dictionary

- Implementation independent
- Descriptive metadata out of scope
- Technical metadata applying to all or most format types
- Media or hardware details are limited
- Business rules are essential for working repositories, but not covered
- Rights information for preservation actions, not access

- 7

**Notes:**
The PREMIS Data Dictionary assumes that implementation decisions need to be made and does not dictate a syntax, although an XML schema is provided.
Descriptive metadata only includes an identifier, but otherwise is out of scope, although its importance is recognized.
Technical metadata that is included is only that which applies to all format types, not specific file format types (e.g. image, video, etc.)
Business rules are policy decisions that a repository makes about preservation strategies that may or may not be relevant to another institution. Some examples are retention periods or risk assessment.

## What PREMIS is and is not

- What PREMIS is:
- Common data model for organizing/thinking about preservation metadata
- Guidance for local implementations
- Standard for exchanging information packages between repositories
- What PREMIS is not:
- Out-of-the-box solution: need to instantiate as metadata elements in repository system
- All needed metadata: excludes business rules, format-specific technical metadata, descriptive metadata for access, non-core preservation metadata
- Lifecycle management of objects outside repository
- Rights management: limited to permissions regarding actions taken within repository

- 8

**Notes:**
PREMIS may be used in various ways. There is an emphasis on its usefulness as an exchange format between repositories, where a standard is clearly needed. Internally, it may serve as a checklist for core metadata included in the repository.
It needs to be used in conjunction with other metadata and is only one part of the infrastructure needed for digital preservation.

## PREMIS Data Model

**Intellectual**
**Entities**

**Objects**

**Rights****Statements**

**Agents**

**Events**

- 9

**Notes:**
These are the relationships in the PREMIS data model. Although descriptive metadata is out of scope, objects can point to descriptions of intellectual entities or the entity itself, in either direction. From the data model you see that agents (people, organizations or software) can only act on objects through events or rights, not directly. Objects can have relationships to other entities in the data model or to each other. 

## Types of information covered in PREMIS (by entity type)

- Object
- Object ID
- Preservation level
- Object characteristics
- (format, size, etc.)
- Storage
- Environment
- Digital signatures
- Relationships
- Linking identifiers

- Event
- Event ID
- Event type
- Event date/time
- Event outcomes
- Linking identifiers
- Agent
- Agent ID
- Agent name
- Rights
- Rights statement
- Granting agent
- Permission granted

- 10

**Notes:**
These are the categories of information covered by PREMIS. The data dictionary is organized by entity type and lists elements that are properties of the given entity. 

Objects include technical metadata, much of which is included under “objectCharacteristics”. In addition to format and size, it also includes things like fixity (commonly known as “checksums”, which is used for managing the authenticity of objects), and any passwords or encryption that limits the use of an object. Environment details the software and hardware that is needed to render or use the object. Relationships are documented and are considered either structural (to understand the structure of complex digital objects if you need to put them back together) or derivative (if you make a new copy from an existing object, for example if you make a service copy from a master copy).

Events detail any actions taken on an object. The type of event is in eventType, which includes actions such as capture, compression, validation, replication, migration, etc. These are actions that are performed on objects as part of a preservation strategy.  Events are extremely important for preservation activities, because it is necessary to track actions performed on files for preserving into the future. 

Agents (people, organizations, software) are not described in great detail, only enough for identification (it is assumed that more information is available elsewhere). 

Rights only concern rights to preserve; greatly expanded in version 2.0 to include rights pertaining to a license, copyright and statutory rights.

It is expected that the majority of this information will be captured from the object itself or from the repository system being used and that a minimal amount will need to be provided by hand.

## PREMIS Maintenance Activity

**http://www.loc.gov/standards/premis/**

- Permanent Web presence,
- hosted by Library of Congress
- Centralized destination for
- information, announcements,
- and other PREMIS-related
- resources
- Discussion list for PREMIS
- implementers (PIG list)
- Coordinate future revisions of Data Dictionary and XML schema
- Editorial committee guides development and revisions

- 11

**Notes:**
Membership of Editorial Committee: Library of Congress, OCLC, FCLA, National Archives of Scotland, British Library, National Library of Australia, U. of Goettingen, LANL, Ex Libris, Library Archives Canada
The PIG list is open for potential or current implementers.

## Current activities

- PREMIS Implementers’ Registry
- _[http://www.loc.gov/standards/premis/premis-registry.html](http://www.loc.gov/standards/premis/premis-registry.html)_
- Revision of data dictionary and schemas (March 2008)
- Guidelines for use of PREMIS within METS have been developed
- PREMIS tutorials
- One or one and a half day tutorials have been given in several locations: Glasgow, Boston, Stockholm, Albuquerque, Washington, San Diego, Berlin
- Training materials available from LC

- 12

**Notes:**
Version 2.0 was released the end of March 2008. We will talk about how PREMIS is used with METS later.

## Why is PREMIS important to catalogers?

- As we take responsibility for more digital materials, we need to ensure that they can be used in the future
- Most preservation metadata will be generated from the object, but catalogers may need to verify its accuracy
- Catalogers may need to play a role in assessing and organizing digital materials
- Understanding the structure of complex digital objects
- Determining significant properties that need to be preserved

- 13

**Notes:**
Catalogers have always done some assessment of material. Also, there are data elements that serve a function both for the key user tasks of bibliographic (descriptive) records and for preservation purposes. 
Although much of the PREMIS metadata will be generated from the object (e.g. format, size, and other information in file headers that get there at the creation of the file), there may be a need for catalogers to verify its accuracy.  There is much discussion about something called “significant properties” that are special features of the object that need to be preserved over time, and this is where it is important for an assessment to be made, and catalogers may need to play a role. An example might be a PDF file that has an embedded graph where the color of the lines determine the meaning. In this case, it is important that the color be preserved, and someone would need to look at the object to make the determination and state it in the metadata.

## Technical metadata for images

- NISO Z39.87 and MIX
- Adobe and XMP
- Exif
- IPTC (International Press Telecommunications Council)/XMP
- Some of these deal with embedded metadata in images

- 14

**Notes:**
This is an overview of some of the standards that have been developed for technical metadata for images. We will treat NISO Z39.87/MIX in the next few slides.
XMP allows for embedding metadata in image files
Exif is used by camera companies to include metadata in file headers of digital photos. XMP metadata may also be embedded in image files.
IPTC is used by newspapers for digital photos. Might libraries be called upon to preserve any of these? That is an open question now, but we are seeing more cases of libraries becoming “trusted digital repositories” for other institutions.

## Metadata For Images in XML (MIX)

- An XML Schema designed for expressing technical metadata for digital still images
- Based on the NISO Z39.87 Data Dictionary – Technical Metadata for Digital Still Images
- Can be used standalone or as an extension schema with METS/PREMIS

- 15

## Using MIX

- Includes
- Characteristics that apply to all or most object types, e.g. size, format (elements also in PREMIS)
- Format specific metadata for images
- Some examples of format specific metadata elements in MIX:
- Image width
- Color space, color profile
- Scanner metadata
- Digital camera settings
- Most well developed of format specific technical metadata standards

- 16

**Notes:**
There is some overlap with PREMIS elements.

## Technical metadata for textual objects

- _[textMD](http://www.loc.gov/standards/textMD/index.html)_ is an XML Schema designed for expressing technical metadata for textual objects
- Developed at New York University; maintenance transferred to LC
- Includes format specific technical metadata for text, e.g.
- byte order
- character set encoding
- font script

- 17

## Technical metadata for audio and video

- Not as well developed as other technical metadata
- Complexities of file formats requires expertise to develop these
- LC developed XML technical metadata schemas in 2003/2004 for LC Audiovisual Prototype Project used with METS; these were widely implemented because of the lack of other schemas
- Audio and video technical metadata schemas under development by expert organizations
- _[Moving Image Catalog ](http://mic.imtc.gatech.edu/)__(MIC) project is also experimenting with these_

- 18

**Notes:**
Implementers are still struggling with format specific metadata for audio and video. Although out of date, there is still much implementation of the LC prototype schemas for lack of anything else that is understandable.
The MIC Union Catalog is experimenting with technical metadata for moving image using MPEG-7.  This project brings together in one place catalog records for individual moving images collected and managed by a number of organizations, enabling users to search for moving images across multiple collections. Participating institutions include LC, NLM, CNN, National Geographic Television and Film Archive, Academy of Motion Picture Arts and Sciences Academy Film Archives and a number of others.

## Technical metadata for multimedia (MPEG-7)

- A multimedia content description standard, associated with the content itself
- Intended to allow fast and efficient searching
- Formally called Multimedia Content Description Interface
- Does not deal with the actual encoding of moving pictures and audio (as MPEG-1, MPEG-2 and MPEG-4 do)
- intended to provide complementary functionality to the previous MPEG standards

- 19

## Structural metadata

- Supports the intended presentation and use and navigation of an object
- Binds the parts together; expresses relationships between parts of a multipart object
- Examples of structural metadata expressions:
- METS structMap
- PREMIS relationship elements
- EAD hierarchical structure

- 20

**Notes:**
We will go into structural metadata in more detail when we talk about the METS structural map in session 4.

## Rights metadata

- Rights schemas with limited scope
- Rights Expression Languages (REL) for managing intellectual property rights, particularly by rights owners
- Rights information is not well understood
- Different laws in different jurisdictions
- Machine actionable vs. human understandable
- Rights take different forms
-  legal statutes, e.g. copyright
-  contractual rights, e.g. licenses

- 21

**Notes:**
Rights is a difficult area, so there are a variety of efforts, some limited in scope, and others more expansive. Some rights are covered by laws, like copyright law, but there are also rights (also known as terms and conditions) that are governed by contracts between parties.

## Rights schemas with limited scope

- METS Rights
- Access rights for use with METS objects
- Rights declarations
- Rights holder
- Context
- CDL copyright schema
- Specifically copyrights, not other intellectual property rights
- Information you need to know to assess copyright status (e.g. creators, rights holders, dates, jurisdiction)
- Note that a new field 542 has been added to MARC 21 with information about copyright to help the cataloger assess the status of the item (based on the CDL work)

- 22

**Notes:**
CDL was developed by the California Digital Library for digital projects.

## Rights schemas with limited scope cont.

- PREMIS Rights
- Focused on rights for preservation rather than access
- Revision of PREMIS data dictionary expanded this area
- Allows for extensibility, i.e. inserting another rights schema
- Creative commons
- Allows creators to choose a license for their work
- Simple rights statements that fit a lot of situations
- _[http://creativecommons.org/](http://creativecommons.org/)_
- An example: _[MIC catalog](http://mic.imtc.gatech.edu/unicatlg_1.htm)_

- 23

**Notes:**
See bottom of page of MIC catalog: “some rights reserved” is a creative commons license.

## Rights metadata for specific object types

- PLUS for images
- MPEG-21 REL for moving images, etc.
- ONIX for licensing terms
- Full Rights Expression Languages
- XRML/MPEG 21
- ODRL

- 24

**Notes:**
There are also efforts to define rights metadata standards for specific object types.
The PLUS coalition is an international non-profit initiative on a mission to simplify and facilitate the communication and management of image rights. It includes a variety of members and is beginning to emerge as a standards body.
MPEG-21 is from the Motion Picture Experts Group that has developed many standards, including one which is a full rights expression language.
We talked about ONIX in terms of descriptive metadata, but it also is concerned with rights issues and has developed a list of licensing terms.
ODRL is a competitor of XRML/MPEG 21 (Open Digital Rights Language).  Its major difference is that it is an open standard, while XRML/MPEG 21 is proprietary and requires payment for use.

## Exercise

- Provide administrative/technical metadata for the object used in the descriptive metadata exercise

- 25

**Notes:**
We will take the same objects used for the descriptive exercise and fill in some PREMIS elements with the information provided in the session 3 exercise handout.

## 4. Metadata syntaxes and containers

- Metadata Standards and Applications Workshop

## Goals of session

- Understand syntaxes used for encoding information, including HTML, XML and RDF
- Discover how container formats are used for managing digital resources and their metadata

- 2

## Overview of Syntaxes

- HTML, XHTML: Hypertext Markup Language; eXtensible Hypertext Markup Language
- XML: Extensible Markup Language
- RDF/XML: Resource Description Framework

- 3

**Notes:**
[Point out the handout that defines some of the XML terms.]
It may not be necessary to understand these syntaxes in detail unless you are involved in using them for processing or encoding, since people don’t normally need to look at the raw data. An understanding is helpful so that you know how information can be transformed from the raw syntax to a user friendly display using widely available tools. As with learning the syntax of MARC records, for instance, it is also useful for problem solving when information doesn’t display as expected.

## HTML

- HyperText Markup Language
- HTML 4 is the current standard
- HTML is an SGML (Standard Generalized Markup Language) application conforming to International Standard ISO 8879
- Widely regarded as the standard publishing language of the World Wide Web
- HTML addressed the problem of SGML complexity by specifying a small set of structural and semantic tags suitable for authoring relatively simple documents

- 4

**Notes:**
SGML has not translated well to the web and has generally been succeeded by XML.
Use HTML for simple documents and web presentation.

## XHTML

- XML-ized version of HTML 4.0, tightens up HTML to match XML syntax
- Requires ending tags, quoted attributes, lower case, etc., to conform to XML requirements
- XHTML is a W3C specification, redefining HTML as an XML implementation, rather than an SGML implementation
- Imposes requirements that are intended to lead to more well-formed, valid XML, easier for browsers to handle

- 5

**Notes:**
HTML does not require ending tags.  XHTML makes HTML look more like XML.  It is important to know that XHTML is a subset of XML to know what it works for and what it does not work well for.

## An XHTML Example

- 6

**Notes:**
This example was created using the DC-Dot metadata generator. Note that it has a link to 2 namespaces: DC elements, DC terms. 
Note also the variable usefulness of the subject keywords.
XHTML is commonly used for digital objects on the web

## XML

- Extensible Markup Language
- A ‘*metamarkup’* *language*: has no fixed tags or elements
- Strict grammar imposes structure designed to be read by machines
- Two levels of conformance:
- well-formed--conforms to general grammar rules
- valid--conforms to particular XML schema or DTD (document type definition)

- 7

**Notes:**
XML on its own is a flexible syntax that doesn’t have a lot of specified elements.  You use whatever element sets you want to use and define them in an XML schema.  The structured grammar is for machines, not to be read by humans, although some of us have adapted to being able to read it.

## XML: Extensible Markup Language

- A technical approach to convey meaning with data
- Not a natural language, although uses natural languages
- <姓名>Louis Armstrong</姓名>
- <name>Louis Armstrong</name>
- Not a programming language
- Language in the sense of:
- A limited set of tags defines the elements that can be used to markup data
- The set of tags and their relationships need to be explicitly defined (e.g., in XML schema)
- We can build software that uses XML as input and processes them in a meaningful way
- You can define your own markups and schemas

- 8

**Notes:**
More on XML. Tags can be defined in any language and are most often codified in a schema. There is no requirement to use English tags, for instance.

## XML is the lingua franca of the Web

- Web pages increasingly use at least XHTML
- Business use for data exchange/ messaging
- Family of technologies can be leveraged
- XML Schema, XSLT, XPath, and XQuery
- Software tools widely available (open source)
- Storage, editing, parsing, validating, transforming and publishing XML
*Microsoft Office 2003* supports XML as document format (WordML and ExcelML)
*Web 2.0* applications based on XML (AJAX, Semantic Web, Web Services, etc.)

- 9

**Notes:**
There are lots of freely available tools for processing XML documents and using them for different purposes. XSLT is for XML “stylesheets”, which tell a computer how to process and/or display an XML document. It is used for many purposes, but particularly to take raw XML and display it in a user friendly form, perhaps converting from XML to HTML for display on the Web. Xpath is for linking and Xquery is for searching.
It is also becoming a preferred standard for encoding metadata (although it is not the only one).

## An XML Schema may define:

- What elements may be used
- Of which types
- Any attributes
- In which order
- Optional or compulsory
- Repeatability
- Subelements
- Logic

- 10

**Notes:**
Since XML is a common format for metadata (according to a defined XML schema), it is helpful to know what XML schema defines.

## Anatomy of an XML Record

- XML declaration--prepares the processor to work with the document and states the XML version
- Namespaces (uses xmlns:*prefix* and a URI to attach a prefix to each element and attribute)
- Distinguishes between elements and attributes from different vocabularies that might share a name (but not necessarily a definition) using association with URIs
- Groups all related elements from an application so software can deal with them
- The URIs are the standardized bit, not the prefix, and they don’t necessarily lead anywhere useful, even if they look like URLs

- 11

**Notes:**
The URI of a namespace might not be resolvable– there might not be something at the other end, but the important thing is that it is there to resolve the ambiguity.  

## XML Namespaces

- xmlns:dc=”_http://purl.org/dc/elements/1.1/”_

- XML Namespace

- Namespace Prefix

- Namespace Identifier

- 12

**Notes:**
“xmlns” is defined by the XML standard to encode the XML namespace where the schema is found.
The namespace prefix is what is used to distinguish where a given XML element comes from.

## XML Anatomy Lesson

-  <mods:genre authority=“marcgt”>bibliography /</mods:genre>

- Attribute

- End Tag

- Content

- Name

- Start Tag

- 13

**Notes:**
The pieces that come together to build an XML statement (nested within another element). For each start tag there must be an end tag. The content is the value between the tags. Attributes may be used for further information about the given tag.

## XML Validation

- XML Instance

- XML Schema

- Validator

- Valid

- Invalid

- 14

**Notes:**
Validators can check where the XML record (here seen as “XML instance”) is valid according to the schema. These are part of any XML editing software.

## XML Schema Example

- <xs:element name="software" minOccurs="0" maxOccurs="unbounded">
- 	<xs:complexType>
- 		<xs:sequence>
- 			<xs:element name="swName" minOccurs="1" maxOccurs="1" type="xs:string"></xs:element>
- 			<xs:element name="swVersion" minOccurs="0" maxOccurs="1" type="xs:string"></xs:element>
- 			<xs:element name="swType" minOccurs="1" maxOccurs="1" type="xs:string"></xs:element>
- 			<xs:element name="swOtherInformation" minOccurs="0" maxOccurs="unbounded" type="xs:string"> </xs:element>
- 			<xs:element name="swDependency" minOccurs="0" maxOccurs="unbounded" type="xs:string"> </xs:element>
- 		</xs:sequence>
- 	</xs:complexType>
- </xs:element>

- 15

**Notes:**
This XML schema example is from the PREMIS environment section.
minOccurs specifies whether it is mandatory or optional (minOccurs=“0” is optional; minOccurs=“1” is mandatory
maxOccurs specifies repeatability (maxOccurs=“1” is not repeatable; maxOccurs=“unbounded” means it can be repeated an unlimited number of times)
complexType defines additional structure of the element.
xs:sequence specifies order
Type specifies a data type (e.g. string is text; integer is number; xs:date is a special structured form of date)

## Will the following XML instance validate?

- <software>
**   ** <swName>**Windows**</swName>
** **   <swVersion>**2000**</swVersion>
** **   <swType>**Operating System**</swType>
- </software>
**How about this?**
- <swVersion>**2000**</swVersion>

- 16

**Notes:**
The second one won’t validate if the schema specifies that the element is in a container and the container element is not included. It will only validate if <software> start and end tag is there.

## Resource Description Framework

- A language for describing resources on the Web
- Structure based on “triples”
- Designed to be read by computers, not humans
- An ontology language to support semantic interoperability—understanding meanings
- Considered an essential part of the Semantic Web
- Can be expressed using XML

- Subject

- Object

- Predicate

- http://www.w3.org/RDF

- 17

**Notes:**
RDF was created in 1999 as a standard that sat on top of XML; has evolved away from encoding metadata to describing the relationships between concepts (names (people, corporate bodies, place), topics, objects

Subject = Topic
Predicate = Relationship (hierarchical, equivalent, associative)
There are a few methods to encode RDF, including in XML.

Permits infinite number of combinations which can provide a framework for the development taxonomies (thesauri, controlled vocabularies, faceted classifications)

## Some RDF Concepts

- A **Resource** is anything you want to describe
- A **Class** is a category; it is a set that comprises individuals
- A **Property** is a Resource that has a name, such as "creator" or "homepage"
- A **Property value** is the value of a Property, such as “Barack Obama" or "_http://dublincore.org_" (note that a property value can be another resource)

- 18

**Notes:**
Simple RDF concepts.
Something that is an element-property can also be considered a conceptual resource, very much like a controlled vocabulary term.

## RDF Statements

- The combination of a **Resource**, a **Property**, and a **Property value** forms a *Statement* (known also as the subject, predicate and object of a Statement), also known as “triples”
- An example *Statement*: "The editor of _http://dublincore.org/documents/usageguide_/ is Diane Hillmann"
-  The subject of the statement above is: 		  _http://dublincore.org/documents/usageguide/_
-  The predicate is: editor
-  The object is: Diane Hillmann

- 19

**Notes:**
Resource = subject
Property = predicate
Property value = object
... of an RDF statement.
These three pieces are called “triples.”

## RDF and OWL

- RDF does not have the language to specify all relationships
- Web Ontology Language (OWL) can specify richer relationships, such as equivalence, inverse, unique
- RDF and OWL may be used together
- RDFS: a syntax for expressing relationships between elements

- 20

**Notes:**
OWL is still in development and there aren’t a lot of tools yet, although it has potential. RDF and OWL are all about defining relationships between things. RDF syntax is limited in the relationships it can express. For instance there is nothing like what we have in our library authority files that mean a “see” reference, that is, here is an alternate name, but don’t use this one, used the preferred one.
RDFS is another syntax for RDF which is a schema itself (not the same as RDF/XML).

## An RDF/XML Example 

- <rdf:RDF
-     xmlns:rdf="_http://www.w3.org/1999/02/22-rdf-syntax-ns#_"
-     xmlns:dc="_http://purl.org/dc/elements/1.1/_">
-     <rdf:Description rdf:about="_http://www.dlib.org_">
-       <dc:title>D-Lib Program - Research in Digital Libraries</dc:title>
-       <dc:description>The D-Lib program supports the community of people
-        with research interests in digital libraries and electronic
-        publishing.</dc:description>
-       <dc:publisher>Corporation For National Research Initiatives</dc:publisher>
-       <dc:date>1995-01-07</dc:date>
-       <dc:subject>
-         <rdf:Bag>
-           <rdf:li>Research; statistical methods</rdf:li>
-           <rdf:li>Education, research, related topics</rdf:li>
-           <rdf:li>Library use Studies</rdf:li>
-         </rdf:Bag>
-       </dc:subject>
-       <dc:type>World Wide Web Home Page</dc:type>
-       <dc:format>text/html</dc:format>
-       <dc:language>en</dc:language>
-     </rdf:Description>
- </rdf:RDF>

- Note unordered list

- 21

**Notes:**
“Native” RDF does not need XML, but in a world that is much more comfortable with XML “packages,” it’s a useful way to move data around. 

In this RDF/XML version of a DC record, the resource URI is expressed as rdf:about rather than dc:identifier.  In both cases, the other statements (expressed here as attribute/value pairs) can be transformed into triples by associating the resource URI with each attribute/value pair.
Under <subject>, we have a list.  You can make an ordered list as well, called “seq” in RDF.

## Overview of container formats

- A container format is needed to package together all forms of metadata and digital content
- Use of a container is compatible with and an implementation of the OAIS information package concept
- METS: packages metadata with objects or links to objects and defines structural relationships
- MPEG 21 DID: represents digital objects using a flexible and expressive model

- 22

**Notes:**
Now we will turn to the use of container formats, which themselves require a syntax.
OAIS=Open Archival Information System, a widely used standard for understanding digital repositories and functions
METS is more prevalent in digital library applications, although MPEG 21 Document Item Declaration (DID) is an alternative.

## Metadata Encoding & Transmission Standard (METS)

- Developed by the Digital Library Federation, maintained by the Library of Congress
- “... an XML document format for encoding metadata necessary for both management of digital library objects within a repository and exchange of such objects between repositories (or between repositories and their users).”
- Records the (possibly hierarchical) structure of digital objects, the names and locations of the files that comprise those objects, and the associated metadata
**	****http://www.loc.gov/standards/mets/**

- 23

**Notes:**
METS was developed in response to a need to encode metadata and information about digital files in information packages.

## METS Usage

- To package metadata with digital object in XML syntax
- For retrieving, storing, preserving, serving resource
- For interchange of digital objects with metadata
- As information package in a digital repository (may be a unit of storage or a transmission format)

- 24

**Notes:**
OAIS defines 3 types of information package: Submission Information Package, Archival Information Package (storage), and Dissemination Information Package (transfer). METS can function as any of these

## Characteristics of METS 

- Open non-proprietary standard
- Extensible
- Modular
- Developed by the digital library community

- 25

**Notes:**
METS Editorial Board endorsed extension schemas for bibliographic data (MARCXML, MODS, DC), for technical metadata for still images (MIX), and technical metadata for text.

##   METS Sections 

- Defined in METS schema for navigation & browsing
- Header (XML Namespaces)
- File inventory,
- Structural Map & Links
- Descriptive Metadata (not part of METS but uses an externally developed descriptive metadata standard, e.g. MODS)
- Administrative Metadata (points to external schemas):
- Technical, Source
- Digital Provenance
- Rights

- 26

**Notes:**
Descriptive metadata describes the package itself. The METS document can be at any level of granularity in terms of the intellectual object it represents.
The METS schema only defines the first 3 sections.
File section: includes a list of all the files in the METS package
Structure map: how the structure of the object is defined; links the digital object to content files and the metadata. 

## The structure of a METS file

- 27

**Notes:**
A graphical view of the structure of METS. Behavior section was added later; there are not a lot of uses of it yet.

## Linking in METS Documents(XML ID/IDREF links)

- DescMD
- 	mods
- 		relatedItem
- 		relatedItem

- AdminMD
- 	techMD
- 	sourceMD
- 	digiprovMD
- 	rightsMD

- fileGrp
- 	file
- 	file

- StructMap
- 	div
- 	   div
- 	      fptr
- 		div
- 		   fptr

- 28

**Notes:**
The structMap (structural map) is the heart of the METS document and specifies its structure by using nested “div” elements. This shows how objects consisting of multiple files are put together. To understand METS and how it uses metadata you need to understand how linking is done.  The <div>s show hierarchy. “fptr” is called the file pointer.

## Linking in METS Documents(XML ID/IDREF links)

- DescMD
- 	mods
- 		relatedItem
- 		relatedItem

- AdminMD
- 	techMD
- 	sourceMD
- 	digiprovMD
- 	rightsMD

- fileGrp
- 	file
- 	file

- StructMap
- 	div
- 	   div
- 	      fptr
- 		div
- 		   fptr

- 29

**Notes:**
From the various hierarchical parts of the structural map you point to the relevant files in the file group.

## Linking in METS Documents(XML ID/IDREF links)

- DescMD
- 	mods
- 		relatedItem
- 		relatedItem

- AdminMD
- 	techMD
- 	sourceMD
- 	digiprovMD
- 	rightsMD

- fileGrp
- 	file
- 	file

- StructMap
- 	div
- 	   div
- 	      fptr
- 		div
- 		   fptr

- 30

**Notes:**
From the files you can point to the administrative metadata sections that apply to the particular file. Each file may be linked to multiple metadata sections.

## Linking in METS Documents(XML ID/IDREF links)

- DescMD
- 	mods
- 		relatedItem
- 		relatedItem

- AdminMD
- 	techMD
- 	sourceMD
- 	digiprovMD
- 	rightsMD

- fileGrp
- 	file
- 	file

- StructMap
- 	div
- 	   div
- 	      fptr
- 		div
- 		   fptr

- 31

**Notes:**
You can link to descriptive metadata in the descriptive metadata section for the object as a whole or for parts of the object.

## Linking in METS Documents(XML ID/IDREF links)

- DescMD
- 	mods
- 		relatedItem
- 		relatedItem

- AdminMD
- 	techMD
- 	sourceMD
- 	digiprovMD
- 	rightsMD

- fileGrp
- 	file
- 	file

- StructMap
- 	div
- 	   div
- 	      fptr
- 		div
- 		   fptr

- 32

**Notes:**
This is where METS and MODS work well together because both are hierarchical. For instance, if you have a CD with 3 tracks,  you can specify metadata (both descriptive and administrative) for each track by using MODS relatedItem type=“constituent”. We will see an example of this in the next session.

## METS extension schemas

- “wrappers” or “sockets” where elements from other schemas can be plugged in
- Provides extensibility
- Uses the XML Schema facility for combining vocabularies from different Namespaces
- Endorsed extension schemas:
- Descriptive: MODS, DC, MARCXML
- Technical metadata: MIX (image); textMD (text)
- Preservation related: PREMIS

- 33

**Notes:**
The METS Editorial Board has endorsed a number of extension schemas, although any XML format may be used.

## 	Descriptive Metadata Section (dmdSec)

- <mets>
-   **<dmdSec></dmdSec>**
-   <fileSec></fileSec>
-   <structMap></structMap>
- </mets>

- Two methods: Reference and Wrap

- 34

**Notes:**
You can insert the metadata in the METS document itself (as XML) or you can reference it, for instance as a record in a library catalog.

## METS examples

- METS with MODS
- Recorded event
- METS with MODS, PREMIS and MIX
- Portrait of Louis Armstrong (XML)
- Portrait of Louis Armstrong (presentation)

- 35

**Notes:**
Link to Recorded event. A METS document is behind the entire display that you see. Click on the very bottom of the page where it says “METS Object Description”. Point out the structural map with the various levels of the hierarchy.  The image on the right is displayed using an XSLT stylesheet which specifies display of one of the files in the file section of the METS document (the thumbnail version). The MODS record is displayed with field names as specified by the stylesheet. Additional files may be accessed or displayed from the other linked files in the file section (e.g. the concert program under “See also”). 

. 
The Louis Armstrong examples shows PREMIS metadata within METS in addition to descriptive metadata.

Click on Portrait of Louis Armstrong (XML) to show where PREMIS is included in the METS document (under amdSec/techMD and amdSec/digiProv MD). PREMIS object information (technical metadata) is under techMD and information about events (ingest and validation) is in digiProv. Linking between files to the metadata is done with the ID attribute on the files to the appropriate metadata section.
If you want show the display under Portrait of Louis Armstrong (presentation); this is derived from the METS document.

## MPEG-21 Digital Item Declaration (DID)

- ISO/IEC 21000-2: Digital Item Declaration
- An alternative to represent Digital Objects
- Starting to get supported by some repositories, e.g., aDORe, DSpace, Fedora
- A flexible and expressive model that easily represents compound objects (recursive “item”)
- MPEG DID is an ISO standard and has industry support, but is often implemented in a proprietary way and standards  development is closed; METS is open source and developed by open discussion, mainly cultural heritage community

- 36

## Abstract Model for MPEG-21 DID

*resource*

*resource*

*resource*

*component*

*component*

*descriptor/statement*

*descriptor/statement*

*descriptor/statement*

*descriptor/statement*

*item*

*item*

*container*

***resource***: datastream

***component***: binding of *descriptor/statements* to datastreams

***item***: represents a Digital Item aka Digital Object aka asset. *Descriptor/statement* constructs convey information about the Digital Item

***container***: grouping of *items* and descriptor/statement constructs pertaining to the container

- 37

**Notes:**
METS and MPEG DID are similar types of container formats in that both are expressed in XML, both represent the structure of digital objects, and both include metadata.
MPEG DID doesn’t have the segmentation in metadata sections that METS does, so this implementation decision need not be made in DID
METS is open source and developed by open discussion, mainly cultural heritage community.
It would be possible to transform a METS container to a MPEG DID and vice versa; development of stylesheets will enable transformations

## Exercise	

- Encode your resource in DC and MODS using XML
- Use the template forms provided

- 38

**Notes:**
Use the same object you used for the descriptive and technical metadata and the subset of elements provided in the exercise handout. You may need to add additional fields to repeat the tags as needed.

## 5. Applying metadata standards: Application profiles

- Metadata Standards and Applications Workshop

## Goals of Session

- Learn how metadata standards are applied and used:
- Learn about the concept and use of application profiles
- Learn about how different metadata standards may be used together in digital library applications

- 2

## Overview of session

- Use of Application profiles
- Dublin Core
- METS
- MODS
- Case study: using metadata standards together based on an application profile

- 3

## Why Application profiles?

- Describes the set of metadata elements, policies, and guidelines defined for a particular application, implementation, or object type
- Declares the metadata terms an organization, information resource, application, or user community uses in its metadata
- Documents metadata standards used in instances, including schemas and controlled vocabularies, policies, required elements, etc.
- Called “application profile” or just “profile”

- 4

**Notes:**
A number of different metadata efforts have begun to develop profiles for particular applications. This gives some guidance and rules for imposing some constraints on metadata standards that by nature are flexible.

## Function of Application Profiles

- Many metadata standards are sufficiently flexible that they need a mechanism to impose some constraints
- Profiles allow expression of the decisions made for a project in machine-readable form (XML or RDF)
- Profiles allow for enforcing those decisions
- This facilitates interoperability and common practices
- Refining
- A narrower interpretation of a standard to suit your project
- Combining
- Mixing elements from various different standards

- 5

**Notes:**
Application Profiles document the hard choices implementers make when adopting standards – for example, they reflect whether a data field is deemed mandatory or optional or simply unused for a particular project. In all of this tailoring, the application profile always remains within the limits set by the larger standard. It can narrow the scope of a standard, but it always has to still conform with the specification it originates from.

## Components of an Application Profile 

- Human readable documentation
- Property descriptions and relationships
- Domain or project specific instruction
- Obligation and constraints
- Machine-readable versions may contain:
- Specific encoding decisions and XML or RDF schemas
- Models of data relationships specific to the AP represented in the schemas
- Functional requirements and use cases supporting decisions

- 6

**Notes:**
An AP makes it possible for people to share community consensus and project decision making.  Machine-readability doesn’t guarantee that data will be interoperable, but Application Profiles make it more likely that machines will be able to cope.

## Using Properties from other Schemas

- DC APs set stringent requirements for determining reusability of terms:
- Is the term a real “property” and defined as such within the source schema?
- Is the term declared properly, with a URI and adequate documentation and support?
- In general, properties whose meaning is partly or wholly determined by its place in a hierarchy are not appropriate for reuse in DC APs without reference to the hierarchy.
- Other styles of profiles have different requirements and strategies for developing machine-readability and validation

- 7

**Notes:**
Different metadata element sets differ in terms of hierarchy in particular.  For example, Dublin Core has a flat structure.  MODS, though, involves a hierarchy, which is not easily expressed in a Dublin Core Application profile problematic.  

The debate about reuse of properties (i.e.data elements from another schema) centers around whether the additional properties use the same data model as Dublin Core. For instance, the Dublin Core Library Application Profile was originally written with several MODS elements, but the Dublin Core Usage Board rejected that approach, since MODS has so far not been modeled as RDF properties conforming to the Dublin Core Data Model (it is currently only in hierarchical XML).  Work on modeling MODS as RDF has been done at MIT and is on the agenda for the MODS Editorial Committee.

## Documenting new properties

- Minimum: a web page, with the relevant information available to other implementations
- Better: a web page and an accessible schema using your terms as part of your application profile
- Best: all terms available on a distributed registry

- 8

**Notes:**
Best practices for documenting a new element
Obligation to have a schema to back it up
Declare the schema to the registry

## Singapore Framework

- A Framework for designing metadata applications for maximum interoperability
- Defines a set of descriptive components that are necessary for documenting an Application Profile
- Forms a basis for reviewing Dublin Core application profiles
- Relates APs to standard domain models and Semantic Web standards
- http://dublincore.org/documents/singapore-framework/

- 9

**Notes:**
This work was a major output of the DCMI 2007 conference in Singapore and attempts to codify practices in creating Dublin Core Application Profiles.
Additional documentation about AP preparation has been developed, and work is progressing to finalize the framework.

## DC Application Profile Examples

- Collections AP
- http://www.dublincore.org/groups/collections/collection-application-profile/2007-03-09/
- Scholarly Works Application Profile (SWAP)
- http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_Application_Profile
- Both these have been reviewed by the DC Usage Board and are deemed compliant with the DC Abstract Model

- 10

## An RDA Application Profile

- A DCMI/RDA Task Group has been defining RDA properties and value vocabularies as formal RDF vocabularies (with URIs)
- IFLA has stated an intention to declare FRBR entities and attributes as well
- Next step is a DC application profile of RDA according to the Singapore Framework
- See http://metadataregistry.org for the provisionally registered properties/vocabularies

- 11

## METS Profiles

- Description of a class of METS documents
- provides document authors and programmers guidance to create and process conformant METS documents
- XML document using a schema
- Expresses the requirements that a METS document must satisfy
- “Data standard” in its own right
- A sufficiently explicit METS Profile may be considered a “data standard”
- METS Profiles are output in human-readable prose and not intended to be “machine actionable” (but they use a standard XML schema)

- 12

**Notes:**
METS also has the concept of application profiles (called just “profiles”). 
Although not intended to be machine actionable, the standard syntax used can allow for validating a METS document for conformance to a given profile.

##  Components of a METS  Profile 

- Unique URI
- Short Title
- Abstract
- Date and time of creation
- Contact Information
- Related profiles

- Extension schemas
- Rules of description
- Controlled vocabularies
- Structural requirements
- Technical requirements
- Tools and applications
- Sample document

- 13

**Notes:**
These are components that are defined in the formal METS profile schema.

## Case study of a METS Profile 

- LC Audio Compact Disc Profile
- Features:
- Specifies MODS for descriptive metadata
- Specifies description rules as AACR2
- Specifies controlled vocabularies used in various elements
- dmdSec requirements 2 and 3 specify use of relatedItem type=“constituent” if there are multiple works on the CD
- Specifies how to detail the physical structure, whether multiple CDs or multiple tracks on a CD (structMap requirements 2 and 3)

- 14

**Notes:**
Link to the LC audio compact disc profile. The link is to the HTML display (the XML file is the same URL but with file extension “xml” instead of “html”). 
The profile is too detailed to go into in depth. Note the specification of controlled vocabularies used and how structural metadata is expressed in the METS structMap. 

## MODS Profiles

- Some applications are establishing MODS profiles to document usage, required elements, controlled vocabularies used, etc.
- Some examples:
- DLF Aquifer MODS profile: to establish implementation guidelines for rich shared metadata for cultural heritage materials
- British Library electronic journal MODS profile

- 15

**Notes:**
We are beginning to also see MODS profiles, again to specify specific rules, guidance, controlled vocabularies for particular applications.
DLF Aquifer has developed rich guidelines that institutions are starting to use as a metadata standard for exchange or harvest of descriptive metadata.
The BL electronic journal MODS profile is under development for a project involving legal deposit of ejournals using MODS for its descriptive metadata. (It also uses METS and PREMIS.)

## Using metadata standards together: a case study

- METS can be used to package together the metadata with the objects
- METS allows for use of any XML metadata schema in its extensions
- MODS works well with METS for descriptive metadata and can be associated with any level of the description
- Technical metadata can be inserted and associated with specific files
- METS can be used as a digital library application if objects are based on a profile and thus are consistent

- 16

**Notes:**
We will look at how we can apply metadata standards in a digital library application using METS as the container. The METS container is used to bundle together the metadata as well as specify the files and their locations that are part of the entity. Objects based on a profile are consistent so that consistent behaviors can be applied, e.g. web presentations, page turning applications, etc.

## <dmdSec> with MODS Extension Schema

**<mets:mets>**
**  ...**
**  ****<mets:dmdSec>**
**    ****<mets:mdWrap>**
**      ****<mets:xmlData>**
**        ****<mods:mods></mods:mods>**
**      ****</mets:xmlData>**
**    ****</mets:mdWrap>**
**  ****</mets:dmdSec>****	****	****	**
**  ...****</mets:mets>**

*Descriptive metadata section*

*MODS data contained inside the  metadata wrap section*

*Use of prefixes before element names to identify schema*

- 17

**Notes:**
This set of slides illustrates how METS and MODS work together in a digital library application. As we learned already, descriptive metadata may be inserted (“mdWrap”) in a METS descriptive metadata section. The use of prefixes shows the authority for the XML schema used and how two different namespaces are used in the same document.

##  <mods:mods>

**      ****<mods:titleInfo>**
**          ****<mods:title>****Bernstein conducts Beethoven**** ****</mods:title>**
**      ****</mods:titleInfo>**
**      ****<mods:name>**
**          ****<mods:namePart>****Bernstein, Leonard****</mods:namePart>**
**      ****</mods:name>**
**      ****<mods:relatedItem type="constituent">**
**          ****<mods:titleInfo>**
**	****<mods:title>****Symphony No. 5****</mods:title>**
**          ****</mods:titleInfo>**
**          ****<mods:name>**
**	**** ****<mods:namePart>****Beethoven, Ludwig van****</mods:namePart>**
**          ****</mods:name>**
**                ****<mods:relatedItem  type="constituent">**
**	****       ****<mods:titleInfo>**
**	****           ****<mods:partName>****Allegro con moto****</mods:partName>**
**	****       ****</mods:titleInfo>**
**	**** ****</mods:relatedItem>**
**	**** ****<mods:relatedItem type="constituent">**
**	****        ****<mods:titleInfo>**
**	****           ****<mods:partName>****Adagio****</mods:partName>**
**	****        ****</mods:titleInfo>**
**	**** ****</mods:relatedItem>**
**      ****</mods:relatedItem>**
** ****</mods:mods>**

- 18

**Notes:**
Here is a simple illustration of a logical hierarchy created with relatedItems (using an audio CD). There are actually 3 levels of description: the item itself (the CD), a work contained within it (Symphony No. 5) and a movement within that work (Allegro con moto). The MODS hierarchy in relatedItem allows for this nested description.
This object uses the compact disc profile we just looked at, which specified how to detail the descriptive metadata of the components in the descriptive metadata section.

## Use of MODS relatedItem type=“constituent”

- A first level child element to MODS
- relatedItem element uses MODS content model
- titleInfo, name, subject, physicalDescription, note, etc.
- Makes it possible to create rich analytics for contained works within a MODS record
- Repeatable and nestable recursively
- Making it possible to build a hierarchical tree structure
- Makes it possible to associate descriptive data with any structural element

- 19

## METS 2 Hierarchies: Logical & Physical 

**<mets:mets>**
**  ****<mets:dmdSec>**
**    ****<mets:mdWrap>**
**      ****<mets:xmlData>**
**        ****<mods:mods>**
**           ****<mods:relatedItem>**
**             ****<mods:relatedItem></mods:relatedItem>**
**           ****</mods:relatedItem>**
**        ****</mods:mods>**
**      ****</mets:xmlData>**
**    ****</mets:mdWrap>**
**  ****</mets:dmdSec>****	****	****	**
**  ****<mets:fileSec></mets:fileSec>**
**  ****<mets:structMap>**
**    ****<mets:div>**
**      ****<mets:div></mets:div>**
**    ****</mets:div>**
**  ****</mets:structMap>**
**</mets:mets>**

*Hierarchy to represent “logical” structure (nested relatedItems) *

*Hierarchy to represent “physical” structure (nested div elements)*

- 20

**Notes:**
We can associate the physical items detailed in the METS structMap with any part of the hierarchy for the logical structure.

## Multiple Inputs to Common Data Format

- New DigitalObjects

- LegacyDatabase

- Profile-basedMETSObject

*A common data format for searching and display*

- Harvest of American Memory Objects

- 21

**Notes:**
In the case of METS/MODS digital library projects, LC is taking metadata from different sources and using them in METS objects that are based on defined profiles. Examples are records from the ILS that are converted to MODS, non-MARC records from American Memory and records newly cataloged using MODS. This provides a common data format for searching and display. Use of an application profile allows for consistent processing of the document in terms of descriptive metadata conversion, display and searching when bringing together metadata from different sources.

## Example: Using a profile as an application

- METS Photograph Profile
- William P. Gottlieb Collection*Portrait of Louis Armstrong*
- Photographic object

- Convert file of 1600 MARC records, using *marc4j*, to XML modsCollection (single file).
- Used XSLT stylesheet to create 1600 records conforming to the METS photograph profile.

- 22

**Notes:**
Here is an example of the use of a profile with MODS metadata and METS as a container format. It allows us to use METS not only as a container, but also as an application.
This uses the Photographic object profile. Records were converted from MARC to MODS. The profile allows for consistency and for the application of an XSLT stylesheet for presentation.
Link to this Portrait of Louis Armstrong and see how it is presented on the web. See (on the left of the screen) that there are 3 versions detailed in this METS document: the original negative, the contact print with annotations, and the published print.

## Logical & Physical Relationships

**<****mods:mods**** ID="ver01">**
**  ****<mods:titleInfo>**
**    ****<mods:title>****Original**** ****Work****</mods:title>**
**  ****</mods:titleInfo>**
**<****mods:relatedItem type="otherVersion****" ID="ver02">**
**    ****<mods:titleInfo>**
**      ****<mods:title>****Derivative ****Work 1****</mods:title>**
**    ****</mods:titleInfo>**
**</mods:relatedItem>**
**<****mods:relatedItem type="otherVersion****" ID="ver03">**
**    ****<mods:titleInfo>**
**      ****<mods:title>****Derivative ****Work 2****</mods:title>**
**    ****</mods:titleInfo>**
**</mods:relatedItem>**
**</mods:mods>**

**Physical (METS structMap)**
**<mets:structMap>**
**   ****<mets:div TYPE="photo:photoObject“****                     DMDID="MODS1">**
**      ****<mets:div TYPE="****photo:version****"**** ****DMDID="ver01">**
**        ****<mets:div TYPE="photo:image">**
**          ****<mets:fptr FILEID="FN10081"/>**
**        ****</mets:div>**
**      ****</mets:div>**
**     ****<mets:div TYPE="****photo:version****"** **DMDID=“ver02">**
**      ****<mets:div TYPE="photo:image">**
**       ****<mets:fptr FILEID="FN10090"/>**
**      ****</mets:div>**
**      ****<mets:div TYPE="****photo:version****"** **DMDID="ver03">**
**        ****<mets:div TYPE="photo:image">**
**          ****<mets:fptr FILEID="FN1009F"/>**
**        ****</mets:div>**
**       ****</mets:div>**
**      ****</mets:div>**
**   ****</mets:div>**
**</mets:structMap>**

- mods:mods* and *mods:relatedItem type ="otherVersion"* **elements create a sequence of 3 nodes*

- div TYPE=“photo:version”* elements correspond to the 3 nodes using a logical sequence of ID to DMDID relationships*

- 23

**Notes:**
The linking ID is used to show how the logical structure in the structural map relates to what is described in the MODS record. In this case there is an original and 3 derivative items (a common case in digitization projects). Information for each is given in MODS related item and related to the “div” in the structMap. The files for which the metadata is given is linked by the FILEID to the file section in the METS document.

## Using a METS profile-based approach

- Ability to model complex library objects
- Use of open source software tools
- Use of XML for data creation, editing, storage and searching
- Use of XSLT for...
- Legacy data conversion
- Batch METS creation and editing
- Web displays and behaviors
- Creation of multiple outputs from XML
- HTML/XHTML for Web display; PDF for printing
- Ability to aggregate disparate data sources into a common display

- 24

## Closing thoughts on application profiles

- Many metadata standards are sufficiently flexible that profiling is necessary
- Documenting what is used in an application will simplify and enhance data presentation, conversion from other sources, ability to provide different outputs
- Constraining a metadata standard by specifying what is used and how facilitates data exchange and general interoperability

- 25

## Exercise: critique an application profile

- University of Maryland Descriptive Metadatahttp://www.lib.umd.edu/dcr/publications/taglibrary/umdm.html
- UVa DescMeta http://lib.virginia.edu/digital/metadata/descriptive.html
- Texas Digital Library profile for electronic theses and dissertations
- 	http://www.tdl.org/documents/ETD_MODS_profile.pdf

- 26

**Notes:**
Divide into 3 groups to do this exercise. We will only look at descriptive metadata application profiles for this exercise.
Note to instructor: The link for the Texas digital library profile doesn’t work by clicking on it. You will need to copy and paste the URI into a web browser (it is the correct one) if you want to show it. Copies of this document are being provided in the student manuals.

## Exercise: Questions to address

- Does the profile define its user community and expected uses?
- How usable would the profile be for a potential implementer?
- How (well) does the profile specify element/term usage?
- How (well) does the profile define and manage controlled vocabularies?
- Does the profile use existing metadata standards?
- Are there key anomalies, omissions, or implementation concerns?

- 27

## 6. Controlled vocabularies

- Metadata Standards and Applications Workshop

## Goals of Session

- Understand how different controlled vocabularies are used in metadata
- Learn about relationships between terms in thesauri
- Understand methods of encoding vocabularies
- Learn about how registries are used to document vocabularies

- 2

## Why controlled vocabularies? 

- Document values that occur in metadata
- Goal is to reduce ambiguity
- Allow for control of synonyms
- Establish formal relationships among terms (where appropriate)
- Test and validate terms
- Role of metadata registries

- 3

**Notes:**
Many metadata schemes allow for content from other sources. Some data elements may be more useful if a controlled vocabulary is used. Some are published formally, others are developed and used locally.
Formal controlled vocabularies may be used for testing and validation of terms– this is often done in integrated library systems, where bibliographic records may validate against authority records. This is one instance of testing and validation of terms. There is work being done on establishing metadata registries for both documentation and machine validation of both controlled vocabularies and metadata elements/terms. This could be particularly useful for controlled vocabularies, since their usefulness depends on consistency.

## Why bother?

- To improve retrieval, i.e., to get an optimum balance of _precision_ and _recall_
- _Precision_ – How many of the retrieved records are relevant?
- _Recall_ – How many of the relevant records did you retrieve?

- 4

**Notes:**
Research in library science shows that precision and recall ARE important to people
Precision:  how much is noise and garbage?

## Improving Recall and Precision

- Controlled Vocabularies improve recall by addressing synonyms [attire vs. dress vs. clothing]
- Controlled Vocabularies improve precision by addressing homographs [bridge (game) vs. bridge (structure) vs. bridge (dental device)]

- 5

**Notes:**
All these “bridges” are very different things!

## Types of Controlled Vocabularies

- Lists of enumerated values
- Synonym rings
- Taxonomy
- Thesaurus
- Classification Schemes
- Ontology

- 6

**Notes:**
NISO has a standard for constructing thesauri (free download – in bibliography)
ANSI/NISO Z39.19-2005:  Guidelines for the Construction, Format, and Management of Monolingual Controlled Vocabularies

## Lists

- A _list_ is a simple group of terms
*    **Example:*
- Alabama
- Alaska
- Arkansas
- California
- Colorado
**. . . .**
-    Frequently used in Web site pick lists and pull down menus

- 7

**Notes:**
With these kind of lists, the user is assumed to know what the values mean, or close enough. 
There are also cases where enumerated lists are used in metadata schemes, perhaps in XML schemas. It would be useful if definitions were available for such values. An example is the PREMIS data dictionary, which has suggested value lists in the descriptions of the elements that take a controlled value.

## Synonym Rings

- Synonym rings  are used to expand queries for content objects
- If a user enters any one of these terms as a query to the system, all items are retrieved that contain any of the terms in the cluster
- Synonym rings are often used in systems where the underlying content objects are left in their unstructured natural language format
- the control is achieved through the interface by drawing together similar terms into these clusters
- Synonym rings are used in conjunction with search engines and provide a minimal amount of control of the diversity of the language found in the texts of the underlying documents

- 8

**Notes:**
Unstructured:  for example, full text searching.
Attempts to deal with the evolution of language over time

## Taxonomies

- A *taxonomy *is a set of preferred terms, all connected by a hierarchy or polyhierarchy
*   **Example:*
*Chemistry*
*	**Organic chemistry*
*	**	**Polymer chemistry*
*	**	**	**Nylon*
- Frequently used in web navigation systems

- 9

**Notes:**
“Nylon” could appear in other hierarchies as well, for example taxonomies of biological terms

## Thesauri

- A *thesaurus* is a controlled vocabulary with multiple types of relationships
-    *Example:*
- Rice
-     UF paddy
- BT Cereals
- BT Plant products
- NT Brown rice
- RT Rice straw

- 10

**Notes:**
LCSH could be considered a thesaurus.

## Ontology

- One definition: “An arrangement of concepts and relations based on an underlying model of reality.”
- Ex.: Organs, symptoms, and diseases in medicine
- No real agreement on definition—every community uses the term in a slightly different way

- 11

**Notes:**
Ontology:  this word has been used and misused.  

## Thesaural Relationships

- Relationship types:
- Use/Used For – indicates preferred term
- Hierarchy – indicates broader and narrower terms
- Associative – almost unlimited types of relationships may be used
-    It is the most complex format for controlled vocabularies and widely used.

- 12

**Notes:**
Thesauri are the most useful, and work is being done in making them more useful in terms of coding.
A hierarchy lets you build many different levels.
Associative relationships can be expressed in different ways.

## 13

**Notes:**
Note that Z39.19 is the content standard for establishing controlled vocabularies (it is independent of syntax used for expressing them).

## Z39.19 Types of Concepts

- Things and their physical parts
- Materials
- Activities or processes
- Events or occurrences
- Properties or states of persons, things, materials or actions
- Disciplines or subject fields
- Units of measurement
- Unique entities

- 14

**Notes:**
Concepts are categorized in this way because of the importance of associating things.

## Examples

- Birds (things)
- Ornithology (discipline)
- Feathers (materials)
- Flying (activity or process)
- Bird counts (event)
- Barn Owl (unique entity)

- 15

**Notes:**
These examples are drawn from birds.

## Relationships

- Equivalence
- Hierarchical
- Associative

- 16

**Notes:**
This is the big piece of any thesaurus.

## Equivalence Relationships

- Term A and Term B overlap completely

- A = B

- 17

**Notes:**
We will review some of the relationships that are possible between controlled terms. 

## Hierarchical Relationships

- Term A is included in Term B

- B

- A

- 18

**Notes:**
One is broader; the other is narrower.

## Associative Relationships

- Semantics of terms A and B overlap

- A

- B

- 19

**Notes:**
Semantics are the meaning– associative relationships partially overlap.

## Expressing Relationship

| Relationship | Rel. Indicator | Abbreviation |
| --- | --- | --- |
| Equivalence
  (synonymy) | Use
Used for | None or U
UF |
| Hierarchy | Broader term
Narrower term | BT
NT |
| Association | Related term | RT |

- 20

**Notes:**
Thesauri have conventions for expressing relationships.

## Vocabulary Management

- The degree of control over a vocabulary is (mostly) independent of its type
**Uncontrolled **– Anybody can add anything at any time and no effort is made to keep things consistent
**Managed **– Software makes sure there is a list that is consistent (no duplicates, no orphan nodes) at any one time. Almost anybody can add anything, subject to consistency rules
**Controlled **– A documented process is followed for the update of the vocabulary. Few people have authority to change the list. Software may help, but emphasis is on human processes and custodianship

- 21

**Notes:**
Formal expression of vocabularies
Not folksonomies, not tagging
If you control a vocabulary, the degree of control depends on what kind of vocabulary it is.
A controlled vocabulary is based on a documented process.

## Informal Vocabularies

- New movement towards ‘bottom up’ classification goes by many names:
- Tagging
- Social bookmarking
- Folksonomies
- Some in this movement, seeing problems of scale, are moving towards more formalization—others are reframing the vocabulary issue

- 22

## Libraries/Museums and Tagging

- Penn Tags
- Still experimental, primarily internal to Penn
- http://tags.library.upenn.edu/help/
- Library of Congress Flickr project
- Open public tagging, still unclear how results will be used
- http://www.flickr.com/photos/library_of_congress/
- The Art Museum Social Tagging Project
- Research/software project focused on museum application
- http://www.steve.museum/

- 23

## Encoding Controlled Vocabularies

- MARC 21
- Authority Format used for names, subjects, series
- Classification Format used for formal classification schemes
- MADS (a derivative of MARC)
- Simple Knowledge Organization System (SKOS)
- Intended for concepts

- 24

**Notes:**
We already encode vocabularies for machine manipulation and other activities, for example the MARC authority and classification formats. 
We already looked at MADS, another means of encoding the sorts of controlled vocabularies covered by the MARC authority format.
SKOS is used for topical kinds of concepts (we will learn more about this shortly). 

## New/Upcoming Standards:Authorities

- Functional Requirements for Authority Data (FRAD)
- A new model for authority information
- Developed by the IFLA Working Group on Functional Requirements and Numbering of Authority Records (FRANAR)
- VIAF (Virtual International Authority File)
- Prototype at: http://orlabs.oclc.org/viaf/
- A Review of the Feasibility of an International Authority Data Number (ISADN)
- Simple Knowledge Organization System (SKOS)—a W3C standard

- 25

**Notes:**
FRAD is in process to be released in final form shortly; comments being added now from second review phase.  The numbering of authority records is also a critical piece of the problem, and the paper outlines these issues.

## Functions of the Authority File

- Document decisions
- Serve as reference tool
- Control forms of access points
- Support access to bibliographic files
- Link bibliographic and authority files
*(Slide from Glenn Patton) *

- 26

**Notes:**

As a step toward understanding how authority data is used currently in the library context, the group has identified five functions of an authority file:

First, the authority file documents decisions made by the cataloger when choosing the appropriate controlled access points for a new bibliographic record or when formulating new access points.

Second, information in an authority file serves as a reference tool for those same two activities as well as providing information that can be used in distinguishing one person, corporate body or work from another.  It may also serve to help the cataloger to determine that none of the access points in the authority file is appropriate and that a new access point is needed.  It can also serve a broader reference function for other library staff.

Third, the authority file can be used to control the forms of access points in bibliographic records and, in an automated environment, change those access points when the authority record itself is changed.

## FRANAR Concept Model, top

- 27

**Notes:**
As is quite obvious, the FRBR model is the starting point for the FRANAR concept model—note on the bottom left hand corner that there are more relationships coming ...

## FRANAR Concept Model, bottom

- 28

**Notes:**
Here you can see that the name and identifier for the entities above are critical, no matter what the entity.  These are related to the controlled access point, governed by rules, and created, modified and applied by an agency of some kind. 

## FRAD person attributes

**From FRBR (AACR2 additions to names):**Dates associated with the personTitle of personOther designation associated with the person
**New:**GenderPlace of birthPlace of deathCountryPlace of residenceAffiliationAddressLanguage of personField of activityProfession/occupationBiography/history
*(Slide from Ed Jones)*

- 29

**Notes:**
FRAD’s got all the FRBR attributes—”additions to names” in AACR2 parlance—plus a passel of new ones

Where did these new attributes come from?

Gender   UNIMARC Authorities

Others   EU practice

## SKOS

- “SKOS Core provides a model for expressing the basic structure and content of concept schemes such as thesauri, classification schemes, subject heading lists, taxonomies, 'folksonomies', other types of controlled vocabulary, and also concept schemes embedded in glossaries and terminologies.”
*--SKOS Core Guide*

- 30

**Notes:**
Documentation for SKOS is in the bibliography.  SKOS is intended to cover everything and more than what is included in the NISO thesaurus standard. SKOS is developed and maintained the W3C (World Wide Web Consortium) Semantic Web Deployment Working Group (SWDWG). 

## SKOS & RDF

- A World Wide Web Consortium (W3C) standard
- Based on RDF and OWL
- Data linked to and/or merged with other data
- Data sources distributed across the web
- http://www.w3.org/2004/02/skos/

- 31

**Notes:**
From SKOS Core Guide
As you can see, SKOS has a high level goal. It is still under development; most recent specification is SKOS Reference (2nd Working Draft, 9 June 2008).

## The skos:Concept class allows you to assert that a resource is a conceptual resource. That is, the resource is itself a concept. 

- 32

**Notes:**
A SKOS conceptual resource is not a physical object.

“The SKOS Core Vocabulary is an application of the Resource Description Framework (RDF), that can be used to express a concept scheme as an RDF graph. Using RDF allows data to be linked to and/or merged with other data, enabling data sources to be distributed across the web, but still be meaningfully composed and integrated.”
--SKOS Core Guide

## Preferred and Alternative Lexical Labels

- 33

**Notes:**
“Animals” has a preferred label = animals
“Animals” has an alternate label = creatures
This could be used to generate text such as:
Creatures SEE Animals
Animals USE FOR Fauna

## The RDF/XML Encoded Version

- 34

**Notes:**
Concept is in this vocabulary
Preferred label is Animals
Alternate labels are Creatures, Fauna

## Example of ISO 639-2 language code in SKOS

- <rdf:Description rdf:about= "http://www.loc.gov/standards/registry/vocabulary/iso639-2/por">                    <rdf:type  rdf:resource="http://www.w3.org/2008/05/skos #Concept"/>  	<skos:prefLabel xml:lang="x-notation">por</skos:prefLabel> 	<skos:altLabel xml:lang="en-latn">Portuguese</skos:altLabel> 	<skos:altLabel xml:lang="fr-latn">portugais</skos:altLabel> 	<skos:notation rdf:datatype="xs:string">por</skos:notation> 	<skos:definition xml:lang="en-latn">This Concept has not yet been 	defined.</skos:definition>
- 	<skos:inScheme rdf:resource= 	"http://www.loc.gov/standards/registry/vocabulary/iso639-2"/> 	<vs:term_status>stable</vs:term_status>
- 	<skos:historyNote rdf:datatype="xs:dateTime">2006-07-	19T08:41:54.000-05:00</skos:historyNote>
-  	<skos:exactMatch rdf:resource= 	"http://www.loc.gov/standards/registry/vocabulary/iso	639-1/pt"/>
- 	<skos:changeNote rdf:datatype="xs:dateTime">2008-07-	09T13:49:05.321-04:00</skos:changeNote>
-  </rdf:Description>

- 35

**Notes:**
This is one type of SKOS expression, which is RDF/XML. Tags defined by SKOS a wrapped in an RDF wrapper. skos:prefLabel uses the language code as value so as to not give a preference to a term in a particular language.  The skos:altLabel is used here for the various language names
skos:inScheme tells you what concept scheme this entry is included in; there can be multiples.
skos:exactMatch gives a URI for the other code which is exactly the same; in this case there is the 2-character code “pt” (ISO 639-1), which is equivalent to this one.

## Registries: the Big Picture

- (Adapted from Wagner & Weibel, “The Dublin Core Metadata Registry: Requirements, Implementation, and Experience” JoDI, 2005)

- 36

**Notes:**
How does all of this encoding of these concepts, etc. work?
Coupled with registries, it allows you to do certain things.
We’ve been able to support traditional library vocabularies because of institutional commitments.  But for others, use registries.
Between Interoperate & Discover:  Express 
Between Standardize and Interoperate:  Register
Could use MADS or SKOS to expose vocabularies.  SKOS is better for subjects and handles concepts well.
E-Card is an encoding standard for names
If you want vocabularies to be available for use by others, you must document and publish them.

## Why Registries?

- Support interoperability
- Discovery of available schemes and schemas for description of resources
- Promote reuse of extant schemes and schemas
- Access to machine-readable and human-readable services
- Support for crosswalking and translation
- Coping with different metadata schemes

- 37

**Notes:**
You can (should) register metadata schemes, values used in your controlled vocabularies.
Registries may also be used to support crosswalks and translations.
Registries may assist in coping with different metadata schemes if machine readable crosswalks are available.

## Declaration, documentation, publication

- To identify the source of a vocabulary, e.g., a term comes from LCSH, as identified in my metadata by a URI
- To clarify a term and its definition
- To publish controlled vocabularies and have access to information about each term

- 38

**Notes:**
These are the pieces that are important for building the infrastructure that makes good metadata function.
Most of these steps can be done by anyone.  Some are building up our support this way– distributed support, rather than centralized support. Even the registry portions (still being built) will be distributed. There is also a place for centrally published controlled vocabularies, where a maintenance agency takes control for a given standard.

## Some uses for registries

- Metadata Schemas
- Crosswalks between metadata schemas
- Controlled Vocabularies
- Mappings between vocabularies
- Application Profiles
- Schema and vocabulary information in combination

- 39

**Notes:**
Although many registries are now only registering schemas, the intention is that all these pieces need registration and management for the benefit of all. 

## Metadata registries

- Some are formal, others are informal lists
- Some formal registries:
- Dublin Core registry of DC terms
- NSDL registry of vocabularies used
- Experiment at:
- 	http://sandbox.metadataregistry.org
- LC is establishing registries
- MARC and ISO code lists
- Enumerated value lists
- LCSH in SKOS (example: http://id.loc.gov/authorities/sh85118553)

- 40

**Notes:**
We will be seeing more work in the future in this area. Formal registries allow reuse of data standards in a broader community than that which developed it.
Click on the link for LCSH in SKOS to see a prototype of how LCSH in SKOS might be used.

Remind the trainees that there is a whole other course on controlled vocabularies as part of the Cataloging for the 21st Century series of workshops.

## Example from Dublin Core Registry—Term Level

- 41

**Notes:**
Gives terms, definitions, translations into other languages, versions. Optimized for multi-language capability.
Can view in different encodings (RDF/XML for example).
Dublin Core manages the DCMI type vocabulary—this registry is intended only for DC terms currently.

## 	7. Approaches to Models of       Metadata Creation, Storage and Retrieval 

- Metadata Standardsand Applications

## Goals of Session

- Understand the differences between traditional vs. digital library
- Metadata Creation
- Storage, and
- Retrieval/Discovery

- 2

## Creating metadata records

- The “Library Model”
- Trained catalogers, one-at-a-time metadata records
- The “Submission Model”
- Authors create metadata when submitting resources
- The “Automated Model”
- Automated tools create metadata for resources
- “Combination Approaches”

- 3

## The Library Model

- Records created “by hand,” one at a time
- Shared documentation and content standards (AACR2, etc.)
- Efficiencies achieved by sharing information on commonly held resources
- Not easily extended past the granularity assumptions in current practice

- 4

**Notes:**
Efficiencies are achieved by decades’ worth of developing agreements and shared models.

## The Submission Model

- Based on author or user generated metadata
- Can be wildly inconsistent
- Submitters generally untrained
- May be expert in one area, clueless in others
- Often requires editing support for usability
- Inexpensive, may not be satisfactory as  an only option

- 5

**Notes:**
“Submission” model developed with the idea that people who are submitting information will create the metadata.
Assumption that the submitter can reliably create their own metadata.
Usually done at universities with professors as authors. 

## The Automated Model

- Based largely on text analysis; doesn’t usually extend well to non-text or low-text
- Requires development of appropriate evaluation and editing processes to support even minimal quality standards
- Still largely research; few large, successful production examples
- One simple automated tool to try: http://www.ukoln.ac.uk/metadata/dcdot/
- Automated model may be more efficient for  for technical metadata

- 6

**Notes:**
Some use natural language processing, text analysis.  At least, machines are consistent.  It’s hard to use a purely automated approach.

Also works for technical metadata. 

## Combination Approaches

- Combination machine and human created metadata
- Ex.: LC Web Archives (http://www.loc.gov/minerva)
- Ex.: INFOMINE (http://infomine.ucr.edu/)
- Combination metadata and content indexing
- Ex.: NSDL (http://nsdl.org)

- 7

**Notes:**
The machine and human approach is used at LC for the Web Archives collections.

MINERVA: For the various collections, tools were used to extract some metadata. Rights information was extracted from the Leaderboard (the project’s permissions tracking tool). Other metadata was extracted from the Web “ARC” files (a file format used for harvested websites used by the Internet Archive). Additional metadata was boiler-plated in when it applied to all records (e.g. the genre “website”).
Some descriptive and technical metadata can be extracted from the file, e.g., file type...
Preliminary keyword, title, and subject metadata were extracted from the archived Web sites to create preliminary MODS records that were subsequently reviewed and/or enhanced by catalogers who assigned controlled subjects from Library of Congress Subject Headings (LCSH) or Thesaurus of Graphic Materials (TGM). A Lucene search interface was developed to search the MODS records both within and across the archived collections.

NSDL—link from metadata provides access to indexing software; index data used in combination with metadata to provide access
In practice, it has not been honed well.  Users get unanticipated results but don’t know why and are sometimes frustrated by this.

## Content “Storage” Models

- ‘Storage models’ in this context relates to the relationships between metadata and content (not the systems that purport to ‘store’ content for various uses)
- These relationships affect how access to the information is accomplished, and how the metadata either helps or hinders the process (or is irrelevant to it)

- 8

**Notes:**
We come from an environment in which content and metadata are separate things.  In the digital world, that’s not always the assumption.  Decisions about that relationship affect access, etc. 
We have seen how metadata can be packaged w/ the objects in digital library applications and the way metadata can be used in retrieval and management. 

## Common ‘Storage’ Models

- Content with metadata
- Metadata only
- Service only

- 9

**Notes:**
Content management systems:  metadata stored with content
A METS file bundles together content with metadata (by either embedding or providing links to files)
Metadata only example:  library catalogs
Will talk about “service only” model as we go along

## Content with metadata

- Examples:
- HTML pages with embedded ‘meta’ tags
- Most content management systems (though they may store only technical or structural metadata)
- Text Encoding Initiative (TEI), ), a full-text markup language (as an example of an application, see the Comic Book Markup Language at http://www.cbml.org/)
- Often proves difficult to update and not optimized to manage metadata over time

- 10

**Notes:**
There are not many HTML “meta” tags embedded.  Search engines don’t’ use them because spammers and others have abused them.  
Metadata sometimes is not flexible enough—doesn’t allow repeatable elements, often optimized to managing the content and not the metadata.  Bibliographic information is not static information.
Image files have technical metadata w/content. e.g., size, format, settings...TIF, GIF, JPG

## Metadata only

- Library catalogs
- Web-based catalogs often provide some services for digital content
- Electronic Resource Management Systems (ERMS)
- Provide metadata records for title level only
- Metadata aggregations
- Using API or OAI-PMH for harvest and re-distribution

- 11

**Notes:**
There might be links to services like licensed content.
Traditional cataloging in library catalogs is usually title level, not at the article level.
Metadata aggregations are analogous to OCLC or RLG.
API: Abbreviation of application program interface, a set of routines, protocols, and tools for building software applications (definition from Webopedia)
OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting)

This metadata may be reused, converted to new formats, and packaged with content (e.g., METS)

## 	Service only

- Often supported partially or fully by metadata
- Google, Yahoo (and others)
- Sometimes provide both search services and distributed search software
- Electronic journals (article level)
- Linked using ‘link resolvers’ or available independently from Websites
- Have metadata behind their services but don’t generally distribute it separately

- 12

**Notes:**
Think about: The services mentioned here are supported partially or fully by metadata.
Google: think of “page rank” as a form of metadata (not descriptive as we’re used to). Yahoo began as a more “library-like” service with human categorization but now uses more of a search model.
“Website powered by Google” an example of distributed service software.
Will talk a little later on about how link resolvers are often metadata based
Non-distributed metadata can’t be incorporated directly into your own services

## Common Retrieval Models

- Library catalogs
- Web-based (“Amazoogle”)
- Portals and federations

- 13

**Notes:**
“Amazoogle” = Amazon and Google

## Library Catalogs

- Based on a consensus that granular metadata is useful
- Expectations of uniformity of information content and presentation
- Designed to optimize recall _and_ precision
- Addition of relevance ranking and keyword searching of limited value (only ‘text’ used is the metadata itself)
- Retrieval options limited by LMS vendor decisions

- 14

**Notes:**
We catalog things at a particular level of granularity and not much above or below that (books, not chapters; serials, not articles). This can be confusing to users who might expect more integration with other search services. 
Movement towards unbundling library management systems and separating the user interface from the back-end management is in early stages but worth watching.  OCLC’s WorldCat Local is being explored by some libraries as an alternative to the OPAC. There are other efforts trying to enhance the user experience.

We have traditionally cataloged things at a particular level of granularity and not much above or below that.  We’re finding ways to link to records which are more granular. Things are evolving...
Keyword searching is limited to the text of metadata, not the text of the object, which limits its usefulness, particularly for those use to a Google approach.
Movement towards unbundling library management systems and making catalogs better is in early stages but worth watching.

## 	New Library Catalogs

- ENDECA
- North Carolina State University Libraries in 2006, was one of the first to experiment with new catalog technologies using legacy metadata
- eXtensible Catalog Project
- University of Rochester attempting to provide a FRBR-ized catalog and integrated access to previously “silo-ed” data managed by libraries.

- 15

**Notes:**
Endeca raised $10M that it used to operate as a research company looking at new ideas and opportunities for overcoming the constraints of relational database technology.  Their goal was to build a software platform capable of optimizing and summarizing huge volumes of data that could ultimately be used by "everyday people for exploration," without requiring armies of experts. 
The Endeca Information Access Platform is powered by a new class of database, the MDEX EngineTM, that helps you successfully build tailored applications for people to explore your existing data, regardless of its source or format. 
In early 2006, the NCSU Libraries announced the first library deployment of a revolutionary new online catalog. Leveraging the advanced search and Guided Navigation® capabilities of the Endeca ProFindTM platform, the NCSU Libraries' new catalog provides the speed and flexibility of popular online search engines while capitalizing on existing catalog records. 

## http://www.lib.ncsu.edu/

**Notes:**
Students, faculty, and researchers can now search and browse the NCSU Libraries' collection as quickly and easily as searching and browsing the Web, while taking advantage of rich content and cutting-edge capabilities that no Web search engine can match. 
Go live and search through the system...

## Web-based

- The “Amazoogle” model:
- Lorcan Dempsey: “Amazon, Google, eBay: massive computational and data platforms which exercise strong gravitational Web attraction.”
- Based primarily on full-text searching and link- or usage-based relevance ranking (lots of recall, little precision)
- Some efforts to combine catalog and Amazoogle searches (ex.: collaborations with WorldCat)
- Google is using metadata

- 17

**Notes:**
Amazon is a combination approach.  Some metadata is actually ONIX, but they are also combining that basic metadata with other “stuff” including full text and user-supplied information.

## Slide 259

**Notes:**
Amazon page example show the “Google type” search box connecting the various categories, and browse features. Meta tags are used to provide this searching.

Most people are familiar with Amazon, so no real need to go live.

## Portals and Federations

**Portals**: defined content boundaries
- Some content also available elsewhere
- ex.: Specific library portals, subject portals like Portals to the World (http://www.loc.gov/rr/international/portals.html)
**Federations**: protected content and services
- Often specialized services based on specifically purposed metadata
- ex.: BEN-http://www.biosciednet.org/portal/)

- 19

**Notes:**
Sometimes users can search for free but can’t get to the content in protected metadata without a license or registration.  Some protected services had the notion that there would be an income stream from their metadata.
Portals to the World:  A Library of Congress collection of electronic resources from around the world. A Collection level MARC record for each country is provided in the LC OPAC.
The Portal can be accessed by an engine search on “Portals to the World.”

BEN requires registration to search or use resources, and many of the resources have specific rights attached. They do not distribute their metadata to other partners, nor is it available to search engines.

## XML based digital library application 

- Similar to a portal application
- May use a database for record creation and maintenance
- Often uses open source tools
- Files are indexed for searching and presented on the Web using an XML based publishing framework
- Combines some of the other metadata creation, storage and retrieval approaches
- http://www.loc.gov/performingarts/

- 20

**Notes:**
This seems to be where digital collection development is heading.

Last bullet links to an example of this sort of application, “Performing Arts Encyclopedia : Explore music, theater, and dance at the Library of Congress.” Visit and study the site if you decide to go live or feel free to use a different example.

## Information Discovery and Retrieval 

- Z39.50
- SRU
- Federated search (Metasearch)

- 21

**Notes:**
There are standards that help manipulate and navigate through the various metadata standards. A few worth mentioning are:
Z39.50, SRU and metasearch.

## Z39.50

- An international (ISO 23950) standard defining a protocol for computer-to-computer information retrieval.
- Makes it possible for a user in one system to search and retrieve information from other computer systems (that have also implemented Z39.50)
- Originally approved by the National Information Standards Organization (NISO) in 1988

- 22

**Notes:**

Z39.50 is a national and international standard defining a protocol for computer-to-computer information retrieval. Z39.50 makes it possible for a user in one system to search and retrieve information from other computer systems (that have also implemented Z39.50) without knowing the search syntax that is used by those other systems. 
As a network application standard, Z39.50 is an open standard that enables communication between systems that run on different hardware and use different software. The Z39.50 standard was developed to overcome the problems associated with multiple database searching such as having to know the unique menus, command language, and search procedures of each system accessed. Z39.50 simplifies the search process by making it possible for a searcher to use the familiar user interface of the local system to search both the local library catalogue as well as any remote database system that support the standard. 
Z39.50 has been implemented throughout the US and Europe by libraries, library software vendors, and  bibliographic utilities such as OCLC. It is being succeeded by SRU (Search and Retrieve via URL).

## Slide 264

**Notes:**
For example, from the LC OPAC you have the option of searching just LC’s catalog,  
And on the right-hand side of the page you can see there is a listing of “other online catalogs.”  If you are interested in searching the databases of various institutions in just one query, you could go to Z39.50 gateway (third one down).

## 			SRU  Search/Retrieval via URL

**SRU** is the successor to Z39.50
**SRU **is a standard XML-focused search protocol for Internet search queries, utilizing CQL (Contextual Query Language), a standard syntax for representing queries
- To learn more about it see: http://www.loc.gov/standards/sru/index.html

- 24

**Notes:**
SRU is intended to define a standard form for Internet search queries as well as the structure of the responses.

SRU is the Web Services-based protocol for querying Internet indexes or databases and returning search results.

As metadata specialists, you may hear of these standards as you work with the technical specialists on digital projects. You don’t need to know it, but being familiar with the technical jargon is useful.

SRU is being used as a search and retrieve protocol that is XML based, so can output results in any metadata format that uses XML.

## Federated search

- Some institutions are using federated search (meta-search) to search multiple data sources
- LC has a new limited version available:
- 	http://www.loc.gov/search/new/

- 25

## Can You Tell?

- Can you tell what’s going on behind these sites?
- How are they organized?
- What creation and storage models are used?
*Plant and Insect Parasitic Nematodes: *_*http://nematode.unl.edu*_*/*
*Public Radio Market:*
*	**    *_*http://www.prms.org*_*/*
*Brown University Library Center for Digital Initiatives: Alcohol, Temperence & Prohibition:*
-        _*http://dl.lib.brown.edu/temperance/*_
*Country walkers:*
*      *_*http://www.countrywalkers.com/*_

- 26

**Notes:**
This can be done as a class exercise led by the instructor.
See extensive notes with the Instructors’ manual.

## 8. Metadata Interoperability and Quality Issues

- Metadata Standards and Applications Workshop

## Goals of Session

- Understand interoperability protocols (OpenURL for reference, OAI-PMH)
- Understand crosswalking and mapping as it relates to interoperability
- Investigate issues concerning metadata quality

- 2

## Tools For Sharing Metadata/Interoperability

- Protocols
- OpenURL for reference linking
- OAI-PMH for harvesting
- Good practices and documentation
- Crosswalking

- 3

**Notes:**
Interoperability 
the ability of two or more systems or components to exchange information and to use the information that has been exchanged 
A repository is a collection of resources that can be accessed to retrieve information. 

## What’s the Point of Interoperability?

- For users, it’s about resource discovery (user tasks)
- What’s out there?
- Is it what I need for my task?
- Can I use it?
- For resource creators, it’s about distribution and marketing
- How can I increase the number of people who find my resources easily?
- How can I justify the funding required to make these resources available?

- 4

**Notes:**
Interoperability is a kind of buzzword but stands for something that traditional libraries have taken for granted.  The metadata world is still exploring what it means.
Users are trying to figure out certain things (see the questions on the slide)
The slide asks important questions for resource creators.

## What’s an OpenURL?

- The OpenURL provides a standardized format for transporting bibliographic metadata about objects between information services
- Provides a basis for building services via the notion of an *extended service-link*, which moves beyond the classic notion of a *reference link* (a link from metadata to the full-content described by the metadata)

- 5

## Additional Open URL Services

- Link from a record in an abstracting and indexing database (A&I) to the full-text described by the record
- Link from a record describing a book in a library catalogue to a description of the same book in an Internet book shop
- Link from a reference in a journal article to a record matching that reference in an A&I database
- Link from a citation in a journal article to a record in a library catalogue that shows the library holdings of the cited journal

- 6

**Notes:**
Examples:

You can use citation information to see if the resource is available in print at the local library.  Or you can populate an ILL form.

Or you can send the citation information to a commercial vendor.

## OpenURL Examples & Demo

- http://sfxserver.uni.edu/sfxmenu?issn=1234-5678&date=1998&volume=12&issue=2&spage=134
- An OpenURL demo:
- http://www.ukoln.ac.uk/distributed-systems/openurl/

- 7

## OAI-PMH

- Open Archives Initiative Protocol for Metadata Harvesting (http://www.openarchives.org/)
- Roots in the ePrint community, although applicability is much broader
- Mission: “The Open Archives Initiative develops and promotes interoperability standards that aim to facilitate the efficient dissemination of content.”
- Content in this context is actually “metadata about content”

- 8

**Notes:**
Interoperability is of particular issue when we talk about distribution outside the source of the metadata.  One important resource for interoperability is OAI-PMH
The effort began with preprints in computer science and physics but the applicability is broader than that.
Metadata is created not just to convey bibliographic information (for example, author information) but to serve a number of functions within digital libraries.
The open archives approach is to enable access to Web-accessible material through interoperable repositories for metadata sharing, publishing and archiving. 

## OAI-PMH in a Nutshell

- Essentially provides a simple protocol for “harvest” and “exposure” of metadata records
- Specifies a simple “wrapper” around metadata records, providing metadata about the record itself
- OAI-PMH is about the metadata, not about the resources
- 	ARTstor cdwa-Lite experiment http://www.artstor.org/index.shtml

- 9

**Notes:**
Protocol for interaction between a harvester and information exposed for harvesting.
Provides administrative metadata about the resource (DC has no administrative metadata) such as ID for the metadata record.

## Metadata

-  About the
- Resource

- OAI Wrapper

- Meta-Metadata

- 10

**Notes:**
A graphic view of the relationship of OAI with the descriptive metadata about the resource.

## What was OAI-PMH designed for?

- Way to distribute records to other libraries
- Low barrier to entry for record providers
- Based on
- Records must be in XML
- OAI-PMH supports any metadata format encoded in XML—Simple Dublin Core is the minimal format specified
- Not Z39.50
- Not a way to support federated search
- No “on-the-fly” sets.
- More like CDS service, but it’s free,
- users “pull” records when they want, at intervals that are convenient for them (every day, every hour, on any schedule, or ad hoc)

- 11

**Notes:**
OAI_PMH is a mechanism for distributing metadata.
Technical support varies between institutions, so barriers to participation are a big issue. Important to note that servers do not need to be dedicated to OAI support, and many software packages are available via the OAI website.  A predictable flow of data maximizes the machine flow of information.
In harvesting metadata, you set the package you’re looking at.  In crawling, you’re going out on the open Web with the intent to collect certain things.  Harvesting has an inherent permission.  The harvester just has to have a harvesting program.
There’s a registry of OAI data providers with a listing of what is there.  Sometimes there is a description, sometimes there is not much.
An “item” is the lowest granularity of a resource.  In a Word document with two different drafts, the item level could include both drafts, or each one would be a separate item.  The data provider decides.
Flow control:  if you have thousands of records and don’t want to have to harvest them in one chunk, define the chunks and use them in chunk-order.  Get them in small enough chunks that it is easy to manage.
You can’t control how people use your data after harvesting.  You can specify what they are allowed to do with them (for example, a rights statement about no commercial use), but there is no enforcement of that.  Sometimes a data provider does not even keep track of who uses the metadata.

## OAI-PMH: Data Provider

- Has records to share
- Runs system that responds to requests
- following protocol
- Advertises base URL from which records are harvestable
- Just leaves system running
- No human intervention needed to service requests
- Can control level of activity to protect performance for primary users

- 12

**Notes:**
The system responds to requests:
There is the Data provider and the Service provider
A data provider has metadata to offer.

## OAI-PMH: Service Provider

- Assumed to be providing “union catalog” service
- OAIster  { http://www.oaister.org/ }
- or a specialist, value-added service
- Sheet Music Consortium {http://digital.library.ucla.edu/sheetmusic/ }
- Harvests records, with ability to select limited to
- Records updated in a certain timespan
- Predetermined sets of records (like CDS)
- Known records by identifiers (OAI identifiers, not LCCNs)

- 13

**Notes:**
DATA PROVIDER ======= SERVICE PROVIDER
Effort occurs at two poles—OAI seeks to mediate in the middle, with reasonable expectations at both ends.

## 14

**Notes:**
OAI-PMH: overview and structure model as provided in a tutorial by Leona Carpenter of the Univ. of Bath.
This shows the sorts of requests handled by OAI-PMH and how it works across metadata repositories.

## OAI Best Practices Activities

- Sponsored by Digital Library Federation (DLF)
- Guidelines for data providers and service providers
- http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl
- Not just DLF, also NSDL
- Best Practices for Shareable Metadata
- http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl?PublicTOC
- Workshops to encourage DLF members to make records for their digitized content harvestable
- Also sponsored by IMLS

- 15

**Notes:**
NSDL=National Science Digital Library
IMLS=Institute of Museum and Library Services

## OAI Example

**Notes:**
You can use the MarcEdit program to do OAI harvesting.  There are numerous other OAI harvesters out there that you can find.

## OAI Example

**Notes:**
Choose Advanced Setting
Check box Harvest Raw Data (do this first or the “save folder” box does not appear)
Enter server address
Metadata type: choose DC, but show others
Save folder on desktop
Explain GetRecord – if you wanted a particular record, identify the record number
Explain Resumption token, helps you if your download fails midstream to know where it stopped.  Leave blank b/c the record set is small
Explain Start/End – If you were downloading only a certain portion of the records, this is the start/end record numbers you want to download.

## OAI Example

**Notes:**
Success!  It downloaded 26 records

## OAI Example

**Notes:**
Open file & look at DC metadata. 

## OAI Example

- 20

**Notes:**
Point out that MarcEdit has an OAIDC-MARC stylesheet if you want to turn that file into MARC records.  If there is time, you can do that live & show.

## OAIster

- A **union catalog of digital resources**. Provides access to digital resources by "harvesting" their descriptive metadata (records) using OAI-PMH.
- Currently provides access to 14,900,092 records from 939 contributors.
- http://www.oaister.org/

- 21

## http://www.oaister.org/

**Notes:**
This is the homepage for OAIster.
OAIster currently provides access to 15,494,385 records from 939 contributors.
It can be searched by Title, Author/Creator, Subject, Language or Entire Record. Searches can also be limited by resource type (text, image, audio, video, dataset) and sorted by title, author, date and hit frequency. Results allow further limiting by data contributor (i.e., where the record was harvested from).
Go live and do a search. Click on search, then fill in hair as subject and limit to image. Look at the results and see how records differ in the values that appear in the elements. For instance, there are different kinds of values in the element ResourceType: in one record there is “73.57.10.jpg “, in another “1 lock of hair”, in another “<br> “ (others have rich metadata that come from controlled vocabularies). This is a result of mapping disparate data to a common field. 

## Slide 290

**Notes:**
The project, DLF Aquifer Development for Interoperability Across Scholarly Repositories: American Social History Online, is intended to enable scholars to use distributed digital collections as one in a variety of local environments. The project addresses the difficulty humanities and social science scholars face in finding and using digital materials located in a variety of environments with a bewildering array of interfaces, access protocols and usage requirements. Its focus is digital library collections pertaining to nineteenth and twentieth century United States social history across institutional boundaries. 

## Crosswalking

- “Crosswalks support conversion projects and semantic interoperability to enable searching across heterogeneous distributed databases. Inherently, there are limitations to crosswalks; there is rarely a one-to-one correspondence between the fields or data elements in different information systems.”
- -- Mary Woodley, *“Crosswalks: The Path to Universal Access?”*

- 24

**Notes:**
The vast majority of metadata comes down to beginning with the form you have it in and what form you want to turn it into.
Mapping (conceptual) === transformation (practice, albeit in an automated way)
At least map from the local (usually richer) scheme to simple DC.
There are various attempts to have lists of crosswalks.  Many are not being maintained and versioned.

## Crosswalks

- Semantic mapping of elements between source and target metadata standards
- Metadata conversion specification: transformations required to convert metadata record content to another
- Element to element mapping
- Hierarchy and object resolution
- Metadata content conversions
- Stylesheets are created to transform metadata based on crosswalks

- 25

**Notes:**
Crosswalks require constant maintenance considering that metadata standards are continuously revised.

## Problems With Converted Records

- Differences in granularity (complex vs. simple scheme)
- Some data might be lost
- Differences in semantics
- Differences in use of content standards
- Properties may vary (e.g. repeatability)
- Converting may not always be the solution

- 26

**Notes:**
Results may be unexpected when converting from one format to the next because of the differences between metadata formats. These differences are...

## Example:Mapping MODS:title  to DC:title

- Includes attribute for type of title
- Abbreviated
- Translated
- Alternative
- Uniform
- Other attributes: ID, authority, displayLabel, xLink
- Subelements: title, partName, partNumber, nonSort
- Title definition reused by: Subject, Related Item

- 27

## Mapping MODS:title to DC:title

- DC has one element refinement: alternative
- DC title has no substructure; MODS allows for subelements for partNumber, partName
- Best practice statement in DC-Lib says include initial article; MODS parses into <nonSort>
- MODS can link to a title in an authority file if desired

- 28

## Metadata Crosswalks

- Dublin Core-MARC
- Dublin Core-MODS
- ONIX-MARC
- MODS-MARC
- EAD-MARC
- EAD-Dublin Core
- Etc.

- 29

**Notes:**
There are conversion tools, which are usually XSLT stylesheets. LC provides some for converting between MARC and MODS to and from various other formats
There are beginning efforts to maintain crosswalks in registries, which could provide machine readability and facilitate in keeping them updated.

## Crosswalks

- Library of Congress
- http://www.loc.gov/marc/marcdocz.html
- MIT
- http://libraries.mit.edu/guides/subjects/metadata/mappings.html
- Getty
- http://www.getty.edu/research/conducting_research/standards/intrometadata/crosswalks.html

- 30

## Slide 298

**Notes:**
This crosswalk and the one following are from the MARC Website.  

This slide shows a crosswalk for unqualified Dublin Core; the following slide is for Qualified Dublin Core.  What do you lose, going from MARC to DC?  (Example, Creator:  some 700s are for related records.  You could have a creator value on this record for someone who is actually the creator on another resource.)

This crosswalk tells people to use Source.  Source is a specific kind of relationship, so you should probably use Relation instead.  
Note that the crosswalks don’t’ tell you how to put values into the other metadata scheme, for example, to put parts of a subject into different subfields.

## MARC to DC Qualifiedhttp://www.loc.gov/marc/marc2dc.html#qualifiedlist

- 32

**Notes:**
This includes a portion of the MARC to DC Qualified crosswalk. Bring it up online to show the rest.
With Qualified Dublin Core, we’ve gained some things but it still does not address a lot of fields.
MARC relator terms may be used as refinements for Contributor. Creator is not used in this mapping because of the difference between  the semantics in the two metadata schemes  (i.e. not all names in MARC 1XX and 7XX are considered creators and creators can be found in 7XX so there is not a perfect mapping). 
DC Qualified allows for stating the source of the vocabulary if controlled. There is still data from the richer MARC record which does not get converted and some data in DC Qualified which is not in MARC. 
There is a mapping of the MARC Leader/06 (Type of record) values to DC Resource Type, although again there is not a one-to-one correlation and some data will not be accurate.

## NISO’s Metadata Principles

**1**: Good metadata conforms to community standards in a way that is appropriate to the materials in the collection, users of the collection, and current and potential future uses of the collection.
**2**: Good metadata supports interoperability.
**3**: Good metadata uses authority control and content standards to describe objects and collocate related objects

- 33

**Notes:**
Whether mapping, converting, harvesting, or doing original metadata creation, these are good practices for metadata in general.

## NISO’s Metadata Principles Continued

**4**: Good metadata includes a clear statement of the conditions and terms of use for the digital object.
**5**: Good metadata supports the long-term curation and preservation of objects in collections.
**6**: Good metadata records are objects themselves and therefore should have the qualities of good objects, including authority, authenticity, archivability, persistence, and unique identification.

- 34

**Notes:**
Libraries have a long history of thinking of metadata use over time.  The need to document standards and practices has probably come up already, repeatedly.

Use vocabularies consistently and document them.

## Quality issues

- Defining quality
- Criteria for assessing quality
- Levels of quality
- Quality indicators

- 35

**Notes:**
Now we will move to issues of quality of metadata.
Quality issues are important in the effective use of metadata. We will consider the following...

## Determining and Ensuring Quality

- What constitutes quality?
- Techniques for evaluating and enforcing consistency and predictability
- Automated metadata creation: advantages and disadvantages
- Metadata maintenance strategies

- 36

**Notes:**
Quality in the metadata world may be different than in traditional libraries.  It’s important that we re-start the conversation about quality with these differences in mind.  We want to talk about ...

## Quality Measurement: Criteria

- Completeness
- Accuracy
- Provenance
- Conformance to expectations
- Logical consistency and coherence
- Timeliness (Currency and Lag)
- Accessibility

- 37

**Notes:**
Completeness: describe the item as completely as is economically feasible
Accuracy: apply standards consistently with minimum of error
Provenance: provide information on source of metadata, whether it was generated or converted
Conformance to expectations: reflects what the given community would expect, using appropriate elements and controlled vocabulary
Logical consistency: uses application profiles and similar structures
Timeliness: when the target item changes the metadata may need revision
Accessibility: make sure metadata is openly available (if possible) and links are current; should be accessible by people with disabilities

## Basic Quality Levels

- Semantic structure (“format,” “schema” or “element set”)
- Syntactic structure (administrative wrapper and technical encoding)
- Data values or content

- 38

## Quality Indicators: Tier 1

- Technically valid
- Defined technical schema; automatic validation
- Appropriate namespace declarations
- Each element defined within a namespace; not necessarily machine-resolvable
- Administrative wrapper present
- Basic provenance (unique identifier, source, date)

- 39

**Notes:**
This is the bottom tier of what you should have.
It is desirable to have some control over the metadata itself, including a unique ID for the metadata itself, which is not the same as the Identifier for the object.

## Quality Indicators: Tier 2

- Controlled vocabularies
- Linked to publicly available sources of terms by unique tokens
- Elements defined and documented by a specific community
- Preferably an available application profile
- Full complement of general elements relevant to discovery
- Provenance at a more detailed level
- Methodology used in creation of metadata?

- 40

**Notes:**
This is a step up.  You know which value is from which vocabulary and are using it properly.
Examples of tokens are:  LCSH, AAT, etc.
At this stage, you will assure that your data “plays well with other data” in regular aggregation.
“On the Horse” problem:  In the Theodore Roosevelt collection, none of the objects actually had the name of Theodore Roosevelt in the title.  Instead, they had titles, like “On the horse” because of course they were all about T.R.  The context was lost. This happens all the time!

At this stage, there is come indication of the methodology of how the metadata was created:  by machine or by a person.

## Quality Indicators: Tier 3

- Expression of metadata intentions based on documented AP endorsed by a specialized community and registered in conformance to a general metadata standard
- Source of data with known history of updating, including updated controlled vocabularies
- Full provenance information (including full source info), referencing practical documentation

- 41

**Notes:**
This level has not been implemented widely, although there is some effort in the METS community to establish METS profiles and for a project to rely on them and perhaps even validate against them. There is also work in the DCMI community to establish application profiles to document practices for high quality metadata.

## Improving Metadata Quality ...

- Documentation
- Basic standards, best practice guidelines, examples
- Exposure and maintenance of local and community vocabularies
- Application Profiles
- Training materials, tools, methodologies

- 42

**Notes:**
Question is about how to provide information to people who are using and creating your data.
We are used to making assumptions in the cataloging community about quality, such as the use of content standards like  AACR2, etc. This is particularly relevant because of the control we have had over library catalogs.
However in the metadata world– you cannot make those assumptions. As libraries begin to need to process metadata from disparate sources they are having to be more flexible in outlook. Not all those sources will have high quality metadata. As we are initiating digital projects, we need to be concerned about quality of metadata and document what we are using.

## Exercise

- Evaluate a small set of machine- and human-created metadata

- 43

**Notes:**
This can be done as an exercise in smaller groups. If desired the alternative exercise may be substituted. See instructor’s notes for more detailed information. 

Exercise: Evaluate a small set of human and machine-created metadata.  The prepared two page handout should be augmented with the printouts of the associated Webpages, which are also included in the packet (these may be eliminated if access to the web is provided in the classroom).

Ages -- machine created (From Identifying Trees)
DC.dot --  machine created (From NSDL metadata registry)
Brazilliance --  human created, with transformations (no resource– all you could see was the record cover)
ICSD Science Zone --  human created