|
|
|
 |
|
Information about Hierarchical Relationships |
What are Hierarchical Relationships & Element Interdependencies?
Hierarchies & Interdependencies in PBCore's XML Schema Definition
(data model representation of the metadata dictionary)
Other Element Views
The Public Broadcasting Metadata Dictionary (PBCore) is:
As a simple dictionary of elements, there is no "hierarchy" implied. They are presented in a "flat" arrangement as a listing of descriptors with specific attributes from which you can pick and choose and apply in whatever cataloging or information/asset/content management system you have. According to an article in Wikipedia entitled Data Dictionary,
A data dictionary is a set of metadata that contains definitions and representations of data elements.When an organization builds an enterprise-wide data dictionary, it may include both semantics and representational definitions for data elements. The semantic components focus on creating precise meaning of data elements. Representation definitions include how data elements are stored in a computer structure such as an integer, string or date format (see data type). Data dictionaries are one step along a pathway of creating precise semantic definitions for an organization.
Basically, a metadata dictionary describes the following:
The metadata dictionary for PBCore is well documented in this website. The individual pages that define the attributes of each metadata element can be found by linking from this section: PBCore User Guide.
Beyond the metadata dictionary, the actual metadata elements are organized into a framework. According to an article in the Wikipedia entitled Data Modeling,
Data dictionaries are usually separate from data models since data models usually include complex relationships between data elements.
When data modeling, we are structuring and organizing data. These data structures are then typically implemented in a database management system. In addition to defining and organizing the data, data modeling will impose (implicitly or explicitly) constraints or limitations on the data placed within the structure.
A data model represents classes of entities (kinds of things) about which a company wishes to hold information, the attributes of that information, and relationships among those entities and (often implicit) relationships among those attributes. The model describes the organization of the data to some extent irrespective of how data might be represented in a computer system.
Some metadata models or schemas are based on a logical, hierarchical arrangement of their metadata elements, not only in the way they are conceptually presented, but also in how they are applied in actual metadata and asset management systems. For example, the IEEE 1484.12.1-2002 Standard for Learning Object Metadata is hierarchical. At the base of their hierarchy is a "root" element. The root element contains many sub-elements. If a sub-element itself contains additional sub-elements it is called a "branch." Sub-elements that do not contain any sub-elements are called "leaves." This entire hierarchical model is called a "tree structure." The relationship between the root, branches, and leaves is depicted in the figure below (taken from IEEE LOM and the IMS Global Learning Consortium), using sample elements from the IEEE LOM metadata standard.
When the IEEE LOM metadata standard is expressed diagramatically, the following structures (branches and leaves) appear as they do in this illustration:
This hierarchy is honored throughout the application of the metadata elements in any profile or management situation.
The PBMD Project has spent over two years comparing and contrasting various metadata descriptors, dictionaries, and schemes in order to arrive at the smallest set of elements that could adequately describe the media items produced by Public Broadcasting radio and television stations that may be shared between stations, regional and national distributors, independent producers, and even vendors of Digital Asset Management systems.
The PBCore is a "core" because it can actually be considered a foundation of descriptors used to categorize media items adequately enough so other interested parties can successfully search for and review metadata records and associated media items. The objective is to be able to share media items and give users complete, well-thought-out, descriptions. Good descriptions help end users know what to expect when they decide to review, play or download a media file.
Within the underlying metadata dictionary, the PBCore implies no hierarchical relationships (root, branches, leaves). 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.
These roots, branches, and leaves are alternatively expressed in a data model as "Master Container," "Content Classes,' "Containers," "Sub-Containers," "Elements."
PBCore DESCRIPTION DOCUMENT (aka the MASTER CONTAINER)
The Master Container assembles together all collections of PBCore knowledge items. For PBCore these knowledge items are metadata descriptions of media. The MasterContainer is expressed as a document that hierarchically structures all the knowledge items and metadata terms and values related to a single data record associated with a media item. In our XML Schema Definition, the MasterContainer is referred to as the "PBCoreDescriptionDocument."
CONTENT CLASS (aka PBCore Section)
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 Schema Tag and Schema Sub-Tag, alternatively "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 governed 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.
An advantage to using the Element Container approach is that, unlike the basically flat arrangement of elements found in Dublin Core (http://www.dublincore.org), PBCore is able to bind together the data found in related elements and keep them that way. For example, a *title* and its associated *titleType* can be catalogued and bound together as one instance of the container *pbcoreTitle*. The container *pbcoreTitle* can be repeated within a single metadata record, with another *title* and *titleType*; for example, a working title or an alternative title can be specified, but still be part of one data record, instead of making multiple data records, each with redundant metadata (descriptions, keywords, coverage, etc.). Similarly a particular format (and its associated specifications) for a media item can be described within the container *pbcoreInstantiation*, and repeated multiple times for different formats/instantiations, all within a single metadata record.
If we emulate the illustration of the root, branches and leaves for the IEEE-LOM metadata hierarchies, PBCore v1.1 begins to look like the following diagram (click on the image to see a higher resolution version):
PBCore v1.1
In contrast and for comparison's sake, here is a diagram of the original "flat" arrangement of the elements found in PBCore v1.0 (click on the image to see a higher resolution image):
PBCore v1.0
Open a separate browser window |
When the actual PBCore v1.1 elements are integrated into a database and its associated cataloging application or digital asset management system, the "presentation" of the elements to the cataloger who is providing and entering metadata descriptions may not necessarily look exactly like the Hierarchy Diagram for PBCore v1.1. Often, the features and capabilities of a particular information management system require metadata elements to be displayed or function in specific ways. The actual "application" of the PBCore metadata elements may vary from the strict framework of the hierarchy or data model.
However, if metadata is to be shared, it is vital that the system's metadata is exported according to the framework of the PBCore XML Schema Definition. This export may require some transactions or transformations to be conducted on the existing metadata. But when accomplished, the exported metadata becomes a "known" and "validated" data document that a receiving information system can accurately interpret and import into its particular structures and applications.
XML transactions take place on exports from information systems. Likewise, they take place on the import of data into information systems. But at least they are conducting transactions on a commonly defined and understood XML Schema Definition.
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 -