What are Hierarchical Relationships & Element Interdependencies?

Hierarchies & Interdependencies implied in UMAP

The Utah Metadata Application Profile (UMAP) is:

• a set of terms and descriptors (elements)...
• used to create information (metadata)...
• that categorizes or describes...
• media items (sometimes called assets or resources).

In 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:

1. common metadata meanings (semantics),
2. common grammar and rules for expressing data (syntax),
3. commonly defined metadata dictionary element properties (attributes)

The metadata dictionary for UMAP is well documented in this website. The individual pages that define the attributes of each metadata element can be found in the UMAP User Guide.

Beyond a metadata dictionary, 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.

Strictly within its underlying metadata dictionary, UMAP implies no hierarchical relationships (root, branches, leaves). However, when 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, hierarchical relationships and interdependices between UMAP elements are diagrammed 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," and "Elements."

UMAP DESCRIPTION DOCUMENT (aka the MASTER CONTAINER)
The Master Container assembles together all collections of UMAP's knowledge items. For UMAP 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 an XML Schema Definition, the MasterContainer would be referred to as the "UMAPDescriptionDocument."

CONTENT CLASS
In the hierarchy of objects in a UMAP Description Document/Master Container, Content Classes are created as "conceptual wrappers" that logically group together a list or structure of thematically-related Elements (metadata fields and their attributes and properties). UMAP maintains 13 Content Classes as the conceptual wrappers for its various metadata elements. They are outlines and defined in our web page Logical Groupings of UMAP Metadata Elements.

ELEMENT CONTAINERS & SUB-CONTAINERS (aka "branches"):
Elements are objects in UMAP 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).

ELEMENTS (aka "leaves"):
Elements are objects that define a metadata field and its values, semantics, attributes, and properties. 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 example of related Elements bound within an Element Container are four associated UMAP elements named *Copyright status*, *Copyright notice*, *Copyright date* and *Copyright held by*. They are bound together by the Element Container called the *Copyright Group*.

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), UMAP is able to bind together the data found in related elements and keep them that way, like a family traveling together in a bunch; whether they take a plane, a bus, or a train for transportation, they always move together as a unit.

We emulate the illustration of the root, branches and leaves of the IEEE-LOM metadata hierarchies for UMAP. To review the diagram, link to our web page called the Graphical View of UMAP.

When the actual UMAP 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 a Hierarchy Diagram. 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 UMAP 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 a framework that is defined in an XML Schema Defintion or XSD. This export may require some transactions or transformations to be conducted on the existing metadata. But when accomplished, the exported metadata from the source becomes a "known" and "validated" data document that a targeted 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. UMAP is in the process of creating its XML Schema Definition.