麻豆社

From the team who brought you , we are pleased to announce the alpha release of . TADS is an API specification for reading, writing, and editing timeline data in a store. Just like TAMS, TADS is designed to be open, interoperable, and cloud-native.

TADS is for timeline data

Modern media workflows benefit from a rapidly increasing assortment of data about content, whether manually or machine-generated: logging, transcripts, shot-changes, and person identification to name but a few, all linked to the content timeline.

This data is essential to production processes: helping creative teams find the best content and tell the most engaging stories, while making their workflows smarter and more efficient. And increasingly, data drives personalised audience-facing experiences such as 麻豆社 R&D's work on Chapters & Key Moments on 麻豆社 iPlayer or our SIGNALS interactivity layer.

However, the ecosystem supporting this data is fragmented. The challenge of integrating disparate systems results in content being transcribed for every team that accesses it, a break in content history whenever an edited programme is rendered, and valuable insights lost or limited in scope.

TADS aims to:

• nurture an open ecosystem for timeline data by providing a common integration point
• do for data what TAMS has done for media, by building on similar principles
• support timeline data for all content, whether in archive systems, file-based MAMs, or TAMS

Working with the industry

We want to work with the community from the start to develop a solution for timeline data storage, continuing the open and interoperable approach of the TAMS ecosystem.

As an alpha specification, TADS is still in the 鈥渞esearch鈥� phase. As such, we intend to maintain this specification (and any associated resources) as 麻豆社 R&D for the near term. But we anticipate that our ability to draw on many years of TAMS development and a shared need for this technology in the industry will allow us to move rapidly towards a stable core specification. Once we and the community deem it appropriate, we鈥檒l revisit the ownership of the TADS specification and explore options for host organisations.

How TADS works

TADS allows you to create Tracks and store data Events on them. Each Track shares a timeline with a media item in another system, such as TAMS or a file system.

Event payloads are formatted as JSON. Each Track is associated with a managed Payload Schema, that uses . TADS validates each new Event against this Payload Schema. Many common data workflows require Events that overlap on the timeline (e.g. tracking visibility of actors in a video) and the editing of Events (e.g. progressive improvements to transcripts). TADS supports both.

The TADS API provides similar mechanisms to TAMS for managing items in the store and receiving updates via Webhooks.

Why not use TAMS for data?

The current rapid deployment of TAMS at scale in multiple businesses has resulted in significant interest in the question of where to store data that isn鈥檛 suitable for storage in TAMS.

When we first open-sourced TAMS, we made . The primary driving factors being the size of the data and the access patterns. It doesn鈥檛 make sense to store data which is significantly smaller than the metadata TAMS stores about it. The indirect access of Media Objects via URLs is inefficient for many forms of data. And the inability to search by the data itself limits the applicable use cases.

TADS aims to solve these issues by better supporting the storing of data in a database rather than object storage. It returns data directly in Events listings. And it better supports search index systems.

While the data models of TADS and TAMS contain some similar concepts, the requirement in TADS for the editing and overlapping of Events breaks important TAMS principles: immutability, and the use of a timerange to uniquely refer to a specific sequence of content.

Building an ecosystem

Using common, open foundations offers agility in media supply chains. It enables organisations (such as the 麻豆社) to make the best use of new capabilities to meet the demands of their audiences, while retaining control of their data, and enables systems that generate metadata to integrate more widely with workflows.

TADS is an API specification for reading, writing, and editing timeline data in a store. We expect it to be used alongside TAMS and other systems. How will all of these systems fit together, and what is missing from the current alpha release of TADS?

Searching by data

Our working assumption is that indexing and search systems are separable from the TADS API, allowing the unique requirements of each data type to be met. However, it鈥檚 important that they work effectively together.

• Are architecture recommendations needed for connecting the TADS API and indexing/search systems?
• Should the TADS API provide data query facilities directly?

Integrating with other schema stores

TADS includes a Payload Schemas solution in its initial release, but we鈥檙e aware that mature business workflows may have their own schema management.

• Should the built-in Payload Schemas solution be an optional part of TADS?
• When schemas are stored in an external system, what鈥檚 the best approach to harmonising Track and schema lifecycles and ensuring TADS reliability?

Describing rich relationships between Tracks and with content

Many workflows need to capture complex relationships, for example, to relate data to content, to group data Tracks to be used together (like with Sources and multi-essence collections in TAMS), or to capture ancestry.

• Is it best to include these relationships in TADS?
• Should the mechanism be generic or tailored to specific use cases?

Integrating with data-driven workflows

TADS has the potential to enable interoperable, data-driven workflows. Expressing the 鈥渄ata contracts鈥� between workflow processes using TADS will be important.

• Which topics should be within the scope of TADS? Perhaps characteristics of Events (overlaps, gaps), nature of the data (purpose, audience, status), or its management (provenance, editing controls, versioning).
• Are built-in Track properties the best approach, or will the requirements be use case specific?

Using TADS alongside TAMS

TADS is well-suited to managing data that annotates media held in TAMS. We have provided initial recommendations for such integrations in . But further recommendations are required for more advanced use cases.

• How are the authorisation of media and data tied together?
• How is TADS data used with TAMS edit-by-reference workflows?

TADS is an alpha specification and will change rapidly in the short term. We are keen to work with the TAMS community and other interested parties to iterate on this first draft, addressing the list of questions above and more. If you鈥檇 like to be a part of this, we鈥檇 love to hear from you! Please contact us via the on the TAMS Slack space, via email at cloudfit-opensource@rd.bbc.co.uk, or .