Context
Mappings of PBCore to Other Metadata Standards

 

 

---

CONTEXT:

A metadata standard is created in order to identify and document (in an organized and logical manner) how content, knowledge, and media are to be described. Media is defined broadly as audio, video, text, images, animations--virtually any item conveying a message, theme, or affect.

Metadata descriptions most often deal with four major categories or classes:

1. the actual intellectual content of an item
   (what's it about?)
2. property and usage rights over an item
   (who owns it, manages it, and what are the use permissions, restrictions, and obligations)
3. format information about an item's physical or digital forms
   (instantiations, formats, technical attributes & configurations)
4. utilization
   (target audiences, preferred integrations into teaching methods, lesson planning)

Descriptions are expressed through metadata "elements." An element is a named placeholder for a very specific type of information, e.g., a title, an author's name, a country, a creation date, a set of keywords, etc.

Different metadata standards exist in order to serve the needs of particular user communities, such as public broadcasters, TV program listings, libraries, medical practitioners, artists, global positioning data, museum collections, statistical and social research, educational applications, and so on and so on.

In most cases, each metadata element that is employed in a metadata standard is itself documented with a consistent set of properties or attributes for identification and definition. PBCore, like many others, is based on the properties that are outlined in the ISO/IEC 11179: Specification and Standardization of Data Elements and is expressed in half a dozen published documents and drafts. Technically speaking, PBCore is considered to be "cognizant of ISO/IEC 11179." To learn more about the data element properties that PBCore employs, reference this page in our website:

Review the "Attributes" or "Properties" Used to Define PBCore Elements

What happens when one community desires to share metadata information entered in its systems with another community that maintains its own metadata standard? In a perfect world, each metadata element from the "source" metadata standard could be paired with a similar metadata element in the "target" metadata standard, and the data would be transferred.

Unfortunately, such a pure one-to-one pairing or "harmonization" is rare. Although each standard may use a common method to express the properties of its metadata elements, the actual data held within the element may not "crosswalk" or "map" perfectly.

The following quote was extracted from an excellent article entitled Issues in Crosswalking Content Metadata Standards. It is published through NISO, the National Information Standards Organization, and authored by Margaret St. Pierre of Blue Angel Technologies, Inc. and William P. LaPlant, Jr., of the U.S. Bureau of the Census Statistical Research Division.

A crosswalk is a specification for mapping one metadata standard to another. Crosswalks provide the ability to make the contents of elements defined in one metadata standard available to communities using related metadata standards. Unfortunately, the specification of a crosswalk is a difficult and error-prone task requiring in-depth knowledge and specialized expertise in the associated metadata standards. Obtaining the expertise to develop a crosswalk is particularly problematic because the metadata standards themselves are often developed independently, and specified differently using specialized terminology, methods and processes. Furthermore, maintaining the crosswalk as the metadata standards change becomes even more problematic due to the need to sustain a historical perspective and ongoing expertise in the associated standards.
http://www.niso.org/press/whitepapers/crsswalk.html

When harmonizing metadata elements from different standards, there are several points of intersection where collisions, rather than smooth merging, may occur.

• Matching Semantic Definitions
  An element in the source standard may not find a companion element in the target standard because the definition, semantics, or meaning for elements are different. With such a mismatch, a descriptor may not translate well.
  
  
• Matching Element-to-Element Relationships
  Suppose the source standard uses separate metadata elements to identify the (1) Last name of a person, (2) First name, (3) Middle name, and (4) Credentials for an individual. What if the target standard only employs a single element to contain all of a person's names, prefixes and suffixes? How do the "many" elements of the source map to the "one" element in the target? There is a "many-to-one" mismatch. Likewise, there may exist a "one-to-many" element mismatch between the source and target standards. Furthermore, one standard may contain extra elements and descriptors that cannot even be paired with the other system.
  
  
• Matching & Converting Content
  The properties for a metadata element may define or restrict its contents by...

1. data types (e.g., text, numeric, string, date, etc.),
2. ranges of values, or
3. data refinements derived from the use of various authorities, controlled vocabularies, or specific syntaxes for the presentation of the data (e.g., keywords separated by semi-colons).
4. repeatability of the element in order to express multiple values or descriptions
5. mandatory or optional usage of the element when entering values.

Even though a metadata element from a source standard may semantically match an element in a target standard, the rules by which the actual data entered in the element may differ between the systems. The mismatch may be resolved by some form of conversion or data reformatting. Consistency in how data was originally entered is key to formulating conversion utilities or crosswalks.

• Matching Single vs. Multiple or Compound Data Objects
  Many asset management systems and databases allow the relationships between several data records/media items to be expressed. For example, a video program might have a transcript (text document), brochure (pdf), DVD (non-digital medium for order fulfillment), and other items associated with it. If an end user searches for the video program, the search results report the related media items as well. These associated/related items are often housed as a "multiple" or "compound" data object. Many databases actually refer to them as "container fields." If the source and target metadata system use different methods to identify and report multiple or compound objects, then a mismatch in mapping occurs.
  
  
• Matching Hierarchical and Flat Metadata Standards
  Some metadata standards, like IEEE-LOM (Learning Object Metadata) use a very hierarchical structure to organize the relationships between metadata elements. These relationships can often become quite complex. PBCore v1.1 uses a hierarchical set of element interdependencies. Other standards, such as Dublin Core, are flat in nature, with no implied or expressed hierarchy. Trying to pair metadata elements from a hierarchical and a flat system can be troublesome.

Outside of PBCore, many groups have been making crosswalks that map metadata between many well-established standards. For a total immersion experience, drop into this website authored by the Metadata Advisory Group of the MIT Libraries:

http://libraries.mit.edu/guides/subjects/metadata/mappings.html

They have listed crosswalks and URL references for sixteen standards, many of them library-oriented. But witnessing the work behind the mappings is a humbling experience.

For an important discussion on exporting and importing metadata descriptions using XML and XML Schema Definitions as the data bridge, reference our web page The PBCore XML Schema Definition (XSD).

To learn more about an important initiative related to harvesting metadata from compatible information systems, link to the web page for the OAI: Open Archives Initiative. The OAI provides a protocol for metadata harvesting that is an application-independent framework.

In an effort to show how the PBCore metadata maps to other standards that may be in use, particularly in public broadcasting venues, we have researched element pairings. Some mappings demonstrate one-to-one pairings and harmonization between metadata elements. Other suggested pairings come with caveats and disclaimers, demonstrating the difficulties in transforming metadata descriptions from a source system to a target system.

As an additional resource, we offer mappings that are not necessarily direct element-to-element pairings with PBCore itself, but are mappings between other significant metadata dictionaries, schemas, and application profiles. These seminal works can be used as "bridging documentation" to begin pairing PBCore to other metadata schemas.

Below are listed our mapping efforts. Access a specific mapping and information about that mapping by clicking on a "double-arrow road sign."

 

---

MAPPINGS OF PBCORE
AND OTHER METADATA STANDARDS:

 

PBCore		Dublin Core & Qualified Dublin Core (DC Terms) (posted 2007-10-12)
Dublin Core		ViDe: User's Guide Establishing a Dublin Core Application Profile for Digital Video (posted 2007-10-17)
Dublin Core		MPEG-7: MIC-ViDe User's Guide for the MPEG-7/Dublin Core Application Profile (posted 2007-10-17)
PBCore		MPEG-7 Will be based on the MIC-ViDe MPEG-7/Dublin Core Application Profile (pending further review & documentation)
Dublin Core		MARC 21 (posted 2007-10-17)
PBCore		MARC 21 Will be based on the Library of Congress MARC 21/Dublin Core Crosswalk (pending further review & documentation)
PBCore		PBS PODS: Public Broadcasting Service's Program Offer Data Service (pending further review & documentation) (for a description of the PBS PODS integration, see our Case Example)
PBCore		Content Depot PRSS: Public Radio Satellite Service and Content Depot Data (pending further review & documentation) (for a description of the Content Depot integration, see our Case Example)
PBCore v1.0		PSD Consortium: Program Service Data for HD Public Radio (an update for PBCore v1.1 is required) (for a description of the PSD integration, see our Case Example)
PBCore		SMPTE DMS-1 (MXF) (pending further review & documentation)
PBCore		Myers ProTrack (pending further review & documentation) (for a description of ProTrack integation, see our Case Example)
PBCore		NDIIPP-PDPTV: National Digital Information Infrastructure and Preservation Program- Preserving Digital Public Television Project (posted 2007-10-22) (for a description of the NDIIPP-PDPTV integration, see our Case Example)
PBCore		IEEE-LOM Learning Object Metadata (posted 2007-10-19)
Dublin Core		IEEE-LOM Learning Object Metadata (posted 2007-10-17)
MIT Libraries Guide		16 Metadata Mappings (A guide to metadata by the Metadata Advisory Group of the MIT Libraries) (posted 2007-10-17)