How to model multiple Episodevariants (aka Programmevariants)?

[rudniclopac]

Hello everyone.

We are currently exploring and implementing EBUCorePlus at SRG SSR and have the following question:

What is the best way to model different variants of the same programme?

As an example: We have the main daily news programme "Tagesschau", which is published on several publishing platforms (e.g. once as a 'normal' broadcast version and once as an HBBTV and VOD version (PlaySRF)). The different versions may differ in terms of length and number of items, e.g. due to legal requirements. In principle, however, the same editorial object (i.e. the programme) is always referred to. This is a 1-n relationship between programme and essence/media resource.

-> How does EBUCorePlus model the different variants and their relationships between Programmes, PublicationEvents and the MediaResources/Essence? versionOf? existsAs'?

Regards

Curdin

[rudniclopac]

@JuergenGrupp Is there any update on this issue?

[JuergenGrupp]

... answer is planned until October 13, 2023

[JuergenGrupp]

Two variants are different in one or more of the following aspects

• the two physical representations (in EBUCorePlus "Essences") are different (eg. encoding, format, resolution)
• a consumer would observe differences in the two pieces (eg. scenes are removed to shorten the piece)
• the two pieces differ in intellectual property rights (eg. different speakers for the same video, different soundtrack)
• the two pieces differ in publishing rights (eg. g. scenes are removed, sequences are covered for legal reasons )

How to deal with these cases in EBUCorePlus? When do we need to create additional individuals of Essence, when of EditorialObjects for a variant? Here's the proposed guideline:

1) One EditorialObject, many Essences This is only the case, if there is no consumer observable difference in the content (except for resolution). The variants are then distinguishable by the attributes of the Essence.

2) Many EditorialObjects, each one with one to many Essences Whenever there is a change in either observability, intellectual property rights oder publishing rights, an EditorialObject is needed on its own and can be linked to the source EditorialObject with "isVersionOf" (or equally the other way around with the inverse property "hasVersion"). The new EditorialObject can then be categorized with the property "versionType" (property type is skos:concept). (Please note: There is no generic usable vocabulary for versionType, you have to create your own skos:concept Scheme)

Is this guideline applicable for your use case? Please comment!

[rudniclopac]

Hi Jürgen, thanks for your explications, which perfectly describes our issue! Thanks for your help!