Cubix has a key feature where content hierarchies can be created – e.g. an episodic hierarchy would be normally 3 tiers – Product / Series / Episode. The metadata schema then configured based around the Tiers of the hierarchy – with fields definable at each layer. These metadata fields can be strings, date ranges, key value pairs (e.g. actor name and character name), tables, dropdowns and more. The fields can also be offered in multiple languages. The metadata then by default inherits down the hierarchy – so that when an asset is tagged under the final tier – it effectively “looks up” through the hierarchy to see all the metadata relevant to them.
A key benefit to this system is that metadata is only entered once – something which provides dividends when working with products that have 100s of episodes. Metadata can also override – so at a lower level, if a value needs to be overridden for that specific node and any subsequent child nodes – it can be. It also provides an naturally asynchronous repository for metadata – where it is not always known what will come first – media or metadata.
All these hierarchies and metadata fields in Cubix are defined on a “per company” basis – which means different companies (and the users therein) working with the content can see different schemas or scopes of schema. This provides natural flexibility for limiting what companies or divisions can see what metadata. The client portals dynamically react to the configured schemas too.
This metadata is then used as a source for OVP / VoD deliveries, or for simply producing sidecar XML files – as well as being accessible via the API / MRSS – so useful for iEPG requirements too.