|
|
|
 |
|
PBCore Elements Viewed |
Context
What is PBCore Compliant?
PBCore Elements Viewed by Obligation to Use (Mandatory)
Other Element Views
Within the underlying metadata dictionary of PBCore, no hierarchical relationships (root, branches, leaves) are necessarily implied. However, in applying the elements from the metadata dictionary within an asset management system, or more importantly, when sharing metadata descriptions from a data export as a properly formatted XML document (that follows the PBCore XML Schema Definition: XSD), hierarchical relationships and interdependices between PBCore elements emerge as roots, branches and leaves.
A more complete explanation is provided on the PBCore web page entitled Hierarchical Relationships and Interdependencies between Metadata Elements.
These roots, branches, and leaves are alternatively expressed in a data model as "Master Container," "Content Classes,' "Containers," "Sub-Containers," and "Elements." PBCore has 53 elements arranged in 15 containers and 3 sub-containers, all organized within four content classes.
CONTENT CLASSES
In the hierarchy of objects in the PBCore Description Document/Master Container, Content Classes are created as "conceptual wrappers" that cluster together a list or structure of thematically-related Elements (metadata fields and their attributes and properties). PBCore maintains four Content Classes as the conceptual wrappers for its various metadata elements:
- PBCoreIntellectualContent
9 containers; 16 elements
(metadata elements describing the actual intellectual content of a media asset or resource)- PBCoreIntellectualProperty
4 containers; 7 elements
(metadata elements related to the creation, creators, usage, permissions, constraints, and use obligations associated with a media asset or resource)
- PBCoreInstantiation
1 container; 3 sub-containers; 28 elements
(metadata elements that identify the nature of the media asset as it exists in some form or format in the physical world or digitally)
- PBCoreExtensions
1 container; 2 elements
(additional descriptions that have been crafted by organizations outside of the PBCore Project. These extensions fulfill the metadata requirements for these outside groups as they identify and describe their own types of media with specialized, custom terminologies unique to their needs and community requirements)
ELEMENT CONTAINERS & SUB-CONTAINERS (aka "branches"):
Elements are objects in the PBCore schema hierarchy that define a metadata field and its values, attributes and properties. An element may be standalone. If several metadata fields are thematically related to each other, they can be bound together under an Element Container. Related elements are subsumed by a larger theme, and should be bound together when data is shared (particularly if an Element Container is a repeatable description with multiple instances of its related Elements). Examples of related Elements bound within a Container are *title* and its associated *titleType*, that are bound together by the Element Container *PBCoreTitle*. Within hierarchical structures, a Container may house Sub-Containers, which themselves bind together related Elements. In PBCore, there are Sub-Containers found within the Content Class PBCoreInstantiation.ELEMENTS (aka "leaves"):
Elements are objects that define a metadata field and its values, semantics, attributes, and properties (for a list of the attributes defined for PBCore elements, see our web page PBCore Element Attributes). An Element is the actual "thing" that carries the descriptive metadata about a media item, such as a title, a date, keywords, rights information, mime types, media types, etc. The metadata elements are what a cataloger interacts with (creating descriptions) within a cataloging tool or asset management system.
What is PBCore Compliant?
Of course, PBCore cannot satisfy all functions and requirements that the breadth and depth of our public broadcasting communities demand in their information systems. For many, PBCore is a starting point from which to build a metadata dictionary for their internal use. Local customizations, such as additional metadata elements or additions to picklists of terms, may be implemented. For others, interoperability and data sharing between different information systems (metadata islands) is of the greatest importance.
When is the use of metadata considered to be PBCore compliant? There are two possible perspectives.
COMPLY WITH THE PBCORE DICTIONARY...
One form of compliancy is to implement metadata by adhering to the PBCore Dictionary of metadata elements as documented in our User Guide. That means a metadata implementation must match the PBCore Dictionary with...
If you refer to the documentation for a typical PBCore metadata element, you will see that for compliancy, an element must match the following attributes...
- Name of the element (although what you call an element can be customized)
- Definition
- Refinements & Encoding Schemes
- Guidelines for Usage
- Obligation to Use
- Repeatability
- Type of Data Entry
- Language of the Element
These attributes are more completely explained on the web page PBCore Element Attributes.
If a local implementation of PBCore varies from the PBCore Dictionary, then it is vital that the variance be documented.
COMPLY WITH THE PBCORE XML XSD FOR DATA SHARING...
Another form of compliancy emerges when interoperability betweeen information systems is required. If your metadata cataloging system is never intended to share data or descriptions with other systems, then any variations and changes you make to the PBCore are confined to your own instance. If you need to export your data to another information system, then the manner in which you cataloged media items and assets must be transformed into a standard framework that other information systems can interpret correctly.
We have created what is called an XML Schema Definition document (XSD) for PBCore v1.1. It is a standard framework upon which data exported from one information system can be transformed into PBCore compliant structures. It is a standard framework with which data can be interpreted in a known fashion by another information system, and imported into its metadata structures. Below is an illustration of the process.
A thorough discussion of XSD can be found on our web page for the PBCore XML Schema Definition (XSD).
When PBCore elements are declared "Mandatory" in the listings outlined below in the PBCore Elements Viewed by Obligation to Use, compliance is significant when metadata is being shared between systems. The PBCore XSD breaks if the obligations specified are ignored. If the PBCore XSD breaks, then data cannot be properly exported or imported between information systems.
The table below is organized by the PBCore obligations to use a metadata element when describing media items. Obligations are identified as...
Associated Sub-Containers, Containers, and Content Classes are included. Each entry is an active hyperlink to an individual page that defines and describes that component.
Listed below are quick jumps to other organizational views of the PBCore elements.
PBCore Element Views
|
|
© 2005 Corporation for Public Broadcasting
- CPB Privacy Policy -
- PBCore Licensing via Creative Commons -