Asset Placeholders & Metadata Containers [INT ENT 21.4 ARC]

Motivation

Placeholders are relevant during the planning phase of a contribution or a programme. They are present in the system and can have metadata attached to them w/o physical assets being available, yet. This allows usage of placeholders in the planning process.

Sample usage contexts are:

• Placeholders in MOS rundowns.

• A third-party system issuing a “media request” to the MAM system and expects that this “media request” is filled with an actual asset (= VidiCore item) at some point-of-time in the future. The third party system needs feedback on the creation process of the actual asset.

Concepts

Metadata Containers

Metadata containers are objects which only contain metadata but no physical assets. They are used to attach metadata to actual assets w/o storing the metadata values directly at the asset. Different types of relations between metadata holders and assets are possible:

• 1:N – E.g. associate series metadata with several physical files/episodes.

• N:1 – The same file is planned in different systems with different metadata (e.g. a service provider serving different TV stations with the same material).

Metadata containers are modelled as VidiCore collections. The VidiCore collection which models the placeholder is created first for storing all relevant metadata. As soon as the actual ingest begins an item is created and put into the metadata container collection to inherit the metadata from there. The ingest process itself can be a feed ingest (where the VidiCore item represents the concrete ingest request) or a file upload or a publishing process from VidiEditor/EditMate or any other way an item comes into the system.

1:N-Relations

1:N-relations could easily be modelled by using VidiCore collections an inheritable metadata:

• A VidiCore collection is used for the metadata holder.

• Metadata groups attached to the collection are defined as inheritable.

• All items in the collection automatically inherit the metadata groups from the collection via VidiCore -internal mechanisms.

• Inherited metadata fields or groups can be overridden on item level in VidiCore.

N:1-Relations

TBD

Out-Of-Scope

Systems that only are used for creating feed ingests (cross point source, start time, end time, etc.) can directly create the recordings as VidiCore items (see Recording Placeholder [INT ENT 21.4 ARC]).

The same applies to data migrations from other systems into an Enterprise MAM Solution: in migration scenarios the asset should be directly created as VidiCore item – even if the physical file is not yet accessible by the Enterprise MAM/VidiCore.

Structure And Defined Metadata Fields

The metadata field  V3_CollectionType (see Collection Types [INT ENT 21.4 ARC]) is set to MetadataContainer to clearly identify collections that only hold the metadata for one or more assets that will be created at a later stage.

All metadata values (fields and groups) need to be put into a separate field group dedicated to this purpose. Only this field group will be marked as inheritable, but not necessarily the fields or subgroups in this group. This ensures that inheritance only takes place in the context of MetadataContainer collections. In cases you different scenarios for using MetadataContainer collections in your system you can define different inheritance rules for each scenario by using different inheritable field groups. User interfaces (e.g. MediaPortal, EditMate) should hide this group structure as its only purpose is to define inheritance; the group contents would be display as if the fields and subgroups where directly attached to the item.

The ID of the placeholder in the external systems (e.g. planning system) shall be stored as VidiCore external ID on the MetadataContainer collection (do not use a metadata field for that).

In some scenarios the MetadataContainer collection may contain several items, but only one of these items is relevant for delivery. The ID of this “relevant” item is stored in the representativeItems metadata field on collection level. Via the representativeItems value a third party system can retrieve which item to use for further processing.

The metadata field V3_MediaState on the MetadataContainer collection can be used to reflect the current state of the ingest process on collection level. The concrete values need to be defined in project context. Reflecting the state of the concrete item to the MetadataContainer collection can be implemented via a workflow triggered by metadata changes on item level.

Typical Use-Cases For Asset Placeholders

Asset Placeholder Filled Via Feed Ingest

• MetadataContainer collection is created and all relevant inheritable metadata groups (and non-inheritable fields and groups) are set on the collection.

• VidiCore placeholder item is created with all metadata as defined for recording placeholders (see Recording Placeholder [INT ENT 21.4 ARC]).

• Placeholder item is put into the MetadataContainer collection.

Asset Placeholder Filled Via File Upload

• MetadataContainer collection is created and all relevant inheritable metadata groups (and non-inheritable fields and groups) are set on the collection.

• User uploads a file (via any UI suitable for that)

• User selects MetadataContainer collection and the UI puts the newly uploaded file into the MetadataContainer collection.

Asset Placeholder Filled Via Publishing From VidiEditor/EditMate

• MetadataContainer collection is created and all relevant inheritable metadata groups (and non-inheritable fields and groups) are set on the collection.

• User publishes file (via editing application)

• User selects MetadataContainer collection and the editing application puts the newly uploaded file into the MetadataContainer collection.

Asset Placeholder Filled Via Semi-Automatic (Workflow with Human Tasks)

• MetadataContainer collection is created and all relevant inheritable metadata groups (and non-inheritable fields and groups) are set on the collection.

• When a new asset is created as VidiCore item, a workflow is triggered that tries to find a matching MetadataContainer collection. If successful, the workflow puts the item into the MetadataContainer collection.

• Otherwise, a human task allows a user to perform a manual selection of the MetadataContainer collection  for the item.

Asset Placeholder Filled Via Manual Assignment (UI)

• MetadataContainer collection is created and all relevant inheritable metadata groups (and non-inheritable fields and groups) are set on the collection.

• A user interface allows the user to select an item and and MetadataContainer collection. The  UI puts the newly uploaded file into the MetadataContainer collection.