Comparison Between PBCore And VMD For Technical Media Metadata

As posted to PBCore Resources

Introduction

VMD stands for Video Metadata and is a schema resulting from the Library of Congress AudioVisual Prototype Project. The documented schema lives at http://lcweb2.loc.gov/mets/Schemas/VMD.xsd and was last updated in 2003. From the annotation in the schema:

“VIDEOMD contains technical metadata that describe a digital video object. It is based upon metadata defined by LC. VIDEOMD contains 36 top-level elements.”

Carl Fleischhauer of the Library of Congress oversaw that activity and he reports that, in the end, the actual digitization was limited to audio and thus the VMD schema was never used by the project. He added that the community’s renewed interest in technical metadata means that this is an excellent time to revisit the topic and consider how best to document the relevant facts about video objects.

PBCore is a schema as well as a set of tools resulting from funding by the Corporation for Public Broadcasting. The documented schema lives at http://www.pbcore.org/PBCore/PBCoreXSD_Ver_1-2-1.xsd and was last updated in February 2009. From http://www.pbcore.org:

“The Public Broadcasting Metadata Dictionary (PBCore) is … a core set of terms and descriptors (elements) … used to create information (metadata) … that categorizes or describes …media items (sometimes called assets or resources).”

VMD and PBCore both contain specifications for technical metadata describing video. Since these “standards” were created at different times within different environments and represent two of only a few available options this blog post offers a comparison of each of their advantages.

VMD is designed to document the technical attributes of a single video object (one video file or one videotape) to be incorporated into a METS document. A METS document may contain multiple VMD instances with structural metadata describing the relationships between them. In contrast to VMD, PBCore is designed to support documentation of multiple video objects and their structure and relationships within a single record. Given these differences, meaningful comparative analysis requires identifying the appropriate level within PBCore to compare with VMD. VMD is roughly the semantic equivalent to the PBCore’s instantiation element and sub-elements which will serve here as the level of comparison.

The objective of performing this analysis is two-fold. First, to highlight some differences that may be helpful to those considering using either one of these schemas, and second, to identify specific strengths and weaknesses, some of which may prove to be valuable points of consideration for future alteration of both standards.

So let’s begin!

Flexibility vs. Control: Man vs. Machine

The design of the PBCore XML schema definition allows for almost all of the values to be expressed as flexible text strings (exceptions to this are ‘language’ and ‘essenceTrackLanguage’ which must be expressed as exactly three letters between ‘a’ and ‘z’). This allows for a field like ‘formatDataRate’ to use “Video 25 megabits/sec”, “Video 3.6 megabytes/sec”, “25 mb/s”, “3.6 MB/s” or “26085067 bytes/second”. Although each of these PBCore values are human-readable and easily understandable, the flexibility allowed in expressing technical data makes it difficult to sort, filter, or evaluate PBCore records from different systems. For instance, if a PBCore record is evaluated to determine if an instantiation is compliant with a broadcast server’s specification, the evaluation process is challenged if one PBCore system says “44.1 kHz” and another says “44100” or one system says “4 Mb/s” while another says “524288”. The equivalent fields in VMD are used solely for the value while the unit of measurement is a fixed aspect of the value’s definition. Phrases that would be mixed into PBCore technical values like ‘ fps’ and ‘ bytes/second’ are not necessary (and not valid) in VMD.

As mentioned, VMD’s XML schema approaches technical data with more constraint. The schema constrains allowable values through validation rules to various data types like integers, text strings, or schema defined data types. The VMD equivalent of PBCore’s ‘formatDataRate’, ‘date_rate’, will not validate unless it is expressed solely as an integer. This restriction enables better interchange and forces the user to a specific manner of expressing data rates rather than stating the value in a unit of measurement within the field itself (PBCore-style).

In general VMD enables greater interoperability because of the constraints on allowable values, but in a few cases the constraints inhibit the entry of valid information. For instance ‘frame_rate’ must be an integer, so frame_rate=”30″ is valid, but frame_rate=”29.97″ is not valid. In this case, PBCore may more accurately represent technical data that requires decimal values, such as “29.97”. Within some organizations VMD has been extended to allow decimal values in place of integers.

Attributes

Both PBCore and VMD utilize XML attributes in order to augment XML data. VMD uses an ID attribute to allow unique identification of XML elements within the VMD document. Thus individual XML elements that may occur multiple times within a VMD record such as ‘compression’, ‘checksum’, ‘material’, and ‘timecode’ may be referred to elsewhere via the ID attribute value. The ID attribute serves a role similar to keys within a database. VMD also uses attributes for identification of an item as analog or digital (similar to PBCore’s use of formatDigital or formatPhysical) and for describing the dimensions of a piece of media.

PBCore 1.2.1 contains one attribute called “version”, an optional attribute to refer to the specific PBCore schema utilized. This attribute may occur within elements of type “pbcore.string.type.base” and “pbcore.threeletterstring.type.base (about half of the PBCore elements).

The use of attributes within these standards accomplishes different goals. PBCore’s version attribute potentially helps in the upgrade process of PBCore records to newer versions of PBCore since the “version” attribute can clarify which release of PBCore applies to the document. Since both VMD and PBCore have moved elements around and changed their definitions with various releases this attribute provide significant value in helping conform records from multiple sources to the current PBCore release.

The use of ID attributes in VMD allows the various elements to be related within a metadata framework. As PBCore user-feedback often points out the need for internal linking inside a PBCore document such as associating a rightsSummary with a specific instantiation or stating that this audienceLevel corresponds to that instantiation but not this one, the application of internal identifiers, such as VMD utilizes, may be worth considering in further PBCore development.

Checksums

Checksums are pertinent to the management of a digital archive and VMD provides a ‘checksum’ element that may contain ‘checksum_datetime’, ‘checksum_type’, and ‘checksum_value’. This allows VMD to document multiple checksum algorithms as applied to a digital object over time.

While PBCore’s schema and document do not directly address checksums, it is feasible that checksum data could be stored in the ‘formatIdentifier’ field (where the checksum algorithm and date is the ‘formatIdentifierSource’) or perhaps as an ‘annotation’. Since the transaction of metadata and content is a key use of PBCore and checksums validate the successful transaction, it is recommended that PBCore users determine or adopt a best practices strategy for handling checksums or that checksum management becomes a consideration of further PBCore development.

EssenceTracks and Compression

PBCore instantiation records contain ‘essenceTrack’ elements to describe the various tracks of a media object, such as video, audio, subtitle, timecode, captioning and more. In contrast VMD records do not document the individual tracks but, more specifically, the types of compression used in the file. Although VMD allows for preservation-orientated values such as ‘codec_creator_app’ and ‘codec_quality’, PBCore’s essenceTrack is more extensive with regard to technical and structural information.

formatGenerations and use

The VMD value for ‘use’ must be either ‘Master’, ‘Service’, ‘Service_High’, ‘Service_Low’, or ‘Preview’. Other values for ‘use’ would invalidate the record. For organizations that do not use this terminology this could be an awkward fit and cause semantic confusion. In contrast, PBCore’s ‘formatGenerations’ value may be any text string and provides an extensive list of suggested values at http://www.pbcore.org/PBCore/picklists/picklist_formatGenerations.html.

Summary

VMD’s XSD is much more prescriptive than PBCore for which values may be used to describe various technical aspects of video. Attractive qualities of VMD include:

•          Fields for documenting checksums, their datetime stamps and types.

•          Fields for documenting the encoding environment, compression quality, and tools that manage encoding/transcoding.

•          Unique IDs for XML elements, enabling some linking where elements are repeatable.

•          More extensive validation enables greater interoperability between systems.

In comparison to VMD, attractive qualities of PBCore include:

•          A metadata structure that more closely mimics audiovisual wrappers (by the instantiation, essenceTrack and annotation elements)

•          Greater degree of flexibility along with a greater capacity for data

•          Extensive recommendations for controlled vocabularies

•          A support system around the schema to provide information to the user on best practices, suggested vocabularies, tools to implement the schema

•          And last but not least – PBCoreresources.org !

Eggs in One Basket?

It’s important as a community to figure out whether there is more value in having two standards to express technical video metadata or one. Maintaining two standards raises many issues. For instance, two issues which affect the compatibility of the two standards are:

•          the scope of technical metadata

•          structural relationship of the metadata’s subjects (asset, instantiation, etc)

However, both VMD and PBCore have advantages over the other in the scope of technical metadata covered by the system. In some environments increased documentation on tracks and annotations may be preferable whereas details on checksums and codec creation environments may be more relevant to another. Either of these standards could be extended to accommodate the advantages of the other (potentially PBCore could already handle VMD’s additions with the definition of best practices for their implementation).

Currently the standards are not interchangeable due to structural reasons and variances in the scope of technical metadata. PBCore is orientated to a fixed relationship between descriptive and technical metadata (a PBCore document must have at least one instantiation and an instantiation must have an asset) whereas VMD is technical only. A strategy that could harmonize these two standards could include defining the PBCore instantiation element itself as its own “mini-standard”. With this approach either VMD or PBCore could accommodate the advantages of the other standard while offering similar implementation strategies.

My hope is that this post offers some insights and generates some discussion in response to these thoughts and questions. In a best case scenario, this may result in some sort of community consensus on a path forward. In the absence of this ideal, I hope that this post offers some thoughts for consideration that will help you, the reader, make an informed decision on selecting a path that best aligns with the goals and needs of your organization.

Dave Rice, AudioVisual Preservation Solutions

thanks to Carl Fleischhauer and Joe Pawletko