Video metadata modeling for DAM systems

Abstract

Video content managers using a Digital Asset Management (DAM) to provide access to thousands or even millions of hours of digital footage will require a well-structured metadata architecture. Beyond basic search and retrieval, video metadata for a fully operational DAM must support a wide range of functions: from tagging and ingesting to transcoding and distributing derivative formats. Crafting a sound video metadata strategy depends on the development of a metadata schema, on documentation of a data dictionary and on the establishment of standards for inbound and outbound A/V formats. This detailed review of these areas aims to assist DAM teams to develop solutions that provide lasting value to their organizations and to avoid committing crucial mistakes that may take years to recover from.

INTRODUCTION

Metadata as a concept has its roots in the computer science community. In fact, Jack Myers trademarked the term in 1986 (unhyphenated with initial capital) for his technology services company.¹ However, with the proliferation of digital media, the meaning of metadata, in practice, now varies considerably by discipline. In the context of Digital Asset Management (DAM), metadata is defined as: information that describes a media asset stored in a digital repository. Because metadata is structured information, it allows the distribution of digital assets to be controlled while at the same time making them accessible (via search) to a wide community of end users.

For most organizations, a major component of the ROI in funding a DAM system is the ability to efficiently expose and distribute large collections of digital content to key audiences (both internal teams and external constituencies). Although it is sometimes taken for granted by the developers of DAM systems, these media content management systems require highly structured metadata to fulfill this goal. That is, without a well-structured metadata architecture, these systems rarely achieve their intended purpose.

For a nascent collection of digital video, cataloguing and distribution are perhaps achievable (if inefficient) without well-structured metadata. However, as the volume of assets in a collection grows into the thousands and even millions of assets, so does the importance of detailed metadata and well-structured indexing and search tools. Beyond basic search and retrieval, video metadata solutions must support a range of functions in a fully operational DAM system. This includes access control, transcoding of assets to derivative formats and automated distribution to the web. In essence, all of the functions required in order to ingest, store, manage, share, distribute and preserve the video over time (Figure 1).

Figure 1

ROI through expanded access.

THE ROLE OF ‘MASTER’ FORMATS, DERIVATIVES AND PROXIES

A fundamental DAM strategy is to utilize the repository as a source for ‘master’ digital assets that can be rendered (on-demand) into a variety of compressed video formats for viewing and distribution as needed. Before we dive deeper into the specifics of video metadata, let's review the role of

• a) ‘master’ formats for assets imported into the DAM;

• b) derivatives formats for distribution to a wide variety of receivers such as educators, researchers and other external end-users.

In the case of video, the preservation ‘master’ will be identical to the original raw file (or as highly faithful as possible) while the distribution renditions may be low-res QuickTime or Flash versions for distribution on the web. Figure 2 provides examples of parameters used when converting master video assets in the DAM to compressed video derivatives for distribution:

Figure 2

Compressed video encoding parameters – video details.

The identification of ‘format standards’ for inbound video assets is also essential in the early stages of the DAM. These standards will set expectations and communicate requirements to video content managers seeking to migrate their video collections and content into the DAM. For example,

• 1 Will there be a set of accepted ‘Master’ formats for import of A/V assets into DAM?

• 2 What low-resolution ‘proxy’ formats be used for previewing video assets and thumbnail generation in DAM interface?

In the case of archived analog video assets, these must be encoded or digitized before import to the DAM and the ingest standards (such as MPEG2 50 mbs iFrame or Motion JPEG 2000) must define which formats will be accepted by the DAM.

‘Born digital’ video assets originate in a variety of hi-resolution formats and data rates (ranging from 25 to 50 mbs depending on the camera used) any of which may be accepted as raw file formats for the DAM (see Figure 3 for example).²

Figure 3

Formats accepted as raw file formats for the DAM.

A closer look at ‘what's in metadata for dam systems?’

With the question of formats addressed, DAM managers must next communicate a plan for capturing the metadata associated with video assets to the videographers and video content managers in the user community. In a DAM system, the structure of the metadata has two basic components.

• First are the sets of metadata elements themselves. When arranged into categories, this is typically referred to as the metadata schema.

• Second are the specific values and syntax allowed for each individual metadata elements. Some elements, such as ‘video producer’ may be a free text field: that is, no limit is placed on the names that users may enter in this field. Other elements, such as ‘origination format’, might be ‘closed’, with a predetermined list of approved values from which DAM users who are tagging an asset must choose. In the latter case, the list of approved values is referred to as a controlled vocabulary.

As the content in the DAM builds, the use of taxonomies and thesauri for enabling search performance and federated views into content management will also be a key aspect of the metadata architecture. The following ‘Overview’ (Figure 4) provides an excerpt from a recent video metadata planning project in which the wide range of metadata elements are grouped into categories such as Technical, Descriptive, Administrative:

Figure 4

Excerpt from a recent video metadata planning project.

So … what types of video metadata should I focus on?

Early on in the process of developing a video metadata model, this question inevitably surfaces: ‘So … which video metadata am I going to need for my assets?’ The answer, not surprisingly, raises the question of what the metadata is intended to accomplish. Organizations invariably have urgent needs that drive the creation of a DAM system. The metadata schema, in turn, must be responsive to those goals. Each of the categories described below focuses on utilizing metadata to achieve a specific function or set of functions in the DAM.

At this early stage in the planning process, the pros and cons of conforming to an existing metadata standard are often discussed. Widely known standards such as Dublin Core and METS frequently come into play, as do video-centric schema such as PBCore, MPEG-7 or EBU Core. In fact, managers of digital content are faced with a constantly shifting variety of standards for developing a video metadata solutions. Although the wealth of standards provides many viable options for video repositories to consider, the lack of a dominant standard for video content undermines consistency across institutions. In addition, each institution has its own unique needs and practices that must be accounted for in the metadata schema. What results is adoption of a unique blend of custom fields, often drawing on well-known standards as important inputs to the final form. Conforming to the basic premise of an existing standard when crafting a video metadata strategy helps to achieve a worthwhile solution (that will provides great value to the organization) and to avoid committing crucial mistakes that may take years to recover from.

In all but the rarest cases, supporting the ‘discovery’ and retrieval of assets by users with descriptive metadata will be a core requirement for the DAM. Other important categories include Administrative, Security and Rights Metadata, Technical and the Digital provenance of the asset. Let's review these categories one at a time:

Descriptive metadata

How will users search for, find and access the digital video assets in your DAM? For this to occur, a range of descriptive metadata will be necessary.

This will encompass such elements as seen in Figure 5.

Figure 5

Descriptive metadata.

Video logging of raw footage adds another layer of complexity to descriptive video metadata. Depending on the capabilities of the DAM, scene-level logging information may live as text in a metadata field, as independent text files that are linked to the video content or in video logging software that is integrated into the repository.

Administrative metadata

In many cases, descriptive metadata overlaps with administrative elements that contribute to efficient search and retrieval as well as supporting basic management and control of assets within the repository. For example, these administrative elements may include those listed in Figure 6.

Figure 6

Administrative metadata.

Technical metadata

Because of the large file sizes and the complexities of editing A/V formats, technical metadata is particularly important. Key elements include the original format that the video was created in, aspect ratio, encoding formats and so on (see Figure 7).

Figure 7

Technical metadata.

When describing the ‘origination format’ of a video asset, a controlled vocabulary will provide users with the ability to consistently tag and effectively search for a given format. Without a controlled list of specific terms, human variation in referring to video formats prevents effective search and retrieval. For example, an authority list of resource types may be found in the Metadata Object Description Schema³ and may include the following types:

• Betacam

• Betacam SP

• Betacam IMX

• Betamax

• DigiBeta

• DV – Standard Definition

• DV – High Definition

• DV Mini

• DVCAM Standard Definition

• DVCAM High Definition

• DVCPRO – 50 MB/S

• DVCPRO – 100 MB/S

• DVD Video

• Flash

• HDCAM

• HDV

• Hi 8

• MPEG

• Real Media

• QuickTime

• SDCAM-SR

• VHS

• Windows Media

• XDCAM

In addition, in cases where a video asset has undergone a series of conversions, for example an original 16-mm film converted to ¾ inch and later to DVD video, this may be captures in a coding history or digital provenance record.

Security and rights management metadata

Intertwined with asset control, management and distribution are metadata fields related to security controls, usage restrictions and rights constraints. Given that DAM implementations often seek to facilitate the automated distribution of media assets to the web, detailed security controls and rights-related restrictions are a vital component of the metadata strategy. Most DAM tools include some form of customizable security ‘policies’ which govern access to assets (based user ID, role and/or membership in user groups). Policies may control not only which users can access an asset, but which actions or permissions they are granted (that is, view, alter, tag with metadata, download, export assets and so on). Beyond these security tools that are integrated into most DAM systems, useful security-related metadata fields may include those shown in Figure 8.

Figure 8

Useful security-related metadata fields.

It's important to note that Rights Management metadata alone is an area of specialization. Many organizations require the development of a complex and in-depth metadata strategy just for managing rights. This may be accompanied by the deployment of dedicated Rights Management software that is integrated into the DAM to govern the distribution of assets. In lieu of that, a Rights Category in the video metadata schema will afford a minimum of control and information sharing about the rights constraints and usage restrictions for digital video content (Figure 9).

Figure 9

Rights category in the video metadata.

A given collection may be dominated by usage constraints related to expiration time frames, geographic restrictions (for example, for domestic use only), channel restrictions (not for use in online media), language restrictions and so on. Additional fields may be created based on the frequency of these dimensions in the downstream distribution of the video content.

Structural metadata

This category of metadata is applied to complex objects. That is, objects that are made up of numerous component parts. For example, an eBook which contains a series of interview clips or still images. When assembled, these components comprise a long-form documentary. The structural metadata communicates the sequence or placement of individual clips and still images within the complex larger whole. Structural metadata covers both hierarchical relationships (chapters, sections, scenes) and the sequence or order within the larger whole (Figure 10).

Figure 10

Structural metadata.

VIDEO METADATA AND USER ADOPTION

A scan across all of these categories of metadata for video content indicates that a thorough video metadata solution will encompass dozens of metadata elements. This poses a challenge for the architects of metadata solutions; the need to address as many information requirements as possible must be balanced against the impact of a large metadata schema with numerous complex fields on user experience.

In many DAM solutions, media teams and other content developers will be required to import assets into the repository without assistance from cataloguers or metadata specialists. Without caution, one's robust metadata schema will engender mass rebellion in the ranks of users. One approach to addressing this challenge is offered by most DAM solutions. For example, if the preferences and templates tools in the DAM software can be used to govern the presentation of individual metadata elements at the user level then templates may be developed to present only a relevant sub-set of fields based on the needs of each functional role. In fact, this type of flexibility in personalizing the user interface (UI) display of metadata is a key factor in the selection process for DAM software, as is the ability to create an extensible, XML-based metadata schema that can be used for bulk import and export. These may seem like ‘nice to haves’ when you first examine rival DAM solutions; however, over time the usefulness of an XML-based representation of your metadata cannot be overestimated – particularly for automating interaction between the DAM and (1) other content management systems and (2) web-based distribution channels.

From a user adoption perspective, these templates are an essential tool to mitigating overwhelming users with metadata requirements and complexity. In essence, users are shielded from being overburdened with metadata complexities through the personalized display of sub-sets of the complete metadata schema. These sub-sets are deployed as templates to users based on reasonable expectations and their own personal experiences with what is necessary and meaningful to them as users. Another technique is to carefully screen and limit the number of required metadata elements in the import process and to increase the number of fields in which metadata is automatically tagged to assets by the system rather than being manually keyed in by humans.

METADATA DICTIONARIES AND WORKFLOW DOCUMENTATION

Again, looking past the design and implementation of the metadata schema, we must recognize that training among the community of users is another key to success. Both in-person training sessions and accessible documentation are required. These tools must clearly communicate how the DAM can improve productivity in the context of daily workflows.

One such piece of documentation will be a Metadata Dictionary. In the Dictionary, the purpose of each metadata element must be defined (in non-technical terms), sample values and examples must be provided, and any applicable rules for the ‘syntax’ to be used when populating the field must be identified. The table in figure 11 also provides users with an understanding of the input method by which it is populated in the DAM software (that is, will the information be manually keyed in by users or auto-tagged to the assets by the DAM software) and any other scope notes detailing the properties of the field such as whether it is a required field during the import process or which value it defaults to in drop-down list. For an example of a well-constructed Metadata Dictionary, consult the PREMIS Data Dictionary (available at www.loc.gov/standards/premis/v2/premis-2-0.pdf).

The excerpts in Figure 11 present examples of individual elements and how they are defined in a ‘training-oriented’ Metadata Dictionary:

Figure 11

Example metadata element description.

At a more technical level, additional properties of each metadata field (such as the field length and data type) are documented in more detail before configuration in the DAM, Quality Assurance (QA) and pilot usage among representatives from user community (Figure 12).

Figure 12

Additional properties of each metadata field.

CONCLUSIONS

Managing large collections of video content and enabling efficient access to those assets depends on the decisions you will make in the metadata modeling process.

Exposing draft metadata models to your community of users early in the process will be critical to your success. Once configured in the DAM, exposure of the model in a ‘pilot’ context is equally important before you begin importing large quantities of assets. In essence, actively seeking user input throughout the process will yield insights into successes and shortcomings of your metadata architecture. With that knowledge in hand, you begin the iterative process that leads to the optimal solutions (and compromises) for your user community. This is particularly true in the case where the DAM will be used by multiple departments or groups of users. Facilitating consensus across these teams may take several sessions to achieve, but will resolve many of the key questions you face in the model development process and benefit the DAM in the long run.