All Vidispine Enterprise MAM products build on the metadata model defined and implemented by VidiCore. All possibilities and the technical details around it are documented in VidiCore’s APIdoc. This page focuses on the metadata model as used in the Enterprise MAM products VidiFlow, VidiEditor, MediaEditor, and EditMate.

Fields

Metadata are stored in fields. Fields are typed and can have one of the data types listed in APIdoc. Depending on the data type the field values can be restricted in a certain way. By default, fields are searchable which means that their values are replicated to the VidiCore search index on Elasticsearch. Marking fields as not searchable where applicable helps reducing the size of the VidiCore search index.

VidiCore distinguishes between three different types of metadata fields: user-defined metadata, system-defined metadata, and transient metadata.

User-Defined Metadata

User-defined metadata can be configured depending on the concrete needs of the system to build. They are stored in the VidiCore database as entities of their own and can be attached to items, collections, and further top-level entities of VidiCore.

VidiCore imposes certain rules on the field names which are respected by the Enterprise MAM Solution. By convention, all user-defined metadata fields in Enterprise MAM start the the prefix V3_.

In Enterprise MAM all fields and their properties can be configured in ConfigPortal:

Open

Different Enterprise MAM products come with pre-defined product-specific metadata. From VidiCore’s perspective these are user-defined, too. By convention, these fields start with a two-character prefix denoting the product:

These fields cannot be changed in ConfigPortal but are listed as read-only and can be used for further configuration aspects (e.g. metadata masks for front-end applications).

Example showing the Enterprise MAM standard metadata field V3_Hidden:

System-Defined Metadata

System-defined metadata are pre-defined by VidiCore. Their definitions cannot be changed. With the single exception of the title field also their values cannot be changed. Only VidiCore itself can set the values.

System-defined metadata are also stored in the VidiCore database as entities of their own. They cannot be changed in ConfigPortal but are listed as read-only and can be used for further configuration aspects (e.g. metadata masks for front-end applications).

A complete list of system-defined metadata is available in VidiCore APIdoc.

Example showing the system-defined metadata title and shapeTag:

Transient Metadata

Transient metadata are not stored in the VidiCore database as separate entities. Instead, they are derived from other information in the database and only returned in the structure of metadata fields whenever metadata for an item or collection are fetched via the API. They cannot be changed in ConfigPortal but are listed as read-only and can be used for further configuration aspects (e.g. metadata masks for front-end applications).

Transient metadata always are searchable.

A complete list of transient metadata is available in VidiCore APIdoc.

Example showing several transient metadata:

Fields With Multiple Values

Fields can have multiple values, too. This makes sense for certain system-defined fields like shapeTagwhich may have multiple values if the item contains multiple shapes. It may also be used for modelling tags.

Example showing a field with multiple values:

Groups

Groups allow structuring metadata. Groups may contain one or more fields. Groups can also contain other groups as subgroups to build a hierarchical structure.

Open

Example:

Timespans

When attaching metadata fields or groups to an item or a collection, there’s always a timespan in between. The timespan describes which part of the items or collections timeline the metadata refer to.

A timespan consists of a start time code and and end time code in the standard VidiCore notation. Both time codes are relative to the start of the visible portion of the asset. The start time code is inclusive whereas the end time code is exclusive so that start and end time code denote a half-open interval [start,end).

The generic timespan [-INF,+INF) denotes the complete item or collection.

Items And Collections

Metadata fields and groups can be attached to VidiCore items and VidiCore collections in the same way.

Metadata Inheritance

Metadata fields and groups can be marked as inheritable. When such fields and groups are attached to a collection, VidiCore will automatically inherit them to all items in this collection. If a child collection is placed into a parent collection, all inheritable metadata from the parent collection will be inherited to the child collection(s) recursively to all child-collections and the items in them.

Inheritance can be broken by setting a field value directly on an item or a sub-collection. If you set the the V3_Programme field on ITEM-VX-42 to Another Universe explicitly the value Our Universe originally inherited from COLLECTION-VX-17 will not be available on ITEM-VX-42 any more:

Metadata References

Instead of directly settings the values of a metadata field or group you can also refer to a field or group value on an existing item, collection, or document by using weak references.

These weak references have the effect that metadata changes on the source field/group are automatically reflected to the destination field/group.

When retrieving metadata for items or collections the values coming to that item/collection via weak references look exactly the same if they were set directly on the item. Only the additional element <referenced> on the field or group value tells you that this is a weak reference:

Searching for these metadata works exactly the same way as if the values were set directly on the item/collection.

Further details can be found in VidiCore APIdoc.

Document Metadata

VidiCore metadata is most cases are attached to items and collections as described above. For some scenarios it may be useful, however, to store metadata documents outside of items or collections in a more global manner.

For this purpose VidiCore offers document metadata. Document metadata are a key-value storage where the key is an arbitrary string and the value is a VidiCore MetadataDocument. These documents can server as storage for system-wide information. You can refer to metadata stored in documents via weak references as described in the previous section.

A small caveat with document metadata is that the keys are not generated automatically (as with item or collections ids), so you need to define your own naming scheme to avoid conflicts with all applications connecting to the same VidiCore.

Enums

Enums are defined as fields where the user can only select from a pre-defined set of values. Multiple enums can depend on each other: the value selected in one enum may restrict the possible values in another enum.

Let’s assume our system has configured the enums V3_Country and V3_City. Both have their possible set of values:

When Germany is set on V3_Country the possible values for V3_City are restricted to Cologne and Gütersloh:

When selecting Malaysia as country the allow values for V3_City changes:

Enums are modelled as metadata data sets in VidiCore. The VidiCore API ensures that the restrictions of the data sets are met for every change on such fields.

Extending Enums With Additional Data

In some scenarios you need additional data on each value of an enum field. An example is a list of sports teams where the user can select a specific team from a list of teams. The team selection would be via a regular enum metadata field. The enum key would be a (technical) team id (e.g. basketball-tor for the Toronto Raptors basketball team), the enum value would be a display string for this team (e.g. “Toronto Raptors (TOR)”).

All additional information on the team (e.g. home stadium, sponsor names, etc.) can be stored in VidiCore document metadata. The enum key is used as the name of the document. All further information is stored as regular VidiCore metadata on this document.

When the user selects “Toronto Raptors (TOR)”)  from the enum, the enum key would be basketball-tor. This key can be used to directly look up the corresponding document via

to retrieve the whole metadata document associated with this team.

The metadata groups or fields in this document can either be copied to an item or a collection – or a metadata reference can be used to link the document to an item or collection.