You may also be interested in:

Media Asset Management systems are a fundamental element of the broadcast media supply chain. Although systems for news, delivery, production and archiving have many shared core technologies, each has evolved its own nuanced functionality to fit workflow demands. Many vendors offer different applications accordingly. This guide explores the fundamental principles of Media Asset Management system design and implementation with a firm eye on production and archiving... but many of the standards and best practices discussed here apply across all MAM systems.

Media Asset Management systems can become more complex as they evolve. The key to achieving long term success lies in a solid understanding of the underlying technology, design principles and terminology. Careful consideration of the scope of the system and following established standards and protocols which will streamline future expansion is critical.

Managing assets becomes a bigger and more complex task as the scope and scale of ingested content increases. AI provides leverage when wrangling these huge quantities of media assets, but knowing what happens under the hood of an asset management system is key to deploying it successfully.

Designing An End-To-End Content Manager

The architectural design of a truly end-to-end content system needs to accommodate the entire lifecycle from ingest to archiving taking deployment into account along the way.

Study the metadata required by each stage of the process to start with. Then isolate the core items that are important everywhere. The core items define the columns required in the spine table.

Then each of the specialized contexts will determine what needs to be implemented in a set of role tables that are attached to the spine when needed. The connection uses SQL joins based on the primary key value.

This is a very conventional database design technique and used in many database project designs.

Spine Table

Examine the Dublin Core specifications when developing the structure of your spine table.  The schema in the table below describes 15 basic properties for media assets. 

Clearly some of these values can be broken out to multiple sub-fields. Introducing extra columns is preferable to creating delimited content within a single field. Creating compound fields makes search queries more complex. The Dublin Core specification only describes a minimum level of functionality necessary for interoperation between different systems. It is often extended by proprietary implementations.

For example, Creation date can be augmented with a time value. The format field could be separated into:

• File format.
• Codec.
• Coding parameters.
• Bit-rate.
• Duration.
• Multi-track audio arrangement.

Additional fields can also be introduced. These might be helpful:

• Asset modification date.
• User ID who created the assets.
• User ID who most recently modified the asset.
• Published date.

Relational Role Tables To Support The Whole Lifecycle

Each stage of the production lifecycle needs to be supported. They all depend on a storage system. There is no need to create more than one repository but the metadata will benefit from some partitioning.

Build the role tables around each stage of the lifecycle. Clearly the program editors are not involved in licenses and marketing issues so their tools would not need to join with those role tables. They would need access to the ingested content, titles and slates and anything else that they could potentially import into an NLE.

These supporting roles would often be managed within a librarian application. Historically, Proximity Artbox was a good design. So good in fact that Apple purchased it as the foundation of the Final Cut Server librarian. That supported a very large number of metadata properties for each entity. Final Cut Server could extract assets based on queries and assemble them into containers formatted as Final Cut projects and then open the NLE with that project ready to edit. Final Cut Server is now discontinued but its implementation can inform our designs.

BBC News developed the Jupiter system to manage an entirely file-based workflow for news production. Around 2004 a design study for a ‘BBC Desktop of the future’ examined how to integrate the Jupiter workflow, ENPS and the News Online web content for News staff and present them in a unified user interface.

We should not deem any of these projects to be failures if they don’t survive for more than a few years. They are all incremental steps on a long journey and we learn a great deal from building and running each one. That knowledge is hard won and carried forward to extend and improve the architectural design of the next generation.

Employing Skilled Database Professionals Is Important

Skilled database specialists are needed to put this together or manage an off-the-shelf foundation. They will add features you might never think of based on their knowledge and experience. This is particularly important when creating queries to search the database. Subtle problems are only solved with advanced SQL techniques. Such as:

In Part 3 we consider integrating multiple systems and the pros and cons of off-the-shelf Vs bespoke systems.