Go to home page for the PBCore

Go to home page for PBCore

Go to User Guide for PBCore


PBCore in Use



What do the "Attributes" or "Properties"
of the PBCore Metadata Elements Mean?

What are Element Attributes or Properties?

There are many specifications on how to define data elements. If one hopes to share metadata descriptions with other organizations and entities (interoperability), then it's best to follow an established set of guidelines or properties in setting up and defining metadata elements. A commonly understood framework allows diverse groups to appreciate, share, even harvest, data from one another. For a more expansive discussion on the impact of well-defined attributes, see the web page Mapping PBCore to other Metadata Standards. There you will find highlights on matching semantic definitions, matching element-to-element relationships, matching and converting content, matching singe vs multiple or compound data objects, and matching hierarchical and flat metadata standards.

The PBCore has used a modified standard for describing data elements used in databases and documents. It is called 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." In using this standard, each descriptor or metadata element is identified by numerous attributes, characteristics, or properties that define the meaning of the element.

What are the attributes or properties we've used in the PBCore Metadata Elements?


The actual name of the descriptor or element.


A brief definition of the descriptor or element. Guidelines for understanding how to use an individual element from the PBCore are described under the attribute "Guidelines for Usage."


Although not officially part of the ISO/IEC 11179 specification, PBCore documents each element by referencing how it is bound to related sibling elements within element containers and larger content classes. This helps express the hierarchical relationship between the PBCore elements when implemented in information, content and asset management systems.


In order to better control the terms and descriptions used while cataloging, some metadata elements can exploit ways to refine or "encode/enter" your data, using formal notations, vocabularies or parsing rules.
  • Use an "authority file" from another agency that specifies how to properly enter descriptive information for a type of metadata element. It may provide taxonomies of terms organized into logical hierarchies, such as the Library of Congress "subject" terms.
  • Use a short listing of prescribed terms, often called a "controlled vocabulary." The best practice is to select a term or terms from a picklist. The picklist insures consistency in data entry.
  • Follow a particular syntax, punctuation or grammar when entering data, e.g., LastName, FirstName MiddleName, Credentials.

Controlling the descriptions entered for a metadata element ultimately means that end users are able to conduct successful searches for relevant media items.


The Guidelines are a brief user's guide to understanding the PBCore, its elements, their intended meanings, and the proper way to use them when entering data or cataloging. The Guidelines for Usage do not address actual applications of the PBCore in different user environments with different databases and digital asset management systems.


A metadata element does NOT necessarily have to be used or contain data when cataloging a media item. The "Obligation to Use" a metadata element is defined by these options...
  1. MANDATORY: must use
  2. MANDATORY IF APPLICABLE: must use if it makes sense for a media item
  3. OPTIONAL: completely up to you
  4. RECOMMENDED: PBCore thinks it is a good idea to enter data for this element



Some metadata schemes, such as the Dublin Core, suggest if you need to catalog more than one term or data entry for a single element, you repeat the instance of an element, each instance having a different term. For example, the element alternativeModes may have two entries, one for "SAP1 - Spanish" and one for "ClosedCaption - English." This attribute may be defined as REPEATABLE, UNBOUNDED, MINIMUM OCCURENCE, MAXIMUM OCCURENCE, or may actually use a number. The repeatability of an element is also tied to its binding to sibling elements of a related nature within an *element container*. PBCore identifies these repeatability relationships for each element.


Any database designer must indicate what type of data is permitted for a field. The type of data permitted is often defined as TEXT STRING, NUMBER, INTEGER, DATE, DATETIME, TIME, CHAR, etc. PBCore uses relatively few data entry types. Most are text strings. Even the metadata elements which contain date/time stamps are considered to be text strings because of our use of the W3C-DTF encoding rules for dates and times, a profile based on ISO 8601.


To illustrate the proper use of an element, PBCore provides many real world examples, particularly when the definition for an element is rather dense or confusing. Additionally, PBCore's website includes "More Metadata Examples" (a link is provided on each web page for the PBCore elements).


(Administrative Attribute)

Usually the attribute called Name and the attribute called Label are the same. The Label is used to indicate the exact manner in which an element is referenced.

As a cataloger, you can ignore this attribute.


(Administrative Attribute)

While developing metadata, several versions of elements or the meaning attached to them will change over time. Like software editions that are released, Element Version indicates the version you are viewing (hopefully, the most recent version).

As a cataloger, you can ignore this attribute.


(Administrative Attribute)


A unique name that identifies an organization that has developed an XML Schema. A namespace is identified via a Uniform Resource Identifier (a URL or URN). For example, the namespace for Dublin Core elements and qualifiers would be expressed respectively in XML as:

xmlns:dc = "http://dublincore.org/elements/1.0/"
xmlns:dcq = "http://dublincore.org/qualifiers/1.0/" >

The use of namespaces allows the definition of an element to be unambiguously identified with a URI, even though the label "title" alone might occur in many metadata sets. In more general terms, one can think of any closed set of names as a namespace. Thus, a controlled vocabulary such as the Library of Congress Subject Headings, a set of metadata elements such as DC, or the set of all URLs in a given domain can be thought of as a namespace that is managed by the authority that is in charge of that particular set of terms.

As a cataloger, you can ignore this attribute.


(Administrative Attribute)


A system to provide management of metadata elements. Metadata registries are formal systems that provide authoritative information about the semantics and structure of data elements. Each element will include the definition of the element, the qualifiers associated with it, mappings to multilingual versions and elements in other schema.

A registration authority facilitates the consistent use of a metadata element by all parties and communities. It also contributes to the longevity of a metadata element as it maintains its integrity over time.

As a cataloger, you can ignore this attribute.


(Administrative Attribute)

Depending on the Registration Authority for a metadata element or its country of origination and usage, the language used to define an element is indicated. For the PBCore, the Language is expected to be English and uses the designation "eng". Standards exist to express languages in either two-letter or three-letter codes.

This attribute, "Language of the Element," refers to the language used to define the element and has nothing to do with the language used in the media item you are cataloging. The descriptor language is used to identify the primary language of the media item.

ISO-639-2: Codes for the representation of names of languages as a 3-letter code.

As a cataloger, you can ignore this attribute.


PBCore in Use



Go to Feedback


Go to CPB website

© 2005 Corporation for Public Broadcasting
- CPB Privacy Policy -
- PBCore Licensing via Creative Commons -